Subject: [mpls] 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: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:

>  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
>
> 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: 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..
Sent: vrijdag 22 januari 2010 20:29

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.

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

Regards,
Maarten

Dear Maarten,

Regards,
Greg

Regards,
Maarten

Dear Editors and All,

Regards,
Greg

---

From: John E Drake <[email-masked]>
Date: Sat, 23 Jan 2010 09:47:23 -0800

That sounds right.  A 'section' is what would normally be called a 'link', but for some reason that term wasn't considered sufficient.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexander Vainshtein
> Sent: Friday, January 22, 2010 12:57 PM
> To: Greg Mirsky; Maarten Vissers
> 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
> 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.
> On Fri, Jan 22, 2010 at 10:32 AM, Maarten Vissers
> <[email-masked]> wrote:
> 
> 
> 	Hi Greg,
> 
> 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.
> 
> 	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
> 	Cc: [email-masked]; [email-masked] <mailto:[email-masked]>
> 
> 	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
> 	On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vissers
> <[email-masked]> wrote:
> 
> 
> 		Greg,
> 
> 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:mpls-tp-
> [email-masked]>  [mailto:[email-masked]] On Behalf Of Greg
> Mirsky
> 		Cc: [email-masked]; [email-masked] <mailto:[email-masked]>
> (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.

---

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,
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

---

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]

>  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
>
>
>
> 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'
> *Sent:* vrijdag 22 januari 2010 20:29
> *To:* Maarten Vissers
> 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.
>
> 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.
>
>>> 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
>
>