The MPLS WG Archive

[<neil.2.harrison@bt.com>]

> > > Tom,
> > > 
> > > A couple of observations on your remarks:
> > > 
> > > (i)	I agree with you that some clarity is required on 
> > > specific reserved label ranges and their uses.  However, I'd
> > > say it's bigger than just the label ranges and should also 
> > > include how all the header fields (ie S, EXP, TTL) are to be 
> > > used in T-MPLS (I noted you don't think this 'T-MPLS' name is 
> > > good, but I'll stick with it here).  Why?  Well, folks need 
> > > to consider the various client/server relationships that 
> > > could exist between the various spins of MPLS as-is and 
> > > T-MPLS....and especially misconnectivity between them....so 
> > > how is this going to be handled?
> > > 
> > > (ii)	I'd urge you not to be so hard on Y.1711.  This is a 
> > > simple defect detection/handling OAM solution for ANY co-ps
> > > mode network based on label-swapping that respects the 
> > > architectural requirement of what defines a connection (ie 
> > > single source, connectivity=1).  Any form of MPLS that has 
> > > merging (so that is LDP and/or PHP) violates the rules for a 
> > > connection.....this is just a fact.....and so Y.1711 is not 
> > > appropriate (but then attempting to apply any sort of 
> > > determinism across any aspect of traffic/fault/performance 
> > > management is fraught with problems when the rules for 
> > > connections are broken).
> 
> 
> Neil, Tom,
> 
> Just curious: you both say that Y.1711 does not work in 
> conjunction with PHP. Why is that? The CV frames have a TTSI 
> vlaue that can be used to identify the source even when 
> because of PHP (and Label Merge) the LSP context is lost.
> 
> Peter

Hi Peter, good question...let me frame it before giving a specific
answer.

Co mode networks SHOULD only have p2p and p2mp connections...in fact the
definition of a 'connection' is only satisfied by such constructs.
Anything else is not a connection and will have various
traffic/fault/perf management problems.  Correct behaviour is forced in
the co-cs mode but is not in the co-ps mode....it's all a function of
how the resource-partition labelling works in these 2 modes (can explain
in great detail if required).

LDP violates this principle by creating SPF merging at arbitrary
locations and so does PHP by creating merging on the last hop.  PHP also
destroys the notion of having the trail termination point in the correct
place. 

OAM should look as much as possible like normal traffic.  It should not
be proxied by control plane protocols....esp so when noting that in a
well-designed co mode network all internal control/management protocols
SHOULD be run OOB wrt traffic data-plane.  Again this desired behaviour
is forced in the co-cs mode due to labelling considerations.

Folks can say what they like about the above observations, I stand by
them as being correct from a best practice design perspective.

So, in a co-ps layer network based on label-swapping an OAM packet
SHOULD be identified by a flag in the normal traffic unit header.  I
wasted a year or so arguing for this several years ago when MPLS had no
OAM and folks like Tom were arguing MPLS did not need any OAM at
all....things have changed a bit since then.

This meant the only way we could provide an indication of an OAM packet
was by a special reserved label (value 14, decimal).  Bit of a kludge
IMO as it means the LSP 'jumps' from having 1 (traffic) label to 2
(traffic+OAM) labels....this is not a very clean behaviour, but it can
work OK.  Still, that is all that was available due to the design error
of not providing for an OAM indicate flag in the original MPLS header.

So yes you are right in one sense Peter, this 1-label to 2-label kludge
does indeed mean that OAM pkts get sent to (what should be) the trail
termination point with PHP.  And in the case of a CV packet this has to
contain a trail source identifier (TTSI) so yes you can work out where
it came from.....does not apply to other OAM packets that do not contain
a TTSI.  Some advice on this is given in Appendix II to Y.1711. 

Hardly think it's a glowing example of good design however, this is just
a spin-off of the original design error and the subsequent kludge.

regards, Neil

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls