Subject: [mpls-tp] Additional MPLS-TP requirements

From: Maarten Vissers <[email-masked]>
Date: Tue, 17 Feb 2009 20:07:23 +0100

I would like to add the following requirements to the MPLS-TP requirements
draft:

Service Requirements

A	MPLS-TP must support the following customer service connectivity
types:
	- uni- and bi-directional point-to-point
	- uni-directional point-to-multipoint
	- bi-directional multipoint-to-multipoint
	- bi-directional rooted-multipoint, with one or more roots.

B	MPLS-TP must be able to support the services in a packet transport
network
	which contains a mixture of MPLS-TP and Ethernet domains. 

Additional Layering Requirement

C	The presence of MPLS-TP and Ethernet domains in a packet transport
network 
	must not require the introduction of additional layers in the
MPLS-TP or
	Ethernet domains in order to support services that have endpoints in
both 
	types of domains.

D	MPLS-TP must use an ETH layer as transport service layer for
rooted-multipoint
	and multipoint-to-multipoint services. This ETH transport service
layer is a
	client of the MPLS-TP transport path layer.

Additional Data Plane Requirement

D	MPLS-TP must support the optional encapsulation of Ethernet frames
into a new MAC frame
	(insert a new MAC header: DA-SA-TYPE) to limit the number of MAC
addresses that
	have to be learned in the transport service layer swithcing nodes,
and to
	prevent that customer frames are arbitrary lost for the case of a
bundled
	Ethernet VLAN service with rooted-multipoint or
multipoint-to-multipoint service
	connectivity.

Regards,
maarten

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 17 Feb 2009 15:59:26 -0500

Maarten, it appears that you are addressing the definition of a complete
packet transport network not the definition of the MPLS-TP part of such
a network.

The only requirements that I support are:
 A	MPLS-TP must support the following customer service connectivity
types:
	- uni- and bi-directional point-to-point
	- uni-directional point-to-multipoint

The remainder are addressing an implementation of a packet transport
network.  See in line below for further comments:

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Maarten Vissers
Sent: Tuesday, February 17, 2009 2:07 PM
To: [email-masked]
Subject: [mpls-tp] Additional MPLS-TP requirements

I would like to add the following requirements to the MPLS-TP
requirements
draft:

Service Requirements

<MB>
	- bi-directional multipoint-to-multipoint
	- bi-directional rooted-multipoint, with one or more roots.
<MB>  Beyond the capability of a MPLS-TP layer network as currently
envisioned.

B	MPLS-TP must be able to support the services in a packet
transport
network
	which contains a mixture of MPLS-TP and Ethernet domains. 
<MB>  This is peer interworking, again out of scope for a MPLS-TP layer
network.

C	The presence of MPLS-TP and Ethernet domains in a packet
transport
network 
	must not require the introduction of additional layers in the
MPLS-TP or
	Ethernet domains in order to support services that have
endpoints in both 
	types of domains.
<MB>  This is interworking, again out of scope for a MPLS-TP layer
network.

D	MPLS-TP must use an ETH layer as transport service layer for
rooted-multipoint
	and multipoint-to-multipoint services. This ETH transport
service layer is a
	client of the MPLS-TP transport path layer.
<MB> This is attempting to define the architecture of a client layer
network and is out of scope for the MPLS-TP layer network which must be
client agnostic.

D	MPLS-TP must support the optional encapsulation of Ethernet
frames
into a new MAC frame
	(insert a new MAC header: DA-SA-TYPE) to limit the number of MAC
addresses that
	have to be learned in the transport service layer swithcing
nodes, and to
	prevent that customer frames are arbitrary lost for the case of
a bundled
	Ethernet VLAN service with rooted-multipoint or
multipoint-to-multipoint service
	connectivity.
<MB> A simple statement that Ethernet frames as defined in IEEE 802.1ah
may be client should be more than adequate.

<MB> The MPLS-TP architecture should only define MPLS-TP not the
complete layer network stack for a packet transport network.

Regards,
maarten

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

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 18 Feb 2009 00:26:15 +0100

Malcolm,

Your observation is correct. I am addressing the definition of a "MPLS-TP
based packet transport network". I have described this unambiguously in my
"Types and Characteristics of MPLS-TP based Packet Transport Network
Equipment" document, as well as in my "Interoperability in and Management of
a Multi-Technology Packet Transport Network" slides and in my "MPLS-TP OAM
PDU Formats: the best alternatives" slides.

Defining a partial solution (as you suggest) does not make any sense in my
opinion, as it will result in MPLS-TP equipment and network management that
is **more complex** then necessary.

In order to limit the complexity of MPLS-TP equipment and network management
it is important to take into account the functionality necessary to support
all service types.

Furthermore, a packet transport network will include Ethernet domains. If we
would specify the MPLS-TP functionality ignoring the presence of those
Ethernet domains implies that we will end up with either no interoperability
between Ethernet and MPLS-TP domains, or with additional complexity in
MPLS-TP equipment and with more complex network management.

In order to prevent that we end up with no interoperability or that we end
up with additional complexity it is important to take into account the
presence of Ethernet domains.

But if operators do not care about UNI to UNI interoperability in their
Ethernet and MPLS-TP based packet transport networks, and if operators do
not care about equipment complexity and associated network management
complexity, then it is not necessary to consider the support of rmp/mp2mp
services oand the interoperability with Ethernet domains in our MPLS-TP
standardization activities. Otherwise, it is important to take those items
into consideration when we make decisions about MPLS-TP OAM PDU formats,
MPLS-TP TCM levels and MPLS-TP Protection Switching.

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]] 
Sent: dinsdag 17 februari 2009 21:59
To: Maarten Vissers; [email-masked]
Subject: RE: [mpls-tp] Additional MPLS-TP requirements

Maarten, it appears that you are addressing the definition of a complete
packet transport network not the definition of the MPLS-TP part of such a
network.

Malcolm Betts
Nortel Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: Tuesday, February 17, 2009 2:07 PM
To: [email-masked]
Subject: [mpls-tp] Additional MPLS-TP requirements

Service Requirements

<MB>

C	The presence of MPLS-TP and Ethernet domains in a packet
transport
network 
	must not require the introduction of additional layers in the
MPLS-TP or
	Ethernet domains in order to support services that have endpoints in
both 
	types of domains.
<MB>  This is interworking, again out of scope for a MPLS-TP layer network.

D	MPLS-TP must use an ETH layer as transport service layer for
rooted-multipoint
	and multipoint-to-multipoint services. This ETH transport service
layer is a
	client of the MPLS-TP transport path layer.
<MB> This is attempting to define the architecture of a client layer network
and is out of scope for the MPLS-TP layer network which must be client
agnostic.

D	MPLS-TP must support the optional encapsulation of Ethernet
frames
into a new MAC frame
	(insert a new MAC header: DA-SA-TYPE) to limit the number of MAC
addresses that
	have to be learned in the transport service layer swithcing nodes,
and to
	prevent that customer frames are arbitrary lost for the case of a
bundled
	Ethernet VLAN service with rooted-multipoint or
multipoint-to-multipoint service
	connectivity.
<MB> A simple statement that Ethernet frames as defined in IEEE 802.1ah may
be client should be more than adequate.

<MB> The MPLS-TP architecture should only define MPLS-TP not the complete
layer network stack for a packet transport network.

Regards,
maarten

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 18 Feb 2009 22:19:58 +0000

> is **more complex** then necessary.

There is no reason why one can't bear in mind big picture when designing
different parts.

We have defined (tight) deadline and as Malcolm pointed out reaching
consensus on whole solution before moving forward will be extremely time
consuming.

Ben