The MPLS WG Archive

[Loa Andersson <loa@pi.se>]

All,

this is the very preliminary information we sent to Q12/15 on
T-MPLS. The intention is to consolidate it further during this
week.

Comments appreciated.

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 list included here is preliminary. For the next version issues
might be added or cleared.

However we would like to alert you that our preliminary judgment is
that some of the issues are of a serious nature.

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.

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 that it is not a given that non-merging of LSPs is from a
protocol procedural or processing point of view necessarily 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 is 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.


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 it interoperable with MPLS
- 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.

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.

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.

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.

Global labels
+++++++++++++
T-MPLS renames per platform labels "global labels", since this it a 
term used for to signify domain wide labels. 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 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 to 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