Subject: [PWE3] ITU-T SG 15 liaison - G.8110.1 amendment 1 (https://datatracker.ietf.org/liaison/344/)

From: Stewart Bryant <[email-masked]>
Date: Tue, 17 Jul 2007 17:36:34 +0100

I have been looking at the ITU liaison addressed to PWE3 and MPLS WGs

June 2007 ITU-T SG 15 IETF PWE3 and MPLS WGs G.8110.1 amendment 1 
(https://datatracker.ietf.org/liaison/344/)

and would appreciate input to a suitable response. This liaison will be 
a topic on the PWE3 agenda.

I have removed the elements of the response where SG15 has agree with 
our comments and edited their text accordingly.

The following points remain:

Section 3.5 Transport MPLS definition
"Should be amended to make it clear TMPLS is a true subset of IETF PWE3 
over MPLS and that in the case of any differences, the IETF definition 
is considered the Normative definition."

SG15 Response:
"G.8110.1 describes the behaviour of a T-MPLS network. Following a 
discussion of your liaison statement it was agreed to clarify that 
T-MPLS uses a subset of the MPLS forwarding plane behaviour. For OAM 
only label 14 is used and hence only “ITU” mechanisms are supported. It 
is also assumed that MPLS and T-MPLS are deployed as disjoint networks. 
An LSP initiated from an IP/MPLS network element is encapsulated in 
Ethernet before it transits a T-MPLS network. Similarly if IP/MPLS is 
used as a server layer for T-MPLS then an LSP initiated from a T-MPLS 
network element is encapsulated in Ethernet before it transits an 
IP/MPLS network. This enforces the independence of the control planes 
for T-MPLS and IP/MPLS. Further as is customary with ITU-T 
Recommendations, equipment designed before the approval of the 
Recommendations is not expected to meet all the requirements of the new 
Recommendation."

SB - I have two concerns regarding this:

1) The statement "assumed that MPLS and T-MPLS are deployed as disjoint 
networks" MUST be backed up by some technical means to ensure that MPLS 
and T-MPLS remain disjoint, otherwise the assumption does not hold and 
someone will attempt interworking. Indeed a contribution at the ITU 
meeting that prepared this response proposed exactly that.

2) "as is customary with ITU-T Recommendations, equipment designed 
before the approval of the Recommendations is not expected to meet all 
the requirements of the new Recommendation."

I think that we need to note that we are not concerned about existing 
MPLS equipment being compliant with T-MPLS, but rather we are concerned 
that T-MPLS or any future enhancement to T-MPLS should not cause a 
conflict with the installed base of existing MPLS equipment, or any 
future IETF development of MPLS, or that it should inhibit some future 
development of MPLS.

Section 4.7.2 and A.3
"The PWE3 WG is concerned that the OAM is not based on VCCV. Any true 
subset of the IETF PWE3/MPLS design should allow the use of the IETF 
preferred OAM mechanism. This does not preclude the ITU specifying an 
additional mechanism as an optional extension to enhance VCCV, although 
it would be preferable for the ITU to work with the IETF to enhance VCCV 
to provide the additional OAM mechanisms that are needed."

"At a previous meeting SG 15 decided to base T-MPLS OAM on Y.1711 and 
requested Q5/13 to enhance the OAM mechanisms based on Y.1711. Based on 
this request Q5/13 developed Y.1373/G.8114, the amendment to G.8110.1 
adds a reference to Y.1373/G.8114. As described above, we expect T-MPLS 
and MPLS to be deployed as disjoint networks and as is customary with 
ITU-T Recommendations, equipment designed before the approval of the 
Recommendations is not expected to meet all the requirements of the new 
Recommendation. We do not anticipate any compatibility issues."

SB - Again, given the existence of a simple solution to ensure that no 
compatibility issue can exist (discriminating codepoint, I do not 
believe such anticipation is good enough.

What is the view of other members of the IETF?

- Stewart

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 18 Jul 2007 09:19:19 -0400

On Jul 17, 2007:12:36 PM, at 12:36 PM, Stewart Bryant wrote:

> and would appreciate input to a suitable response. This liaison  
> will be a topic on the PWE3 agenda.
>
> I have removed the elements of the response where SG15 has agree  
> with our comments and edited their text accordingly.
>
> "Should be amended to make it clear TMPLS is a true subset of IETF  
> PWE3 over MPLS and that in the case of any differences, the IETF  
> definition is considered the Normative definition."
>
> SG15 Response:
> T-MPLS uses a subset of the MPLS forwarding plane behaviour. For  
> OAM only label 14 is used and hence only “ITU” mechanisms are  
> supported. It is also assumed that MPLS and T-MPLS are deployed as  
> disjoint networks. An LSP initiated from an IP/MPLS network element  
> is encapsulated in Ethernet before it transits a T-MPLS network.  
> Similarly if IP/MPLS is used as a server layer for T-MPLS then an  
> LSP initiated from a T-MPLS network element is encapsulated in  
> Ethernet before it transits an IP/MPLS network. This enforces the  
> independence of the control planes for T-MPLS and IP/MPLS. Further  
> as is customary with ITU-T Recommendations, equipment designed  
> before the approval of the Recommendations is not expected to meet  
> all the requirements of the new Recommendation."
>
> 1) The statement "assumed that MPLS and T-MPLS are deployed as  
> disjoint networks" MUST be backed up by some technical means to  
> ensure that MPLS and T-MPLS remain disjoint, otherwise the  
> assumption does not hold and someone will attempt interworking.  
> Indeed a contribution at the ITU meeting that prepared this  
> response proposed exactly that.
>
> before the approval of the Recommendations is not expected to meet  
> all the requirements of the new Recommendation."
>
> I think that we need to note that we are not concerned about  
> existing MPLS equipment being compliant with T-MPLS, but rather we  
> are concerned that T-MPLS or any future enhancement to T-MPLS  
> should not cause a conflict with the installed base of existing  
> MPLS equipment, or any future IETF development of MPLS, or that it  
> should inhibit some future development of MPLS.
>
>
> Section 4.7.2 and A.3
> "The PWE3 WG is concerned that the OAM is not based on VCCV. Any  
> true subset of the IETF PWE3/MPLS design should allow the use of  
> the IETF preferred OAM mechanism. This does not preclude the ITU  
> specifying an additional mechanism as an optional extension to  
> enhance VCCV, although it would be preferable for the ITU to work  
> with the IETF to enhance VCCV to provide the additional OAM  
> mechanisms that are needed."
>
> "At a previous meeting SG 15 decided to base T-MPLS OAM on Y.1711  
> and requested Q5/13 to enhance the OAM mechanisms based on Y.1711.  
> Based on this request Q5/13 developed Y.1373/G.8114, the amendment  
> to G.8110.1 adds a reference to Y.1373/G.8114. As described above,  
> we expect T-MPLS and MPLS to be deployed as disjoint networks and  
> as is customary with ITU-T Recommendations, equipment designed  
> before the approval of the Recommendations is not expected to meet  
> all the requirements of the new Recommendation. We do not  
> anticipate any compatibility issues."
>
> SB - Again, given the existence of a simple solution to ensure that  
> no compatibility issue can exist (discriminating codepoint, I do  
> not believe such anticipation is good enough.
>
	
	We should (again) return a statement to the above reply
stating that OAM must be based on VCCV, or at least that is
the preferred (default) OAM mechanism. This is only logical if
we (IETF) insist as is asserted above, that PWE3's definition of
PW/MPLS is the normative reference for TMPLS.

	--Tom