The MPLS WG Archive

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Thom,

> -----Original Message-----
> From: Thomas Nadeau [mailto:tnadeau@cisco.com]
> Sent: Wednesday, December 12, 2001 11:35 AM
> To: Ping Pan
> Cc: dirk.ooms@alcatel.be; Shahram Davari; mpls@UU.NET
> Subject: Re: MPLSOAM BOF meeting draft minutes
> 
> 
> 
> 
> >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).

1) There is a running code for MPLS-OAM draft. 
2) I also didn't see a consensus for GTTP and LSP-Ping.

Yours,
-Shahram

> 
>          --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. 
>