Subject: RE: OAM functions for MPLS (Was: RE: Comments on draft-owens-te- network-suvivability-00.txt )

From: Florian-Daniel Otel <[email-masked]>
Date: Mon, 8 May 2000 12:18:31 +0200 (MET DST)

> Some quick background to bring up up to speed:

> 1	The Thiemer ID is mainly a background/requirements paper......but it
> does not go anywhere near far enough.

Point taken.

> 2	When we use relative addressing (ie labels) these are not globally
> unique but only interface unique.  Note - An IP pkt has an absolute address,
> and so is globally unique (save for NAT etc issues).  This means that we can
> have various forms of misbranching defect affecting MPLS LSPs.  These are
> well-known defects in ATM (though to be honest the solutions are far from
> perfect........it would take too long to explain why here).  For example:
> -	simple break in LSP connectivity
> -	two LSPs swapped
> -	one LSP merging into another LSP (with or without the 'offending'
> LSP being affected or not)
> -	self-merging of an LSP (with or without a break on connectivity to
> its sink)........this being the classic looping defect of transient IGP
> behaviour.
> For an operator these are serious defects.  Not only do they affect
> availability/QoS SLAs per se, be they can have security, censorship and
> fraud implications if traffic gets misdelivered.  It would not be very good
> publicity for any operator to have such defects happening that could not be
> (i) detected and (ii) diagnosed/corrected.

> 3	To date there has been little work on identifying and then
> specifying MPLS level defects.....both in terms of the defect entry/exit
> criteria and the consequent actions.  MPLs has only been seen so far as an
> 'IP booster'......but when one really analyses what is going on (eg with TE
> and VPN issues) then one is rapidly forced into the conclusion that MPLS
> *must* become a layer network in its own right.  And a proper layer network
> *must* have certain characteristics......a key one being absolute source
> adddesses of trail access points.

Ok, now this becomes scary for me. I'm not so advanced about MPLS so
far (I'm taking the first steps now, so please take this w/ a grain of 
salt and don't flame yours truly newbie :) ) but so far for me  MPLS is a neat
labeling artchitecture. An *IP boost* as you call it. Moreover, AFAIG
things are quite settled  in the sense that there is already an
installed based of MPLS. Turning it into a full-fleged L2 proto in
itself..Well, that's far beyond me to judge but my impression is that
it will be quite a shake-down if this happens. If ever.

<snip> 

> Our current thinking is that 1 bit of the TTL field would be
> sufficient noting that:
> -	a TTL number space of 255 is too big anyway
> -	TTL is rather a wrong architectural concept for MPLS *if* one is
> trying to guess the 'passed IP hops' in an IP client
> layer.......architecturally, LSPs are a server layer to IP (or indeed any
> client layer......though IP is the only one so far defined) and as such one
> should not be using the functions of a client layer within a server layer.
> Same would go for any use of ICMP in MPLS, and indeed some of the misguided
> debate I have been seeing on the relationships across the full L1/2/3 stack
> (esp with optical layer).
> -	a TTL field would be useful in MPLS but *only* for stopping looping
> pkts in that layer (ie irrespective of what the client layer was), and then
> only as a back-stop mechanism, ie still need defect indication
> -	TTL only caters for looping defects, it does not cater for all the
> other misbranching defects I mentioned in 2 above.

Again, i'm still finding my way through the  aprox 70 existing `MPLS drafts`,
but IIRC there are at no less then three documents decribing methods
for loop avoidance. Ok, TTL is just a simplistic 'back-stop'
mechanism, but are that so many intrested in more than this ?

> 6	Only a few people have bothered to comment on the 'missing' OAM
> perspective for MPLS so far.  Though I have had varying degrees of support
> for saying we need a payload ID field.......but none strong enough to say
> its essential.  Though without one, I am struggling to understand how to
> progress this area, and I think MPLS will have missed a very big
> opportunity.

AFAIG there was already a discussion about this kind of field in MPLS
and the idea was rejected. 

Anyway, with the risk of having the 'not this subject again, please' 
reaction I'm biting the bullet and Cc: this to the MPLS mailing list
where i think there are people more competent than me to discuss the
matter. As much of a fan i'm to the KISS principle and as much the
idea of turning MPLS in a full-flegded L2 proto is scaring to me
(not that present state is that simple but still ...) IMHO you raised
some points that worth at least to be refuted ;) 

> Hope that helps Florian. 

> Regards, Neil 

With kind regards,

Florian.