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 Recommendations"
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 mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls |
|