The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Title: RE: MPLSOAM BOF meeting draft minutes

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