The MPLS WG Archive

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

In message <B9571FDEBD3DD21181E500606DD5EE050E891C11@mbddmknt01.hc.bt.com>, nei
l.2.harrison@bt.com writes:
> Dave McDysan 13 December 2001 18:37
> > > -----Original Message-----
> > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Giles
> > > Heron
> > > Sent: Thursday, December 13, 2001 1:20 PM
> > > To: Shahram Davari
> > > Cc: Don Fedyk; Ben Mack-Crane; neil.2.harrison@bt.com; mpls@UU.NET
> > > Subject: Re: MPLSOAM BOF meeting draft minutes
> > >
> > >
> > >
> > > I don't measure every circuit.  And what I do measure I measure for
> > > other purposes than "OAM".  It has a side effect of also 
> > allowing me to
> > > do CV at a core MPLS tunnel level.
> > >
> > > I'm hoping that I won't see two blackholes a month.  And I 
> > stand by my
> > > statement that if I did I'd be beating on my LSR vendor pretty darn
> > > hard!
> > >
> > 
> > In the end, I believe that this is the real solution to this 
> > problem. I
> > haven't yet seen discussion on this thread about what would 
> > be done if an
> > MPLS OAM CV with BDI did detect a fault. Do we reboot the 
> > entire node? What
> > if it is a software/hardware bug that affects multiple nodes 
> > from a certain
> > vendor?
> > 
> > Dave
> NH=> Fair point Dave.  You are right this has not indeed been decided
> upon....but could we even attempt to do that (I mean standardise what needs
> doing to the node....it depends what we are seeing)?  At least the 1st step
> would be to detect, and diagnose, the problem....and taking local executive
> actions to protect traffic as needed, eg protection switching.  When you get
> down to it what is CV? It's merely a heartbeat that is decoupled from user
> activity saying source X is correctly connected to sink Y.....and it beats
> me why this functionality (so often encountered elsewhere...perhaps we
> should call it a 'hello' packet?) seems to create such a problem for some
> folks.
> BTW - I saw your earlier note on ATM OAM and if you want to discuss this
> I'll willingly do it off-line...or give me a call (+44 1 604 820 724).  ATM
> OAM has some subtle problems.
> 
> regards, Neil



Neil,

I hate to add to this agonizingly long thread, I counted 107 messages
already and going nowhere.  I appologize in advance to reader out
there.

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.

IP succeeded in large part due to its simplicity.  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.

MPLS is a bit more complex, but it is possible to "get it right".
Adding more complexity will not make the matter any better.  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.]

As far as what to do - This thread indicates no clear consensus (IMHO)
that IETF work on MPLS-OAM is needed.

Two years ago you brought MPLS-OAM to IETF (maybe longer, I remember
talking about it at Pittsburgh).  I tried to work with you by
suggesting ways to substantially simplify it and I remember you as
being very uncompromising.  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.  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>.

Curtis


ps - refenence [8] in draft-harrison-mpls-oam-req-01.txt is a unique
idea - self referencing citation.  btw - yes I have read the drafts.