Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 26 Jan 2010 21:49:36 +0200

Maarten,
I has believed - and still believe - that Ethernet data plane has been defined (and continues to be defined via multiple updates) by the IEEE 802.1 teams, since 802.1 is the "design authority " for the Ethernet technology - just as IETF is a design authority for MPLS technology and its derivatives.

As for differences between Ethernet and MPLS actual data planes - I think those are well known, no need to repeat myself.

I firmly believe that attempts to disregard actual data plane differences for the sake of imposing a unified OAM model will eventually fail.

Regards,
     Sasha

________________________________
From: Maarten Vissers [[email-masked]]
Sent: Tuesday, January 26, 2010 7:14 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Sasha,

You have an incorrect understanding of the background of Y.1731.
Y.1731 is created by ITU-T SG13 with the help of SG15. The work started in 2002 and was initiated by the deployment of Ethernet in transport networks where it replaced SDH equipment. The performance of those initial deployments were extremely poor due to lack of OAM and protection. Set up of VLANs was done by NMS. In the same year work on Ethernet over Transport architecture was initiated in SG15 (by me :-) ), quickly expanding in the development of a series of recommendations specifying the Ethernet as a transport technology.

802.1ag was started later, and implements only a subset of the Y.1731 toolset; i.e. the subset which spanning tree protocol/vlan registration protocol controlled ethernet switches specified in 802.1 would need and can use. But ITU-T SG13/15 and IEEE 802.1 made sure that there is interworking possible between networks using Y.1731 and networks using 802.1ag.

Ethernet switches compliant with ITU-T's Ethernet recommendations are transport network grade switches (with VLAN ID translation capabilities (e.g. VID translation, PW label swapping) in every node), which are managed by NMS and optionally the GMPLS control plane.

The Ethernet data plane specified in the ITU-T Recommendations supports all MPLS(-TP) data plane capabilities plus it supports rmp and mp2mp Ethernet VC connections. Some operators have recognized this and have build their packet transport network with a UNI-to-UNI Ethernet VC layer as their transport service layer; transport path layer technologies used are Ethernet VP and MPLS(-TP) VP. The efficient rooted-multipoint Ethernet VC connections are used for broadband backhaul in such networks, p2p Ethernet VC connections are used to support any type of Line service and mp2mp Ethernet VC connections are used to support E-LAN services. With the growing bandwidth demand OTN ODUs will be added in the near future as transport path layer technology to carry the Ethernet VC connections between S-PE nodes. MPLS and Ethernet data planes in such networks are managed in the same way. Ethernet Transport Networks (ETN) exist for many years already and are proven technology.

It is on this basis that I continue to state that the MPLS(-TP) and (ITU-T Ethernet recommendations based) Ethernet VLAN data plane functionalities are the same and that we can and should use the very similar OAM, protection switching and the same management principles. T-MPLS was fully based on this understanding and approach, and was designed to seamlessly operate in a hybrid T-MPLS/Ethernet packet transport network. My hope is that seamless interoperability will also be possible in the emerging hybrid MPLS-TP/Ethernet packet transport networks.

Regards,
Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 27 Jan 2010 00:43:16 +0100

Sasha,
 
This is getting into a yes/no discussion at this point in time.
We have a different understanding. 
Each of us believe what we believe, based on the work we have been doing so
far.
Thanks for the discussion.
 
Regards,
Maarten

  _____  

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: dinsdag 26 januari 2010 20:50
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Maarten,
I has believed - and still believe - that Ethernet data plane has been
defined (and continues to be defined via multiple updates) by the IEEE 802.1
teams, since 802.1 is the "design authority " for the Ethernet technology -
just as IETF is a design authority for MPLS technology and its derivatives. 
 
As for differences between Ethernet and MPLS actual data planes - I think
those are well known, no need to repeat myself.
 
I firmly believe that attempts to disregard actual data plane differences
for the sake of imposing a unified OAM model will eventually fail.
 
Regards,
     Sasha
 
  _____  

Sasha,
 
You have an incorrect understanding of the background of Y.1731.
Y.1731 is created by ITU-T SG13 with the help of SG15. The work started in
2002 and was initiated by the deployment of Ethernet in transport networks
where it replaced SDH equipment. The performance of those initial
deployments were extremely poor due to lack of OAM and protection. Set up of
VLANs was done by NMS. In the same year work on Ethernet over Transport
architecture was initiated in SG15 (by me :-) ), quickly expanding in the
development of a series of recommendations specifying the Ethernet as a
transport technology. 
 
802.1ag was started later, and implements only a subset of the Y.1731
toolset; i.e. the subset which spanning tree protocol/vlan registration
protocol controlled ethernet switches specified in 802.1 would need and can
use. But ITU-T SG13/15 and IEEE 802.1 made sure that there is interworking
possible between networks using Y.1731 and networks using 802.1ag.
 
Ethernet switches compliant with ITU-T's Ethernet recommendations are
transport network grade switches (with VLAN ID translation capabilities
(e.g. VID translation, PW label swapping) in every node), which are managed
by NMS and optionally the GMPLS control plane.
 
The Ethernet data plane specified in the ITU-T Recommendations supports all
MPLS(-TP) data plane capabilities plus it supports rmp and mp2mp Ethernet VC
connections. Some operators have recognized this and have build their packet
transport network with a UNI-to-UNI Ethernet VC layer as their transport
service layer; transport path layer technologies used are Ethernet VP and
MPLS(-TP) VP. The efficient rooted-multipoint Ethernet VC connections are
used for broadband backhaul in such networks, p2p Ethernet VC connections
are used to support any type of Line service and mp2mp Ethernet VC
connections are used to support E-LAN services. With the growing bandwidth
demand OTN ODUs will be added in the near future as transport path layer
technology to carry the Ethernet VC connections between S-PE nodes. MPLS and
Ethernet data planes in such networks are managed in the same way. Ethernet
Transport Networks (ETN) exist for many years already and are proven
technology.
 
It is on this basis that I continue to state that the MPLS(-TP) and (ITU-T
Ethernet recommendations based) Ethernet VLAN data plane functionalities are
the same and that we can and should use the very similar OAM, protection
switching and the same management principles. T-MPLS was fully based on this
understanding and approach, and was designed to seamlessly operate in a
hybrid T-MPLS/Ethernet packet transport network. My hope is that seamless
interoperability will also be possible in the emerging hybrid
MPLS-TP/Ethernet packet transport networks.
 
Regards,
Maarten

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 27 Jan 2010 07:18:45 +0200

Maarten,
Looks like one point where we come to full agreement!
Thanks for an interesting discussion and best regards,
     Sasha
________________________________
From: Maarten Vissers [[email-masked]]
Sent: Wednesday, January 27, 2010 1:43 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Sasha,

This is getting into a yes/no discussion at this point in time.
We have a different understanding.
Each of us believe what we believe, based on the work we have been doing so far.
Thanks for the discussion.

Regards,
Maarten

Maarten,

Regards,
     Sasha

Sasha,

Regards,
Maarten