The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] New Liaison Statement, "T-MPLS Consented Recommendatio ns"
> > 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 [snipped] _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls |
|