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

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

Loa,

Good summary of the discussion so far.

I think we should ask Q12/15 for clarification on is how MPLS and 
T-MPLS equipment are expected or required to interoperate.  As I 
understand it, T-MPLS operates at the transport layer (layer 1), and 
as such may provide transport services for MPLS networks.  In this 
scenario, there may be a physical or logical interface between an 
MPLS LSR and a T-MPLS switch, so that MPLS packets may be transported 
on T-MPLS LSPs at Layer 1.  One could (should?) expect that the MPLS 
packets arriving on such an interface (say, PoS as an example) would 
be transparently transported across the T-MPLS network to the 
destination LSR.  In this scenario, the MPLS LSRs are CEs to the 
T-MPLS network.

So, I guess we need to know whether or not the T-MPLS equipment will 
do any MPLS-layer processing of the packets, or simply transparently 
transport them without inspection or change, and what signaling (if 
any) would be used across this interface.

The details of this interface would will dictate the interoperability 
requirements between MPLS LSRs and T-MPLS switches.

Cheers,
Andy

-------------

At 4/22/2006 00:11 +0200, Loa Andersson wrote:
>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