Subject: RE: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations"

From: <[email-masked]>
Date: Tue, 11 Apr 2006 16:48:14 +0100

Thanks George....please see below.
> 
> Neil -
> 
> > (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 
> 
> Could you enlighten us as to what you are considering here.  
> Prima facia, it would appear that you are diverting further 
> from MPLS than the liaised material would indicate....
NH=> Let me state up front that I have no axe to grind wrt T-MPLS....so
all I was saying here is that folks need to look at more than just the
label field of the traffic unit and be clear they understand how this
works in T-MPLS.  
> 
> > 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?
> 
> We handle such relationships for ATM, SONET, Ethernet without 
> calling any of those MPLS.  I see no argument here for 
> including MPLS in the name of your transport technology.
NH=> This is not *my* transport technology please note.

But it seems you are missing my point here.....so let me be more
explicit.

If I take FR and ATM these represent 2 different co-ps mode layer
networks, and they use quite different traffic units...obvious, right?
It's quite clear here that misconnectivity defects between the FR and
ATM layer networks have a fundamental traffic unit conflict which makes
them impossible.

Now if I take the LDP spin of MPLS and T-MPLS these also represent 2
different layer networks but they will be based on the same traffic
unit.  So if these 2 layer networks can co-exist in the same box there
is more concern about misconnectivity.

Hopefully that clarifies my concern.

regards, Neil

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: <[email-masked]>
Date: Tue, 11 Apr 2006 19:19:55 +0100

> > > Tom,
> > > 
> > > A couple of observations on your remarks:
> > > 
> > > (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