The MPLS WG Archive

[Dave Cooper <dcooper@gblx.net>]

David Allan [dallan@nortelnetworks.com] wrote:
> In the absence of standard tools vendors are welcome to do what they can
> with what they have. That some of the problems can be solved today is great.
> 
> This shouldn't be confused with a comprehensive solution (the type my
> customers are looking for), and simple incumbency of a partial solution

I don't think folks are confusing LSP-Ping as an alternative to OAM
that will meet all the requirements of OAM.  In Bonica's presentation,
it was plainly stated that it is not intended to be a comprehensive 
OAM solution.  The scope of LSP-Ping is stated explicitly in the draft.

Its not an issue of LSP-Ping/Traceroute or OAM.  More an issue
of whether the two can coexist in the IETF.

-dave



> should not dictate solution space boundaries.
> 
> cheers
> Dave
> 
> > -----Original Message-----
> > From: Thomas Nadeau [mailto:tnadeau@cisco.com]
> > Sent: Wednesday, December 12, 2001 12:32 PM
> > To: Gibson, Mark
> > Cc: mpls@UU.NET
> > Subject: RE: MPLSOAM BOF meeting draft minutes
> > 
> > 
> > 
> > >So this is an intersting post, the nub of which seems to be that, in
> > >general, vendors only want a mechanism that they can 
> > implemement easliy
> > >using their current code base, rather than go for something 
> > that solves all
> > >cases that might involve extra work.
> > 
> >          No, not exactly. My point is that there is code that
> > works today in operational networks that solves most of
> > the stated problems. It does not make sense for anyone
> > involved to discard this code. It seems to make more sense to
> > me to use these, and perhaps include additional ones in the
> > set to solve what problems remain (or to use them together).
> > 
> >          --Tom
> > 
> > 
> > >Isn't the best way to roll out the current short term 
> > solutions that meet a
> > >subset of the requirements as presented in the BoF (and I 
> > note that no-one
> > >questioned that these were correct) and in parallel work on 
> > a more general
> > >and complete OAM solution.
> > >
> > >Aiming only to solve a subset of the failure modes seems a 
> > poor goal. Or
> > >perhaps the way that GTTP and ping solutions can be enhanced 
> > to address all
> > >the scenarios elucidated in the problem statement can be described.
> > 
> > 
> > >Mark
> > >
> > >PS add me to the consensus for the general solution.
> > >
> > >-----Original Message-----
> > >From: Thomas Nadeau [mailto:tnadeau@cisco.com]
> > >Sent: 12 December 2001 16:35
> > >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).
> > >
> > >          --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.
> > 
> > 
> > 
> > --------------------------------------------------------------
> > ----------
> > Mathematics is the supreme nostalgia of our time. 
> > 
> > 

-- 
Dave Cooper
Global Network Architecture, Global Crossing
Voice: 602.744.3473 - Cell: 916.761.3266