The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] consolidated response to Q12/15 on T-MPLS
There were no comments to the contrary as far as I can tell. That is, no one commented on the list or at the meeting that leaving MPLS in the name as okay. I did however, hear at least 3 responses to explicitly strike MPLS from the name. --Tom > Tom, > > I don't know if we have consensus that we want the ITU-T to remove > "MPLS" from "T-MPLS". The issue is that we don't want anyone to > attempt to trademark any terms that include the letters "MPLS" in > that order, whether it's the ITU or a private company. > > Cheers, > Andy > > ---------- > > At 4/24/2006 09:06 -0400, Thomas D. Nadeau wrote: > >> Loa, >> >> You see to have missed one of the comments which >> came from at least 2 of the comments received during >> the WG meeting and afterwards. In particular, you >> do not ask that the "T-MPLS" name remove "MPLS" from >> the name. This probably best falls under the >> "T-MPLS trademark" subsection below. I suggest you >> simply change the subheading to "Specification Naming" >> and add a paragraph explaining the above regarding >> name change, and also include the trademark >> discussion. >> >> --Tom >> >> >>> Working Group, >>> >>> this is the consolidated list of concerns we've sent to the Q12/15. >>> >>> Note that we will further refine this list and send our formal >>> response May 17th. Further comments are welcome. >>> >>> Loa and George >>> >>> -- >>> Loa Andersson >>> >>> Principal Networking Architect >>> Acreo AB phone: +46 8 632 77 14 >>> Isafjordsgatan 22 mobile: +46 739 81 21 64 >>> Kista, Sweden email: loa.andersson@acreo.se >>> loa@pi.se >>> >>> Areas of concerns on Transport MPLS from the MPLS working group >>> =============================================================== >>> >>> To: Q12/15 >>> >>> At this point, members of the IETF are expressing their concerns on >>> Transport-MPLS on the MPLS and CCAMP mailing lists. We are working >>> to collect and evaluate these and come to a consensus response to >>> your liaison. >>> >>> The included somewhat consolidated list is still preliminary, e.g. >>> it still lacks in structure. >>> >>> However we would like to alert you that our preliminary judgment is >>> that some of the issues are of a serious nature. At least PHP, >>> signaling protocol and reserved labels are of this serious nautre. >>> >>> More careful reading of the documents reveals that there is an >>> appendix in G.8110.1 that addresses MPLS pseudowires. This document >>> should also have been liaised to the PWE3 working group in the >>> IETF as well. This appendix references draft-pan-pwe3-over-sub-ip-01 >>> this draft is no longer active. >>> >>> Requirements >>> ------------ >>> We have not seen any requirements specification for T-MPLS. >>> >>> Penultimate Hop Popping (PHP) >>> ----------------------------- >>> We discussed this several times with different ITU-T SGs and >>> Questions, we've agreed that the right way of stating this is >>> that it is "mandatory to implement, optional to use" PHP. We >>> would appreciate if the T-MPLS could adopt the same text. >>> >>> Note: We also think that it is a misconception to think that >>> non-PHP is less complex than PHP. >>> >>> Signaling protocol >>> ------------------ >>> It is nowhere specified which signaling protocol will be used for >>> for T-MPLS. >>> >>> It is also unclear if traffic engineering functionality is required. >>> >>> Note: if traffic engineering functionality is required, there >>> is a strong recommendation from the IETF to use RSVP-TE. >>> >>> Note 2: If this effort leads to requirements on changes in the IETF >>> signaling protocols this should be handled according to >>> draft-andersson-rtg-gmpls-change-02. >>> >>> Non-merging >>> ----------- >>> T-MPLS states that merging of LSPs is not used. >>> >>> Merging was introduced to address the problem with a high number >>> of LSPs in the core. How is the n-squared problem addressed in >>> T-MPLS? >>> >>> Note: It is not a given that non-merging of LSPs from a protocol >>> procedural or processing point of view necessarily is less >>> complex than a merging variant. >>> >>> Reserved labels >>> --------------- >>> MPLS reserves label values 0-15 for special use. T-MPLS at one point >>> also intended to reserve values 16-31 for similar use. It has been >>> pointed out that this will make all existing MPLS implementations >>> incompatible with T-MPLS. >>> >>> Labels 16-31 are said to be for further study. Some comments to the >>> MPLS mailing list indicates that there is no plans to assign any >>> semantics to labels 16-31. What is the reason to mention them if >>> this is the case. >>> >>> In particular does the statement imply that these label values >>> should be >>> reserved. It is our opinion that: >>> >>> 1) If they are reserved then T-MPLS is incompatible with MPLS in a >>> number of scenarios. It also would mean that T-MPLS is not a >>> subset >>> of MPLS (over and above the issue cited below). >>> >>> 2) If they are not reserved, reserving them in the future would >>> cause >>> intolerable deployment difficulties. >>> >>> In conclusion you should either say the labels are reserved and >>> clearly >>> declare that T-MPLS is not compatible with MPLS or remove the FFS >>> text >>> entirely. >>> >>> >>> True subset of MPLS >>> ------------------- >>> It has been claimed that T-MPLS is a true subset of MPLS, yet the >>> Y.1711 seems to be a part of T-MPLS. Y.1711 is not part of MPLS. >>> >>> If what is wanted is really a subset of MPLS, we believe several >>> aspects >>> has to be made clear >>> - the exact relationship to MPLS >>> - that enough functionality is there to make interoperability with >>> MPLS possible >>> - the MPLS OAM specification in RFC4377 has to be addressed >>> >>> There is previous art in defining similar "subsets" of MPLS, >>> e.g. "draft-loa-mpls-cap-set-01.txt" and >>> "draft-rosen-mpls-profiles-00.txt"; these efforts did not go very >>> far >>> since it was not obvious that they solved a real problem. >>> In general it would be good to have a clear problem statement for >>> T-MPLS. >>> >>> T-MPLS trademark >>> ---------------- >>> It has been brought to our notice that one of the parties active >>> in developing the T-MPLS has a trademark on "T-MPLS". We don't >>> know if this is a serious matter. Our postion on this is that >>> IETF owns MPLS, though we never tried to trademark it, we are for >>> open standards, and would see any attempt to use the MPLS and >>> GMPLS technologies by means of trademarking as hostile. >>> >>> Interoperability at the MPLS / T-MPLS interface >>> ----------------------------------------------- >>> Several of the issues we have are for the interoperability between >>> a T-MPLS device and an MPLS device. We can't see that these issues >>> are discussed anywhere. We believe that these issues need to be >>> addressed at least to make sure that there is no interoperability >>> problems. >>> >>> Per platform or per interface labels >>> +++++++++++++++++++++++++++++++++++ >>> For a local link repair it is crucial whether the box you are >>> talking to uses a per platform or per link label space. >>> >>> Note that if T-MPLS were to reserve labels 16-31 >>> then T-MPLS cannot have a per platform label space if the platform >>> also >>> has mpls interfaces. These labels are *NOT* reserved by MPLS and >>> are >>> extremely likely to be allocated. >>> >>> I would also like it made clear as to whether they envision T-MPLS >>> diverging on the interpretation of the EOS bit and the QoS/Exp bits. >>> >>> Global labels >>> +++++++++++++ >>> T-MPLS renames per platform labels "global labels", since global is >>> an IETF term used to signify domain wide labels, is there a >>> rationale for this renaming of platform to global? T-MPLS should >>> align with the MPLS terminology. >>> >>> TTL management and LSP tunnels >>> ++++++++++++++++++++++++++++++ >>> RFC3443 describes how TTLs are handled in LSPs tunnels. The G.8110.1 >>> state that it only supports RFC3443 for pipes and short pipes only. >>> This is a potential incompatibility with MPLS over the interface >>> between MPLS and T-MPLS networks. >>> >>> Interoperability over interface between MPLS and T-MPLS networks >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Some of the MPLS applications has been designed with certain MPLS >>> features taken for granted, e.g.: >>> >>> - pseudowires assumes per platform labels >>> - VPN assumes PHP >>> - etc >>> >>> for these applications to work as before a T-MPLS box will need to >>> have two types of interfaces. One interface that works as specified >>> in T-MPLS and another interface that works as specified in MPLS. >>> The T-MPLS needs to translate between the T-MPLS and the MPLS >>> environment since this is not in the MPLS specifications from start. >>> >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> mpls mailing list >> mpls@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|