The MPLS WG Archive

[Thomas Nadeau <tnadeau@cisco.com>]

>Tom...have you actually read what has been proposed in Y.1711 say?
>
>I am very concerned that there seems to be this view that we are proposing
>something awfully complex.

         This is the impression I got after reading your draft. It seems
that I am not alone.

>It is my opinion that what is being proposed in
>Y.1711 is about as simple as you can get (actually less so than either
>LSP-ping or GTTP) and it and delivers a very strong fault-management
>capability for operators.
>
>It would be useful if people could please explain *precisely* why/what in
>Y.1711 is too complex so I can understand comments such as this far better.

         Perhaps you could summarize the differences and similarities
between it and LSP ping/GTTP for the list?

         --Tom




>thanks, Neil
>
> > -----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.