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

From: Greg Mirsky <[email-masked]>
Date: Thu, 21 Jan 2010 13:20:55 -0800

Dear Editors and All,
I'm puzzled by what looks to me as contradiction between quoted in the RFC
5586 definition of the Section Layer Network and the last paragraph on
sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to
section as server layer that provides service between *adjacent nodes* (my
underlining). At the same time, the last paragraph of subsection 4.2.1.2
stipulates behavior of intermediate nodes on an MPLS Section in regard to
G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent
nodes, then, as I understand the definition, there can not be intermediate
nodes on the section (on the segment, but not on a section) at this
particular layer.
Your clarification is greatly appreciated.

Regards,
Greg

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 22 Jan 2010 16:51:58 +0100

Greg,
 
It is not uncommon to carry a section layer signal as a service through the
network of another carrier. E.g. Ethernet port based services carry the
Ethernet section layer signals as a service through the transport network.
The compatible MPLS type of port based service would carry the MPLS section
layer signal as a service through the network of another carrier. The
section will now pass through intermediate nodes.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Greg Mirsky
Sent: donderdag 21 januari 2010 22:21
To: BOCCI Matthew; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Editors and All,
section as server layer that provides service between adjacent nodes (my

Regards,
Greg

---

From: <[email-masked]>
Date: Fri, 22 Jan 2010 16:05:33 -0000

I guess this depends on one's definition of what a section layer is.  I
think of a section layer as "the place where the *binary information
symbol* meets the *q'ary symbol metallic/optical/radio road*"....so this
is a true BOS (symbol/lexicon conversion) function in order to be able
to modulate an EM wave and hence be able to send information over
significant geographic distance.
 
What you describe below Maarten reads to me as a how a (client) *binary
information* link connection at layer N is supported by a (server)
*binary network connection* at layer N-1....so its just how we support a
normal link connection when we are not at the BOS.
 
Perhaps there is something additional however that I am missing here?
 
regards, Neil

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Maarten Vissers
	Sent: 22 January 2010 15:52
	To: 'Greg Mirsky'
	Cc: [email-masked]; [email-masked]
	Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS
Section

	Greg,
	 
	It is not uncommon to carry a section layer signal as a service
through the network of another carrier. E.g. Ethernet port based
services carry the Ethernet section layer signals as a service through
the transport network. The compatible MPLS type of port based service
would carry the MPLS section layer signal as a service through the
network of another carrier. The section will now pass through
intermediate nodes.
	 
	Regards,
	Maarten

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Greg Mirsky
	Sent: donderdag 21 januari 2010 22:21
	To: BOCCI Matthew; [email-masked];
[email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

	Dear Editors and All,
	I'm puzzled by what looks to me as contradiction between quoted
in the RFC 5586 definition of the Section Layer Network and the last
paragraph on sub-section 4.2.1.2 MPLS Section. The definition (section
1.3 p.4) refers to section as server layer that provides service between
adjacent nodes (my underlining). At the same time, the last paragraph of
subsection 4.2.1.2 stipulates behavior of intermediate nodes on an MPLS
Section in regard to G-ACh message, the ACH and the GAL. If an MPLS
Section is between adjacent nodes, then, as I understand the definition,
there can not be intermediate nodes on the section (on the segment, but
not on a section) at this particular layer.
	Your clarification is greatly appreciated.
	
	Regards,
	Greg

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 22 Jan 2010 17:29:57 +0100

Neil,
 
It seems that you mix up the physical media and section layer networks. I.e.
your "the place where the *binary information symbol* meets the *q'ary
symbol metallic/optical/radio road*".... is the function of the physical
media layer network. The section layer is the client of the physical media
layer and the server of the path layer.
 
According to G.805, the section layer network is concerned with all
functions which provide for the transfer of infomation between locations in
path layer networks. It is this latter item that allows section layer trails
to span multiple physical media layer trails, and thus to have intermediate
nodes in the connection.
 
Regards,
Maarten
 
Section 1.2.2/RFC5654 describes: "Note that G.805 [ITU.G805.2000] defines
the section layer as one of the two layer networks in a transmission-media
layer network. The other layer network is the physical-media layer network."
 
Section 5.3.3.3.3/G.805 describes: "It is possible to identify a set of
layer networks within the transmission media layer network which is likely
to be independently administered by a network operator by decomposing the
transmission media layer network. The connectivity of a transmission media
layer network cannot be directly modified by management action. Transmission
media layer networks are divided into section layer networks and physical
media layer networks. 

Section layer networks are concerned with all the functions which provide
for the transfer of information between locations in path layer networks.
The section layer network may be decomposed into specific section layer
networks as described in the examples in clause 6.

Physical media layer networks are concerned with the actual fibres, metallic
wires or radio frequency channels which support a section layer network. The
physical media layer network may be decomposed into specific physical media
layer networks to represent, for example, wave division multiplexing. Since
a server layer network does not exist for the lowest layer network (e.g. the
physical media layer network) the network connection is directly supported
by the media and not by a trail."

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 22 januari 2010 17:06
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

I guess this depends on one's definition of what a section layer is.  I
think of a section layer as "the place where the *binary information symbol*
meets the *q'ary symbol metallic/optical/radio road*"....so this is a true
BOS (symbol/lexicon conversion) function in order to be able to modulate an
EM wave and hence be able to send information over significant geographic
distance.
 
What you describe below Maarten reads to me as a how a (client) *binary
information* link connection at layer N is supported by a (server) *binary
network connection* at layer N-1....so its just how we support a normal link
connection when we are not at the BOS.

regards, Neil

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: 22 January 2010 15:52
To: 'Greg Mirsky'
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Greg,

Regards,
Maarten

  _____  

Dear Editors and All,

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 22 Jan 2010 08:55:23 -0800

Dear Maarten,
so this is carrier's carrier scenario when MPLS-TP section is client of
MPLS-TP transport? But wouldn't presumed processing of client MPLS-TP
section by intermediate nodes of server MPLS-TP layer be just plain
violation of server-client model?

Regards,
Greg

On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vissers <[email-masked]
> wrote:

>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Greg Mirsky
> *Sent:* donderdag 21 januari 2010 22:21
> *To:* BOCCI Matthew; [email-masked];
> [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section
>
> Dear Editors and All,

---

From: <[email-masked]>
Date: Fri, 22 Jan 2010 16:49:33 -0000

Thanks for the additional information and pointers Maarten  Seems to me
like the major functional difference between 'section' and 'physical' is
that the former operates in the binary symbol space and the other is a
lexicon mapped q'ary symbol space (which is also a client/server
relationship BTW).   I'm not sure whether it would be fair to say any
other factors (if there are any) are minor compared to this.  
 
regards, neil

	From: Maarten Vissers [mailto:[email-masked]] 
	Sent: 22 January 2010 16:30
	To: Harrison,N,Neil,DKQ7 R; [email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS
Section

	Neil,
	 
	It seems that you mix up the physical media and section layer
networks. I.e. your "the place where the *binary information symbol*
meets the *q'ary symbol metallic/optical/radio road*".... is the
function of the physical media layer network. The section layer is the
client of the physical media layer and the server of the path layer.
	 
	According to G.805, the section layer network is concerned with
all functions which provide for the transfer of infomation between
locations in path layer networks. It is this latter item that allows
section layer trails to span multiple physical media layer trails, and
thus to have intermediate nodes in the connection.
	 
	Regards,
	Maarten
	 
	Section 1.2.2/RFC5654 describes: "Note that G.805
[ITU.G805.2000] defines the section layer as one of the two layer
networks in a transmission-media layer network. The other layer network
is the physical-media layer network."
	 
	Section 5.3.3.3.3/G.805 describes: "It is possible to identify a
set of layer networks within the transmission media layer network which
is likely to be independently administered by a network operator by
decomposing the transmission media layer network. The connectivity of a
transmission media layer network cannot be directly modified by
management action. Transmission media layer networks are divided into
section layer networks and physical media layer networks. 

	Section layer networks are concerned with all the functions
which provide for the transfer of information between locations in path
layer networks. The section layer network may be decomposed into
specific section layer networks as described in the examples in clause
6.

	Physical media layer networks are concerned with the actual
fibres, metallic wires or radio frequency channels which support a
section layer network. The physical media layer network may be
decomposed into specific physical media layer networks to represent, for
example, wave division multiplexing. Since a server layer network does
not exist for the lowest layer network (e.g. the physical media layer
network) the network connection is directly supported by the media and
not by a trail."

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

	I guess this depends on one's definition of what a section layer
is.  I think of a section layer as "the place where the *binary
information symbol* meets the *q'ary symbol metallic/optical/radio
road*"....so this is a true BOS (symbol/lexicon conversion) function in
order to be able to modulate an EM wave and hence be able to send
information over significant geographic distance.
	 
	What you describe below Maarten reads to me as a how a (client)
*binary information* link connection at layer N is supported by a
(server) *binary network connection* at layer N-1....so its just how we
support a normal link connection when we are not at the BOS.
	 
	Perhaps there is something additional however that I am missing
here?
	 
	regards, Neil

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Maarten Vissers
		Sent: 22 January 2010 15:52
		To: 'Greg Mirsky'
		Cc: [email-masked]; [email-masked]
		Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on
MPLS Section

		Greg,
		 
		It is not uncommon to carry a section layer signal as a
service through the network of another carrier. E.g. Ethernet port based
services carry the Ethernet section layer signals as a service through
the transport network. The compatible MPLS type of port based service
would carry the MPLS section layer signal as a service through the
network of another carrier. The section will now pass through
intermediate nodes.
		 
		Regards,
		Maarten

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Greg Mirsky
		Sent: donderdag 21 januari 2010 22:21
		To: BOCCI Matthew; [email-masked];
[email-masked]
		Cc: [email-masked]; [email-masked]
		Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS
Section

		Dear Editors and All,
		I'm puzzled by what looks to me as contradiction between
quoted in the RFC 5586 definition of the Section Layer Network and the
last paragraph on sub-section 4.2.1.2 MPLS Section. The definition
(section 1.3 p.4) refers to section as server layer that provides
service between adjacent nodes (my underlining). At the same time, the
last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate
nodes on an MPLS Section in regard to G-ACh message, the ACH and the
GAL. If an MPLS Section is between adjacent nodes, then, as I understand
the definition, there can not be intermediate nodes on the section (on
the segment, but not on a section) at this particular layer.
		Your clarification is greatly appreciated.
		
		Regards,
		Greg

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 22 Jan 2010 09:11:05 -0800

Dear Neil,
the RFC refers to "MPLS Section" that is defined in the MPLS-TP Rosetta
Stone as "*A network segment between two LSRs that are immediately adjacent
at the MPLS layer*". Thus, as I understand this definition, MPLS Section is
not yet the layer of opaque binary symbols to be transformed into pulses and
such but, on the other hand, it can not have intermediate MPLS-TP nodes
either as it presents atomic element of MPLS-TP transport layer.

Regards,
Greg

On Fri, Jan 22, 2010 at 8:05 AM, <[email-masked]> wrote:

> Behalf Of *Maarten Vissers
> *Sent:* 22 January 2010 15:52
> *To:* 'Greg Mirsky'
>
> *Subject:* Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section
>
>  Greg,
>

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 22 Jan 2010 18:13:02 +0100

I don't consider the symbol space as a important functional difference from
an management perspective. The major functional difference is the role of
each layer in the network.
 
Regards,
Maarten

  _____  

Sent: vrijdag 22 januari 2010 17:50

Thanks for the additional information and pointers Maarten  Seems to me like
the major functional difference between 'section' and 'physical' is that the
former operates in the binary symbol space and the other is a lexicon mapped
q'ary symbol space (which is also a client/server relationship BTW).   I'm
not sure whether it would be fair to say any other factors (if there are
any) are minor compared to this.  
 
regards, neil

  _____  

Neil,

 
Regards,
Maarten

 

  _____  

 

regards, Neil

  _____  

Greg,

Regards,
Maarten

  _____  

Dear Editors and All,

Regards,
Greg

---

From: <[email-masked]>
Date: Fri, 22 Jan 2010 17:51:30 -0000

Thanks Greg for bringing up a key point:
 
""MPLS Section" that is defined in the MPLS-TP Rosetta Stone as "A
network segment between two LSRs that are immediately adjacent at the
MPLS layer". .......think we need to factor-in S bit sublayering here.
 
S bit sublayering in MPLS allows one to have multiple signalling
protocols (though I would hardly call LDP a signalling protocol, and I'm
not sure that BGP4 dist of labels fits either) whilst attempting to
preserve the notion of 'a single common routing instance', ie a single
instance of routing which spans all the S bit sublayers.  This model is
not a very good one for a transport role (for many reasons) and yet it
seems it persists in MPLS-TP....and it's also partly responsible for the
error of creating a MS PW layer network *above* MPLS-TP...which as an
aside observation destroys the notion of a 'common instance of routing'
anyway!
 
All this is hardly good behaviour for an aspiring transport network and
MPLS-TP would be far better off without the S bit sublayering (and for
sure MS PWs) and thus each LSP would belong to its own layer network
like all other network technologies in fact (MPLS is the odd man out
here).
 
So, the point I am teasing out here is that there is a difference
between:
-    a false client/server relationship where a 'link sublayer
connection' at MPLS level N is provided by a 'LSP sublayer connection'
at MPLS level N-1, and
-    a true client/server relationship where a 'link connection' in MPLS
layer network N is provided by a 'LSP network connection' at MPLS layer
network N-1.
 
Note - Please ignore actual words/vocab used here, it is the concept
that I am trying to get across that is important.
 
Of course, this is all additional to the original point I raised with
Maarten wrt to difference between 'section' and 'physical'...though
sublayering does (unnecessarily) muddy this up as I noted above.
 
BTW Maarten there are important management functions at the physical
layer due to section/physical binary<=>q'ary symbol mappings (which is a
client/server relationship) because there is usually significant
redundancy in the server q'ary symbols (ie it has a larger lexicon than
it binary client) to allow for things like spectral-shaping/zero-dc,
error detection.....
 
regards, Neil

	From: Greg Mirsky [mailto:[email-masked]] 
	Sent: 22 January 2010 17:11
	To: Harrison,N,Neil,DKQ7 R
	Cc: [email-masked]; [email-masked]; [email-masked]
	Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS
Section

	Dear Neil,
	the RFC refers to "MPLS Section" that is defined in the MPLS-TP
Rosetta Stone as "A network segment between two LSRs that are
immediately adjacent at the MPLS layer". Thus, as I understand this
definition, MPLS Section is not yet the layer of opaque binary symbols
to be transformed into pulses and such but, on the other hand, it can
not have intermediate MPLS-TP nodes either as it presents atomic element
of MPLS-TP transport layer.
	
	Regards,
	Greg

		I guess this depends on one's definition of what a
section layer is.  I think of a section layer as "the place where the
*binary information symbol* meets the *q'ary symbol
metallic/optical/radio road*"....so this is a true BOS (symbol/lexicon
conversion) function in order to be able to modulate an EM wave and
hence be able to send information over significant geographic distance.
		 
		What you describe below Maarten reads to me as a how a
(client) *binary information* link connection at layer N is supported by
a (server) *binary network connection* at layer N-1....so its just how
we support a normal link connection when we are not at the BOS.
		 
		Perhaps there is something additional however that I am
missing here?
		 
		regards, Neil

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

			Greg,
			 
			It is not uncommon to carry a section layer
signal as a service through the network of another carrier. E.g.
Ethernet port based services carry the Ethernet section layer signals as
a service through the transport network. The compatible MPLS type of
port based service would carry the MPLS section layer signal as a
service through the network of another carrier. The section will now
pass through intermediate nodes.
			 
			Regards,
			Maarten

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Greg Mirsky
			Sent: donderdag 21 januari 2010 22:21
			To: BOCCI Matthew;
[email-masked]; [email-masked]
			Cc: [email-masked]; [email-masked]
			Subject: [mpls-tp] RFC 5586: Intermediate nodes
on MPLS Section

			Dear Editors and All,
			I'm puzzled by what looks to me as contradiction
between quoted in the RFC 5586 definition of the Section Layer Network
and the last paragraph on sub-section 4.2.1.2 MPLS Section. The
definition (section 1.3 p.4) refers to section as server layer that
provides service between adjacent nodes (my underlining). At the same
time, the last paragraph of subsection 4.2.1.2 stipulates behavior of
intermediate nodes on an MPLS Section in regard to G-ACh message, the
ACH and the GAL. If an MPLS Section is between adjacent nodes, then, as
I understand the definition, there can not be intermediate nodes on the
section (on the segment, but not on a section) at this particular layer.
			Your clarification is greatly appreciated.
			
			Regards,
			Greg

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 22 Jan 2010 19:32:21 +0100

Hi Greg,
 
The intermediate nodes contain multiple MPLS-TP (MTP) layer network
instances, of which the top MTP layer is shared by carrier A and B. See
slide 7 in the mplstp-connection-concepts file. Note that the same applies
for the case of Ethernet (ETH) layer networks. In the attached
ethernet-connection-concepts file you find the same case illustrated also on
slide 7.
 
Other slides illustrate other cases of carrier-carrier and customer-carrier
interactions.
 
Note that the functional models for the MPLS-TP and Ethernet cases are the
same; I already had the Ethernet models and have converted those into
MPLS-TP equivalent models to illustrate this section layer question. The
difference between both technologies is the encoding of MEG levels; in
Ethernet via the MEG Level (MEL) field, in MPLS-TP via a Label Stack Entry
(LSE) header.
 
Regards,
Maarten

  _____  

From: Greg Mirsky [mailto:[email-masked]] 
Sent: vrijdag 22 januari 2010 17:55
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Maarten,

Regards,
Greg

On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vissers
<[email-masked]> wrote:

Greg,

Regards,
Maarten

  _____  

Dear Editors and All,

Regards,
Greg

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 22 Jan 2010 19:36:59 +0100

Neil,
 
> BTW Maarten there are important management functions at the physical layer
due to
> section/physical binary<=>q'ary symbol mappings (which is a client/server
relationship)
> because there is usually significant redundancy in the server q'ary
symbols (ie it has a
> larger lexicon than it binary client) to allow for things like
spectral-shaping/zero-dc,
> error detection.....
 
If I look at the management objects in the information model, then I don't
find any of your "important management functions at the physical layer"
being listed... i.e. those fucntions seems to be hidden from the management
viewpoint...
 
Regards,
Maarten
 
  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 22 januari 2010 18:52
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

""MPLS Section" that is defined in the MPLS-TP Rosetta Stone as "A network
segment between two LSRs that are immediately adjacent at the MPLS layer".
.......think we need to factor-in S bit sublayering here.
 
S bit sublayering in MPLS allows one to have multiple signalling protocols
(though I would hardly call LDP a signalling protocol, and I'm not sure that
BGP4 dist of labels fits either) whilst attempting to preserve the notion of
'a single common routing instance', ie a single instance of routing which
spans all the S bit sublayers.  This model is not a very good one for a
transport role (for many reasons) and yet it seems it persists in
MPLS-TP....and it's also partly responsible for the error of creating a MS
PW layer network *above* MPLS-TP...which as an aside observation destroys
the notion of a 'common instance of routing' anyway!
 
All this is hardly good behaviour for an aspiring transport network and
MPLS-TP would be far better off without the S bit sublayering (and for sure
MS PWs) and thus each LSP would belong to its own layer network like all
other network technologies in fact (MPLS is the odd man out here).
 
So, the point I am teasing out here is that there is a difference between:
-    a false client/server relationship where a 'link sublayer connection'
at MPLS level N is provided by a 'LSP sublayer connection' at MPLS level
N-1, and
-    a true client/server relationship where a 'link connection' in MPLS
layer network N is provided by a 'LSP network connection' at MPLS layer
network N-1.
 
Note - Please ignore actual words/vocab used here, it is the concept that I
am trying to get across that is important.

BTW Maarten there are important management functions at the physical layer
due to section/physical binary<=>q'ary symbol mappings (which is a
client/server relationship) because there is usually significant redundancy
in the server q'ary symbols (ie it has a larger lexicon than it binary
client) to allow for things like spectral-shaping/zero-dc, error
detection.....
 
regards, Neil

  _____  

Dear Neil,
the RFC refers to "MPLS Section" that is defined in the MPLS-TP Rosetta
Stone as "A network segment between two LSRs that are immediately adjacent
at the MPLS layer". Thus, as I understand this definition, MPLS Section is
not yet the layer of opaque binary symbols to be transformed into pulses and
such but, on the other hand, it can not have intermediate MPLS-TP nodes
either as it presents atomic element of MPLS-TP transport layer.

Regards,
Greg

 

regards, Neil

  _____  

Greg,

Regards,
Maarten

  _____  

Dear Editors and All,

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 22 Jan 2010 11:28:52 -0800

Dear Maarten,
I'll concentrate, as you suggested, on the slide #7 and the following you've
wrote "The intermediate nodes contain multiple MPLS-TP (MTP) layer network
instances". I think that from the definition of MPLS Section follows that
there can not be an intermediate MPLS node on a given MPLS Section which is
aware of that Section. In your example (slide #7) nodes P and P' (to
differentiate them from left to right) of Carrier A are terminating points
of MPLS Section of Carrier A. S-PEs of Carrier B are unaware of that MPLS
Section. Thus, when Node P sends OAM with GAL as BOS to monitor the P-P'
Section, none of nodes of Carrier B, including S-PEs, should bother to
process the GAL. Doing otherwise will break client-server layering. That is
why I can not agree that an intermediate node contains instances of multiple
MPLS-TP networks. I think of a node as performing its functions at certain
MPLS-TP network layer only. Another question is whether Carrier B sets its
VC label as BOS or not, as I understand we haven't decided yet with number
of BOS in carrier's carrier scenario. But that, to me, is separate
discussion.
Maarten, I greatly appreciate your input and our discussion.

Regards,
Greg

On Fri, Jan 22, 2010 at 10:32 AM, Maarten Vissers <
[email-masked]> wrote:

> for the case of Ethernet (ETH) layer networks. In the
> attached ethernet-connection-concepts file you find the same case
> illustrated also on slide 7.
>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* vrijdag 22 januari 2010 17:55
> *To:* Maarten Vissers
>
> On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vissers <
> [email-masked]> wrote:
>
>>  Greg,
>>
>> It is not uncommon to carry a section layer signal as a service through
>> the network of another carrier. E.g. Ethernet port based services carry the
>> section as server layer that provides service between *adjacent nodes*(my underlining). At the same time, the last paragraph of subsection 4.2.1.2

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 22 Jan 2010 22:56:55 +0200

Greg, Maarten and all,
I concur with Greg. If section connects adjacent nodes (at a certain layer), physical intermediate nodes crossed by such a section in the carriers' carrier scenario are fully transparent to that.

My 2c,
     Sasha
________________________________
From: [email-masked] [[email-masked]] On Behalf Of Greg Mirsky [[email-masked]]
Sent: Friday, January 22, 2010 9:28 PM
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Maarten,
I'll concentrate, as you suggested, on the slide #7 and the following you've wrote "The intermediate nodes contain multiple MPLS-TP (MTP) layer network instances". I think that from the definition of MPLS Section follows that there can not be an intermediate MPLS node on a given MPLS Section which is aware of that Section. In your example (slide #7) nodes P and P' (to differentiate them from left to right) of Carrier A are terminating points of MPLS Section of Carrier A. S-PEs of Carrier B are unaware of that MPLS Section. Thus, when Node P sends OAM with GAL as BOS to monitor the P-P' Section, none of nodes of Carrier B, including S-PEs, should bother to process the GAL. Doing otherwise will break client-server layering. That is why I can not agree that an intermediate node contains instances of multiple MPLS-TP networks. I think of a node as performing its functions at certain MPLS-TP network layer only. Another question is whether Carrier B sets its VC label as BOS or not, as I understand we haven't decided yet with number of BOS in carrier's carrier scenario. But that, to me, is separate discussion.
Maarten, I greatly appreciate your input and our discussion.

Regards,
Greg

On Fri, Jan 22, 2010 at 10:32 AM, Maarten Vissers <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

The intermediate nodes contain multiple MPLS-TP (MTP) layer network instances, of which the top MTP layer is shared by carrier A and B. See slide 7 in the mplstp-connection-concepts file. Note that the same applies for the case of Ethernet (ETH) layer networks. In the attached ethernet-connection-concepts file you find the same case illustrated also on slide 7.

Other slides illustrate other cases of carrier-carrier and customer-carrier interactions.

Note that the functional models for the MPLS-TP and Ethernet cases are the same; I already had the Ethernet models and have converted those into MPLS-TP equivalent models to illustrate this section layer question. The difference between both technologies is the encoding of MEG levels; in Ethernet via the MEG Level (MEL) field, in MPLS-TP via a Label Stack Entry (LSE) header.

Regards,
Maarten

________________________________
From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: vrijdag 22 januari 2010 17:55
To: Maarten Vissers

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Maarten,
so this is carrier's carrier scenario when MPLS-TP section is client of MPLS-TP transport? But wouldn't presumed processing of client MPLS-TP section by intermediate nodes of server MPLS-TP layer be just plain violation of server-client model?

Regards,
Greg

On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vissers <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

It is not uncommon to carry a section layer signal as a service through the network of another carrier. E.g. Ethernet port based services carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of port based service would carry the MPLS section layer signal as a service through the network of another carrier. The section will now pass through intermediate nodes.

Regards,
Maarten

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Greg Mirsky
Sent: donderdag 21 januari 2010 22:21
To: BOCCI Matthew; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Editors and All,
I'm puzzled by what looks to me as contradiction between quoted in the RFC 5586 definition of the Section Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to section as server layer that provides service between adjacent nodes (my underlining). At the same time, the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate nodes on the section (on the segment, but not on a section) at this particular layer.
Your clarification is greatly appreciated.

Regards,
Greg

---

From: Maarten Vissers <[email-masked]>
Date: Sat, 23 Jan 2010 06:37:00 +0100

Hi Greg,
 
See inline.. 
  _____  

From: Greg Mirsky [mailto:[email-masked]] 
Sent: vrijdag 22 januari 2010 20:29
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Maarten,
aware of that Section.  
 
In your example (slide #7) nodes P and P' (to differentiate them from left
to right) of Carrier A are terminating points of MPLS Section of Carrier A.

[maarten] Correct.
 
S-PEs of Carrier B are unaware of that MPLS Section.  
 
[maarten] not correct. The figure shows two MPLS-TP Section layer MEG
levels; the top level MEG has its endpoints (blue MEP functions) in the
carrier A P and P' nodes, the bottom level MEG has its end points in the
interface ports of P and left S-PE and in right S-PE and P' nodes.
 
[maarten] The most left and right S-PEs of carrier B terminate the physical
media layer (the 802.3 ETY layer) and then the MPLS-TP Section TCM/Segment
OAM in the blue colored MEP function. On top of this MEP function there is a
(blue) MPLS-TP Section layer MIP function, which will process the MPLS-TP
Section layer OAM from the top MEG level.
 
[maarten] I have attached a slightly modified version of the slide 7. The
modification is the replacement of the 802.3 interface between carrier A's P
node and the left S-PE node of carrier B by an SDH STM-N interface. Such SDH
interface has excellent section monitoring capabilities and it is now not
necessary to instantiate the MPLS-TP Section layer TCM/Segment MEG level
between these P and left S-PE nodes. This is reflected by the absence of the
lower blue Section MEP functions.
 
[maarten] On the side of the adaptation functions  between MPLS-TP Section
layer and SDH layers (blue/grey colored trapezoid symbols) I have indicated
"P-LSE" to represent that it may be necessary to insert a kind of "priority
label stack entry header" (in analogy to the priority vlan tag in ethernet).
The use of such "P-LSE" header on the MPLS-TP over SDH interface would be
required when carrier A wants to have explicit control over the priority and
drop eligibility of each of the MPLS-TP packets passed through the carrier B
network; i.e. including the MPLS-TP Section OAM packets. If all Section OAM
packets have the same priority/drop eligibility, then insertion of such
P-LSE header is not necessary as carrier B's S-PE node can assign the right
priority/drop eligible level to the the unlabelled (section OAM) packets.
 
[maarten] For the latter case, the MPLS-TP Section layer signal will have
its section OAM equipped with GAL as BOS. For the former case, the MPLS-TP
Section layer signal will have its section OAM equipped with 'P-LSP'  label
as BOS and GAL as second label.
 
[maarten] Assume the latter case, then the blue MIP function in the left
S-PE node will process the GAL as BOS.
 
Thus, when Node P sends OAM with GAL as BOS to monitor the P-P' Section,
none of nodes of Carrier B, including S-PEs, should bother to process the
GAL. Doing otherwise will break client-server layering.  
 
[maarten] I understand why we were coming to different conclusions. I hope I
have clarified my view with the SDH physical media layer example.
 
[maarten] You may now also understand why the definition of Section layer in
G.805 defines that the section layer network is concerned with all functions
which"**provide for the transfer of infomation between locations in path
layer networks**. 
It is this latter item that allows section layer trails to span multiple
physical media layer trails, and thus to have intermediate nodes in the
section layer connection.
 
[maarten] But in all honesty, most of the Section layer connections are
terminating at the same ports as their underlying physical media layer
connections. Someone who looks only at the appearances of section layers
inside one network will conclude that section layer connections terminate at
adjacent nodes. Someone who looks beyond its own network will conclude that
section layer connections terminate in nodes that provide access to path
layer signals.
 
That is why I can not agree that an intermediate node contains instances of
multiple MPLS-TP networks. I think of a node as performing its functions at
certain MPLS-TP network layer only.  
 
[maarten] It is my understanding that we are missing a description which
explicitly describes the mapping of labels onto layers. One MPLS-TP layer
network will in my understanding contain one or more labels. As the ppt file
with my investigation results is too large to attach, I will email you a
copy privately. I have attached a summary of the results up to this point in
time.
 
Another question is whether Carrier B sets its VC label as BOS or not, as I
understand we haven't decided yet with number of BOS in carrier's carrier
scenario. But that, to me, is separate discussion. 
 
[maarten] I have understood that that decision has been made. Refer to the
SB10 comment "Yes. S=1 does not indicate the boundary between the client and
server. It indicates the boundary between the label stack and the label
stack payload." in the draft-ietf-mpls-tp-framework-07-post-review-of
ITU-T-informal-cts-19-Jan-2010.doc. This is now inlcuded in
draft-ietf-mpls-tp-framework-08, see section 3.4.1.

[maarten] I appreciate your questions and discussion.
 
Regards,
Maarten 

Regards,
Greg

On Fri, Jan 22, 2010 at 10:32 AM, Maarten Vissers
<[email-masked]> wrote:

Hi Greg,

 
 
Regards,
Maarten

  _____  

Dear Maarten,

Regards,
Greg

Greg,

Regards,
Maarten

  _____  

Dear Editors and All,

Regards,
Greg

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 23 Jan 2010 09:56:43 +0200

Maarten,
I may be missing something important, but how iy seems that you ignore the fundamental differences between Ethernet and MPLS data planes in your analysis.

Ethernet data plane inherently recognizes "well-know multicast MAC destination addresses". If a switch wants so, it can catch all the frames with such a DA and decide how it treats them "out-of-band". All Ethernet protocols operate in this way, 802.1ag is not an exception. And this is exactly what allows separation between addressing and MEP/MIP levels in 802.1ag.  The disadvantage of this approach is that Ethernet OAM frames are not necessarily fate-sharing with the data traffic.

The MPLS data plane is defined in RFC 3031, 30302 and (for upstream-allocated labels) in RFC 5331, 5332. Its analog of Ethernet well-know multicast MAC destination addresses is the reserved Router Alert Label. But its usage  has been rejected for usage in MPLS-TP OAM exactly because fate-sharing of data and OAM packets could be broken. Instead, MPLS-TP uses two different mechanisms:

 1.
GAL. This mechanism can only be used to address MEPs, because the LER processing a packet with the GAL at some level in the label stack is not allowed to look at it unless it terminates all the labels above it are terminated (i.e., its ILM entries for these labels must be "pop and forward to the loopback interface").
 2.
TTL expiration. This is the only mechanism for addressing MIPs in MPLS-TP. And, of course, TTL expiration must occur in the first label stack entry following all the labels terminated by the supporting node.

In short, LERs do not look at the next label if they do not terminate the previous one.

Hence I think that some of the MEPs you've defined are non-addressable (and hence unusable) in MPLS-TP which shares the MPLS data plane.

My 2c,

     Sasha

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Maarten Vissers [[email-masked]]
Sent: Saturday, January 23, 2010 7:37 AM
To: 'Greg Mirsky'
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Hi Greg,

See inline..

Dear Maarten,
I'll concentrate, as you suggested, on the slide #7 and the following you've wrote "The intermediate nodes contain multiple MPLS-TP (MTP) layer network instances". I think that from the definition of MPLS Section follows that there can not be an intermediate MPLS node on a given MPLS Section which is aware of that Section.

In your example (slide #7) nodes P and P' (to differentiate them from left to right) of Carrier A are terminating points of MPLS Section of Carrier A.

[maarten] Correct.

[maarten] not correct. The figure shows two MPLS-TP Section layer MEG levels; the top level MEG has its endpoints (blue MEP functions) in the carrier A P and P' nodes, the bottom level MEG has its end points in the interface ports of P and left S-PE and in right S-PE and P' nodes.

[maarten] The most left and right S-PEs of carrier B terminate the physical media layer (the 802.3 ETY layer) and then the MPLS-TP Section TCM/Segment OAM in the blue colored MEP function. On top of this MEP function there is a (blue) MPLS-TP Section layer MIP function, which will process the MPLS-TP Section layer OAM from the top MEG level.

[maarten] I have attached a slightly modified version of the slide 7. The modification is the replacement of the 802.3 interface between carrier A's P node and the left S-PE node of carrier B by an SDH STM-N interface. Such SDH interface has excellent section monitoring capabilities and it is now not necessary to instantiate the MPLS-TP Section layer TCM/Segment MEG level between these P and left S-PE nodes. This is reflected by the absence of the lower blue Section MEP functions.

[maarten] On the side of the adaptation functions  between MPLS-TP Section layer and SDH layers (blue/grey colored trapezoid symbols) I have indicated "P-LSE" to represent that it may be necessary to insert a kind of "priority label stack entry header" (in analogy to the priority vlan tag in ethernet). The use of such "P-LSE" header on the MPLS-TP over SDH interface would be required when carrier A wants to have explicit control over the priority and drop eligibility of each of the MPLS-TP packets passed through the carrier B network; i.e. including the MPLS-TP Section OAM packets. If all Section OAM packets have the same priority/drop eligibility, then insertion of such P-LSE header is not necessary as carrier B's S-PE node can assign the right priority/drop eligible level to the the unlabelled (section OAM) packets.

[maarten] For the latter case, the MPLS-TP Section layer signal will have its section OAM equipped with GAL as BOS. For the former case, the MPLS-TP Section layer signal will have its section OAM equipped with 'P-LSP'  label as BOS and GAL as second label.

[maarten] Assume the latter case, then the blue MIP function in the left S-PE node will process the GAL as BOS.

Thus, when Node P sends OAM with GAL as BOS to monitor the P-P' Section, none of nodes of Carrier B, including S-PEs, should bother to process the GAL. Doing otherwise will break client-server layering.

[maarten] I understand why we were coming to different conclusions. I hope I have clarified my view with the SDH physical media layer example.

[maarten] You may now also understand why the definition of Section layer in G.805 defines that the section layer network is concerned with all functions which"**provide for the transfer of infomation between locations in path layer networks**.
It is this latter item that allows section layer trails to span multiple physical media layer trails, and thus to have intermediate nodes in the section layer connection.

[maarten] But in all honesty, most of the Section layer connections are terminating at the same ports as their underlying physical media layer connections. Someone who looks only at the appearances of section layers inside one network will conclude that section layer connections terminate at adjacent nodes. Someone who looks beyond its own network will conclude that section layer connections terminate in nodes that provide access to path layer signals.

That is why I can not agree that an intermediate node contains instances of multiple MPLS-TP networks. I think of a node as performing its functions at certain MPLS-TP network layer only.

[maarten] It is my understanding that we are missing a description which explicitly describes the mapping of labels onto layers. One MPLS-TP layer network will in my understanding contain one or more labels. As the ppt file with my investigation results is too large to attach, I will email you a copy privately. I have attached a summary of the results up to this point in time.

Another question is whether Carrier B sets its VC label as BOS or not, as I understand we haven't decided yet with number of BOS in carrier's carrier scenario. But that, to me, is separate discussion.

[maarten] I have understood that that decision has been made. Refer to the SB10 comment "Yes. S=1 does not indicate the boundary between the client and server. It indicates the boundary between the label stack and the label stack payload." in the draft-ietf-mpls-tp-framework-07-post-review-of ITU-T-informal-cts-19-Jan-2010.doc. This is now inlcuded in draft-ietf-mpls-tp-framework-08, see section 3.4.1.

Regards,
Maarten

Regards,
Greg

Regards,
Maarten

Dear Maarten,

Regards,
Greg

Regards,
Maarten

Dear Editors and All,

Regards,
Greg

---

From: Maarten Vissers <[email-masked]>
Date: Sat, 23 Jan 2010 17:02:38 +0100

Sasha,

> Hence I think that some of the MEPs you've defined are non-addressable
(and hence unusable) in MPLS-TP which shares the MPLS data plane. 

If what you state is correct there is a serious problem within the existing
draft specification for MPLS-TP.  These functional models describe a part of
the required functional behaviour in a (packet) transport network of any
technology.

I doubt that such problem exist... so the MEPs and MIPs in my models are all
addressable (and hence usable) in MPLS-TP...

Let's analyse the left inter domain interface between carrier A's P node and
B's left S-PE node as an exercise...

1) there is a MPLS-TP Section layer transport path (VSC) between carrier A
nodes P-left and P-right

2) there is a MPLS-TP Section layer transport path segment (VSC Segment)
between nodes P-left and S-PE-left

3) there is a MPLS-TP transport service layer transport path (VCC) between
nodes S-PE-left and S-PE-right (yellow MEPs).

- The MPLS-TP LSP OAM inserted by the lower blue MEP in node P-left has as
top and bottom of stack the GAL. 

- The MPLS-TP LSP OAM inserted by the higher blue MEP in node P-left has as
top of stack the label inserted by the lower blue MEP (identified as LSE)
and as bottom of stack the GAL. 

- The lower blue MEP in node S-PE-left has to process all packets with top
of stack the GAL. 

- The blue MIP in node S-PE-left has to process all packets generated by the
higher blue MEP in node P of which the TTL expires; these packets arrive at
node S-PE-left with two labels, of which the bottom of stack label is the
GAL and the top of stack label is a regular LSP label. 

- The interface port in the S-PE-left port will swap the top of stack label
of non-OAM and TTL not-expired packets; the new label value will be the
value inserted by the left yellow MEP in the S-PE-left node (indicated by
LSE next to the yellow MEP symbol). 

- If the packet was a VSC OAM packet of which the TTL expires, the packet
will be extracted by the blue MIP within the VSC.

- The yellow MEP inserts the LSP OAM into the carrier A's VSC, creating a
monitored VSC Segment, and treats this VSC Segment as one of its VCCs. This
VCC related LSP OAM will pass through a VCC MIP on the egress NNI port in
the S-PE-left node (i.e. egress MIP issue applies). 

- The VCC signal is multiplexed into an MPLS-TP transport path layer
transport path (VPC) and its packets are prepended with a new LSP label
identifying the VCC. 

- Etc.

- In the reverse direction, the VPC terminates on the right NNI port of the
S-PE-left node, providing access the VCC LSPs carried in the VPC. If the TTL
of a VCC LSP OAM expires the VCC LSP MIP function will process the OAM. All
other VCC LSP related packets are forwarded to the egress port which is
connected to carrier A's P node. 

- The VCC LSP terminates on the egress port, and the LSP label identifying
this VCC LSP is terminated; the yellow VCC LSP MEP on the egress port can
now determine which packets carry the VCC LSP OAM by checking for the GAL as
next top label.

- The VCC LSP label is also removed from the non-VCC LSP OAM packets and it
is possible that on one of those packets the TTL expires. Such packets are
processed by the blue MIP function above the yellow MEP function in the
S-PE-left node.

- The outer label on packets of which the TTL has not expired will be
swapped, and LSP OAM will be added in the lower blue section layer MEP on
the S-PE-left node. This OAM will be output with GAL as top and bottom of
stack label.

- Etc.

I can't find a problem in the above required behaviour, besides the well
known egress-MIP identification problem. 

There is always an outer LSP label being terminated when a MEP function is
following and LSP OAM has to be extracted and processed.

In some cases the LSP terminates on an ingress port (DOWN MEP), in other
cases the LSP terminates on an egress port (UP MEP).

See inline for more comment...

  _____  

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: zaterdag 23 januari 2010 8:57
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; 'Greg Mirsky'
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Maarten,
I may be missing something important, but how iy seems that you ignore the
fundamental differences between Ethernet and MPLS data planes in your
analysis. 
 
[maarten] I am absolutely not ignoring the differences between Ethernet and
MPLS data planes, as I am also not ignoring the commonalities. 
 
[maarten] What I mean is that it is possible to set up an e.g. 9-port mp2mp
LSP connection in the MPLS technology and order an mpls switch to read the
inner (PW) label and use the value of this inner label to forward the packet
to one of the 9 output ports of the mp2mp LSP... It should be clear that a
switch with such capability has a feature which is not described in the MPLS
RFCs; i.e. it is a proprietary extension which I am describing below to
illustrate that such extension does not interfere with the standardized MPLS
behaviour, and that it does not change that behaviour. 
 
-----------------
[maarten] It is very simple to test the forwarding of packets in such mp2mp
LSP in a research lab :-)...; inner label values 1000-1999 were delivered at
output port 1, inner label values 2000-2999 were delivered at output 2,
inner label values 3000-3999 were delivered at output port 3, etc. The mpls
switch reads the outer label value to identify the LSP, then reads the inner
label value and forwards all packets with inner label value 1xxx to output
port 1, with inner label value 2xxx to output port 2, etc.
 
[maarten] Another nice test application for such LSP is in a physical ring;
e.g. with 8 nodes. In this case you can identify the destination ring node
in the 3 most significant bits of the PW label and the output trib card on a
ring node by the next 7 bits and the individual PW instances by the 10 least
significant bits. Number the ring nodes from 0 to 7. Now ring node 0 will
forward the packets with inner label values 001/010/011xxxxxxxxxxxxxxxxx via
its east line port and packets with inner label values
100/101/110/111xxxxxxxxxxxxxxxxx via its west line port. If the ring breaks
between nodes 5 and 6, then ring node 0 will change the forwarding of
packets with inner label values 100/101xxxxxxxxxxxxxxxxx from the west line
port to the east line port. Node 0 is informed about the break between nodes
6 and 7 by means of a ring-APS message including the number of the node and
the interface (east/west) detecting the fault. Ring node 0 will always
extract packets with inner label values 000xxxxxxxxxxxxxxxxxxx to prevent
that packets get looped in the mp2mp Ring-LSP and forward packets with other
label values on the east line port to the west line port (and vice versa).
 
[maarten] to support the transport of p2mp PWs through such mp2mp LSP
another set of PW label values was allocated, e.g. 10000-10999. The mpls
switch reads the outer label value to identify the LSP, then reads the inner
label value and in case of a value in the 10xxx range looks up in a table
the subset of output ports to which this packet has to be sent.
 
[maarten] The same mpls switch also supports p2p LSPs and when the outer
label value is associated with such p2p LSP it will ignore the inner label
value and forward the packet to the output port.
 
[maarten] The same mpls switch also supports p2mp LSPs and when the out
label value is associated with such p2mp LSP the switch will ignore the
inner label value and looks up in a table the set of output ports of this
p2mp LSP and forwards the packet to all output ports.
 
[maarten] The same mpls switch also looks at the inner label on the
interface port to identify if the packet is an OAM packet and then look at
the ACH channel type to identify the type of OAM packet to see if the packet
must be processed in the interface port (and not forwarded to the switch
fabric). The existing mpls switch ports will only be able to look at inner
labels of packets of which the outer label is terminated; new mpls switch
ports will be able to look at inner labels of all packets; this is a similar
evolution as we got in ethernet... existing ethernet switches could only
look at the TYPE and DA fields to identify if an OAM frame had to be
processed (those switches could only support a subset of the Y.1731 OAM),
new ethernet switches are looking at the TYPE and MEL fields and can support
the full set of Y.1731 OAM.
 
[maarten] I hope you understand now that it is possible to extend the MPLS
data plane specified in the RFCs with a 'connectionless-LSP' capability.
Such extended mpls dataplane will then contain a mix of connection
oriented-LSPs and connectionless-LSPs. The behaviour of the
connection-oriented-LSPs complies with the specifications in the RFCs. The
connectionless-LSPs are a bonus.
---------------------
 
[maarten] An ethernet switch reads the outer vlan identifier and when the
outer vlan identifier is associated with a 
- p2p VLAN it will ignore the DA value and forward the frame to the output
port
- p2mp VLAN it will ignore the DA value and looks up in a table the set of
output ports of this p2mp VLAN and forwards the frame to all those output
ports
- mp2mp or rmp VLAN it will read the DA and looks up in a table the output
port or ports of this mp2mp VLAN to which this frame should be forwarded.
The ethernet switch also looks at the inner TYPE (i.e. TPID) in all cases on
the interface port to identify if the frame is an OAM frame and then look at
the MEL field and OpCode fields to identify the type of OAM frame and its
MEG level to see if the packet must be processed in the interface port (and
not forwarded to the switch fabric).
 
[maarten] I don't see as such any functional difference between the mpls and
ethernet data planes; the same information elements are present in both data
planes, but with a different encoding of this information in the
frame/packet... the main difference is that standard mpls switches don't use
the inner label value to control forwarding of a packet to a subset of
output ports of an LSP, while ethernet switches typically support both the
use of the DA value to control forwarding and the don't use of the DA value
to control forwarding to a subset of VLAN output ports... but note that
there is also a set of ethernet switches that only support don't use of the
DA value to control forwarding, i.e. which support only p2p and p2mp VLANs.
 
Ethernet data plane inherently recognizes "well-know multicast MAC
destination addresses". If a switch wants so, it can catch all the frames
with such a DA and decide how it treats them "out-of-band".  
 
[maarten] The well-known MAC multicast destination addresses listed in Table
8-1/802.1Q are identifying management plane and control plane protocols that
are carried over the links; those frames are not belonging to the user
traffic carried in the VLANs. In MPLS-TP similar management and control
plane information is carried via the MCC and SCC packets specified in
RFC5718.
 
[maarten] If you read G.8021 then you will notice that the well-know
multicast MAC destination addresses for OAM are not being recognized in the
ETH atomic functions processing Ethernet OAM.  
Note that G.8021 has never used the DA field in the Ethernet OAM frame as a
means to identify OAM from non-OAM frames, as Y.1731 has from day one
specified OAM frames that carry a unicast address which do not contain these
well-known OAM multicase destination addresses. 
Y.1731/G.8021 use the TYPE field to separate OAM from non-OAM frames, the
MEL field to identify the MEG level and the OpCode field to identify the
type of OAM. 
 
[maarten] MPLS-TP will use the LABEL field to separate LSP-OAM from non-LSP
OAM packets, the label stack to identify the MEG level and the ACH channel
type field to identify the type of OAM. 
I.e. the same information, just a different encoding.
 
All Ethernet protocols operate in this way, 802.1ag is not an exception. And
this is exactly what allows separation between addressing and MEP/MIP levels
in 802.1ag.  
 
[maarten] As indicated above, your understanding of Ethernet OAM protocol
processing does not align with Y.1731/G.8021 specifications.
 
[maarten] The unicast LBM OAM is a special OAM frame/packet as it requires
one additional information element; i.e. a MIP identifier. This MIP
identifier must be carried in the LBM OAM frame/packet in both Ethernet and
in bidirectional p2mp MPLS-TP LSP cases; in MPLS-TP to differentiate MIPs in
a bidirectional p2mp LSP located at the same hop count from the MEP. Because
the bidir p2mp LSP was only recently described in this mailinglist the
implications of such LSP on the loopback OAM have not yet been investigated
and documented.
 
[maarten] Both in Ethernet and MPLS OAM the OAM process must read this MIP
identifier field when the OAM frame/packet is identified as a LBM OAM. The
MIP identifier in Ethernet OAM is the EUI-48 of the physical subsystem on
which the MIP resides, while in MPLS-TP OAM this is not yet in scope of the
OAM framework. But if there is a real demand for such bidir p2mp LSP or PW,
we should include the MIP Identifier in the OAM framework document for
loopback OAM.
 
The disadvantage of this approach is that Ethernet OAM frames are not
necessarily fate-sharing with the data traffic. 
 
[maarten]  All Ethernet OAM frames fate share with the VLAN (i.e. the
Ethernet transport entity) in a similar manner as all MPLS-TP OAM packets
will fate share with the PW and LSP (i.e. the MPLS transport entities).
 
[maarten] There is one type of OAM that has to fate share with more then the
VLAN/PW/LSP; i.e. the frame/packet loss OAM has to fate share with both the
VLAN/PW/LSP and the frames/packets for which the ingress count is
transported in this OAM frame/packet. In p2p/p2mp VLANs/PWs/LSPs there is no
problem to meet this requirement. In rmp/mp2mp VLANs and mp2p PWs/LSPs there
is a problem to meet the second requirement. I.e. no difference as such
between Ethernet and MPLS.
 
The MPLS data plane is defined in RFC 3031, 30302 and (for
upstream-allocated labels) in RFC 5331, 5332. Its analog of Ethernet
well-know multicast MAC destination addresses is the reserved Router Alert
Label. But its usage  has been rejected for usage in MPLS-TP OAM exactly
because fate-sharing of data and OAM packets could be broken. Instead,
MPLS-TP uses two different mechanisms: 

1.	

	GAL. This mechanism can only be used to address MEPs, because the
LER processing a packet with the GAL at some level in the label stack is not
allowed to look at it unless it terminates all the labels above it are
terminated (i.e., its ILM entries for these labels must be "pop and forward
to the loopback interface").  [maarten] The ethernet equivalent to the GAL
is the OAM ethertype value 89-02. 
2.	

	TTL expiration. This is the only mechanism for addressing MIPs in
MPLS-TP. And, of course, TTL expiration must occur in the first label stack
entry following all the labels terminated by the supporting node.  [maarten]
As described above, as soon as MPLS-TP has to support bidir p2mp LSPs/PWs it
will have to include the MIP Identifier to address the MIP that has to
perform the loopback.

[maarten] Ethernet OAM Y.1731 specifies an Ethernet MCC OAM frame to carry
management plane frames. This is similar to the MPLS-TP MCC OAM packet
defined in RFC5718.

Regards,

Maarten  

In short, LERs do not look at the next label if they do not terminate the
previous one. 

Hence I think that some of the MEPs you've defined are non-addressable (and
hence unusable) in MPLS-TP which shares the MPLS data plane. 

My 2c,

     Sasha

  _____  

From: [email-masked] [[email-masked]] On Behalf Of
Maarten Vissers [[email-masked]]
Sent: Saturday, January 23, 2010 7:37 AM
To: 'Greg Mirsky'
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Hi Greg,
 
See inline.. 
  _____  

Dear Maarten,

[maarten] Correct.

 

 

 

 

 

 
Regards,
Maarten 

Regards,
Greg

Hi Greg,

 
 
Regards,
Maarten

  _____  

Dear Maarten,

Regards,
Greg

Greg,

Regards,
Maarten

  _____  

Dear Editors and All,

Regards,
Greg

---

From: Maarten Vissers <[email-masked]>
Date: Sun, 24 Jan 2010 06:10:41 +0100

Sasha,
 
I have described in my previous email to you how the mpls data plane could
be extended to support mp2mp LSPs (e.g. Ring-LSPs) and that such additional
capability is backwards compatible with the current standardized behaviour.
I did this to illustrate the differences and commonalities between mpls and
ethernet data planes.
 
I would like to extend this illustration of commonalities and differences of
those two data plane by illustrating an extension of the unidir p2mp LSP
functionality and how one can emulate PBT with LSPs. Neither of those
extensions will impact the compatibility with existing implementations; i.e.
those extensions would be pure additions.
 
1) if one would set up a unidir p2mp LSP with 1 input port and 9 output
ports and want to transport over this p2mp LSP a large number of p2p PWs,
then this is possible today (but is not efficient)... allocate the PW label
values such that PWs destined for output port 1 have PW label values
1000-1999, PWs destined for output port 2 have PW label values 2000-2999,
etc. 
In a traditional p2mp LSP, all PWs are delivered to all 9 output ports, and
output port 1 will then discard packets that have PW label values 2000 and
higher. Output port 2 will discard packets with PW label values 16-1999 and
3000 and higher, etc. 
If the intermediate P nodes would be able to read the inner (PW) label as
described in my earlier email, then such P node can for this specific p2mp
LSP limit the forwarding of the packets to one output port; i.e. the undir
p2mp LSP is becoming a unidir rooted-mp LSP. 
 
The ability to read the inner label within a selected LSP and use its value
in the forwarding decision of the packet does not impact the forwarding in
the other LSPs. 
 
>From a connection management perspective (management or control plane) the
set up of the basic p2mp connection is the same, there is only an additional
configuration necessary of the forwarding process in each P node; i.e.
configure PW label range to output port mapping. 
E.g. an intermediate P node supporting this p2mp LSP may have 1 input port
and 3 output ports (ports A, B, C) for this p2mp LSP; packets with inner
label values 1xxx, 2xxx, 3xxx have to be forwarded to output port A, packets
with inner label values 4xxx, 5xxx, 6xxx have to be forwarded to output port
B and packets with inner label values 7xxx, 8xxx, 9xxx have to be forwarded
to output port C.
 
If one would set up both a p2mp LSP and a co-routed mp2p LSP then we would
get a bidir rooted-mp LSP, which has similar forwarding behaviour as the
rooted-mp VLAN. 
 
2) PBT provides a full mesh of p2p ESPs between Ethernet/PBT PE nodes. The
PBT P nodes forward on the basis of a mp2p construct. 
In the mpls data plane the same behaviour can be obtained by setting up a
full mesh of p2p LSPs between S-PE nodes and transport those p2p LSPs over a
full mesh of mp2p LSPs. The NNI port on the S-PE node will then push a p2p
LSP label (PP label) and a mp2p LSP label (MPP label). 
As pushing/popping multiple labels in an NNI port seems a trivial item these
days (i.e. this capability is deployed to implement tandem
connection/segment monitoring in MPLS-TP), it should be simple to apply it
the run p2p LSPs over mp2p LSP. The P nodes forward on the basis of the MPP
label. The S-PE nodes terminate both MPP label and PP label and forward the
PWs, packet PWs, serviceLSPs and segment monitor LSPs which were transported
via the PP LSPs.
 
If desired it is possible to structure the PP LSP label values, and have the
most significant bits of this PP label identify the source S-PE NNI port;
but I don't think that mpls data plane has this as a requirement; i.e. it
can handle unstructured sets of PP label values. Note that
http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-03 LSP OAM supports
the OAM needed in such mp2p LSP transport paths.
 
If one would set up two diversely routed sets of mp2p LSPs it is possible to
emulate the PBT protection swithcing. PW, packet PW, service LSP, segment
monitoring PW/LSP packets are under normal conditions transported via the
Working PP LSP over the Working MPP LSP. If this one fails, then the S-PE
will send the packets over the Protection PP LSP over the Protection MPP
LSP.
 
Note that the p2p LSPs can be monitored for connectivity and performance
(e.g. packet loss). The mp2p LSPs can only be monitored for connectivity;
packet loss can not be monitored if unstructured PP labels are used. As the
mp2p LSP is only used to reduce the number of entries in the P node
switching table it is not a problem that packet loss in the mp2p LSP can not
be monitored.
 
I hope I was able to illustrate that there is not much difference between
the ethernet and mpls data planes, and that with minimal extensions in the
forwarding control of packets within an LSP it is possible to expand the
mpls data plane capabilities that today are only provided in the ethernet
data plane, without a need to change the existing mpls packet formats and
without impacting the existing standardized behaviour.
 
Please note that I am not proposing to introduce such extensions into the
mpls data plane.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: zaterdag 23 januari 2010 17:03
To: 'Alexander Vainshtein'
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Sasha,
 
previous one. 

- Etc.

- Etc.

 

  _____  

Maarten,

 
-----------------

 

 

 

 

 

 

1.	

Regards,

Maarten  

My 2c,

     Sasha

  _____  

Hi Greg,
 
See inline.. 
  _____  

Dear Maarten,

[maarten] Correct.

 

 

 

 

 

 
Regards,
Maarten 

Regards,
Greg

Hi Greg,

 
 
Regards,
Maarten

  _____  

Dear Maarten,

Regards,
Greg

Greg,

Regards,
Maarten

  _____  

Dear Editors and All,

Regards,
Greg

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 26 Jan 2010 10:37:40 +0200

Maarten,
I apologize for a delayed response.
I think that the example you've given actually confirms my point of view: your model does not work with the regular MPLS data plane.
Here is my analysis of your logic, based on the assumption that all LSPs are P2P and downstream label allocation is used. The conclusions would not change if

 1.  <Maarten> The MPLS-TP LSP OAM inserted by the lower blue MEP in node P-left has as top and bottom of stack the GAL [[Sasha]] OK. This implies that S-PE-left looks on the labeled packets it receives from P-Left, otherwise it would simply ignore GAL
 2.  <Maarten> The MPLS-TP LSP OAM inserted by the higher blue MEP in node P-left has as top of stack the label inserted by the lower blue MEP (identified as LSE) and as bottom of stack the GAL... The interface port in the S-PE-left port will swap the top of stack label of non-OAM and TTL not-expired packets [[Sasha]] This implies that the top label in this stack has been allocated by S-PE-Left, bound by it to a certain FEC, and this binding "distributed" (no matter by which means) to P-Left. Were it not so, the label placed by the higher blue MEP on top of the label stack in a labeled packet P-left sends to S-PE-left would be treated by the latter as invalid, and the packet would be discarded - see RFC 3031, Section 3.18. And this, in its turn, means that S-PE-Left is adjacent to P-Left : it allocates and binds to FECs labels that P-left puts on top of the stack in labeled packets that from its point of view, belong to these FECs. In your example the FEC in question is formed by the packets that should go to PE-right, and the conclusion is that PE-right is NOT adjacent to PE-Left.

The bottom line, IMHO and FWIW, that adjacency in the MPLS data plane (and, by implication, in the MPLS-TP one) is directly related to the label allocation and label-to-FEC binding. If we can agree on that, this should be explicitly mentioned in the MPLS-TP Framework document to prevent misunderstanding.

Regards,
     Sasha
Sent: Saturday, January 23, 2010 6:03 PM
To: Alexander Vainshtein

Sasha,

> Hence I think that some of the MEPs you've defined are non-addressable (and hence unusable) in MPLS-TP which shares the MPLS data plane.

If what you state is correct there is a serious problem within the existing draft specification for MPLS-TP.  These functional models describe a part of the required functional behaviour in a (packet) transport network of any technology.

I doubt that such problem exist... so the MEPs and MIPs in my models are all addressable (and hence usable) in MPLS-TP...

Let's analyse the left inter domain interface between carrier A's P node and B's left S-PE node as an exercise...

1) there is a MPLS-TP Section layer transport path (VSC) between carrier A nodes P-left and P-right

2) there is a MPLS-TP Section layer transport path segment (VSC Segment) between nodes P-left and S-PE-left

3) there is a MPLS-TP transport service layer transport path (VCC) between nodes S-PE-left and S-PE-right (yellow MEPs).

- The MPLS-TP LSP OAM inserted by the lower blue MEP in node P-left has as top and bottom of stack the GAL.

- The MPLS-TP LSP OAM inserted by the higher blue MEP in node P-left has as top of stack the label inserted by the lower blue MEP (identified as LSE) and as bottom of stack the GAL.

- The lower blue MEP in node S-PE-left has to process all packets with top of stack the GAL.

- The blue MIP in node S-PE-left has to process all packets generated by the higher blue MEP in node P of which the TTL expires; these packets arrive at node S-PE-left with two labels, of which the bottom of stack label is the GAL and the top of stack label is a regular LSP label.

- The interface port in the S-PE-left port will swap the top of stack label of non-OAM and TTL not-expired packets; the new label value will be the value inserted by the left yellow MEP in the S-PE-left node (indicated by LSE next to the yellow MEP symbol).

- If the packet was a VSC OAM packet of which the TTL expires, the packet will be extracted by the blue MIP within the VSC.

- The yellow MEP inserts the LSP OAM into the carrier A's VSC, creating a monitored VSC Segment, and treats this VSC Segment as one of its VCCs. This VCC related LSP OAM will pass through a VCC MIP on the egress NNI port in the S-PE-left node (i.e. egress MIP issue applies).

- The VCC signal is multiplexed into an MPLS-TP transport path layer transport path (VPC) and its packets are prepended with a new LSP label identifying the VCC.

- Etc.

- In the reverse direction, the VPC terminates on the right NNI port of the S-PE-left node, providing access the VCC LSPs carried in the VPC. If the TTL of a VCC LSP OAM expires the VCC LSP MIP function will process the OAM. All other VCC LSP related packets are forwarded to the egress port which is connected to carrier A's P node.

- The VCC LSP terminates on the egress port, and the LSP label identifying this VCC LSP is terminated; the yellow VCC LSP MEP on the egress port can now determine which packets carry the VCC LSP OAM by checking for the GAL as next top label.

- The VCC LSP label is also removed from the non-VCC LSP OAM packets and it is possible that on one of those packets the TTL expires. Such packets are processed by the blue MIP function above the yellow MEP function in the S-PE-left node.

- The outer label on packets of which the TTL has not expired will be swapped, and LSP OAM will be added in the lower blue section layer MEP on the S-PE-left node. This OAM will be output with GAL as top and bottom of stack label.

- Etc.

I can't find a problem in the above required behaviour, besides the well known egress-MIP identification problem.

There is always an outer LSP label being terminated when a MEP function is following and LSP OAM has to be extracted and processed.

In some cases the LSP terminates on an ingress port (DOWN MEP), in other cases the LSP terminates on an egress port (UP MEP).

Maarten,

[maarten] I am absolutely not ignoring the differences between Ethernet and MPLS data planes, as I am also not ignoring the commonalities.

[maarten] What I mean is that it is possible to set up an e.g. 9-port mp2mp LSP connection in the MPLS technology and order an mpls switch to read the inner (PW) label and use the value of this inner label to forward the packet to one of the 9 output ports of the mp2mp LSP... It should be clear that a switch with such capability has a feature which is not described in the MPLS RFCs; i.e. it is a proprietary extension which I am describing below to illustrate that such extension does not interfere with the standardized MPLS behaviour, and that it does not change that behaviour.

-----------------
[maarten] It is very simple to test the forwarding of packets in such mp2mp LSP in a research lab :-)...; inner label values 1000-1999 were delivered at output port 1, inner label values 2000-2999 were delivered at output 2, inner label values 3000-3999 were delivered at output port 3, etc. The mpls switch reads the outer label value to identify the LSP, then reads the inner label value and forwards all packets with inner label value 1xxx to output port 1, with inner label value 2xxx to output port 2, etc.

[maarten] Another nice test application for such LSP is in a physical ring; e.g. with 8 nodes. In this case you can identify the destination ring node in the 3 most significant bits of the PW label and the output trib card on a ring node by the next 7 bits and the individual PW instances by the 10 least significant bits. Number the ring nodes from 0 to 7. Now ring node 0 will forward the packets with inner label values 001/010/011xxxxxxxxxxxxxxxxx via its east line port and packets with inner label values 100/101/110/111xxxxxxxxxxxxxxxxx via its west line port. If the ring breaks between nodes 5 and 6, then ring node 0 will change the forwarding of packets with inner label values 100/101xxxxxxxxxxxxxxxxx from the west line port to the east line port. Node 0 is informed about the break between nodes 6 and 7 by means of a ring-APS message including the number of the node and the interface (east/west) detecting the fault. Ring node 0 will always extract packets with inner label values 000xxxxxxxxxxxxxxxxxxx to prevent that packets get looped in the mp2mp Ring-LSP and forward packets with other label values on the east line port to the west line port (and vice versa).

[maarten] to support the transport of p2mp PWs through such mp2mp LSP another set of PW label values was allocated, e.g. 10000-10999. The mpls switch reads the outer label value to identify the LSP, then reads the inner label value and in case of a value in the 10xxx range looks up in a table the subset of output ports to which this packet has to be sent.

[maarten] The same mpls switch also supports p2p LSPs and when the outer label value is associated with such p2p LSP it will ignore the inner label value and forward the packet to the output port.

[maarten] The same mpls switch also supports p2mp LSPs and when the out label value is associated with such p2mp LSP the switch will ignore the inner label value and looks up in a table the set of output ports of this p2mp LSP and forwards the packet to all output ports.

[maarten] The same mpls switch also looks at the inner label on the interface port to identify if the packet is an OAM packet and then look at the ACH channel type to identify the type of OAM packet to see if the packet must be processed in the interface port (and not forwarded to the switch fabric). The existing mpls switch ports will only be able to look at inner labels of packets of which the outer label is terminated; new mpls switch ports will be able to look at inner labels of all packets; this is a similar evolution as we got in ethernet... existing ethernet switches could only look at the TYPE and DA fields to identify if an OAM frame had to be processed (those switches could only support a subset of the Y.1731 OAM), new ethernet switches are looking at the TYPE and MEL fields and can support the full set of Y.1731 OAM.

[maarten] I hope you understand now that it is possible to extend the MPLS data plane specified in the RFCs with a 'connectionless-LSP' capability. Such extended mpls dataplane will then contain a mix of connection oriented-LSPs and connectionless-LSPs. The behaviour of the connection-oriented-LSPs complies with the specifications in the RFCs. The connectionless-LSPs are a bonus.
---------------------

[maarten] An ethernet switch reads the outer vlan identifier and when the outer vlan identifier is associated with a
- p2p VLAN it will ignore the DA value and forward the frame to the output port
- p2mp VLAN it will ignore the DA value and looks up in a table the set of output ports of this p2mp VLAN and forwards the frame to all those output ports
- mp2mp or rmp VLAN it will read the DA and looks up in a table the output port or ports of this mp2mp VLAN to which this frame should be forwarded.
The ethernet switch also looks at the inner TYPE (i.e. TPID) in all cases on the interface port to identify if the frame is an OAM frame and then look at the MEL field and OpCode fields to identify the type of OAM frame and its MEG level to see if the packet must be processed in the interface port (and not forwarded to the switch fabric).

[maarten] I don't see as such any functional difference between the mpls and ethernet data planes; the same information elements are present in both data planes, but with a different encoding of this information in the frame/packet... the main difference is that standard mpls switches don't use the inner label value to control forwarding of a packet to a subset of output ports of an LSP, while ethernet switches typically support both the use of the DA value to control forwarding and the don't use of the DA value to control forwarding to a subset of VLAN output ports... but note that there is also a set of ethernet switches that only support don't use of the DA value to control forwarding, i.e. which support only p2p and p2mp VLANs.

Ethernet data plane inherently recognizes "well-know multicast MAC destination addresses". If a switch wants so, it can catch all the frames with such a DA and decide how it treats them "out-of-band".

[maarten] The well-known MAC multicast destination addresses listed in Table 8-1/802.1Q are identifying management plane and control plane protocols that are carried over the links; those frames are not belonging to the user traffic carried in the VLANs. In MPLS-TP similar management and control plane information is carried via the MCC and SCC packets specified in RFC5718.

[maarten] If you read G.8021 then you will notice that the well-know multicast MAC destination addresses for OAM are not being recognized in the ETH atomic functions processing Ethernet OAM.
Note that G.8021 has never used the DA field in the Ethernet OAM frame as a means to identify OAM from non-OAM frames, as Y.1731 has from day one specified OAM frames that carry a unicast address which do not contain these well-known OAM multicase destination addresses.
Y.1731/G.8021 use the TYPE field to separate OAM from non-OAM frames, the MEL field to identify the MEG level and the OpCode field to identify the type of OAM.

[maarten] MPLS-TP will use the LABEL field to separate LSP-OAM from non-LSP OAM packets, the label stack to identify the MEG level and the ACH channel type field to identify the type of OAM.
I.e. the same information, just a different encoding.

All Ethernet protocols operate in this way, 802.1ag is not an exception. And this is exactly what allows separation between addressing and MEP/MIP levels in 802.1ag.

[maarten] As indicated above, your understanding of Ethernet OAM protocol processing does not align with Y.1731/G.8021 specifications.

[maarten] The unicast LBM OAM is a special OAM frame/packet as it requires one additional information element; i.e. a MIP identifier. This MIP identifier must be carried in the LBM OAM frame/packet in both Ethernet and in bidirectional p2mp MPLS-TP LSP cases; in MPLS-TP to differentiate MIPs in a bidirectional p2mp LSP located at the same hop count from the MEP. Because the bidir p2mp LSP was only recently described in this mailinglist the implications of such LSP on the loopback OAM have not yet been investigated and documented.

[maarten] Both in Ethernet and MPLS OAM the OAM process must read this MIP identifier field when the OAM frame/packet is identified as a LBM OAM. The MIP identifier in Ethernet OAM is the EUI-48 of the physical subsystem on which the MIP resides, while in MPLS-TP OAM this is not yet in scope of the OAM framework. But if there is a real demand for such bidir p2mp LSP or PW, we should include the MIP Identifier in the OAM framework document for loopback OAM.

The disadvantage of this approach is that Ethernet OAM frames are not necessarily fate-sharing with the data traffic.

[maarten]  All Ethernet OAM frames fate share with the VLAN (i.e. the Ethernet transport entity) in a similar manner as all MPLS-TP OAM packets will fate share with the PW and LSP (i.e. the MPLS transport entities).

[maarten] There is one type of OAM that has to fate share with more then the VLAN/PW/LSP; i.e. the frame/packet loss OAM has to fate share with both the VLAN/PW/LSP and the frames/packets for which the ingress count is transported in this OAM frame/packet. In p2p/p2mp VLANs/PWs/LSPs there is no problem to meet this requirement. In rmp/mp2mp VLANs and mp2p PWs/LSPs there is a problem to meet the second requirement. I.e. no difference as such between Ethernet and MPLS.

 1.
GAL. This mechanism can only be used to address MEPs, because the LER processing a packet with the GAL at some level in the label stack is not allowed to look at it unless it terminates all the labels above it are terminated (i.e., its ILM entries for these labels must be "pop and forward to the loopback interface").  [maarten] The ethernet equivalent to the GAL is the OAM ethertype value 89-02.
 2.
TTL expiration. This is the only mechanism for addressing MIPs in MPLS-TP. And, of course, TTL expiration must occur in the first label stack entry following all the labels terminated by the supporting node.  [maarten] As described above, as soon as MPLS-TP has to support bidir p2mp LSPs/PWs it will have to include the MIP Identifier to address the MIP that has to perform the loopback.

[maarten] Ethernet OAM Y.1731 specifies an Ethernet MCC OAM frame to carry management plane frames. This is similar to the MPLS-TP MCC OAM packet defined in RFC5718.

Regards,

Maarten

My 2c,

     Sasha

Hi Greg,

See inline..

Dear Maarten,

[maarten] Correct.

Regards,
Maarten

Regards,
Greg

Regards,
Maarten

Dear Maarten,

Regards,
Greg

Regards,
Maarten

Dear Editors and All,

Regards,
Greg

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 26 Jan 2010 15:44:26 +0100

Sasha,
 
See inline..

  _____  

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

Maarten,
I apologize for a delayed response. 
I think that the example you've given actually confirms my point of view:
your model does not work with the regular MPLS data plane.
Here is my analysis of your logic, based on the assumption that all LSPs are
P2P and downstream label allocation is used. The conclusions would not
change if 

1.	<Maarten> The MPLS-TP LSP OAM inserted by the lower blue MEP in node
P-left has as top and bottom of stack the GAL [[Sasha]] OK. This implies
that S-PE-left looks on the labeled packets it receives from P-Left,
otherwise it would simply ignore GAL  

[maarten2] The S-PE-left has a MPLS-TP blue MEP function at its input and
this blue MEP function will look for packets with as top label the GAL.

1.	<Maarten> The MPLS-TP LSP OAM inserted by the higher blue MEP in
node P-left has as top of stack the label inserted by the lower blue MEP
(identified as LSE) and as bottom of stack the GAL... The interface port in
the S-PE-left port will swap the top of stack label of non-OAM and TTL
not-expired packets [[Sasha]] This implies that the top label in this stack
has been allocated by S-PE-Left, bound by it to a certain FEC, and this
binding "distributed" (no matter by which means) to P-Left. Were it not so,
the label placed by the higher blue MEP on top of the label stack in a
labeled packet P-left sends to S-PE-left would be treated by the latter as
invalid, and the packet would be discarded - see RFC 3031, Section 3.18. And
this, in its turn, means that S-PE-Left is adjacent to P-Left : it allocates
and binds to FECs labels that P-left puts on top of the stack in labeled
packets that from its point of view, belong to these FECs. In your example
the FEC in question is formed by the packets that should go to PE-right, and
the conclusion is that PE-right is NOT adjacent to PE-Left. 

[maarten2] There are two MEG levels (bindings) in the Section layer:
A. P-left to S-PE-left
B. P-left to P-right.
For the A. binding P-left and S-PE-left are adjacent. They share one
Maintenance Entity Group (MEG) level and monitor this Section MEG by means
of two Section MEP functions.
For the B. binding P-left and P-right are  adjacent. They share one
Maintenance Entity Group (MEG) level and monitor this Section Segment MEG by
means of two Section Segment MEP functions.
 
The bottom line, IMHO and FWIW, that adjacency in the MPLS data plane (and,
by implication, in the MPLS-TP one) is directly related to the label
allocation and label-to-FEC binding. If we can agree on that, this should be
explicitly mentioned in the MPLS-TP Framework document to prevent
misunderstanding. 
 
[maarten2]  There are multiple adjacencies in the MPLS and MPLS-TP (and any
other) data plane. 
Those adjacencies are Maintenance Entity Groups and are represented by their
MEG levels.
For OAM the MEG type of adjacencies are relevant, not the label type
adjacencies.
A server layer or server sublayer MEG type adjacency has a 1-to-1
relationship with a label type adjacency.
A label identifies one 'link connection' within a 'network connection', in
the blue Section layer, the label used on the link between P-left and
S-PE-left identifies one of the three link connections that establish the
Section layer network connection, which latter is monitored by the Section
MEG.
 
[maarten2] I understand that there are two types of adjacencies to recognize
and specify in MPLS-TP. I suggest that we specify both explicitly and that
we describe the relationship between these two adjacencies. This will
prevent further misunderstandings.
 
Regards,
Maarten
 
Regards,
     Sasha

  _____  

Sasha,
 
previous one. 

- Etc.

- Etc.

 

  _____  

Maarten,

 
-----------------

 

 

 

 

 

 

1.	

Regards,

Maarten  

My 2c,

     Sasha

  _____  

Hi Greg,
 
See inline.. 
  _____  

Dear Maarten,

[maarten] Correct.

 

 

 

 

 

 
Regards,
Maarten 

Regards,
Greg

Hi Greg,

 
 
Regards,
Maarten

  _____  

Dear Maarten,

Regards,
Greg

Greg,

Regards,
Maarten

  _____  

Dear Editors and All,

Regards,
Greg

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 26 Jan 2010 16:48:09 +0200

Maarten,
IMHO and FWIW, OAM must follow what the data plane (which, in the case of MPLS is label-based) does.
If MEG levels (and adjacencies) are not bound to data plane adjacencies, what are these MEGs about?

Regards,
     Sasha

Sent: Tuesday, January 26, 2010 4:44 PM

Sasha,

See inline..

Maarten,

[maarten2] The S-PE-left has a MPLS-TP blue MEP function at its input and this blue MEP function will look for packets with as top label the GAL.

 1.  <Maarten> The MPLS-TP LSP OAM inserted by the higher blue MEP in node P-left has as top of stack the label inserted by the lower blue MEP (identified as LSE) and as bottom of stack the GAL... The interface port in the S-PE-left port will swap the top of stack label of non-OAM and TTL not-expired packets [[Sasha]] This implies that the top label in this stack has been allocated by S-PE-Left, bound by it to a certain FEC, and this binding "distributed" (no matter by which means) to P-Left. Were it not so, the label placed by the higher blue MEP on top of the label stack in a labeled packet P-left sends to S-PE-left would be treated by the latter as invalid, and the packet would be discarded - see RFC 3031, Section 3.18. And this, in its turn, means that S-PE-Left is adjacent to P-Left : it allocates and binds to FECs labels that P-left puts on top of the stack in labeled packets that from its point of view, belong to these FECs. In your example the FEC in question is formed by the packets that should go to PE-right, and the conclusion is that PE-right is NOT adjacent to PE-Left.

[maarten2] There are two MEG levels (bindings) in the Section layer:
A. P-left to S-PE-left
B. P-left to P-right.
For the A. binding P-left and S-PE-left are adjacent. They share one Maintenance Entity Group (MEG) level and monitor this Section MEG by means of two Section MEP functions.
For the B. binding P-left and P-right are  adjacent. They share one Maintenance Entity Group (MEG) level and monitor this Section Segment MEG by means of two Section Segment MEP functions.

[maarten2]  There are multiple adjacencies in the MPLS and MPLS-TP (and any other) data plane.
Those adjacencies are Maintenance Entity Groups and are represented by their MEG levels.
For OAM the MEG type of adjacencies are relevant, not the label type adjacencies.
A server layer or server sublayer MEG type adjacency has a 1-to-1 relationship with a label type adjacency.
A label identifies one 'link connection' within a 'network connection', in the blue Section layer, the label used on the link between P-left and S-PE-left identifies one of the three link connections that establish the Section layer network connection, which latter is monitored by the Section MEG.

[maarten2] I understand that there are two types of adjacencies to recognize and specify in MPLS-TP. I suggest that we specify both explicitly and that we describe the relationship between these two adjacencies. This will prevent further misunderstandings.

Regards,
Maarten

Regards,
     Sasha

Sasha,

- Etc.

- Etc.

Maarten,

-----------------

 1.

Regards,

Maarten

My 2c,

     Sasha

Hi Greg,

See inline..

Dear Maarten,

[maarten] Correct.

Regards,
Maarten

Regards,
Greg

Regards,
Maarten

Dear Maarten,

Regards,
Greg

Regards,
Maarten

Dear Editors and All,

Regards,
Greg

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 26 Jan 2010 16:22:37 +0100

Sasha,
 
Below the definitions of a MEG and ME from Y.1731. It are the basic
architecture components for OAM. 
OAM frames exist within one MEG, and determine the status/performance of the
MEG. 
An MEG exists within the bounds of a transport entity.
 
In MPLS-TP a MEG is bound to a MS-PW and to a LSP. 
In the example, the "Section layer transport path" is provided by an LSP,
which is monitored by the top blue MEG. 
The "Section layer transport path segment" between P-left and S-PE-left is
provided by either an unlabeled or priority labelled LSP, which is monitored
by the bottom blue MEG.
This "Section layer transport path segment" may be unmonitored (as
illustrated in mplstp-connection-concepts-06w.pdf), and in this case there
is no MEG and there is no LSP.
 
Regards,
Maarten

5.1        Maintenance entity (ME)

ME represents an entity that requires management and is a relationship
between two maintenance entity group end points (see clause 5.3). MEs in
Ethernet networks have been identified in Figure 23 of [ITU-T G.8010] (see
Figure 5-1), Figure 24 of [ITU-T G.8010] and clause 9 of [ITU-T Y.1730]. MEs
can nest but not overlap.

5.2        ME group (MEG)

ME group (MEG) includes different MEs that satisfy the following conditions:

.            MEs in a MEG exist in the same administrative boundary; and

.            MEs in a MEG have the same MEG level (see clause 5.6); and

.            MEs in a MEG belong to the same point-to-point ETH connection
or multipoint ETH connectivity.

For a point-to-point ETH connection, a MEG contains a single ME. For a
multipoint ETH connectivity containing n end-points, a MEG contains
n*(n-1)/2 MEs.

5.3        MEG end point (MEP)

MEG end point (MEP) marks the end point of an ETH MEG which is capable of
initiating and terminating OAM frames for fault management and performance
monitoring. The OAM frames are distinct from the transit ETH flows. The OAM
frames are added to the aggregate of transit ETH flows and it is assumed
that they are subject to the same forwarding treatment as the transit ETH
flows being monitored. A MEP does not add a new forwarding identifier to the
transit ETH flows. A MEP does not terminate the transit ETH flows, though it
can observe these flows (e.g., count frames). 

5.4        MEG intermediate point (MIP)

MEG intermediate point (MIP) is an intermediate point in a MEG which is
capable of reacting to some OAM frames. A MIP does not initiate OAM frames.
A MIP takes no action on the transit ETH flows.

  _____  

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

Maarten,
IMHO and FWIW, OAM must follow what the data plane (which, in the case of
MPLS is label-based) does.
If MEG levels (and adjacencies) are not bound to data plane adjacencies,
what are these MEGs about?
 
Regards,
     Sasha

  _____  

Sasha,
 
See inline..

  _____  

Maarten,

 

 
Regards,
Maarten
 
Regards,
     Sasha

  _____  

Sasha,
 
previous one. 

- Etc.

- Etc.

 

  _____  

Maarten,

 
-----------------

 

 

 

 

 

 

1.	

Regards,

Maarten  

My 2c,

     Sasha

  _____  

Hi Greg,
 
See inline.. 
  _____  

Dear Maarten,

[maarten] Correct.

 

 

 

 

 

 
Regards,
Maarten 

Regards,
Greg

Hi Greg,

 
 
Regards,
Maarten

  _____  

Dear Maarten,

Regards,
Greg

Greg,

Regards,
Maarten

  _____  

Dear Editors and All,

Regards,
Greg

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 26 Jan 2010 17:31:59 +0200

Maarten,
You are saying (not for the first time) that the same OAM model equally applies to all data planes. I think that this is fundamentally incorrect: one size does not fit all.

Y.1731 inherited its definitions of MEGs and such with IEEE 802.1ag which dealt exclusively with the networks build by 802.1-compliant switches (a.k.a. "learning bridges") with their specific data plane.

The data plane of MPLS (and MPLS-TP) is very much different.

Regards,
     Sasha

Sent: Tuesday, January 26, 2010 5:23 PM

Sasha,

Below the definitions of a MEG and ME from Y.1731. It are the basic architecture components for OAM.
OAM frames exist within one MEG, and determine the status/performance of the MEG.
An MEG exists within the bounds of a transport entity.

In MPLS-TP a MEG is bound to a MS-PW and to a LSP.
In the example, the "Section layer transport path" is provided by an LSP, which is monitored by the top blue MEG.
The "Section layer transport path segment" between P-left and S-PE-left is provided by either an unlabeled or priority labelled LSP, which is monitored by the bottom blue MEG.
This "Section layer transport path segment" may be unmonitored (as illustrated in mplstp-connection-concepts-06w.pdf), and in this case there is no MEG and there is no LSP.

Regards,
Maarten

5.1        Maintenance entity (ME)
ME represents an entity that requires management and is a relationship between two maintenance entity group end points (see clause 5.3). MEs in Ethernet networks have been identified in Figure 23 of [ITU-T G.8010] (see Figure 5-1), Figure 24 of [ITU-T G.8010] and clause 9 of [ITU-T Y.1730]. MEs can nest but not overlap.
5.2        ME group (MEG)
ME group (MEG) includes different MEs that satisfy the following conditions:

*            MEs in a MEG exist in the same administrative boundary; and

*            MEs in a MEG have the same MEG level (see clause 5.6); and

*            MEs in a MEG belong to the same point-to-point ETH connection or multipoint ETH connectivity.
For a point-to-point ETH connection, a MEG contains a single ME. For a multipoint ETH connectivity containing n end-points, a MEG contains n*(n-1)/2 MEs.
5.3        MEG end point (MEP)
MEG end point (MEP) marks the end point of an ETH MEG which is capable of initiating and terminating OAM frames for fault management and performance monitoring. The OAM frames are distinct from the transit ETH flows. The OAM frames are added to the aggregate of transit ETH flows and it is assumed that they are subject to the same forwarding treatment as the transit ETH flows being monitored. A MEP does not add a new forwarding identifier to the transit ETH flows. A MEP does not terminate the transit ETH flows, though it can observe these flows (e.g., count frames).
5.4        MEG intermediate point (MIP)
MEG intermediate point (MIP) is an intermediate point in a MEG which is capable of reacting to some OAM frames. A MIP does not initiate OAM frames. A MIP takes no action on the transit ETH flows.

Maarten,

Regards,
     Sasha

Sasha,

See inline..

Maarten,

Regards,
Maarten

Regards,
     Sasha

Sasha,

- Etc.

- Etc.

Maarten,

-----------------

 1.

Regards,

Maarten

My 2c,

     Sasha

Hi Greg,

See inline..

Dear Maarten,

[maarten] Correct.

Regards,
Maarten

Regards,
Greg

Regards,
Maarten

Dear Maarten,

Regards,
Greg

Regards,
Maarten

Dear Editors and All,

Regards,
Greg

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 26 Jan 2010 18:14:55 +0100

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 [mailto:[email-masked]] 
Sent: dinsdag 26 januari 2010 16:32
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Maarten,
You are saying (not for the first time) that the same OAM model equally
applies to all data planes. I think that this is fundamentally incorrect:
one size does not fit all. 
 
Y.1731 inherited its definitions of MEGs and such with IEEE 802.1ag which
dealt exclusively with the networks build by 802.1-compliant switches
(a.k.a. "learning bridges") with their specific data plane.

Regards,
     Sasha

  _____  

Sasha,

 
Regards,
Maarten

5.2        ME group (MEG)

5.3        MEG end point (MEP)

  _____  

Maarten,
 
Regards,
     Sasha

  _____  

Sasha,
 
See inline..

  _____  

Maarten,

 

 
Regards,
Maarten
 
Regards,
     Sasha

  _____  

Sasha,
 
previous one. 

- Etc.

- Etc.

 

  _____  

Maarten,

 
-----------------

 

 

 

 

 

 

1.	

Regards,

Maarten  

My 2c,

     Sasha

  _____  

Hi Greg,
 
See inline.. 
  _____  

Dear Maarten,

[maarten] Correct.

 

 

 

 

 

 
Regards,
Maarten 

Regards,
Greg

Hi Greg,

 
 
Regards,
Maarten

  _____  

Dear Maarten,

Regards,
Greg

Greg,

Regards,
Maarten

  _____  

Dear Editors and All,

Regards,
Greg

---

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

Maarten and all,
I resend this message since the original one exceeded the moderators' limit (40K).

I've snipped the tail of the message thread.

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

Maarten,

Regards,
     Sasha

---

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

Maarten and all,
I resend this message since the original one has exceeded the moderators' limit (40K).
I've snipped the tail of the thread.

Regards,
     Sasha
Sent: Tuesday, January 26, 2010 4:48 PM

Maarten,

Regards,
     Sasha

Sasha,

See inline..

Maarten,

Regards,
Maarten

Regards,
     Sasha

---

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

Maarten and all,
I resend this message since the original one has exceeded the moderator's limit.
I've snipped the tail of the email thread.
Regards,
     Sasha
________________________________
From: Alexander Vainshtein
Sent: Tuesday, January 26, 2010 5:31 PM
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Maarten,

Regards,
     Sasha

Sasha,

Regards,
Maarten

---

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,

 

 
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

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 26 Jan 2010 13:03:39 -0800

Dear Maarten,
I think that your scenarios are based on the following assumption you're
making "The existing mpls switch ports will only be able to look at inner
labels of packets of which the outer label is terminated; *new mpls switch
ports will be able to look at inner labels of all packets* (my underline);
this is a similar evolution as we got in ethernet... " I don't think that is
the direction where MPLS-TP should go and will go.

Regards,
Greg

On Sat, Jan 23, 2010 at 8:02 AM, Maarten Vissers <[email-masked]

> draft specification for MPLS-TP.  These functional models describe a part
> of the required functional behaviour in a (packet) transport network of any
> technology.
>
>
>
> I doubt that such problem exist... so the MEPs and MIPs in my models are
> all addressable (and hence usable) in MPLS-TP...
>
>
>
> - The blue MIP in node S-PE-left has to process all packets generated by
> the higher blue MEP in node P of which the TTL expires; these packets arrive
> at node S-PE-left with two labels, of which the bottom of stack label is the
> *From:* Alexander Vainshtein [mailto:[email-masked]]
> *Sent:* zaterdag 23 januari 2010 8:57
> *To:* Maarten Vissers
> *Cc:* [email-masked]; [email-masked]; 'Greg Mirsky'
> *Subject:* RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section
>
>  Maarten,
>  [maarten] What I mean is that it is possible to set up an e.g. 9-port
> mp2mp LSP connection in the MPLS technology and order an mpls switch to read
> the inner (PW) label and use the value of this inner label to forward the
> packet to one of the 9 output ports of the mp2mp LSP... It should be clear
> that a switch with such capability has a feature which is not described in
> the MPLS RFCs; i.e. it is a proprietary extension which I am describing
> below to illustrate that such extension does not interfere with the
> standardized MPLS behaviour, and that it does not change that behaviour.
>
> -----------------
> The ethernet switch also looks at the inner TYPE (i.e. TPID) in all cases
> on the interface port to identify if the frame is an OAM frame and then look
> at the MEL field and OpCode fields to identify the type of OAM frame and its
> [maarten] I don't see as such any functional difference between the mpls
> and ethernet data planes; the same information elements are present in both
> data planes, but with a different encoding of this information in the
> [maarten] The well-known MAC multicast destination addresses listed in
> Table 8-1/802.1Q are identifying management plane and control plane
> protocols that are carried over the links; those frames are not belonging to
> the user traffic carried in the VLANs. In MPLS-TP similar management and
> control plane information is carried via the MCC and SCC packets specified
> in RFC5718.
>
> [maarten] MPLS-TP will use the LABEL field to separate LSP-OAM from
> non-LSP OAM packets, the label stack to identify the MEG level and the ACH
> channel type field to identify the type of OAM.
> All Ethernet protocols operate in this way, 802.1ag is not an exception.
> And this is exactly what allows separation between addressing and
> MEP/MIP levels in 802.1ag.
>
> [maarten] There is one type of OAM that has to fate share with more then
> the VLAN/PW/LSP; i.e. the frame/packet loss OAM has to fate share with both
> the VLAN/PW/LSP and the frames/packets for which the ingress count
> is transported in this OAM frame/packet. In p2p/p2mp VLANs/PWs/LSPs there is
> no problem to meet this requirement. In rmp/mp2mp VLANs and mp2p PWs/LSPs
> there is a problem to meet the second requirement. I.e. no difference as
> such between Ethernet and MPLS.
>
>    1. GAL. This mechanism can only be used to address MEPs, because the
>    to the loopback interface").  [maarten] The ethernet equivalent to the
>    GAL is the OAM ethertype value 89-02.
>    2. TTL expiration. This is the only mechanism for addressing MIPs in
>  *From:* [email-masked] [[email-masked]] On Behalf Of
> *Sent:* Saturday, January 23, 2010 7:37 AM
> *To:* 'Greg Mirsky'
> *Sent:* vrijdag 22 januari 2010 20:29
> *To:* Maarten Vissers
> I'll concentrate, as you suggested, on the slide #7 and the following
> you've wrote "The intermediate nodes contain multiple MPLS-TP (MTP) layer
> network instances". I think that from the definition of MPLS Section
> follows that there can not be an intermediate MPLS node on a given MPLS
> Section which is aware of that Section.
>
> [maarten] I understand why we were coming to different conclusions. I hope
> I have clarified my view with the SDH physical media layer example.
>
> [maarten] You may now also understand why the definition of Section layer
> in G.805 defines that the section layer network is concerned with all
> functions which"**provide for the transfer of infomation between locations
> in path layer networks**.
> SB10 comment "Yes. S=1 does not indicate the boundary between the client
> and server. It indicates the boundary between the label stack and the label
>>> I'm puzzled by what looks to me as contradiction between quoted in the
>>> RFC 5586 definition of the Section Layer Network and the last paragraph on
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
>

---

From: <[email-masked]>
Date: Wed, 27 Jan 2010 10:57:00 -0000

Some care is going to need to be exercised here...why?  Well, I was on
the MPLS-TP audio-conf call yesterday that considered 2 issues (both
that I have raised previously):
-    what does the term 'network layer' mean?
-    why should MS PWs exist in MPLS-TP?
 
Wrt to the latter item the technical issue here is that PWs are an
artefact of the architectural conditions imposed by the LDP form of
MPLS, and since LDP is not used in MPLS-TP then PWs are not technically
required in MPLS-TP.  Furthermore, we should not create a new (PW) co-ps
mode layer network above MPLS-TP (which is what MS PWs represent) just
because we can.  A very closely related issue is the difference between
(i) true client/server LSP layering and (ii) nested LSP sublayering that
we find in MPLS today and identified from the setting of the S bit (note
that the former demands different routing instances per client and
server whilst the latter assumes the same instance of routing across the
sublayers)
 
What became clear from the ensuing discussion is (this is only a subset
of conclusions reached):
-    the above is technically accurate, ie if we were designing MPLS-TP
without the history there would be no need to create PWs
-    MS PWs are optional
-    (and the key point wrt this thread) MPLS-TP will allow both (i)
nested LSPs as we find in MPLS today (sublayering, same layer network)
and (ii) true client/server LSPs (true layering, different layer
networks) to exist....the choice is down to the network operator...and
*maybe both these cases can appear in the same stack of nested headers*
(?)
 
I am not quite sure how one can distinguish cases (i) and (ii) from just
looking at DP headers, but the key point I wanted to make here is that
in case (ii) there must be no snooping of the client layer network as
transparency and client/server layer network functional decoupling are
essential (this observation applies to all client/server cases).  Note
carefully that in MPLS as-is one cannot tell the implied semantic of a
label just from looking at the DP header, one has to know the context of
the label (ie essentially which 'signalling' protocol issued it) to know
this.  Note also that TCM is a form of sublayering and one can justify
snooping here *iff* one is sure of the semantic of the higher level
header (especially the label). 
 
I think there could be some quite interesting problems in a multi-party
networking scenario due to this sublayering/layering flexibility.  My
personal view is that a transport network does not require sublayering.
 
regards, Neil

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Greg Mirsky
Sent: 26 January 2010 21:04
To: Maarten Vissers
Cc: [email-masked]; Alexander Vainshtein; [email-masked]
Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS
Section

	Dear Maarten,
	I think that your scenarios are based on the following
assumption you're making "The existing mpls switch ports will only be
able to look at inner labels of packets of which the outer label is
terminated; new mpls switch ports will be able to look at inner labels
of all packets (my underline); this is a similar evolution as we got in
ethernet... " I don't think that is the direction where MPLS-TP should
go and will go.
	
	Regards,
	Greg

	On Sat, Jan 23, 2010 at 8:02 AM, Maarten Vissers
<[email-masked]> wrote:

		Sasha,

		> Hence I think that some of the MEPs you've defined are
non-addressable (and hence unusable) in MPLS-TP which shares the MPLS
data plane. 

		If what you state is correct there is a serious problem
within the existing draft specification for MPLS-TP.  These functional
models describe a part of the required functional behaviour in a
(packet) transport network of any technology.

		I doubt that such problem exist... so the MEPs and MIPs
in my models are all addressable (and hence usable) in MPLS-TP...

		Let's analyse the left inter domain interface between
carrier A's P node and B's left S-PE node as an exercise...

		1) there is a MPLS-TP Section layer transport path (VSC)
between carrier A nodes P-left and P-right

		2) there is a MPLS-TP Section layer transport path
segment (VSC Segment) between nodes P-left and S-PE-left

		3) there is a MPLS-TP transport service layer transport
path (VCC) between nodes S-PE-left and S-PE-right (yellow MEPs).

		- The MPLS-TP LSP OAM inserted by the lower blue MEP in
node P-left has as top and bottom of stack the GAL. 

		- The MPLS-TP LSP OAM inserted by the higher blue MEP in
node P-left has as top of stack the label inserted by the lower blue MEP
(identified as LSE) and as bottom of stack the GAL. 

		- The lower blue MEP in node S-PE-left has to process
all packets with top of stack the GAL. 

		- The blue MIP in node S-PE-left has to process all
packets generated by the higher blue MEP in node P of which the TTL
expires; these packets arrive at node S-PE-left with two labels, of
which the bottom of stack label is the GAL and the top of stack label is
a regular LSP label. 

		- The interface port in the S-PE-left port will swap the
top of stack label of non-OAM and TTL not-expired packets; the new label
value will be the value inserted by the left yellow MEP in the S-PE-left
node (indicated by LSE next to the yellow MEP symbol). 

		- If the packet was a VSC OAM packet of which the TTL
expires, the packet will be extracted by the blue MIP within the VSC.

		- The yellow MEP inserts the LSP OAM into the carrier
A's VSC, creating a monitored VSC Segment, and treats this VSC Segment
as one of its VCCs. This VCC related LSP OAM will pass through a VCC MIP
on the egress NNI port in the S-PE-left node (i.e. egress MIP issue
applies). 

		- The VCC signal is multiplexed into an MPLS-TP
transport path layer transport path (VPC) and its packets are prepended
with a new LSP label identifying the VCC. 

		- Etc.

		- In the reverse direction, the VPC terminates on the
right NNI port of the S-PE-left node, providing access the VCC LSPs
carried in the VPC. If the TTL of a VCC LSP OAM expires the VCC LSP MIP
function will process the OAM. All other VCC LSP related packets are
forwarded to the egress port which is connected to carrier A's P node. 

		- The VCC LSP terminates on the egress port, and the LSP
label identifying this VCC LSP is terminated; the yellow VCC LSP MEP on
the egress port can now determine which packets carry the VCC LSP OAM by
checking for the GAL as next top label.

		- The VCC LSP label is also removed from the non-VCC LSP
OAM packets and it is possible that on one of those packets the TTL
expires. Such packets are processed by the blue MIP function above the
yellow MEP function in the S-PE-left node.

		- The outer label on packets of which the TTL has not
expired will be swapped, and LSP OAM will be added in the lower blue
section layer MEP on the S-PE-left node. This OAM will be output with
GAL as top and bottom of stack label.

		- Etc.

		I can't find a problem in the above required behaviour,
besides the well known egress-MIP identification problem. 

		There is always an outer LSP label being terminated when
a MEP function is following and LSP OAM has to be extracted and
processed.

		In some cases the LSP terminates on an ingress port
(DOWN MEP), in other cases the LSP terminates on an egress port (UP
MEP).

		From: Alexander Vainshtein
[mailto:[email-masked]] 
		Sent: zaterdag 23 januari 2010 8:57
		To: Maarten Vissers
		Cc: [email-masked]; [email-masked]; 'Greg Mirsky'
		Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on
MPLS Section

		Maarten,
		I may be missing something important, but how iy seems
that you ignore the fundamental differences between Ethernet and MPLS
data planes in your analysis. 
		 
		[maarten] I am absolutely not ignoring the differences
between Ethernet and MPLS data planes, as I am also not ignoring the
commonalities. 

		[maarten] What I mean is that it is possible to set up
an e.g. 9-port mp2mp LSP connection in the MPLS technology and order an
mpls switch to read the inner (PW) label and use the value of this inner
label to forward the packet to one of the 9 output ports of the mp2mp
LSP... It should be clear that a switch with such capability has a
feature which is not described in the MPLS RFCs; i.e. it is a
proprietary extension which I am describing below to illustrate that
such extension does not interfere with the standardized MPLS behaviour,
and that it does not change that behaviour. 
		 
		-----------------
		[maarten] It is very simple to test the forwarding of
packets in such mp2mp LSP in a research lab :-)...; inner label values
1000-1999 were delivered at output port 1, inner label values 2000-2999
were delivered at output 2, inner label values 3000-3999 were delivered
at output port 3, etc. The mpls switch reads the outer label value to
identify the LSP, then reads the inner label value and forwards all
packets with inner label value 1xxx to output port 1, with inner label
value 2xxx to output port 2, etc.
		 
		[maarten] Another nice test application for such LSP is
in a physical ring; e.g. with 8 nodes. In this case you can identify the
destination ring node in the 3 most significant bits of the PW label and
the output trib card on a ring node by the next 7 bits and the
individual PW instances by the 10 least significant bits. Number the
ring nodes from 0 to 7. Now ring node 0 will forward the packets with
inner label values 001/010/011xxxxxxxxxxxxxxxxx via its east line port
and packets with inner label values 100/101/110/111xxxxxxxxxxxxxxxxx via
its west line port. If the ring breaks between nodes 5 and 6, then ring
node 0 will change the forwarding of packets with inner label values
100/101xxxxxxxxxxxxxxxxx from the west line port to the east line port.
Node 0 is informed about the break between nodes 6 and 7 by means of a
ring-APS message including the number of the node and the interface
(east/west) detecting the fault. Ring node 0 will always extract packets
with inner label values 000xxxxxxxxxxxxxxxxxxx to prevent that packets
get looped in the mp2mp Ring-LSP and forward packets with other label
values on the east line port to the west line port (and vice versa).
		 
		[maarten] to support the transport of p2mp PWs through
such mp2mp LSP another set of PW label values was allocated, e.g.
10000-10999. The mpls switch reads the outer label value to identify the
LSP, then reads the inner label value and in case of a value in the
10xxx range looks up in a table the subset of output ports to which this
packet has to be sent.
		 
		[maarten] The same mpls switch also supports p2p LSPs
and when the outer label value is associated with such p2p LSP it will
ignore the inner label value and forward the packet to the output port.
		 
		[maarten] The same mpls switch also supports p2mp LSPs
and when the out label value is associated with such p2mp LSP the switch
will ignore the inner label value and looks up in a table the set of
output ports of this p2mp LSP and forwards the packet to all output
ports.
		 
		[maarten] The same mpls switch also looks at the inner
label on the interface port to identify if the packet is an OAM packet
and then look at the ACH channel type to identify the type of OAM packet
to see if the packet must be processed in the interface port (and not
forwarded to the switch fabric). The existing mpls switch ports will
only be able to look at inner labels of packets of which the outer label
is terminated; new mpls switch ports will be able to look at inner
labels of all packets; this is a similar evolution as we got in
ethernet... existing ethernet switches could only look at the TYPE and
DA fields to identify if an OAM frame had to be processed (those
switches could only support a subset of the Y.1731 OAM), new ethernet
switches are looking at the TYPE and MEL fields and can support the full
set of Y.1731 OAM.
		 
		[maarten] I hope you understand now that it is possible
to extend the MPLS data plane specified in the RFCs with a
'connectionless-LSP' capability. Such extended mpls dataplane will then
contain a mix of connection oriented-LSPs and connectionless-LSPs. The
behaviour of the connection-oriented-LSPs complies with the
specifications in the RFCs. The connectionless-LSPs are a bonus.
		---------------------
		 
		[maarten] An ethernet switch reads the outer vlan
identifier and when the outer vlan identifier is associated with a 
		- p2p VLAN it will ignore the DA value and forward the
frame to the output port
		- p2mp VLAN it will ignore the DA value and looks up in
a table the set of output ports of this p2mp VLAN and forwards the frame
to all those output ports
		- mp2mp or rmp VLAN it will read the DA and looks up in
a table the output port or ports of this mp2mp VLAN to which this frame
should be forwarded.
		The ethernet switch also looks at the inner TYPE (i.e.
TPID) in all cases on the interface port to identify if the frame is an
OAM frame and then look at the MEL field and OpCode fields to identify
the type of OAM frame and its MEG level to see if the packet must be
processed in the interface port (and not forwarded to the switch
fabric).
		 
		[maarten] I don't see as such any functional difference
between the mpls and ethernet data planes; the same information elements
are present in both data planes, but with a different encoding of this
information in the frame/packet... the main difference is that standard
mpls switches don't use the inner label value to control forwarding of a
packet to a subset of output ports of an LSP, while ethernet switches
typically support both the use of the DA value to control forwarding and
the don't use of the DA value to control forwarding to a subset of VLAN
output ports... but note that there is also a set of ethernet switches
that only support don't use of the DA value to control forwarding, i.e.
which support only p2p and p2mp VLANs.
		 
		Ethernet data plane inherently recognizes "well-know
multicast MAC destination addresses". If a switch wants so, it can catch
all the frames with such a DA and decide how it treats them
"out-of-band".  

		[maarten] The well-known MAC multicast destination
addresses listed in Table 8-1/802.1Q are identifying management plane
and control plane protocols that are carried over the links; those
frames are not belonging to the user traffic carried in the VLANs. In
MPLS-TP similar management and control plane information is carried via
the MCC and SCC packets specified in RFC5718.
		 
		[maarten] If you read G.8021 then you will notice that
the well-know multicast MAC destination addresses for OAM are not being
recognized in the ETH atomic functions processing Ethernet OAM.  
		Note that G.8021 has never used the DA field in the
Ethernet OAM frame as a means to identify OAM from non-OAM frames, as
Y.1731 has from day one specified OAM frames that carry a unicast
address which do not contain these well-known OAM multicase destination
addresses. 
		Y.1731/G.8021 use the TYPE field to separate OAM from
non-OAM frames, the MEL field to identify the MEG level and the OpCode
field to identify the type of OAM. 
		 
		[maarten] MPLS-TP will use the LABEL field to separate
LSP-OAM from non-LSP OAM packets, the label stack to identify the MEG
level and the ACH channel type field to identify the type of OAM. 
		I.e. the same information, just a different encoding.
		 
		All Ethernet protocols operate in this way, 802.1ag is
not an exception. And this is exactly what allows separation between
addressing and MEP/MIP levels in 802.1ag.  
		 
		[maarten] As indicated above, your understanding of
Ethernet OAM protocol processing does not align with Y.1731/G.8021
specifications.
		 
		[maarten] The unicast LBM OAM is a special OAM
frame/packet as it requires one additional information element; i.e. a
MIP identifier. This MIP identifier must be carried in the LBM OAM
frame/packet in both Ethernet and in bidirectional p2mp MPLS-TP LSP
cases; in MPLS-TP to differentiate MIPs in a bidirectional p2mp LSP
located at the same hop count from the MEP. Because the bidir p2mp LSP
was only recently described in this mailinglist the implications of such
LSP on the loopback OAM have not yet been investigated and documented.
		 
		[maarten] Both in Ethernet and MPLS OAM the OAM process
must read this MIP identifier field when the OAM frame/packet is
identified as a LBM OAM. The MIP identifier in Ethernet OAM is the
EUI-48 of the physical subsystem on which the MIP resides, while in
MPLS-TP OAM this is not yet in scope of the OAM framework. But if there
is a real demand for such bidir p2mp LSP or PW, we should include the
MIP Identifier in the OAM framework document for loopback OAM.
		 
		The disadvantage of this approach is that Ethernet OAM
frames are not necessarily fate-sharing with the data traffic. 
		 
		[maarten]  All Ethernet OAM frames fate share with the
VLAN (i.e. the Ethernet transport entity) in a similar manner as all
MPLS-TP OAM packets will fate share with the PW and LSP (i.e. the MPLS
transport entities).
		 
		[maarten] There is one type of OAM that has to fate
share with more then the VLAN/PW/LSP; i.e. the frame/packet loss OAM has
to fate share with both the VLAN/PW/LSP and the frames/packets for which
the ingress count is transported in this OAM frame/packet. In p2p/p2mp
VLANs/PWs/LSPs there is no problem to meet this requirement. In
rmp/mp2mp VLANs and mp2p PWs/LSPs there is a problem to meet the second
requirement. I.e. no difference as such between Ethernet and MPLS.
		 
		The MPLS data plane is defined in RFC 3031, 30302 and
(for upstream-allocated labels) in RFC 5331, 5332. Its analog of
Ethernet well-know multicast MAC destination addresses is the reserved
Router Alert Label. But its usage  has been rejected for usage in
MPLS-TP OAM exactly because fate-sharing of data and OAM packets could
be broken. Instead, MPLS-TP uses two different mechanisms: 

		1.	
			GAL. This mechanism can only be used to address
MEPs, because the LER processing a packet with the GAL at some level in
the label stack is not allowed to look at it unless it terminates all
the labels above it are terminated (i.e., its ILM entries for these
labels must be "pop and forward to the loopback interface").  [maarten]
The ethernet equivalent to the GAL is the OAM ethertype value 89-02. 
		2.	
			TTL expiration. This is the only mechanism for
addressing MIPs in MPLS-TP. And, of course, TTL expiration must occur in
the first label stack entry following all the labels terminated by the
supporting node.  [maarten] As described above, as soon as MPLS-TP has
to support bidir p2mp LSPs/PWs it will have to include the MIP
Identifier to address the MIP that has to perform the loopback.

		[maarten] Ethernet OAM Y.1731 specifies an Ethernet MCC
OAM frame to carry management plane frames. This is similar to the
MPLS-TP MCC OAM packet defined in RFC5718.

		Regards,

		Maarten  

		In short, LERs do not look at the next label if they do
not terminate the previous one. 

		Hence I think that some of the MEPs you've defined are
non-addressable (and hence unusable) in MPLS-TP which shares the MPLS
data plane. 

		My 2c,

		     Sasha

		From: [email-masked]
[[email-masked]] On Behalf Of Maarten Vissers
[[email-masked]]
		Sent: Saturday, January 23, 2010 7:37 AM
		To: 'Greg Mirsky'
		Cc: [email-masked]; [email-masked]
		Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on
MPLS Section

		Hi Greg,
		 
		See inline.. 

		Dear Maarten,
		I'll concentrate, as you suggested, on the slide #7 and
the following you've wrote "The intermediate nodes contain multiple
MPLS-TP (MTP) layer network instances". I think that from the definition
of MPLS Section follows that there can not be an intermediate MPLS node
on a given MPLS Section which is aware of that Section.  
		 
		In your example (slide #7) nodes P and P' (to
differentiate them from left to right) of Carrier A are terminating
points of MPLS Section of Carrier A.  
		 
		[maarten] Correct.

		[maarten] not correct. The figure shows two MPLS-TP
Section layer MEG levels; the top level MEG has its endpoints (blue MEP
functions) in the carrier A P and P' nodes, the bottom level MEG has its
end points in the interface ports of P and left S-PE and in right S-PE
and P' nodes.
		 
		[maarten] The most left and right S-PEs of carrier B
terminate the physical media layer (the 802.3 ETY layer) and then the
MPLS-TP Section TCM/Segment OAM in the blue colored MEP function. On top
of this MEP function there is a (blue) MPLS-TP Section layer MIP
function, which will process the MPLS-TP Section layer OAM from the top
MEG level.
		 
		[maarten] I have attached a slightly modified version of
the slide 7. The modification is the replacement of the 802.3 interface
between carrier A's P node and the left S-PE node of carrier B by an SDH
STM-N interface. Such SDH interface has excellent section monitoring
capabilities and it is now not necessary to instantiate the MPLS-TP
Section layer TCM/Segment MEG level between these P and left S-PE nodes.
This is reflected by the absence of the lower blue Section MEP
functions.
		 
		[maarten] On the side of the adaptation functions
between MPLS-TP Section layer and SDH layers (blue/grey colored
trapezoid symbols) I have indicated "P-LSE" to represent that it may be
necessary to insert a kind of "priority label stack entry header" (in
analogy to the priority vlan tag in ethernet). The use of such "P-LSE"
header on the MPLS-TP over SDH interface would be required when carrier
A wants to have explicit control over the priority and drop eligibility
of each of the MPLS-TP packets passed through the carrier B network;
i.e. including the MPLS-TP Section OAM packets. If all Section OAM
packets have the same priority/drop eligibility, then insertion of such
P-LSE header is not necessary as carrier B's S-PE node can assign the
right priority/drop eligible level to the the unlabelled (section OAM)
packets.
		 
		[maarten] For the latter case, the MPLS-TP Section layer
signal will have its section OAM equipped with GAL as BOS. For the
former case, the MPLS-TP Section layer signal will have its section OAM
equipped with 'P-LSP'  label as BOS and GAL as second label.
		 
		[maarten] Assume the latter case, then the blue MIP
function in the left S-PE node will process the GAL as BOS.
		 
		Thus, when Node P sends OAM with GAL as BOS to monitor
the P-P' Section, none of nodes of Carrier B, including S-PEs, should
bother to process the GAL. Doing otherwise will break client-server
layering.  
		 
		[maarten] I understand why we were coming to different
conclusions. I hope I have clarified my view with the SDH physical media
layer example.
		 
		[maarten] You may now also understand why the definition
of Section layer in G.805 defines that the section layer network is
concerned with all functions which"**provide for the transfer of
infomation between locations in path layer networks**. 
		It is this latter item that allows section layer trails
to span multiple physical media layer trails, and thus to have
intermediate nodes in the section layer connection.
		 
		[maarten] But in all honesty, most of the Section layer
connections are terminating at the same ports as their underlying
physical media layer connections. Someone who looks only at the
appearances of section layers inside one network will conclude that
section layer connections terminate at adjacent nodes. Someone who looks
beyond its own network will conclude that section layer connections
terminate in nodes that provide access to path layer signals.
		 
		That is why I can not agree that an intermediate node
contains instances of multiple MPLS-TP networks. I think of a node as
performing its functions at certain MPLS-TP network layer only.  
		 
		[maarten] It is my understanding that we are missing a
description which explicitly describes the mapping of labels onto
layers. One MPLS-TP layer network will in my understanding contain one
or more labels. As the ppt file with my investigation results is too
large to attach, I will email you a copy privately. I have attached a
summary of the results up to this point in time.
		 
		Another question is whether Carrier B sets its VC label
as BOS or not, as I understand we haven't decided yet with number of BOS
in carrier's carrier scenario. But that, to me, is separate discussion. 
		 
		[maarten] I have understood that that decision has been
made. Refer to the SB10 comment "Yes. S=1 does not indicate the boundary
between the client and server. It indicates the boundary between the
label stack and the label stack payload." in the
draft-ietf-mpls-tp-framework-07-post-review-of
ITU-T-informal-cts-19-Jan-2010.doc. This is now inlcuded in
draft-ietf-mpls-tp-framework-08, see section 3.4.1.
		
		Maarten, I greatly appreciate your input and our
discussion. 

		Regards,
		Maarten 
		
		Regards,
		Greg

			Hi Greg,
			 
			The intermediate nodes contain multiple MPLS-TP
(MTP) layer network instances, of which the top MTP layer is shared by
carrier A and B. See slide 7 in the mplstp-connection-concepts file.
Note that the same applies for the case of Ethernet (ETH) layer
networks. In the attached ethernet-connection-concepts file you find the
same case illustrated also on slide 7.
			 
			Other slides illustrate other cases of
carrier-carrier and customer-carrier interactions.
			 
			Note that the functional models for the MPLS-TP
and Ethernet cases are the same; I already had the Ethernet models and
have converted those into MPLS-TP equivalent models to illustrate this
section layer question. The difference between both technologies is the
encoding of MEG levels; in Ethernet via the MEG Level (MEL) field, in
MPLS-TP via a Label Stack Entry (LSE) header.
			 
			Regards,
			Maarten

			

			Dear Maarten,
			so this is carrier's carrier scenario when
MPLS-TP section is client of MPLS-TP transport? But wouldn't presumed
processing of client MPLS-TP section by intermediate nodes of server
MPLS-TP layer be just plain violation of server-client model?
			
			Regards,
			Greg

				Greg,
				 
				It is not uncommon to carry a section
layer signal as a service through the network of another carrier. E.g.
Ethernet port based services carry the Ethernet section layer signals as
a service through the transport network. The compatible MPLS type of
port based service would carry the MPLS section layer signal as a
service through the network of another carrier. The section will now
pass through intermediate nodes.
				 
				Regards,
				Maarten

				From: [email-masked]
[mailto:[email-masked]] On Behalf Of Greg Mirsky
				Sent: donderdag 21 januari 2010 22:21
				To: BOCCI Matthew;
[email-masked]; [email-masked]
				Cc: [email-masked]; [email-masked]
				Subject: [mpls-tp] RFC 5586:
Intermediate nodes on MPLS Section

				Dear Editors and All,
				I'm puzzled by what looks to me as
contradiction between quoted in the RFC 5586 definition of the Section
Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS
Section. The definition (section 1.3 p.4) refers to section as server
layer that provides service between adjacent nodes (my underlining). At
the same time, the last paragraph of subsection 4.2.1.2 stipulates
behavior of intermediate nodes on an MPLS Section in regard to G-ACh
message, the ACH and the GAL. If an MPLS Section is between adjacent
nodes, then, as I understand the definition, there can not be
intermediate nodes on the section (on the segment, but not on a section)
at this particular layer.
				Your clarification is greatly
appreciated.
				
				Regards,
				Greg