Subject: [mpls-tp] MPLS-TP Protocol Type definition => is the GAL Header required in LSP OAM packets?

From: Maarten Vissers <[email-masked]>
Date: Thu, 29 Jan 2009 15:33:55 +0100

I have created a couple of slides to understand the MPLS-TP Protocol Type
definition and values. Refer to
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/mpls-tp-protocol-typ
es-00.ppt

MPLS-TP's protocol type information is carried inside a set of fields (e.g.
S, 4-bit nibble, channel type, ...). It is possible to define in MPLS-TP
standards MPLS-TP PW and LSP specific Protocol Type values as combinations
of specific values in those fields. Some examples are presented in slides
8,9 and 11.

Looking at slides 10 and 11 (with MPLS-TP LSP Protocol Type definition), the
question pops up what the added value of the GAL Header is in LSP OAM
packets. It seems that the GAL Header in LSP OAM packets is unnecessary from
a protocol definition perspective. The G-AC Header (G-ACH) seems to contain
sufficient typing information, which makes the GAL Header unnecessary in
normal LSP OAM packets. The GAL Header would only be required in Section LSP
OAM packets when those are carried directly over a physical medium.

Removal of the GAL Header from LSP OAM packets will unite the PW and LSP OAM
packet formats into a signle MPLS-TP OAM packet format, removing the
artificial difference between both types of OAM packets in today's
proposals.

What was the rationale to include such GAL Header in the LSP OAM packet
format?
- A NNI port on a Provider (P) node not able to process MPLS-TP LSP OAM will
have to pass through any such OAM packets.
- A NNI port on a Provider Edge (PE) node not able to process MPLS-TP LSP
OAM will have to discard any such OAM packets.

The NNI port on a PE node not able to process MPLS-TP LSP OAM may receive
LSP packets of which the S-bit in the LSP label stack entry header has
values 0 or 1. 
A) S=0 implies that there is another LSE header in the packet and further
processing is to be determined on the basis of the next LSE header's
content.
B) S=1 implies that this is the bottom LSE header in the packet and further
processing information has to be derived from the bits following this bottom
of stack LSE header; e.g. the 4-bits nibble following the TTL field
indicates if the packet is an IPv4 or IPv6 packet.

Under normal conditions, this NNI port will not receive any MPLS-TP LSP OAM
packets when this port is not capable to process such MPLS-TP LSP OAM
packets. However under fault conditions (i.e. misconnection), it is possble
that a NNI port generating MPLS-TP LSP OAM packets is connected with an NNI
port which is not able to support such OAM packets. For the case the G-ACH
follows the LSP label stack entry header immediately (without intermediate
GAL header), the NNI port on the PE node will receive LSP packets with S=1
and 4-bit nibble=0001. This port will not know what to do with it, and
should as such discard those LSP OAM packets as unknown and unexpected
packets. I.e. what else could be done with those packets that do not have a
next LSE header and are not IPv4/v6?

Looking forward to understand the rationale for the GAL header in LSP OAM
packets... If there is no real rationale for it, I propose to remove this
GAL Header from those LSP OAM packets.

Regards,
Maarten

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

---

From: <[email-masked]>
Date: Thu, 29 Jan 2009 14:59:50 -0000

Maarten

Quick answer to your question from my perspective.....others may have
different reasons/views here.

I came to exactly the same conclusion some time ago, ie in principle we
do not need the GAL for OAM.  But what we do need the GAL for is to
indicate the OOB CP/MP server layer 1-hop channel between logically
adjacent MPLS-TP nodes.

But we can use the GAL for OAM indicate too (a "belt+braces" means of
ID).  It is not ideal because OAM now does not look like traffic units,
and it should do, ie traffic has 1 normal forwarding header (S=1), OAM
has 2 headers of GAL (S=1) and normal forwarding header (S=0).  You may
recall when I wrote Y.1711 way back I hated the idea of a special label
14 for 'OAM indicate' for exactly the reason noted above.  But then I
could not get access to any of the other bits in the header, eg TTL
field.....the OAM indicate flag should really be part of the normal
forwarding header.  

Now in MPLS-TP we do not need the TTL field for loop mitigation (no co
mode network needs a TTL) but I understand we cannot touch this.  So I
am happy to accept the compromise of using the GAL here.  And a key
reason I say this is because in MPLS-TP we have no need to worry about
the 1 nibble payload nonsense of ECMP as this cannot be allowed in
MPLS-TP.  In other words, whilst we can look at the 1st nibble for 0001
(G-ACH) we do not have to....and this also removes restrictions on what
can follow the GAL in future.  But as I said above, the key value of the
GAL IMO is to provide the OOB CP/MP indication.

regards, Neil

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: 29 January 2009 14:34
> To: [email-masked]
> Subject: [mpls-tp] MPLS-TP Protocol Type definition => is the 
> GAL Header required in LSP OAM packets?
> 
> I have created a couple of slides to understand the MPLS-TP 
> Protocol Type definition and values. Refer to 
> S, 4-bit nibble, channel type, ...). It is possible to define 
> in MPLS-TP standards MPLS-TP PW and LSP specific Protocol 
> Type values as combinations of specific values in those 
> fields. Some examples are presented in slides
> 8,9 and 11.
> 
> Looking at slides 10 and 11 (with MPLS-TP LSP Protocol Type 
> definition), the question pops up what the added value of the 
> GAL Header is in LSP OAM packets. It seems that the GAL 
> Header in LSP OAM packets is unnecessary from a protocol 
> definition perspective. The G-AC Header (G-ACH) seems to 
> contain sufficient typing information, which makes the GAL 
> Header unnecessary in normal LSP OAM packets. The GAL Header 
> would only be required in Section LSP OAM packets when those 
> are carried directly over a physical medium.
> 
> Removal of the GAL Header from LSP OAM packets will unite the 
> PW and LSP OAM packet formats into a signle MPLS-TP OAM 
> packet format, removing the artificial difference between 
> both types of OAM packets in today's proposals.
> 
> What was the rationale to include such GAL Header in the LSP 
> OAM packet format?
> - A NNI port on a Provider (P) node not able to process 
> MPLS-TP LSP OAM will have to pass through any such OAM packets.
> - A NNI port on a Provider Edge (PE) node not able to process 
> MPLS-TP LSP OAM will have to discard any such OAM packets.
> 
> The NNI port on a PE node not able to process MPLS-TP LSP OAM 
> may receive LSP packets of which the S-bit in the LSP label 
> stack entry header has values 0 or 1. 
> A) S=0 implies that there is another LSE header in the packet 
> and further processing is to be determined on the basis of 
> the next LSE header's content.
> B) S=1 implies that this is the bottom LSE header in the 
> packet and further processing information has to be derived 
> from the bits following this bottom of stack LSE header; e.g. 
> the 4-bits nibble following the TTL field indicates if the 
> packet is an IPv4 or IPv6 packet.
> 
> Under normal conditions, this NNI port will not receive any 
> MPLS-TP LSP OAM packets when this port is not capable to 
> process such MPLS-TP LSP OAM packets. However under fault 
> conditions (i.e. misconnection), it is possble that a NNI 
> port generating MPLS-TP LSP OAM packets is connected with an 
> NNI port which is not able to support such OAM packets. For 
> the case the G-ACH follows the LSP label stack entry header 
> immediately (without intermediate GAL header), the NNI port 
> on the PE node will receive LSP packets with S=1 and 4-bit 
> nibble=0001. This port will not know what to do with it, and 
> should as such discard those LSP OAM packets as unknown and 
> unexpected packets. I.e. what else could be done with those 
> packets that do not have a next LSE header and are not IPv4/v6?
> 
> Looking forward to understand the rationale for the GAL 
> header in LSP OAM packets... If there is no real rationale 
> for it, I propose to remove this GAL Header from those LSP 
> OAM packets.
> 
> Regards,
> Maarten
> 
>

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 29 Jan 2009 16:33:32 +0100

Neil,

I do not understand why the GAL header is necessary for OOB CP/MP?

As far as I can see it is possible to get an OOB CP/MP without GAL header. 
The G-ACH Channel Type will indicate SCC (carries control plane info) or MCC
(carries management plane info). You can add this SCC/MCC to the 
- MPLS-TP Section Network Connection or Tandem Connection, or
- MPLS-TP Path Network Connection or Tandem Connection
- MPLS-TP Channel Network Connection or Tandem Connection
as required in the network.

In most cases you add the SCC/MCC information to the MPLS-TP Section Network
Connection. I.e. similar to the SDH MS Network Connection (using MS-DCC). 
	Note - In this case we need the GAL Header as an "OAM Priority
Label" to make up for the absence of a Section LSP label stack entry header
(i.e. the section LSP is typically "unlabelled" on is PHY).

For the case it is necessary to connect to a remote NTU/MTU device, which is
located behind a third party network (refer to G.8601), it is appropriate to
use the MPLS-TP Path Network Connection to carry the SCC/MCC information
between the last node of the service provider's network and the NTU/MTU
device. This is an example of the Carrier-Carrier (I) application depicted
in
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/layers-and-sublayers
-00.ppt.

In the previous case it is assumed that the E-NNI between the service
provider's GateWay node and the third party operator network carries
multiple MPLS-TP Path signals; each path signal should connect with one
NTU/MTU device.

For the case all path signals within an E-NNI must be connected to a NTU/MTU
device it is better to forward the section signal through the thrid party
network. For this case you would use the Section Network Connection to carry
the SCC/MCC information between the service provider's gateway node and
NTU/MTU device. This would also be the case when the channel signals are
mapped directly into the section signal (i.e. without intermediate path
layer signal). This is an example of the Carrier-Carrier (II) application
depicted in
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/layers-and-sublayers
-00.ppt.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 29 januari 2009 16:00
To: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MPLS-TP Protocol Type definition => is the GAL Header
required in LSP OAM packets?

Maarten

I came to exactly the same conclusion some time ago, ie in principle we do
not need the GAL for OAM.  But what we do need the GAL for is to indicate
the OOB CP/MP server layer 1-hop channel between logically adjacent MPLS-TP
nodes.

But we can use the GAL for OAM indicate too (a "belt+braces" means of ID).
It is not ideal because OAM now does not look like traffic units, and it
should do, ie traffic has 1 normal forwarding header (S=1), OAM has 2
headers of GAL (S=1) and normal forwarding header (S=0).  You may recall
when I wrote Y.1711 way back I hated the idea of a special label
14 for 'OAM indicate' for exactly the reason noted above.  But then I could
not get access to any of the other bits in the header, eg TTL field.....the
OAM indicate flag should really be part of the normal forwarding header.  

Now in MPLS-TP we do not need the TTL field for loop mitigation (no co mode
network needs a TTL) but I understand we cannot touch this.  So I am happy
to accept the compromise of using the GAL here.  And a key reason I say this
is because in MPLS-TP we have no need to worry about the 1 nibble payload
nonsense of ECMP as this cannot be allowed in MPLS-TP.  In other words,
whilst we can look at the 1st nibble for 0001
(G-ACH) we do not have to....and this also removes restrictions on what can
follow the GAL in future.  But as I said above, the key value of the GAL IMO
is to provide the OOB CP/MP indication.

regards, Neil

> Subject: [mpls-tp] MPLS-TP Protocol Type definition => is the GAL 
> Header required in LSP OAM packets?
> 
> I have created a couple of slides to understand the MPLS-TP Protocol 
> Type definition and values. Refer to 
> S, 4-bit nibble, channel type, ...). It is possible to define in 
> MPLS-TP standards MPLS-TP PW and LSP specific Protocol Type values as 
> combinations of specific values in those fields. Some examples are 
> presented in slides
> 8,9 and 11.
> 
> definition), the question pops up what the added value of the GAL 
> Header is in LSP OAM packets. It seems that the GAL Header in LSP OAM 
> packets is unnecessary from a protocol definition perspective. The 
> G-AC Header (G-ACH) seems to contain sufficient typing information, 
> which makes the GAL Header unnecessary in normal LSP OAM packets. The 
> GAL Header would only be required in Section LSP OAM packets when 
> those are carried directly over a physical medium.
> 
> Removal of the GAL Header from LSP OAM packets will unite the PW and 
> LSP OAM packet formats into a signle MPLS-TP OAM packet format, 
> removing the artificial difference between both types of OAM packets 
> in today's proposals.
> 
> What was the rationale to include such GAL Header in the LSP OAM 
> packet format?
> - A NNI port on a Provider (P) node not able to process MPLS-TP LSP 
> OAM will have to pass through any such OAM packets.
> - A NNI port on a Provider Edge (PE) node not able to process MPLS-TP 
> LSP OAM will have to discard any such OAM packets.
> 
> The NNI port on a PE node not able to process MPLS-TP LSP OAM may 
> receive LSP packets of which the S-bit in the LSP label stack entry 
> header has values 0 or 1.
> A) S=0 implies that there is another LSE header in the packet and 
> further processing is to be determined on the basis of the next LSE 
> header's content.
> B) S=1 implies that this is the bottom LSE header in the packet and 
> further processing information has to be derived from the bits 
> following this bottom of stack LSE header; e.g.
> the 4-bits nibble following the TTL field indicates if the packet is 
> an IPv4 or IPv6 packet.
> 
> Under normal conditions, this NNI port will not receive any MPLS-TP 
> LSP OAM packets when this port is not capable to process such MPLS-TP 
> LSP OAM packets. However under fault conditions (i.e. misconnection), 
> it is possble that a NNI port generating MPLS-TP LSP OAM packets is 
> connected with an NNI port which is not able to support such OAM 
> packets. For the case the G-ACH follows the LSP label stack entry 
> header immediately (without intermediate GAL header), the NNI port on 
> the PE node will receive LSP packets with S=1 and 4-bit nibble=0001. 
> This port will not know what to do with it, and should as such discard 
> those LSP OAM packets as unknown and unexpected packets. I.e. what 
> else could be done with those packets that do not have a next LSE 
> header and are not IPv4/v6?
> 
> Looking forward to understand the rationale for the GAL header in LSP 
> OAM packets... If there is no real rationale for it, I propose to 
> remove this GAL Header from those LSP OAM packets.
> 
> Regards,
> Maarten
> 
>

---

From: <[email-masked]>
Date: Thu, 29 Jan 2009 16:13:24 -0000

IMO it is far better to have an OOB CP/MP channel explicitly indicated
as a botomm-of-stack entry between logically adjacent nodes using a
special/reserved label for this purpose.  

But that is just my opinion.

regards, Neil

> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: 29 January 2009 15:34
> To: Harrison,N,Neil,CXM R; [email-masked]
> Subject: RE: [mpls-tp] MPLS-TP Protocol Type definition => is 
> the GAL Header required in LSP OAM packets?
> 
> Neil,
> 
> The G-ACH Channel Type will indicate SCC (carries control 
> plane info) or MCC (carries management plane info). You can 
> add this SCC/MCC to the
> - MPLS-TP Channel Network Connection or Tandem Connection as 
> required in the network.
> 
> In most cases you add the SCC/MCC information to the MPLS-TP 
> Section Network Connection. I.e. similar to the SDH MS 
> Network Connection (using MS-DCC). 
> 	Note - In this case we need the GAL Header as an "OAM 
> Priority Label" to make up for the absence of a Section LSP 
> label stack entry header (i.e. the section LSP is typically 
> "unlabelled" on is PHY).
> 
> For the case it is necessary to connect to a remote NTU/MTU 
> device, which is located behind a third party network (refer 
> to G.8601), it is appropriate to use the MPLS-TP Path Network 
> Connection to carry the SCC/MCC information between the last 
> node of the service provider's network and the NTU/MTU 
> device. This is an example of the Carrier-Carrier (I) 
> application depicted in 
> In the previous case it is assumed that the E-NNI between the 
> service provider's GateWay node and the third party operator 
> network carries multiple MPLS-TP Path signals; each path 
> signal should connect with one NTU/MTU device.
> 
> For the case all path signals within an E-NNI must be 
> connected to a NTU/MTU device it is better to forward the 
> section signal through the thrid party network. For this case 
> you would use the Section Network Connection to carry the 
> SCC/MCC information between the service provider's gateway 
> node and NTU/MTU device. This would also be the case when the 
> channel signals are mapped directly into the section signal 
> (i.e. without intermediate path layer signal). This is an 
> example of the Carrier-Carrier (II) application depicted in 
> Subject: RE: [mpls-tp] MPLS-TP Protocol Type definition => is 
> the GAL Header required in LSP OAM packets?
> 
> Maarten
> 
> Quick answer to your question from my perspective.....others 
> may have different reasons/views here.
> 
> I came to exactly the same conclusion some time ago, ie in 
> principle we do not need the GAL for OAM.  But what we do 
> need the GAL for is to indicate the OOB CP/MP server layer 
> 1-hop channel between logically adjacent MPLS-TP nodes.
> 
> It is not ideal because OAM now does not look like traffic 
> units, and it should do, ie traffic has 1 normal forwarding 
> header (S=1), OAM has 2 headers of GAL (S=1) and normal 
> forwarding header (S=0).  You may recall when I wrote Y.1711 
> way back I hated the idea of a special label
> 14 for 'OAM indicate' for exactly the reason noted above.  
> But then I could not get access to any of the other bits in 
> the header, eg TTL field.....the OAM indicate flag should 
> really be part of the normal forwarding header.  
> 
> Now in MPLS-TP we do not need the TTL field for loop 
> mitigation (no co mode network needs a TTL) but I understand 
> we cannot touch this.  So I am happy to accept the compromise 
> of using the GAL here.  And a key reason I say this is 
> because in MPLS-TP we have no need to worry about the 1 
> nibble payload nonsense of ECMP as this cannot be allowed in 
> (G-ACH) we do not have to....and this also removes 
> restrictions on what can follow the GAL in future.  But as I 
> said above, the key value of the GAL IMO is to provide the 
> OOB CP/MP indication.
> 
> regards, Neil
> 
> > MPLS-TP's protocol type information is carried inside a set 
> of fields 
> > (e.g.
> header in LSP

---

From: Dieter Beller <[email-masked]>
Date: Thu, 29 Jan 2009 18:00:03 +0100

Neil,

[email-masked] wrote:

Not only yours - this is exactly what is proposed in draft-beller-mpls-tp-gach-dcn-00

The only difference is that we used the term "in-band DCN" instead of
"OOB CP/MP

channel". In-band because the MCC/SCC is carried together with user
traffic LSPs

between adjacent nodes.

Cheers,

Dieter

regards, Neil

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: 29 January 2009 15:34
To: Harrison,N,Neil,CXM R; [email-masked]
Subject: RE: [mpls-tp] MPLS-TP Protocol Type definition => is

Neil,

As far as I can see it is possible to get an OOB CP/MP
without GAL header.

http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/layers
-and-sublayers
-00.ppt.

http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/layers
-and-sublayers
-00.ppt.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: donderdag 29 januari 2009 16:00
To: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MPLS-TP Protocol Type definition => is

Maarten

But we can use the GAL for OAM indicate too (a "belt+braces"
means of ID).

MPLS-TP. In other words, whilst we can look at the 1st
nibble for 0001

regards, Neil

-----Original Message-----

Protocol

Type definition and values. Refer to
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/mpls-t
p-protocol-typ
es-00.ppt

of fields

(e.g.
S, 4-bit nibble, channel type, ...). It is possible to define in
MPLS-TP standards MPLS-TP PW and LSP specific Protocol Type

values as

Looking at slides 10 and 11 (with MPLS-TP LSP Protocol Type
definition), the question pops up what the added value of the GAL
Header is in LSP OAM packets. It seems that the GAL Header

in LSP OAM

packets is unnecessary from a protocol definition perspective. The
G-AC Header (G-ACH) seems to contain sufficient typing information,
which makes the GAL Header unnecessary in normal LSP OAM

packets. The

Removal of the GAL Header from LSP OAM packets will unite

the PW and

LSP OAM packet formats into a signle MPLS-TP OAM packet format,
removing the artificial difference between both types of

OAM packets

in today's proposals.

What was the rationale to include such GAL Header in the LSP OAM
packet format?
- A NNI port on a Provider (P) node not able to process MPLS-TP LSP
OAM will have to pass through any such OAM packets.
- A NNI port on a Provider Edge (PE) node not able to

process MPLS-TP

packet is

an IPv4 or IPv6 packet.

Under normal conditions, this NNI port will not receive any MPLS-TP
LSP OAM packets when this port is not capable to process

such MPLS-TP

LSP OAM packets. However under fault conditions (i.e.

misconnection),

it is possble that a NNI port generating MPLS-TP LSP OAM packets is
connected with an NNI port which is not able to support such OAM
packets. For the case the G-ACH follows the LSP label stack entry
header immediately (without intermediate GAL header), the

NNI port on

the PE node will receive LSP packets with S=1 and 4-bit nibble=0001.
This port will not know what to do with it, and should as

such discard

header in LSP

Regards,
Maarten

--

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 29 Jan 2009 18:56:00 +0100

Neil,

The GAL in a LSP OAM packet is not a connection identifying label and it
neither identifies the OAM/Comms channel type. That's why it could be
removed from the LSP OAM packets.

The OAM/Comms channel type is identified by means of the G-AC Header and its
Channel Type; e.g. Channel Type = "0x02 29" could be defined as LSP MCC to
carry OOB MP information. 
This G-ACH(CT=0x0229) would be preceeded by a LSP label stack entry header
with Label value >15 (identifying the LSP) and S=1 (identifying that this is
a bottom-of-stack LSE header). 

For the case of an unlabelled Section LSP, the Section LSP MCC packet would
contain a G-ACH(CT=0x0229) that is preceeded by a GAL Header (acting as OAM
Priority Label).

In the MPLS-TP functional model you will find the MCC and SCC accessible at
e.g. the Section/Path adaptation function (Section LSP MCC), or the
Path/Channel adaptation function (LSP MCC), or the Path/Path tandem
connection adaptation function (Segment-LSP MCC).

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 29 januari 2009 17:13
To: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MPLS-TP Protocol Type definition => is the GAL Header

IMO it is far better to have an OOB CP/MP channel explicitly indicated as a
botomm-of-stack entry between logically adjacent nodes using a
special/reserved label for this purpose.  

regards, Neil

> Subject: RE: [mpls-tp] MPLS-TP Protocol Type definition => is the GAL 
> The G-ACH Channel Type will indicate SCC (carries control plane info) 
> or MCC (carries management plane info). You can add this SCC/MCC to 
> the
> - MPLS-TP Channel Network Connection or Tandem Connection as required 
> in the network.
> 
> In most cases you add the SCC/MCC information to the MPLS-TP Section 
> Network Connection. I.e. similar to the SDH MS Network Connection 
> (using MS-DCC).
Label" 
> to make up for the absence of a Section LSP label stack entry header 
> For the case it is necessary to connect to a remote NTU/MTU device, 
> which is located behind a third party network (refer to G.8601), it is 
> appropriate to use the MPLS-TP Path Network Connection to carry the 
> SCC/MCC information between the last node of the service provider's 
> network and the NTU/MTU device. This is an example of the 
> Carrier-Carrier (I) application depicted in 
> multiple MPLS-TP Path signals; each path signal should connect with 
> one NTU/MTU device.
> 
> For the case all path signals within an E-NNI must be connected to a 
> NTU/MTU device it is better to forward the section signal through the 
> thrid party network. For this case you would use the Section Network 
> Connection to carry the SCC/MCC information between the service 
> provider's gateway node and NTU/MTU device. This would also be the 
> case when the channel signals are mapped directly into the section 
> signal (i.e. without intermediate path layer signal). This is an

---

From: <[email-masked]>
Date: Thu, 29 Jan 2009 18:20:37 -0000

You are trading on the original arch 1st nibble 'fix' to cater for ECMP
wrt non IP clients.  If this 'fix' did not exist (and in MPLS-TP it has
no need to) then one would require the GAL for CP/MP indicate (given
there is no PID field in an MPLS header).

But this is all water under the bridge now.  Further, if I was designing
MPLS-TP from scratch I would definitely set aside a label for an OOB
CP/MP because it's such an obviously correct thing to do
architecturally.

And given this is what is proposed now then I fully support it.

regards, neil

> Sent: 29 January 2009 17:56
> The GAL in a LSP OAM packet is not a connection identifying 
> label and it neither identifies the OAM/Comms channel type. 
> That's why it could be removed from the LSP OAM packets.
> 
> The OAM/Comms channel type is identified by means of the G-AC 
> Header and its Channel Type; e.g. Channel Type = "0x02 29" 
> could be defined as LSP MCC to carry OOB MP information. 
> This G-ACH(CT=0x0229) would be preceeded by a LSP label stack 
> entry header with Label value >15 (identifying the LSP) and 
> S=1 (identifying that this is a bottom-of-stack LSE header). 
> 
> For the case of an unlabelled Section LSP, the Section LSP 
> MCC packet would contain a G-ACH(CT=0x0229) that is preceeded 
> by a GAL Header (acting as OAM Priority Label).
> 
> In the MPLS-TP functional model you will find the MCC and SCC 
> accessible at e.g. the Section/Path adaptation function 
> (Section LSP MCC), or the Path/Channel adaptation function 
> (LSP MCC), or the Path/Path tandem connection adaptation 
> function (Segment-LSP MCC).
> 
> Regards,
> Maarten
> 
> IMO it is far better to have an OOB CP/MP channel explicitly 
> indicated as a botomm-of-stack entry between logically 
> adjacent nodes using a special/reserved label for this purpose.  
> 
> plane info) 
> connected to a 
> principle 
> > we do not need the GAL for OAM.  But what we do need the 
> GAL for is to 
> units, and 
> > it should do, ie traffic has 1 normal forwarding header 
> (S=1), OAM has 
> > 2 headers of GAL (S=1) and normal forwarding header (S=0).  You may 
> > But then I could not get access to any of the other bits in the 
> > header, eg TTL field.....the OAM indicate flag should 
> really be part 
> mitigation (no co 
> > (G-ACH) we do not have to....and this also removes restrictions on 
> > what can follow the GAL in future.  But as I said above, 
> the key value 
> > of the GAL IMO is to provide the OOB CP/MP indication.
> > 
> > regards, Neil
> > 
> MPLS-TP LSP 
> packet and