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

["Thomas D. Nadeau" <[e-mail]>]

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

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