Re: [mpls] consolidated response to Q12/15 on T-MPLS

["Andrew G. Malis" <[e-mail]>]

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:  [phone]
>>Isafjordsgatan 22                  mobile: [phone]
>>Kista, Sweden                      email:  [e-mail]
>>                                            [e-mail]
>>
>>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
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/mpls
>
>_______________________________________________
>mpls mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/mpls


_______________________________________________
mpls mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpls