Subject: MPLSOAM BOF final minutes & presentations

From: Shahram Davari <[email-masked]>
Date: Wed, 2 Jan 2002 08:22:11 -0800

Hi All,

Based on received comments, please find attached the final minutes of the MPLSOAM BOF. The presentations have been submitted to IETF and will be available to the public shortly.

Thanks,
Shahram Davari
MPLSOAM BOF Co-chair

---

From: Shahram Davari <[email-masked]>
Date: Wed, 2 Jan 2002 08:45:33 -0800

Hi All,

Please find the MPLSOAM BOF final minutes below as plain text format (not an enclosure).

Thanks,
-Shahram

*************************************
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 architecting 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 of
the 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.