The MPLS WG Archive

[Thomas Nadeau <tnadeau@cisco.com>]

>In the BoF, the question was more like: "is there any operator requesting 
>(1) the ability to detect LSP failure, (2) the ability to detect where the 
>failure is, (3) the ability to figure out LSP traffic performance". The 
>answer is of course yes. In IP networks, those problem can be solved with 
>LSP-ping, MPLS icmp traceroute, GTTP and SNMP MIBs.
>
>The question you should ask yourself is:" LSP traffic black-hole has been 
>seen in several backbones. Do you think the operators want to wait for a 
>fancy solution that will come out sometime in the future, or a solution 
>that can solve most of the problems with a couple of simple tools and will 
>be available soon?"

         The issue is my mind is can the current set of smaller tools 
(MIBs, ping, etc...)
together satisfy  operator requirements -- they clearly satisfy many -- or 
is a larger more unified
approach needed? And if the answer is that the existing tools are lacking, 
then can they be augmented
to satisfy the additional requirements. Taking this approach would leverage 
the code already
implemented and deployed for the existing tools. I think that we should 
consider carefully
why we should throw the existing code out for an alternate approach that 
has no working code
(or apparent consensus).

         --Tom



>- Ping
>
>dirk.ooms@alcatel.be wrote:
>
>>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.
>
>
>--
>Ping Pan      Phone: (408)-745-3704



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.