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

From: Loa Andersson <[email-masked]>
Date: Sat, 22 Apr 2006 00:11:42 +0200

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:  [email-masked]
                                            [email-masked]

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sun, 23 Apr 2006 03:36:36 -0400

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

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

---

From: Scott W Brim <[email-masked]>
Date: Sun, 23 Apr 2006 06:37:29 -0400

On 04/23/2006 03:36 AM, Andrew G. Malis allegedly wrote:
> 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.

That's the plan as far as I know, but I don't think it has been
completely spelled out.

Another interesting scenario is where a device has both "full" MPLS and
T-MPLS LSPs on the same interface.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 24 Apr 2006 09:06:27 -0400

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 24 Apr 2006 10:21:04 -0400

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

----------

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 24 Apr 2006 11:13:17 -0400

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

---

From: Scott W Brim <[email-masked]>
Date: Mon, 24 Apr 2006 11:27:46 -0400

> at least 3 responses to explicitly strike MPLS

I spoke against insisting on renaming, although maybe not on this list.
 So far the ITU-T's stated intention is to define a subset of MPLS, not
to create something new.  See their liaison: "The intent of these
Recommendations is not to change MPLS but rather to identify a subset of
existing MPLS necessary and sufficient to provide connection-oriented
packet transport."  There is no need or advantage to asking them to take
"MPLS" out of their name until it is clearly no longer a subset.  That
will depend on how the current discussion goes.  Let's not create the
future we are concerned about.

You bring up trademark.  That's unrelated -- it's not the IETF and the
ITU, it's between the IETF and whoever trademarked something with "MPLS"
in it.

Thanks ... Scott

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Mon, 24 Apr 2006 16:41:49 -0500

Also client processing is different - T-MPLS has T-MPLS client-specific
processes (Section 7 lists clients as IP, Ethernet, ATM, MPLS, T-MPLS).
The new amendment to G.8010 (unfortunately not liaisoned) clearly shows
two different processes (e.g. Ethernet/MPLS, Ethernet/T-MPLS). 

Having here a weekend of rainy weather with time to read, T-MPLS
features are listed in section 6.1, including:
- supports bidirectional LSPs
- supports control channel separation
- supports only Y.1720 protection switching (ITU's 1+1 scheme based on
sequence numbers)

To me, it "looks" somewhat like GMPLS (and similar application -
transport equipment), though it's labeled MPLS, and supports different
functionality than MPLS or GMPLS. The control plane is tbd. It is
difficult to comment if it is a subset of MPLS (or GMPLS) - without a
clear statement of the requirements and understanding of the
modifications to the "superset".

Especially interesting will be e-2-e operations when Figure 5's "foreign
TMPLS network" is present in a not-so-clean scenario of cloudy networks.

Deborah

-----Original Message-----
From: Scott W Brim [mailto:[email-masked]] 
Sent: Sunday, April 23, 2006 6:37 AM
To: Andrew G. Malis
Cc: [email-masked]
Subject: Re: [mpls] consolidated response to Q12/15 on T-MPLS

> So, I guess we need to know whether or not the T-MPLS equipment will
do
> transport them without inspection or change, and what signaling (if
any)

---

From: Loa Andersson <[email-masked]>
Date: Wed, 26 Apr 2006 15:32:35 +0200

All,

(taking the chair hat off)

I agree with Scott here. This one of the rasons why we have
put effort on writing the (g)mpls-change-process.

IETF should have conrol over the MPLS protocols, "non-MPLSing"
T-MPLS just makes this harder. Insisting in renaming would
just feed the trolls that want split out an ITU-MPLS.

(hat back on - my kids tells me I looks ridiculous in a hat ;) )

but anyway please feel free to have opinions on the (re-)naming
issue.

/Loa

-- 
Loa Andersson

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 26 Apr 2006 10:58:05 -0400

> put effort on writing the (g)mpls-change-process.
	
	All things being equal, if the change process
was followed, I think the situation would be
quite different here.  Unfortunately, things aren't
equal because they (ITU) didn't follow the process,
and so we are in this situation.  This also begs the
question of will this happen again in the future?

	I wonder if there is some way to rewind the process
within the ITU and have the document start over there
and go through the liaison and g/mpls-change-process? Not
being an ITU process geek, I have no idea.

> just feed the trolls that want split out an ITU-MPLS.

	If T-MPLS is a true sub-set of MPLS then the
naming is not so much of an issue IMHO. That is, if
T-MPLS is simply a (configurable) subset of functionality.
However, it is clear that the existing document as
well as recently announced amendments to it, are
straying from what I defined as a subset.  In particular,
the OAM as defined is *completely* different from what
the IETF specifications stipulate, and there are
reserved labels w/o semantics.  In the case of the latter,
there have been recent follow-on contributions that
are taking a stab at defining these reserved labels, and
these are troubling, especially based on the discussion of
interop. that was voiced earlier. In this case, I
think it is damaging to call the specification
"*-MPLS" because it forms the basis for an "ITU-MPLS"
that can then not only wildly diverge from what we
have defined here (and what is deployed and certainly
working!), but also be confused with said deployed version
in the marketplace.

> (hat back on - my kids tells me I looks ridiculous in a hat ;) )

	I won't comment on that. *)

	--Tom