Subject: [PWE3] New Liaison Statement, "Response to PWE3 and MPLS WG concerns with G.8110.1 Amendment 1"

From: Greg Jones (ITU-T SG 15) <[email-masked]>
Date: Tue, 26 Jun 2007 09:57:24 -0400

Title: Response to PWE3 and MPLS WG concerns with G.8110.1 Amendment 1
Submission Date: 2007-06-26
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=345 

From: Greg Jones(ITU-T SG 15) <[email-masked]>
To: IETF PWE3 and MPLS WGs([email-masked],[email-masked],[email-masked],[email-masked])
Cc: [email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
Reponse Contact: [email-masked]
Technical Contact: [email-masked]
Purpose: For information 
Body: 
Attachment(s):
     Response to PWE3 and MPLS WG concerns with G.8110.1 Amendment 1 - body text (https://datatracker.ietf.org/documents/LIAISON/file453.doc)

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 26 Jun 2007 20:54:40 +0100

The IETF response to our liaison of draft-ietf-pwe3-mpls-transport-00.txt
was sent as a word document. To make sure that all members of PWE3 are 
able to read it, I have extracted the substantive text as ASCII.

I have major concerns about the assumption of disjoint operation since I 
cannot see how the T-MPLS protocol prevents this.

I request WG input on how to respond to this liaison.

- Stewart

======

Thank you for your liaison statement “PWE3 and MPLS WG response to 
G.8110.1 Amendment 1”. 

We note your concerns with our work on T-MPLS and your draft 
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-transport-00.txt.

It appears that the work in the IETF is addressing some different 
requirements:

“Input from network operators indicates that the key requirements is the 
transparent carriage of the MPLS network of one party over the MPLS 
network of another party, with the constraint that the MPLS design MUST 
NOT be changed and that the solution MUST be compatible with their 
existing large base of already deployed MPLS networks.”

Some members of SG 15 expressed support for these requirements.  
However, the basis for the work in SG 15 has been the development of a 
packet switched network that meets all of the network operators 
transport operations requirements.  The assumption we have made is that 
when deploying T-MPLS for this purpose it will be deployed on a network 
that is disjoint from any already deployed IP/MPLS network.

Equipment developed prior to the approval of the T-MPLS Recommendations 
is not expected to comply with these Recommendations.

Our intention in developing the suite of T-MPLS Recommendations is to 
define a packet based transport network technology.  The design 
objectives of T-MPLS are:

a) Follow the principles of the transport network used in other ITU-T 
defined transport technologies (e.g SDH, ATM, OTN).

b) To use the PDU and forwarding plane processes defined by the IETF for 
MPLS.

After the presentation of the Liaison Statement the following was noted:

•    T-MPLS OAM mechanisms have been developed by ITU-T G.8114/Y.1373 to 
provide transport-like fault and performance monitoring capabilities 
including alarm suppression, packet loss measurements and support of 
multiple ownerships

•    T-MPLS protection mechanisms have been developed by ITU-T G.8131 to 
provide transport-like protection schemes including trail and 
sub-network protection

•    The separation between the data plane and the control plane is a 
major requirement in transport networks

An electronic copy of this liaison statement is available at:
http://ties.itu.ch/ftp/public/itu-t/tsg15opticaltransport/COMMUNICATIONS/

---

From: "Kyung-Yeop Hong \(hongk\)" <[email-masked]>
Date: Tue, 26 Jun 2007 19:01:37 -0400

I attended the discussion at the ITU-T SG15 meeting in Geneva when
Stewart presented the IETF liaison of
draft-ietf-pwe3-mpls-transport-00.txt.

Some members of SG15, including major carriers and vendors, expressed
their support for the IETF draft, and requested to include their
opinions in the response liaison statement. However, their requests were
not taken.
Stewart was there so he knows this as well.

It is surprising that this response liaison does not reflect the reality
of the discussion occurred at the SG15 meeting.

Kyung-Yeop

-----Original Message-----
From: Stewart Bryant (stbryant) 
Sent: Tuesday, June 26, 2007 3:55 PM
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] New Liaison Statement,"Response to PWE3 and MPLS WG
concerns with G.8110.1 Amendment 1"

The IETF response to our liaison of
draft-ietf-pwe3-mpls-transport-00.txt
was sent as a word document. To make sure that all members of PWE3 are 
able to read it, I have extracted the substantive text as ASCII.

- Stewart

======

Thank you for your liaison statement "PWE3 and MPLS WG response to 
G.8110.1 Amendment 1". 

We note your concerns with our work on T-MPLS and your draft 
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-transport-00.tx
t.

"Input from network operators indicates that the key requirements is the

transparent carriage of the MPLS network of one party over the MPLS 
network of another party, with the constraint that the MPLS design MUST 
NOT be changed and that the solution MUST be compatible with their 
existing large base of already deployed MPLS networks."

MPLS.

*    T-MPLS OAM mechanisms have been developed by ITU-T G.8114/Y.1373 to

*    T-MPLS protection mechanisms have been developed by ITU-T G.8131 to

*    The separation between the data plane and the control plane is a 
major requirement in transport networks

An electronic copy of this liaison statement is available at:
http://ties.itu.ch/ftp/public/itu-t/tsg15opticaltransport/COMMUNICATIONS
/

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 28 Jun 2007 09:06:36 +0300

Stewart, 

If SG15's position is
  "The assumption we have made is that when deploying T-MPLS for this
purpose 
   it will be deployed on a network that is disjoint from any already
deployed IP/MPLS network."
then they should explicitly state a limitation in the scope section of
the new Recommendation.

I recall several times when as editor I was forced to add such
limitations.

Something like
  "The protocol described in the Recommendation shall not be deployed in
any existing IP/MPLS network,
   nor shall it interwork in any fashion with such a network."

Y(J)S

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Tuesday, June 26, 2007 22:55
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] New Liaison Statement,"Response to PWE3 and MPLS WG

- Stewart

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Thu, 28 Jun 2007 09:17:43 +0300

Yaakov, Stewart and all.

IMHO the only real way to assure disjoint operation of MPLS and T-MPLS 
is to allocate dedicated protocol numbers (EtherType etc.) for T-MPLS.
Such an allocation would not harm T-MPLS in any way.

On the contrary, to the best of my understanding, usage of the same
protocol 
numbers cannot not serve any purpose beyond facilitating MPLS/T-MPLS 
interworking (be it intentional or not).

So I suggest we resurrect our old proposal to SG15 to switch to a
different
set of protocol numbers.

My 2c.

Regards,
                     Sasha

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: Thursday, June 28, 2007 9:07 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] RE: [PWE3] New Liaison Statement,"Response to PWE3 and
MPLS WG concerns with G.8110.1 Amendment 1"

Stewart, 

If SG15's position is

Something like

Y(J)S

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Tuesday, June 26, 2007 22:55
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] New Liaison Statement,"Response to PWE3 and MPLS WG

- Stewart

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Italo Busi" <[email-masked]>
Date: Fri, 29 Jun 2007 09:17:06 +0200

Yaakov,

actually G.8110.1 Amendment 1 inserts the following statement at the end of the
Scope clause of G.8110.1:

"
Equipment developed prior to the production of this Recommendation is not
expected to comply with this Recommendation.
" 

Note that the fact that T-MPLS is not intended for deployment inside existing
IP/MPLS networks does not mean that T-MPLS shall not interwork with IP/MPLS.

SDH, OTH and WDM are networks disjoint from IP/MPLS networks but these networks
interoperate (via a client/server relationship).

Italo

> Sent: Thursday, June 28, 2007 8:07 AM
> To: [email-masked]
> Subject: RE: [PWE3] New Liaison Statement,"Response to PWE3 
> and MPLS WG concerns with G.8110.1 Amendment 1"
> 
> Stewart, 
> 
> If SG15's position is

---

From: "Italo Busi" <[email-masked]>
Date: Fri, 29 Jun 2007 09:37:28 +0200

Sasha,

when the issue was discussed during the approval phase of G.8110.1, appendix III
was added to G.8110.1 to clarify why T-MPLS reuses the same protocol number
(e.g. EtherType) of MPLS and which are the implications for that.

In particular this appendix clearly states that:

"
When a pakcet is received on an Ethernet interface with EtherType 0x8847, it is
looked up in one particular label space as defined in IETF RFC 3031 section 3.4.

The label manager is responsible for the allocation and reclamation of the
labels that are used within an MPLS or T-MPLS adaptation function.
"

Given this behavior, I cannot understand any real technical argument in favour
of a different protocol number (e.g. EtherType).

T-MPLS and MPLS have the same forwarding plane. As you have stated, having the
same forwarding plane (including the same protocol number) is facilitating
MPLS/T-MPLS interworking.

This is for me another good technical reason not to change the protocol number
(e.g. EtherType).

Best regards, Italo

> From: Sasha Vainshtein [mailto:[email-masked]] 
> Sent: Thursday, June 28, 2007 8:18 AM
> To: Yaakov Stein; [email-masked]
> Subject: RE: [mpls] RE: [PWE3] New Liaison 
> Statement,"Response to PWE3 and MPLS WG concerns with 
> G.8110.1 Amendment 1"
> 
> Yaakov, Stewart and all.
>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 29 Jun 2007 14:42:20 +0100

> expected to comply with this Recommendation.
What that says is that MPLS equipment is not expected to comply with the 
T-MPLS design. I am not sure how concerned we need to be about that.

What is of concern is the inverse i.e. that T-MPLS - which runs on the 
same code-point as MPLS - MUST comply with the MPLS design, and the 
sentence above does not address that concern.

The concern here is that nothing in T-MPLS breaks MPLS (historic, 
current or future) in any MPLS deployment scenario.

> IP/MPLS networks does not mean that T-MPLS shall not interwork with IP/MPLS.
Hm - I am sure I saw Maartin present a contribution at ITU showing an 
T-MPLS equipment interworking with an MPLS equipment - could you make a 
copy of the contribution available to the IETF?

The first half of the sentence is clearly incorrect, in that IF T-MPLS 
is ever deployed, MPLS WILL be carried over T-MPLS. Given that LSRs 
terminate other transport network interfaces - SDH, SONET, T1/E1, 
Ethernet, the clear expectation is that future integration needs will 
mean that LSRs will need to terminate T-MPLS transport network 
interfaces. Therefore one equipment will need to be able to process MPLS 
and T-MPLS packets without ambiguity.

As we have said there are two ways to do this, either provide some clear 
method of discrimination - for example a separate set of codepoints, or 
provide complete compatibility - which requires T-MPLS to call by 
reference the MPLS specs so that there is no distinction between the two 
protocols.

I suppose one could take another approach and specify a mandatoty 
mechanism whereby presence of MPLS poisons the T-MPLS network so that if 
anyone ever attempts to interconnect MPLS and T-MPLS, the T-MPLS network 
crashes. Given the SG15 conviction that MPLS and T-MPLS will never be 
interconnected there should be no objection to the inclusion of this 
feature :)
> interoperate (via a client/server relationship).
Firstly from the above you clearly accept my point that an LSR will need 
to terminate T-MPLS just as it does SDH etc.

Secondly the key difference is that there is no way that an an equipment 
can be become confused about whether it is dealing with an SDH frame or 
an IP packet. Here the ITU has deliberately constructed a mechanism 
whereby it is impossible to determine whether a packet is an MPLS packet 
or a T-MPLS packet, and that is the root of our concern and needs to be 
addressed.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 29 Jun 2007 14:46:48 +0100

Italo

Can we be crystal clear on this - is MPLS/T-MPLS interworking allowed or 
not?

Stewart

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Fri, 29 Jun 2007 20:19:33 +0300

Italo and all,
Please see inline below.

Regards,
                Sasha

-----Original Message-----
From: Italo Busi [mailto:[email-masked]] 
Sent: Friday, June 29, 2007 10:37 AM
To: Sasha Vainshtein; 'Yaakov Stein'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] RE: [PWE3] New Liaison Statement,"Response to PWE3

Sasha,

when the issue was discussed during the approval phase of G.8110.1,
appendix III was added to G.8110.1 to clarify why T-MPLS reuses the same
protocol number (e.g. EtherType) of MPLS and which are the implications
for that.

"
When a pakcet is received on an Ethernet interface with EtherType
0x8847, it is looked up in one particular label space as defined in IETF
RFC 3031 section 3.4.

The label manager is responsible for the allocation and reclamation of
the labels that are used within an MPLS or T-MPLS adaptation function.
"
[Sasha] The problem, IMHO, is that the existing "label managers" (used
by the MPLS label distribution protocols) are NOT aware of
this distinction since it is NOT part of the existing MPLS control plane
specs. 
The text you've quoted implicitly assumes  that the MPLS control plane
(specified, implemented and deployed) and the T-MPLS management plane
MUST interwork properly (by splitting the label spaces) in order to
prevent T-MPLS being poisoned by MPLS or vice versa. This sounds like
imposing a new requirement on the MPLS control protocols designed by the
IETF.
Did I miss something?

Given this behavior, I cannot understand any real technical argument in
favour of a different protocol number (e.g. EtherType).

T-MPLS and MPLS have the same forwarding plane. As you have stated,
having the same forwarding plane (including the same protocol number) is
facilitating MPLS/T-MPLS interworking.

This is for me another good technical reason not to change the protocol
number (e.g. EtherType).

[Sasha] I am completely confused now. Are MPLS and T-MPLS supposed to
interwork, or not?
Please note also that the current designs for, say P2MP (multicast) LSPs
use (to some extent) mapping of the protocol numbers to label spaces.
Hence using a separate protocol number for T-MPLS would be in line with
the common trend.

Best regards, Italo

> Subject: RE: [mpls] RE: [PWE3] New Liaison Statement,"Response to PWE3

> protocol numbers cannot not serve any purpose beyond facilitating 
> MPLS/T-MPLS interworking (be it intentional or not).
> 
> different set of protocol numbers.
> 
> My 2c.
> 
> Regards,
>                      Sasha
>  
> 

>   "The protocol described in the Recommendation shall not be deployed 
> in any existing IP/MPLS network,
> Subject: Re: [PWE3] New Liaison Statement,"Response to PWE3 and MPLS 
> WG concerns with G.8110.1 Amendment 1"
> 

> I have major concerns about the assumption of disjoint operation since

> I cannot see how the T-MPLS protocol prevents this.
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 29 Jun 2007 13:26:32 -0400

> Hence using a separate protocol number for T-MPLS would be in line  

	This is clearly what is the most ridiculous part here.
If we just keep MPLS <= T-MPLS "interworking" or any other translation
functions are a non-issue. Let us please keep things simple.

	--Tom

---

From: Phil Bedard <[email-masked]>
Date: Fri, 29 Jun 2007 15:20:30 -0400

Excuse me if this has already been covered, I've just read some of  
the current messages and to me it seems the definition of  
"interworking" needs to be better defined in these discussions.   To  
me interworking is a translation function on the same data plane, not  
one framing technology encapsulating another.   The connection- 
oriented specifications of T-MPLS seem to not allow its frames to be  
translated and carried on an IP/MPLS network without special  
treatment, unless I'm mistaken.   So there really isn't  
"interworking".    The fact they use the same forwarding plane,  
packet format, and codepoints seems to confuse things.   If they are  
truly distinct protocols that serve different purposes, as the T-MPLS  
advocates seem to say, then clear separation needs to be made between  
the two.

Phil

On Jun 29, 2007, at 1:19 PM, Sasha Vainshtein wrot