The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <B9571FDEBD3DD21181E500606DD5EE050E891C3E@mbddmknt01.hc.bt.com>, nei
l.2.harrison@bt.com writes:
> Curtis, see below....regards, Neil
> Curtis Villamizar wrote 15 December 2001 02:56
> <snipped to the chase>
> 
> > Dave's point does get to the heart of the matter.  If the box is
> > broken fix it.  It would appear to me that Dave is implying that it is
> > not acceptable to detect a problem with one LSP impacting one customer
> > and reboot the entire box or a set of boxes when you detect it.  That
> > seemed to me to be a correct observation on Dave's part.
> NH=> Who said anything about re-booting a box on detection of a (single) LSP
> failure?  I know there are several 'graceful restart' drafts out there but
> what has this got to do with LSP fault-management or availability
> measurements of the LSPs in a VPN say?  Clearly if the box needs re-booting
> (which kind-of does not make me feel very comfortable in itself when you
> think about it) this is quite a different, and a far more serious, issue. 
> > 
> > IP succeeded in large part due to its simplicity.
> NH=> Well it took 30+ years to get here...and from my perspective QoS still
has a long way to go.  The 'success' I would argue is probably more do to
> with the fact that IP could go wide-area and its ubiquity rather than its
> simplicity....and the emergence of applications like Email, and of course in
> no small way thanks to the British physicist Tim Berners-Lee for the
> invention of the WWW which is the lion's share of the traffic I
> believe....but we are digressing.

We are.  IP (btw) is defined in RFC791 which was a 1981 RFC and it was
widely deployed in 1983, so IP is 20 years old.  The Internet was a
success before WWW, just not in the consumer market.  It had eclipsed
CSNET, VNET, USENET, Fidonet, and was far larger than any
interconnected telco switched service based network.  (Switched
services was a big business of building lots of little islands).

I share your disappointment in the slow advancement of IP QoS.
Regardless, IP is a success and providers do deliver service with SLA
that are cost effective to operate and seem to fit what the market
will bear in terms of cost of service and service quality.  We very
seriously digress.

> > IP routers did not
> > always "get it right".  For example, the NSS routers used in the
> > T3-NSFNET, a research project that some poeple might still remember,
> > had forwarding problems in early to mid 1992 known as "grey link" and
> > "black link" problems in which forwarding cards would show routes
> > installed but would not be forwarding (Ping Pan will remember this:).
> > We didn't add OAM to IP.  We didn't ping every location from every
> > other location.  We fixed the routers.
> NH=> "Fixing" seems to be a common ongoing theme, esp if my last visit to
> our VPN config team is anything to go by....will this stuff ever get mature
> to class it as carrier strength I wonder?  On the one hand I am told this
> stuff fails so infrequently its not a problem, on the other hand I hear of
> customers saying this stuff is not fit for purpose because we can't fault
> manage it, I see graceful re-start stuff appearing....and you are kind-of
> telling me 'don't worry we'll get it right in the end'?  It's no wonder so
> many people I know are far from convinced about the merits of MPLS.
> > 
> > MPLS is a bit more complex, but it is possible to "get it right".
> NH=> Any idea when that might be....2005, 2010,....given IP protocols are
> still being worked on and 30 years have gone by?
> 
> > Adding more complexity will not make the matter any better.
> NH=> Are you seriously telling me that sending a very simple fixed length CV
> packet (all it contains is a absolute tunnel source address....it does not
> even have TLVs) from the LSP source to the LSP sink periodically is complex?
> It does not need to be on all LSPs, it only impacts LSR source/sink points
> (ie transparent to intermediate LSRs) and you should carefully note that
> source generation and sink processing functions can be decoupled.  How can
> you compare this (lack of) complexity to say (chosen from a large candidate
> pool) advertising DS resource classes and their completely unrelated
> survivability indexes in an IGP?  Or even compare it to GTTP, which is far
> more complex IMO and still does not detect problems, ie still have to wait
> for complaint from the customer.

By "get it right" I mean the forwarding works.  There is no percierved
need to add protocols to IP to monitor the discrepency between IP
forwarding plane and IP control plane.  This is not because these
things can never happen, it is just that by the time a router is
deplyed these days, that type of problem is ironed out.

Some MPLS implementations have apparently not acheived the same level
of maturity.

> >  If
> > anything, the people who would otherwise be fixing the problem will be
> > busy modifying ASICs at worse or modifying microcode at best to
> > support OAM probes plus the protocol bits, and it may make the problem
> > itself worse by diverting brainpower.  [Brainpower is finite.]
> NH=> Well, perhaps one suggestion would be to get all those people who are
> spending so much effort trying to introduce a control-plane into SDH and
> OTNs to think more about giving us MPLS carrier strength solutions first?
> > 
> > As far as what to do - This thread indicates no clear consensus (IMHO)
> > that IETF work on MPLS-OAM is needed.
> NH=> I'd agree with that.
> > 
> > Two years ago you brought MPLS-OAM to IETF (maybe longer, I remember
> > talking about it at Pittsburgh).
> NH=> Pittsburgh, my 1st introduction to IETF and yourself, was 8/00.....just
> over a year ago.

I stand corrected.  One year ago.

> > I tried to work with you by
> > suggesting ways to substantially simplify it and I remember you as
> > being very uncompromising.
> NH=> From my clear recollection you were in favour of CV but had problems
> with the need for FDI and alarm suppression (latter is not surprising, since
> it makes no sense in a CNLS environment but is rather important in a CO
> environment).  As regards the 'uncompromising' bit, its hard to 'give in'
> when many others agree with you and no one else provides a satisfactory
> alternative...I am still waiting for one.  Those who actually know me a bit
> better than you know that I am always willing to be convinced by logic, but
> I won't bend to dogma.

I appears that connectivity verification is the capability that you
are most interested in acheiving.  <draft-pan-lsp-ping-02.txt> aka
"LSP Ping" provides that capability.  It does so using the IPV4
Explicit Null Label with a UDP packet underneath, rather than using a
new MPLS-OAM label.  The payload is RSVP-TE specific.  If you want
this capability you may have to give up the MPLS-OAM label and settle
for IPV4 Explicit Null Label and UDP.  If you must have CR-LDP
support, then you can discuss the payload with the authors.  This
would be constructive.

Perhaps you can express your objections to Ron Bonica, and Ping Pan,
et al.  Based on my prior experience with these people, if your
requests are reasonable they will listen and incorporate them.

The time to compromise on MPLS-OAM was a year ago.  You chose to take
it to the ITU instead.  At this point compromising will mean
abandoning MPLS-OAM and making sure that the capabilities you want are
incorporated into GTTP and LSP Ping, even if you don't like the probe
format or control plane format.  That IMHO would be the most pragmatic
way for you to get the capabilities you need to run your network into
the IETF work.

> >  I don't know that you weren't technical
> > right, but my suggestions were with the intent to define something
> > simple enough to gain acceptance in the IETF, but sufficient to do the
> > job.  At that time the MPLS WG decided not to adopt it as a WG item.
> > 
> > If ITU SG13 is defining MPLS-OAM, then IETF does not need to work on
> > MPLS-OAM unless there is something wrong with the ITU work.
> NH=> I agree.  What I and others would like to avoid if possible is
> competing solutions....but when I look around (many topics), that is clearly
> not always possible.

I don't see two competing solutions in IETF.  I don't recognize ITU as
a relevant standards organization in this area.  In other areas yes.
Therefore I don't see two competing solutions at all.  That could
change if a customer demands MPLS-OAM, but while I see MPLS-OAM as
less straightforward to implement, I don't see it as unachievable.

Perhaps you did not recognize that in the IETF "take it to the ITU" is
a polite way of saying "go away".  I am trying to be polite (maybe
that isn't apparent enough) but at the same time trying to tell you
that IMHO MPLS-OAM is going nowhere and you would be better off trying
to make sure GTTP and LSP ping meet your requirements.

> > If the
> > ITU work is too complicated and something simpler is needed then it
> > makes sense for IETF to do something, but basing IETF work on
> > something already defined by another standards organization and
> > regarded as deficient is a poor approach.  The IETF *is* doing
> > something simpler, namely LSP ping <draft-pan-lsp-ping-02.txt> and
> > GTTP <draft-bonica-tunproto-01.txt>.
> NH=> These are not simpler and they don't address the requirements operators
> have as discussed at the BoF I believe.
> > 
> > Curtis

The ever pragmatic implementors have noted that IPV4 Explicit Null
Label and UDP are already supported and LSP Ping drops into existing
implementations more smoothly than adding an OAM label.  The use of
OUI has probably not helped MPLS-OAM since this implies delivery to
any number of non-IP control planes.  The same pragmatic implementors
prefer to stick with an IP control plane.

LSP ping support connectivity verification over LSP of any type,
including BGP VPN and LSP tunnels carring non-IP traffic.  LSP ping is
initiated by the ingress LSR, although it could be injected at
midpoint, the need to do so is not currently percieved.  GTTP can be
used to verify control plane.  If the connectivity verification fails,
but the control plane appears intact, then there is a disjoint
forwarding and control plane.

> > ps - refenence [8] in draft-harrison-mpls-oam-req-01.txt is a unique
> > idea - self referencing citation.
> NH=> Thanks for spotting that, it needs fixing (as do some other typos I
> have noted that are still in there).....but I am afraid I can't claim the
> credit for this, the editing was done by someone else (I am guilty however
> of not spotting/correcting it before issue).  I suspect the reference was
> meant to be to my initial paper (which is now time-expired)

:-)

> >  btw - yes I have read the drafts.
> NH=> Just the requirements?  Perhaps you could be so good as to explain then
> what is wrong in just there then, and how Ping/Bonica drafts satisfy or
> don't these requirements?  Please note that I am not in agreement with all
> that is found in the 'messaging' draft....largely on the grounds, which you
> may find hard to believe, of a need for simplicity and retaining focus on
> essentials. 

Before posting I reread all three OAM drafts and the GTTP and LSP Ping
draft.  I will admit that the MPLS-OAM drafts are much more clear than
earlier versions.  I think draft-azad-mpls-oam-messaging-00.txt is
unclear about the semantics of some of the messages, such as the
Performance statistics, Performance loopback, and Performance
notification, and that these may be far less useful if the reciever
does not add the number of packets/bytes received.  These should also
be made optional.  I'm a big fan of PPP LQM and would love to see an
analogous capability made optional.  It would be easy to extend LSP
ping by adding a LSP performance object.  It would be very hard to
accurately stamp the number of packets/bytes received, because it
would have to be done in hardware to be done right, and therefore
would have to be optional with an indication in the protocol when
counters were added by software and would be too inaccurate for
monitoring but sufficiently accruate to aid in enforcement of an SLA
specified in loss over periods of an hour or longer.

Curtis