The MPLS WG Archive

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

As a service provider, I also do not see a critical need for MPLS OAM in a
large ISP backbone or in network-based IP VPNs.

On the other hand, in the case of MPLS supporting PWE3 type services that
require OAM (e.g., circuit emulation, ATM), I think that application of
these types of OAM functions may indeed be required.

Dave

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Loa
> Andersson
> Sent: Wednesday, December 12, 2001 6:20 PM
> To: Ron Bonica
> Cc: dirk.ooms@alcatel.be; Shahram Davari; mpls@UU.NET
> Subject: Re: MPLSOAM BOF meeting draft minutes
>
>
> All,
>
> I would like to echo Ron's sentiment. I run an all IP network, that is
> MPLS enabled. I use MPLS to better deliver IP services. I do not run an
> MPLS network delivering MPLS services!
>
> /Loa
>
> Ron Bonica wrote:
> >
> > Dirk,
> >
> > There was not clear consensus among the operators in the room.
> I operate an
> > MPLS enabled network and do not support adding OAM
> functionality to the core
> > MPLS technology.
> >
> >                                    Ron
> >
> > > -----Original Message-----
> > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> > > dirk.ooms@alcatel.be
> > > Sent: Tuesday, December 11, 2001 7:46 PM
> > > To: Shahram Davari
> > > Cc: mpls@UU.NET
> > > Subject: Re: MPLSOAM BOF meeting draft minutes
> > >
> > >
> > > 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.
>
> --
> Loa Andersson
> Chief Architect,
> Utfors Research, Architecture and Future Lab (URAX)
> Utfors AB
> Råsundavägen 12
> Box 525, 169 29 Solna
> Office          +46 8 5270 2000
> Office direct   +46 8 5270 5038
> Mobile          +46 70 848 5038
> Email           loa.andersson@utfors.se
> WWW             www.utfors.se
>