The MPLS WG Archive

[Dave McDysan <dave.mcdysan@wcom.com>]

As a service provider, I would like to see some more description of how
existing methods map against the draft requirements document and the stated
problem. As a practical matter, there is a need to address problems in the
near term while a standard is worked out, implemented, tested, and deployed
to an extent where it is operationally useful.

Dave

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Thomas
> Nadeau
> 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).
>
>          --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.
>