The MPLS WG Archive

[Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>]

Hello Neil,

I think a draft covering MPLS OAM that can set requirements and define
the essential minimal OAM functions and mechanisms would be extremely 
useful.  As Florian mentions, there are several drafts addressing 
various specific items and one general one so far.  This work needs 
to be progressed and some common mechanism(s) for carrying out the 
variety of OAM functions should be defined.

I have been thinking about this from the viewpoint of the recovery
framework and protection switching drafts to which I have contributed.
In looking at MPLS based recovery, it becomes clear that a simple
and reliable path continuity test would be very useful.  Also a fast
communication path to convey a fault indication is useful if rapid 
protection switching is required.

A simple way to identify OAM packets, while allowing them to
follow the same data path as user packets (when required), is
essential to these functions.  If this can be done without disruption
to the embedded MPLS base, as Kireeti has indicated, this would be 
ideal.  I think there are some promising possibliities being discussed
in the related thread on "OAM labels".

I would be happy to help out with your proposed draft, if needed (though
I can't claim to have any special talents for editing ASCII state diags.).

Regards,
Ben

neil.2.harrison@bt.com wrote:
> 
> Hi Florian,
> 
> I have been involved with much of the recent ATM OAM work.......but came in
> late in the day when, unfortunately, it was too late to change the stds
> (though believe me we tried).  Its a very complex story and I don't want to
> waste people's time by going through its history here (speak to me privately
> if you want the details).  But in essence, there are too many optional OAM
> combinations and not enough thought was given early enough to the basic
> architectural OAM functional relationships (especially harmonised defect
> state handling at near-end and far-end of trails)......which is why after
> many years (maybe 8 or so) we do not even have any agreement of how to
> measure availability on ATM trails (and which also means, as a by-product,
> that the up-state-only QoS measurements can become worthless).
> 
> Based on this experience, and working closely with my IP network design
> colleagues, we have pared down our functional requirements (and their
> manifestation as OAM pkts) to what we believe are the essential minimal in
> order to (i) allow operations people to maintain and fault-find and (ii)
> protect customer traffic from wrong delivery under various connectivity
> failure scenarios.
> 
> I really ought to get something drafted so that other people can more
> constructively criticise it......there may indeed be better ways to provide
> the functionality we would like to see.   I will try and do something over
> the next few weeks or so and circulate to those who have expressed an
> interest so far.
> 
> Regards, Neil
> 
> > -----Original Message-----
> > From: Florian-Daniel Otel [SMTP:otel@ce.chalmers.se]
> > Sent: Monday, June 05, 2000 3:41 PM
> > To:   Shahram Davari
> > Cc:   'neil.2.harrison@bt.com'; EGray@zaffire.com; swtan@mmu.edu.my;
> > kireeti@juniper.net; dwilder@baynetworks.com; mpls@UU.NET
> > Subject:      OAM functionality (Was: RE: can egress know the ingress of a
> > packet?)
> >
> >
> > Sharam,
> >
> > > Hi Neil,
> >
> > > I also think we need some sort of OAM function at MPLS layer. And as you
> > > said, to be able to process OAM cells, they must be recognized by LSRs.
> > But
> > > it might be hard to change the definition of TTL field at this point in
> > > time. So I have a different proposal. Why don't we assign/reserve some
> > Label
> > > values to be used only by OAM packets. This is very analogous to ATM, in
> > > which, some VPI/VCIs are reserved for OAM cells (e.g. VPI=0 and VCI
> > =0-15).
> > > For example we could assign Label = 0 for the Keepalive messages that
> > you
> > > described.
> >
> > > I am interested in writing such an I-D, and in fact my company is expert
> > in
> > > ATM OAM, so we could leverage that knowledge for the MPLS OAM.
> >
> > As Neil already pointed out, there are several people intrested in O&M
> > functionality in MPLS, and for several reasons (you can also check the
> > discussion between Neil and Vishal on TEwg mailing list on 17 Apr &
> > ff. I also had some off-list questions about it).
> >
> > But the impression i got (and please, someone correct me if I'm wrong)
> > is that, as the Theimer OAM requirements draft clearly states:
> >
> > "[..]we do not intend to simply adopt the OAM functions and procedures
> > previously defined  for other technologies (in particular ATM), as
> > this would probably lead to very complex and expensive
> > implementations[..]"
> >
> >
> >
> > Putting it bluntly, the way i read this is that "we simply don't want
> > to turn MPLS into ATM-2 by adding all possible types of OAM functions".
> >
> >
> > So, my take is (and, by all means, please correct me if i'm wrong)
> > that in addition to the (rather vague IMHO) Theimer draft there you
> > have all other proposals for recovery, protection, restoration and
> > loop prevention but no other general O&M spec than the above
> > draft. Why is that and how to solve (if ever need be) the OAM
> > needs...well, that's it's beyond my knowledge (and the reason I'm
> > asking about it here).
> >
> >
> > My $0.02 worth.
> >
> > With kind regards,
> >
> > Florian.