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
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
|
|