The MPLS WG Archive

[dirk.ooms@alcatel.be]

In previous BoFs I attended the main question was: "Is there any
operator requesting this?".  In the OAM BoF there was a clear operator
demand, but now there are some vendors that make objections.  Weird
world.

dirk

Shahram Davari wrote:
> 
> Hi,
> 
> This is the draft minute of the BOF. Please send your comments to the MPLS list.
> 
> Thanks,
> Shahram Davari
> 
> **************************************************
> 
> 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 MacCrane - Current problems need to be detected at data plane layer.
> 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 McCrane- Tellabs - 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 McCrane - 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 M- 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 - Ron's comments that there are two views - MPLS being a layered network -
> is not true. MPLS doesn't exist outside IP because it uses IP routing and
> signaling.
> 
> George Swallow - IP's basic forwarding is unicast. No bidirectionality is not
> assumed. Therefore we have unidirectional LSPs. IP-centric approaches, are
> therefore sufficient.  Use Ping to see if everything is fine. IF you cease to
> get ping replies, need to go to control plane for resolution of problem.
> 
> 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.
> 
> Bilal Jemushi- 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.