The MPLS WG Archive

[Loa Andersson <loa@pi.se>]

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:  +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 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
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls