Current Meeting Report
Slides


2.6.5 MPLS Maintenance Mechanisms (mplsoam) Bof

Current Meeting Report

MPLS Maintenance Mechanisms BOF December 11, 2001 52nd IETF meeting, Salt Lake City
2.15 pm to 3.15 pm, Room: Imperial C

Minutes recorded by Ananth Nagarajan


1. Introduction and Agenda

Shahram Davari did the introduction. Requests Q&A to be kept to the end.

Peter presented - What sort of OAM does MPLS need?

MPLS needs OAM. Are the current mechanisms (ping and traceroute) sufficient?


2. A word from the ADs (Scott Bradner and Bert Wijnen)

Scott - Reason for this BOF is because of disconnect on MPLS OAM requirements.

What is the problem that we are trying to solve? Answer may be that there are two fundamental different things and don't need merging. If both are needed, then they may not need to be done in the IETF. ITU has requested an OAM label. So it may be done in the ITU.

Presenters were requested to explain the problem that they are trying to solve first.


3. Presentation - what are the requirements for MPLS OAM? - Peter Willis

OAM protects the three main organs of a network operator (brain, heart, wallet) OAM requirements have been implicitly stated in RFC 1812 "Reqts for IP routers". Described various MPLS fault scenarios and highlighted deficiencies in current handling mechanisms. Various I-Ds and RFCs that include OAM requirements were listed. MPLS OAM tool requirements were listed. Also, a list of things that MPLS OAM tools should not do were listed. Limitations with traditional IP-based ping mechanisms were discussed. OAM mechanisms in other protocols were listed.

The list of people who expressed interest in this work and a list of IETF I-Ds related to this work was provided.


4. Presentation - To what degree do current proposals meet these requirements? - Shahram Davari

Shahram discussed and compared currently available tools (IP tools such as Bonica-GTTP, Ping Pan's LSP Ping, and MPLS specific tools such as the expired draft-harrison-mpls-oam-00). It was also shown that various approaches satisfy various subsets of MPLS control planes, except the draft-harrison, which satisfies all MPLS control planes (i.e., RSVP-TE, CR-LDP, LDP, BGP, Configuration-based). Compliance of these three approaches with various OAM requirements was compared.

Summary : operators have identified requirements, current proposals are insufficient. Do we need one generic solution or a number of point solutions?

We also need to improve current proposals.


5. Presentation - Ron Bonica
Alternative approach:
Currently two approaches - OAM versus Ping/GTTP. These approaches are based on two competing views - MPLS as a layer, versus MPLS as a routing mechanism. Trying to address how to harmonize these two views.

The proposed solution is : MPLS WG adopts the IP-centric view (ping, gttp) and the PWE3 WG should dictate the layer 2 OAM mechanisms.


6. Discussion

Brajesh Kumar - Need tools (may be modification of gttp/ping). But a full OAM draft may take too long to be beneficial.

Yakov Rekhter - Presentations focused on frame/cell switching with MPLS. None focused on DWDM/GMPLS. Should we not broaden the scope?
A: Immediate problem is to address Frame-based LSRs. GMPLS will be in the future.

Yakov - are you saying that certain functionality available at certain data planes need not apply to others.

Ben Mack-Crane - (after further clarification by email)

These problems are already solved at other layers, for example SONET/SDH, PDH, OTN."


Yakov - Requirements need to be broadened.

Ping Pan - LSP ping is driven by provider requirements. Not intended to give full measurements on OAM. Agree that functionality is limited, but this is within the context of IP. OAM is much beyond the context of IP. LDP is not covered by lsp-ping because LDP is used for label distribution and there is no need to ping a label (unless associated with a VPN).

Shahram - LSP-Ping should also work with LDP.

Ray (Goldwire technology) - This work is truly essential and needs to be done. Administratively a bad idea to have a separate WG. Seconds Ron's proposal.

Dave Allan - Seeing demand for this functionality from customers. Doing this in PWE3 will not be a good idea. These should be built in current network elements.

Kireeti - Couple of comments : 1. LSP-PING is currently rsvp-te specific, but can be extended. Actually a "good" thing that it works only at a data plane, and not at control plane. 2. Non-goal not to do control plane stuff is not good. Should do control plane also. In response to Dave, if LSP-ping and GTTP don't work, we should examine why they don't' work for IP. Regarding SONET trails, we need a tool for control plane for this. Depending on what ITU says, we might need such tools. May be we should build something in CCAMP for this. Similarly other WGs should do related stuff.

Ben Mack-Crane - SG 13 in ITU has been doing work. Need to coordinate what is done there and what here.

Rahul - Redback - none of the discussions talked about ICMP extensions to mpls. That can solve a lot of these issues.

Shahram - that has been rejected by IESG.

Rahul - need to open it up again, since it is deployed.

Shahram - can't solve all the problems mentioned.

Rahul - don't agree.

Ben Mack-Crane - IP centric approaches may have limitations like security violations. Still makes sense to use MPLS OAM mechanisms for IP centric networks. Both data and control plane needs OAM. IT is good to keep them separate.

Dave McDysan - Interpretations on references are inaccurate. Questions analysis on limitations of other proposals. Harrison OAM is very similar to ATM.

Ping Pan - GTTP/LSP Ping is designed for IP network operators. Agree that OAM is very important. But this needs to be done elsewhere.(ITU). Appropriate IP mechanisms need to be done in appropriate IETF WGs.

Ben Mack-Crane- Defending harrison draft, as Neil had problems with ATM OAM and wanted to make stuff better than ATM. MPLS OAM is not an "application" over MPLS and therefore not a separate application (unlike what Ping said).

Yakov - (after clarification on the mailing list)

Ron's slides showed that there are two views on MPLS, with one of these views saying that MPLS is a layer on its own. This view doesn't match the reality, as in reality MPLS, and specifically its control plane, doesn't exist outside IP because MPLS control plane uses IP addressing, routing (OSPF, ISIS), and signaling (RSVP-TE, LDP, CR-LDP).


George Swallow - (after clarification on the mailing list)

In architeting MPLS the design goal was to offer IP based services. Along with that the ubiquity of IP was also assumed. In IP unicast forwarding, bidirectionality is neither assumed nor assured.

These assumptions lead us to build unidirectional LSPs and to allow penultimate hop popping since the box at the end of an LSP is assumed to be able to forward IP packets and removing the label at the previous hop is a useful optimization.

IP-centric approaches, are the right approach. For instance the method proposed in draft-pan is to use normal IP pings to monitor a tunnel. Only when the normal ping fails do you use the tunnel ping. This is used to differentiate between a loss of the ping (failure ofthe forward path) and loss of the reply (failure of the reverse path).

Dave Allan - LSP creation is discussed in framework doc. Yes, MPLS is predominantly deployed with IP control plane. But need to realize that the forwarding plane can exist without IP. (Ships in the night etc weren't made with IP in mind).

Jerry Ash - Many carriers feel that MPLS OAM is needed. First question is requirements and second question is capabilities to satisfy requirements. Requirements are only partially fulfilled. Need a complete answer, so need this work to progress.

Brajesh Kumar - This discussion is focused only on two approaches. OAM draft is a good draft and specifies requirements clearly. Not achievable in short term.


7. Sense of the room and next steps (Scott and Bert)

Bert - Sense is divided. Original beholders of MPLS feel GTTP/Ping and SNMP etc are sufficient. Also opinion that work has been done, including work in ITU. It is clear that a lot of people need this, but not clear where to do this (MPLS or existing WGs or separate WG). Need to think more and discuss more.

Yakov Rekhter- may be we should get working code and implementation experience. (blue sky talk as opposed to something that can be implemented).

Need minutes to be posted to relevant WGs to help evaluate next steps.

Marco - Good result seen here is that the requirements are clear. Could improve current tools or invent new tools. This is a significant result of this BOF.

Bert - Need to chat a little more on requirements document and possibly have an informational RFC.

Bilel Jamoussi- Need a decision soon. Dragging this to MPLS mailing list may not be good. Need bounded time frame for this decision. 2-3 weeks? To decide whether it will be done here or ITU.

Bert - If work is not done here, people are free to do it elsewhere. The purpose of this BOF was to get an understanding of problems etc. and it has been achieved.


Slides

MPLS Management: Alternative Approaches
'What sort of OAM does MPLS need?'
Beyond the current IETF solutions
What are the requirements for MPLS OAM?