The MPLS WG Archive

["Sasha Vainshtein" <Sasha@AXERRA.com>]

Italo and all,
Please see inline below.

Regards,
                Sasha


-----Original Message-----
From: Italo Busi [mailto:Italo.Busi@alcatel-lucent.it] 
Sent: Friday, June 29, 2007 10:37 AM
To: Sasha Vainshtein; 'Yaakov Stein'; stbryant@cisco.com
Cc: mpls@lists.ietf.org; pwe3@ietf.org
Subject: RE: [mpls] RE: [PWE3] New Liaison Statement,"Response to PWE3
and MPLS WG concerns with G.8110.1 Amendment 1"

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.
"
[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

> -----Original Message-----
> From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]
> Sent: Thursday, June 28, 2007 8:18 AM
> To: Yaakov Stein; stbryant@cisco.com
> Cc: mpls@lists.ietf.org; pwe3@ietf.org
> 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.
> 
> 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:yaakov_s@rad.com]
> Sent: Thursday, June 28, 2007 9:07 AM
> To: stbryant@cisco.com
> Cc: mpls@lists.ietf.org; pwe3@ietf.org
> 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
>   "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:stbryant@cisco.com]
> Sent: Tuesday, June 26, 2007 22:55
> Cc: mpls@lists.ietf.org; pwe3@ietf.org
> 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.
> 
> 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
> 
> 
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
> 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 


_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls