The MPLS WG Archive

[Loa Andersson <loa.andersson@utfors.se>]

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