The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] Re: [PWE3] New Liaison Statement,"Response to PWE3 and MPLS WG concerns with G.8110.1 Amendment 1"
Italo Busi wrote: > Yaakov, > > actually G.8110.1 Amendment 1 inserts the following statement at the end of the > Scope clause of G.8110.1: > > " > Equipment developed prior to the production of this Recommendation is not > expected to comply with this Recommendation. > " > > What that says is that MPLS equipment is not expected to comply with the T-MPLS design. I am not sure how concerned we need to be about that. What is of concern is the inverse i.e. that T-MPLS - which runs on the same code-point as MPLS - MUST comply with the MPLS design, and the sentence above does not address that concern. The concern here is that nothing in T-MPLS breaks MPLS (historic, current or future) in any MPLS deployment scenario. > Note that the fact that T-MPLS is not intended for deployment inside existing > IP/MPLS networks does not mean that T-MPLS shall not interwork with IP/MPLS. > Hm - I am sure I saw Maartin present a contribution at ITU showing an T-MPLS equipment interworking with an MPLS equipment - could you make a copy of the contribution available to the IETF? The first half of the sentence is clearly incorrect, in that IF T-MPLS is ever deployed, MPLS WILL be carried over T-MPLS. Given that LSRs terminate other transport network interfaces - SDH, SONET, T1/E1, Ethernet, the clear expectation is that future integration needs will mean that LSRs will need to terminate T-MPLS transport network interfaces. Therefore one equipment will need to be able to process MPLS and T-MPLS packets without ambiguity. As we have said there are two ways to do this, either provide some clear method of discrimination - for example a separate set of codepoints, or provide complete compatibility - which requires T-MPLS to call by reference the MPLS specs so that there is no distinction between the two protocols. I suppose one could take another approach and specify a mandatoty mechanism whereby presence of MPLS poisons the T-MPLS network so that if anyone ever attempts to interconnect MPLS and T-MPLS, the T-MPLS network crashes. Given the SG15 conviction that MPLS and T-MPLS will never be interconnected there should be no objection to the inclusion of this feature :) > SDH, OTH and WDM are networks disjoint from IP/MPLS networks but these networks > interoperate (via a client/server relationship). > Firstly from the above you clearly accept my point that an LSR will need to terminate T-MPLS just as it does SDH etc. Secondly the key difference is that there is no way that an an equipment can be become confused about whether it is dealing with an SDH frame or an IP packet. Here the ITU has deliberately constructed a mechanism whereby it is impossible to determine whether a packet is an MPLS packet or a T-MPLS packet, and that is the root of our concern and needs to be addressed. - Stewart _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|