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

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

	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