Subject: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]

From: Lou Berger <[email-masked]>
Date: Thu, 27 Aug 2009 09:59:59 -0400

Looks like the LabN and IETF servers have decided to not talk to each
other, so this message didn't make it to the list.

Lou

-------- Original Message --------
Subject: Re: [mpls-tp] That S-bit discussion (again)
Date: Wed, 26 Aug 2009 13:22:10 -0400
From: Lou Berger <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: Drake, John E <[email-masked]>, [email-masked],
[email-masked]

Adrian/All,

I agree with John on this. I think this issue is now addressed in:
http://tools.ietf.org/html/draft-ietf-mpls-tp-framework-02#section-3.4.1

Note that this section is quite a bit different than in the 01 rev and
it's worth taking a look.

It explicitly covers S bit handling:

   Within the MPLS-TP transport network, the network layer protocols are
   carried over the MPLS-TP LSP using a separate MPLS label stack (the
   server stack).  The server stack is entirely under the control of the
   nodes within the MPLS-TP transport network and it is not visible
   outside that network.  In accordance with [RFC3032], the bottom
   label, with the 'bottom of stack' bit set to '1', defines the network
   layer protocol being transported.  Figure 5 shows how an a client
   network protocol stack (which may be an MPLS label stack and payload)
   is carried over as a network layer transport service over an MPLS-TP
   transport network.

         +------------------------------------+
         |        MPLS-TP LSP label(s) (S=0)  | n*4 octets
         .                                    . (four octets per label)
         +------------------------------------+
         |      Service label (s=1)           |   4 octets
         +------------------------------------+
         |       Client Network               |
         |       Layer Protocol               |
         |           Stack.                   |
         +------------------------------------+

      Note that the Client Network Layer Protocol
      Stack may include an MPLS label stack
      with the S bit set (S=1).

         Figure 5: Network Layer Transport Service Protocol Stack

It also covers handling on the terminating PE (Mach Chen's question):
   A label per network layer protocol payload type that is to be
   transported is REQUIRED.  Such labels are referred to as "Service
   Labels", one of which is shown in Figure 5.  The mapping between
   protocol payload type and Service Label is either configured or
   signaled.

Lou

On 8/25/2009 6:39 PM, Drake, John E wrote:
> Adrian,
> 
> This is consistent with my understanding and is what is written in
> section 3.4.1 of the overview I-D.
> 
> RFC 3032 uses the terminology defined in RFC 3031 and 'network layer' is
> defined to be 'layer 3'.  RFC 3032 is silent as to whether an MPLS stack
> can be part of a network layer payload.  Section 3.4.1 explicitly states
> that it can.
> 
> To answer your separate question, it seems to be pretty clear that RFC
> 3032 considers  the transport of a network layer payload without an
> intervening pseudo-wire to be the normal case.  I think it is also the
> case that if the client is transporting pseudo-wire payloads, they would
> start with a client MPLS stack.
> 
> Thanks,
> 
> John 
> 
>> -----Original Message-----
>> From: Adrian Farrel [mailto:[email-masked]] 
>> Sent: Tuesday, August 25, 2009 3:21 PM
>> To: [email-masked]
>> Subject: [mpls-tp] That S-bit discussion (again)
>>
>> Prompted by something Neil said, he and I have had a quick 
>> exchange and find we don't have the same interpretation of RFC 3032.
>>
>> To quote from Section 2.1 of the RFC...
>>
>>    The label stack entries appear AFTER the data link layer 
>> headers, but
>>    BEFORE any network layer headers.  The top of the label 
>> stack appears
>>    earliest in the packet, and the bottom appears latest.  The network
>>    layer packet immediately follows the label stack entry 
>> which has the
>>    S bit set.
>>
>>    Each label stack entry is broken down into the following fields:
>>
>>       1. Bottom of Stack (S)
>>
>>          This bit is set to one for the last entry in the label stack
>>          (i.e., for the bottom of the stack), and zero for all other
>>          label stack entries.
>>
>> Our debate may a bit legalistic :-)
>>
>> What is a "label stack," and what is a "network layer header/packet"?
>>
>> I am suggesting that, by definition, a label stack is 
>> something that ends with an S-bit set to 1. Anything that 
>> follows is payload. Therefore, if what follows is another 
>> label stack, this is just fine, and that separate label stack 
>> will also have its S-bit set to 1 at the bottom of the stack. 
>> In my world, this does not represent one label stack with two 
>> S=1 settings; it is two label stacks each with one S=1 setting.
>>
>> I accept that *one* way to carry MPLS over MPLS is to simply 
>> increase the depth of a single label stack (and so have just 
>> one S=1). But I suggest that the better way to achieve 
>> demarcation between client and server networks (such as MPLS 
>> over MPLS-TP) is to set S=1 at the bottom of the MPLS-TP 
>> stack. In this view, the client MPLS stack is the "network 
>> layer header."
>>
>> [It is a separate question whether the MPLS over MPLS-TP 
>> payload is carried native or via a packet-PW. I suggest we 
>> try to answer one question before embarking on the second question!]
>>
>> Opinions?
>>
>> Cheers,
>> Adrian 
>>
>> _______________________________________________
>> mpls-tp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 
> 
>

---

From: <[email-masked]>
Date: Thu, 27 Aug 2009 15:56:27 +0100

Thanks Lou,

Assuming I am reading this correctly, the client semantic (ie 'who') is
carried by the (20 bit) service label....so how does setting S=1 here
add value?  Seems to me we could set S=1 in all headers and just rely on
the label semantic with this logic.

BTW - I don't think choosing a normal forwarding header is a good idea
anyway for the case of MPLS(TP)overMPLS(TP).  Not only have we got the
existing case of misconncetivity between LSPs in the same party MPLS
layer network, now we can have this between different party MPLS layer
networks.  What I am essentially postulating here is that the
misconnectivity risk is larger with a normal fowarding label (drawn from
the >15 value population) than with a special reserved label (drawn from
the 0-15 set)....simply on the basis of how many nodes would expect to
see (ie have issued) the relevant label in the 2 cases.

regards, Neil  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: 27 August 2009 15:00
> To: [email-masked]
> Subject: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 27 Aug 2009 11:22:23 -0400

Neil,
	See below.

On 8/27/2009 10:56 AM, [email-masked] wrote:
> add value?  

The way I see it is that the S bit provides an unambiguous indication of
when forwarding should stop at a particular layer of the network.  So if
operating within an MPLS-TP domain, the domain boundary is always
represented in the packet.

I think this is important from a misdelivery/misconfiguration
perspective.  If we didn't care about such cases, it's not clear that an
S bit would ever have been needed.  Even in the original definition of
MPLS.

Also, I think the use of labels after the S bit is allowed for by 3032.
Sure there's an implicit expectation that the 'Network Layer Protocol'
carried by MPLS isn't MPLS, but if MPLS is itself considered a 'Network
Layer Protocol' then this is allowed by 3032.

> Seems to me we could set S=1 in all headers and just rely on

Sure. we could also always set it to 0.  Again, this holds true for base
MPLS too.

> networks.  

If you're saying misconnection between different layers, than this is
what use of the S bit precludes.  If you're saying misconnection among
different clients at the same layer, while this is true, I don't see how
it differs from any misconection case.

> What I am essentially postulating here is that the

So how do you prefer/propose to address this point?

Thanks,
Lou

---

From: <[email-masked]>
Date: Thu, 27 Aug 2009 16:38:24 +0100

Thanks Lou for the helpful response.  You asked a question:

NH=> What I am essentially postulating here is that the
> So how do you prefer/propose to address this point?

When I first looked at this problem (a long time ago now) it seemed
rather important that the solution should:
(i) be efficient/simple, ie don't insert a Eth PW as this is rather a
sledgehamer approach to creating functional isolation between 2
different MPLS stacks;
(ii) try and ensure we could minimise the risk of misdelivery under
defect conditions....which is always a possibility due to the arbitrary
LSP sublayering hierarchy that a digital wrapper, ie S bit, approach
has.

I therefore concluded that for the unique case of MPLS(TP)overMPLS(TP)
(with a desire to preserve the original S bit concept) it would be best
to use a gloabally well-known label that is *not* used in the DP for
normal LSP forwarding purposes...that is a label drawn from the 0-15
set.

This would have special DP significance (ie a functional breakwater
between different MPLS LSP stacks) and would have a very restricted
pouplation size compared to a normal fowarding label (drawn from the >15
value label set).  Thus, this would help mitigate the risk of
misconnectivity between different operator MPLS networks.

I still think this is what we should do here.

regards, Neil

> From: Lou Berger [mailto:[email-masked]] 
> Sent: 27 August 2009 16:22
> To: Harrison,N,Neil,DEY2 R
> Cc: [email-masked]
> Subject: Re: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]
> 
> Neil,
> 	See below.
>

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 27 Aug 2009 10:24:05 -0700

Hi Lou,

You mentioned:

"The way I see it is that the S bit provides an unambiguous indication of
when forwarding should stop at a particular layer of the network.  So if
operating within an MPLS-TP domain, the domain boundary is always
represented in the packet."

How can S=1 prevent forwarding? AFAIK all LSRs forward MPLS packets with S=1.

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, August 27, 2009 8:22 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]

Neil,
	See below.

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 27 Aug 2009 17:01:01 -0400

Sorry, should have been more precise in my language.

either the s bit or the reserved label provide an unambiguous indication
of where label stack processing should stop at (for) a particular layer
of the network.

Lou

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 27 Aug 2009 14:11:58 -0700

Hi Lou,

Thanks. Now my observation is that using S=1, the context of the label is going to tell us the type of payload, while if we use a reserved label, it is the reserved label that tells us what is the payload. As Neil mentioned the former is prone to mis-connection because the context of a label has different meaning at different locations of a network. So if one of these packets ends up at a wrong terminating node, then it might be wrongly forwarded onward, while a reserve label is always interpreted the same.

Regards,
Shahram 

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, August 27, 2009 2:01 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 27 Aug 2009 17:24:44 -0400

Hi Lou,

IMO:

a) reserved label is sufficient to tell a user data packet from an OAM/CP packet;
b) when there is no mis-configuration, S-bit does not matter (indeed, label stack depth could =1 or >1, in any case only external label matters;
c) when there is a mis-configuration, S-bit does not help much either.

>From what you wrote you seem to agree with that. Sorry for a naïve question, but could you help me understand why do we need S-bit at all?

Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, August 27, 2009 5:01 PM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 27 Aug 2009 18:00:37 -0400

Shahram,
	You seem to be implying a reserved label per transported network layer
type.  I didn't interpret Neil as saying this (and certainly for the
non-MPLS case).  Is this your proposal?  The reserved label space is
awfully small...

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 27 Aug 2009 18:12:47 -0400

Hi Igor,

See below.

> a) reserved label is sufficient to tell a user data packet from an OAM/CP packet;

okay, but this is orthogonal to our current discussion.

> b) when there is no mis-configuration, S-bit does not matter (indeed, label stack depth could =1 or >1, in any case only external label matters;

What is an 'external label'?

> c) when there is a mis-configuration, S-bit does not help much either.

sure, as it always has, it identifies where a particular MPLS layer
stops processing a label stack. (and looks to config/CP info on what to
do next).  Again, as stated my my earlier mail to Neil, I see no
difference (other than number of bits used) between using the S bit and
a reserved label for such a layer boundary identifier.

>>From what you wrote you seem to agree with that. Sorry for a naïve question, but could you help me understand why do we need S-bit at all?

It provides an in-band/in-packet indication of when a particular
MPLS(TP) layer should stop processing the label stack.  (Which is the
same thing that Neil's reserved label does.) This is only really useful,
in the TE context, in a misconfiguration.

Lou

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 27 Aug 2009 15:39:56 -0700

Lou,

I would agree with you that we can't allocate a reserved label per payload (transported network layer) type. 
But can't we use for example GAL/G-ACH for all types of traffic carried in MPLS-TP? G-ACH includes a payload field that can be used to identify the Transported Network layer. Although I know the MPLS-TP framework uses G-ACH only for Management and Control traffic.

Shahram

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, August 27, 2009 3:01 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]

Shahram,

Lou

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 28 Aug 2009 00:40:30 +0200

Aren't we trying to put too much context into the label? In other
technologies a label is purely used as a client instance identifier, and a
protocol ID/payload type is used to identify the type of client. In
addition, management protocols and control plane protocols are carried in
management communication channels and signalling communication channels,
each having their own specific identification.

In MPLS-TP OAM we are adding such MCC and SCC capability, and those can be
used to carry the well known MPLS/GMPLS management and control plane
protocols.

In MPLS-TP the tunnel/path layer signals will have to carry both Ethernet VC
and MPLS-TP VC signals. There should be no need to carry other client signal
types. It is possible to use a label stack entry header with S=1 to indicate
that this label stack entry header identifies a client layer signal, and
each label value has been registered what the client type is (i.e. EVC or
MVC). Normal deployment is to carry either EVCs, or MVCs in a MPLS-TP tunnel
layer signal, not a mix of the two. This allows to register the type of
client per MPLS-TP tunnel trail, which is more efficient than registering
this for every service layer signal carried inside the tunnel.

In MPLS-TP the section layer signals carry either MPLS-TP tunnel (VP) layer
signals, or carry Ethernet VC or MPLS-TP VC signals. There should be no need
to carry other client signal types. It is possible to use a label stack
entry header with S=1 to indicate that this label stack entry header
identifies a client layer signal, and each label value has been registered
what the client type is (i.e. MVP, or EVC, or MVC). Normal deployment is to
carry either EVCs, or MVCs, or MVPs in a MPLS-TP section layer signal, not a
mix of two or three. This allows to register the type of client per MPLS-TP
section trail, which is more efficient than registering this for every
service or tunnel layer signal carried inside the section.

In MPLS-TP the service/channel layer signals have to carry a larger variety
of client signals; e.g. Ethernet VLAN, ATM VP, ATM VC, AAL5, FR, PPP, HDLC,
TDM, SDH VC-n, etc. but each service/channel layer signal carries only one
client type. It is possible to use a label stack entry header with S=1 to
indicate that this label stack entry header identifies a client layer
signal, and each label value has been registered what the client type is
(i.e. Ethernet VLAN, ATM VP, etc). Alternatively, such clienttype
registration can be done per MPLS-TP service trail. If a label stack entry
header is used and if the MPLS-TP service layer trail supports only a single
type of client, then it is possible to specify that label 16 represents e.g.
Ethernet VLAN clients, label 17 represents ATM VP clients, etc. In this way
there will be more then enough values available to support any future client
in the next century.

Label stack entry headers with S=0 can be located between two label stack
entry headers with S=1. The headers with S=0 represent sublayers/MEG levels
of the local layer.

As Section layer signals are typically set up before tunnel layer signals
are set up and before service layer signals are set up, it is unlikely that
MPLS-TP seciton layer signals are misconnected to tunnel endpoints or
service endpoints.

Similarly, MPLS-TP tunnel layer signals are set up before service layer
signals are set up, and it is unlikely that MPLS-TP tunnel layer singals are
misconnected to service layer endpoints.

The interlayer adaptation functions (section to tunnel, tunnel to service)
can be specified to only accept packets of which the top label stack entry
header has S=1. receipt of a packe twith a top header with S=0 can result in
discarding this packet.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lou Berger
Sent: vrijdag 28 augustus 2009 0:01
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]

Shahram,
	You seem to be implying a reserved label per transported network
layer type.  I didn't interpret Neil as saying this (and certainly for the
non-MPLS case).  Is this your proposal?  The reserved label space is awfully
small...

Lou

On 8/27/2009 5:11 PM, Shahram Davari wrote:
> Hi Lou,
> 
> Thanks. Now my observation is that using S=1, the context of the label is
going to tell us the type of payload, while if we use a reserved label, it
is the reserved label that tells us what is the payload. As Neil mentioned
the former is prone to mis-connection because the context of a label has
different meaning at different locations of a network. So if one of these
packets ends up at a wrong terminating node, then it might be wrongly
forwarded onward, while a reserve label is always interpreted the same.
> either the s bit or the reserved label provide an unambiguous 
> indication of where label stack processing should stop at (for) a 
> particular layer of the network.
> 
> Lou
> 
>> "The way I see it is that the S bit provides an unambiguous 
>> indication of when forwarding should stop at a particular layer of 
>> the network.  So if operating within an MPLS-TP domain, the domain 
>> boundary is always represented in the packet."
>>
>>> Assuming I am reading this correctly, the client semantic (ie 'who') 
>>> is carried by the (20 bit) service label....so how does setting S=1 
>>> here add value?
>> The way I see it is that the S bit provides an unambiguous indication 
>> of when forwarding should stop at a particular layer of the network.  
>> So if operating within an MPLS-TP domain, the domain boundary is 
>> always represented in the packet.
>>
>> perspective.  If we didn't care about such cases, it's not clear that 
>> an S bit would ever have been needed.  Even in the original 
>> definition of MPLS.
>>
>> carried by MPLS isn't MPLS, but if MPLS is itself considered a 
>> 'Network Layer Protocol' then this is allowed by 3032.
>>
>>> Seems to me we could set S=1 in all headers and just rely on the 
>>> label semantic with this logic.
>>>
>> Sure. we could also always set it to 0.  Again, this holds true for 
>> base MPLS too.
>>
>>> BTW - I don't think choosing a normal forwarding header is a good 
>>> idea anyway for the case of MPLS(TP)overMPLS(TP).  Not only have we 
>>> got the existing case of misconncetivity between LSPs in the same 
>>> party MPLS layer network, now we can have this between different 
>>> party MPLS layer networks.
>> what use of the S bit precludes.  If you're saying misconnection 
>> among different clients at the same layer, while this is true, I 
>> don't see how it differs from any misconection case.
>>
>>> What I am essentially postulating here is that the misconnectivity 
>>> risk is larger with a normal fowarding label (drawn from the >15 
>>> value population) than with a special reserved label (drawn from the 
>>> 0-15 set)....simply on the basis of how many nodes would expect to 
>>>> Looks like the LabN and IETF servers have decided to not talk to 
>>>> each other, so this message didn't make it to the list.
>>>>
>>>> Lou
>>>>
>>>> Note that this section is quite a bit different than in the 01 rev 
>>>> and it's worth taking a look.
>>>>
>>>>> 3032 considers  the transport of a network layer payload without 
>>>>> an intervening pseudo-wire to be the normal case.  I think it
>>>> is also the
>>>>>>    BEFORE any network layer headers.  The top of the label stack 
>>>>>> appears
>>>>>>    layer packet immediately follows the label stack entry which 
>>>>>> has the
>>>>>>    S bit set.
>>>>>>
>>>>>> I am suggesting that, by definition, a label stack is something 
>>>>>> that ends with an S-bit set to 1. Anything that follows is 
>>>>>> payload. Therefore, if what follows is another label stack, this 
>>>>>> is just fine, and that separate label stack will also have its 
>>>>>> S-bit set to 1 at the bottom of the stack.
>>>>>> increase the depth of a single label stack (and so have just one 
>>>>>> S=1). But I suggest that the better way to achieve demarcation 
>>>>>> between client and server networks (such as MPLS over MPLS-TP) is 
>>>>>> to set S=1 at the bottom of the MPLS-TP stack. In this view, the 
>>>>>> client MPLS stack is the "network layer header."
>>>>>>
>>>>>> [It is a separate question whether the MPLS over MPLS-TP payload 
>>>>>> is carried native or via a packet-PW. I suggest we try to answer 
>>>>>> one question before embarking on the second
>>>> question!]
>>>>>> Opinions?
>>>>>>
>>>>>> Cheers,
>>>>>> Adrian
>>>>>>

---

From: <[email-masked]>
Date: Fri, 28 Aug 2009 00:00:58 +0100

Maarten,
 
> 
> Aren't we trying to put too much context into the label? 

NH=> Are you serious?  If you are you have not understood MPLS.  A label
in MPLS has anything but singular semantics!  This is nothing like you
are thinking about.

regards, neil

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 28 Aug 2009 01:04:13 +0200

Neil,

I am aware of that, and try to reduce the amount of context such that it
starts looking like a normal transport network design.

Regards,
Maarten 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 28 augustus 2009 1:01
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]

Maarten,
 
> Aren't we trying to put too much context into the label? 

NH=> Are you serious?  If you are you have not understood MPLS.  A label in
MPLS has anything but singular semantics!  This is nothing like you are
thinking about.

regards, neil

---

From: <[email-masked]>
Date: Fri, 28 Aug 2009 00:45:51 +0100

I agree Maarten.  I am also trying to get folks on this same page.  But
to do this I have to keep going back though 'how we got here' history to
know what is right/wrong going forwards.  I remain hopeful however,
because the logic is quite compelling once understood.

I've tried oh so many times to get the point across that a PW label is
there primarily to recover lost source information due to LDP
merging....why this gets resisted beats me, because its so plainly
obvious from simple information considerations.  Now whilst I know loads
of folks who get this from the off (ie folks who have good func arch
background...and I'm quite sure you get this) many still don't.  Some (I
think) still don't see the huge impact of PWs moving from SS to
MS.....this is not a minor change, this generates a PW layer network as
I am sure you recognise.  And it has the accompanying issue that the PW
label that originally MUST have a source (demerging) semantic in the SS
case really now needs a destination/forwarding semantic in the MS case.

Then we get into the small detail of S bit sublayering.....which is
where we are now at.  Transport networks don't need sublayers as I am
sure you know better than most.  But given how important the S bit is to
the original MPLS arch I am trying to find an elegant way to keep this
concept whilst addressing the important MPLSoverMPLS case.  One can but
try!

regards, neil 

> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: 28 August 2009 00:04
> To: Harrison,N,Neil,DEY2 R; [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Fri, 28 Aug 2009 00:45:43 +0100

Guys....this is missing the point IMO.  Lou is correct that I am not
implying a label per client...this is plain silly.

In a co-ps (or co-cs mode for that matter) network we do NOT need to add
a PID function IFF the connection carries a single client.  The client
(ie 'who') knowledge is held in the CP/MP.  It is only if we want to
carry multiple client per single server connection that we have to add a
PID function (CF GFP for co-cs mode server transport networks that has a
PID function for just such a case).

The problem (let me call it that) in MPLS-TP is that we don't need S bit
sublayering, but its such a strong concept in regular MPLS that we need
to try and cater for it.  And this is exactly what I am trying to do
with my proposal to use a reserved label. 

BTW - we strictly should only use the GAL/G-ACH channel for CP/MP
protocols and not DP protocols.  This is why OAM should not appear under
the GAL/G-ACH as OAM is a DP protocol.  If we really wanted to get this
right (though I am for sure not at all hopeful on this one) the 'OAM
indicate' flag SHOULD be part of the normal DP fowarding header.  You
may care to note that the 8 bit TTL field is strictly redundant in a
properly designed/operated co-ps mode layer network....that is, 8 bits
of a quite scarce O/H resource is doing nothing useful.   And as a
further aside here, one might like to observe that a connection should
only have a single QoS class....this is a little more subtle
theoretically (all about preserving information ordering in transport
networks) BUT it will have a major practical impact (==complexity) once
folks get round to trying to define entry/exit of unavailable states for
an LSP.  One can but warn.

regards, Neil 

> From: Shahram Davari [mailto:[email-masked]] 
> Sent: 27 August 2009 23:40
> To: Lou Berger
> Cc: Harrison,N,Neil,DEY2 R; [email-masked]
> I would agree with you that we can't allocate a reserved 
> label per payload (transported network layer) type. 
> But can't we use for example GAL/G-ACH for all types of 
> traffic carried in MPLS-TP? G-ACH includes a payload field 
> that can be used to identify the Transported Network layer. 
> Although I know the MPLS-TP framework uses G-ACH only for 
> Management and Control traffic.
> 
> Shahram
> 
> > Thanks. Now my observation is that using S=1, the context 
> of the label is going to tell us the type of payload, while 
> if we use a reserved label, it is the reserved label that 
> tells us what is the payload. As Neil mentioned the former is 
> prone to mis-connection because the context of a label has 
> different meaning at different locations of a network. So if 
> one of these packets ends up at a wrong terminating node, 
> then it might be wrongly forwarded onward, while a reserve 
> label is always interpreted the same.
> > 
> > Regards,
> > Shahram 
> >

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 28 Aug 2009 02:47:29 +0200

Neil,

In a p2p trail, a client label represents a client instance identifier. It
implicitly also represents source and destination port idnetifiers, but this
is of less interest as there is only one source port and one destination
port. The scope of the client label value is the p2p trail and thus an input
port and output port.

In a p2mp trail, a client label represents again a client instance
identifier. It implicitly also represents a source port identifier and a
destination port group identifier, but this is of less interest as there is
no variability; i.e. every traffic unit is delivered to every destination
port. The scope of the client label value is the p2mp trail and thus an
input port and a set of output ports.

It is possible to change the scope of those client labels and make those
desitnation specific; e.g. label value X1 is registered at output port A, X2
is registered at output ports A and B, etc. Now the client label value has
true destination port information associated.

In a mp2p trail a client label represents again a client instance identifier
like in the two previous cases. It implicitly also represents a source port
identifier and a destination port indentifier, but this information is of
less interest as there is no variability; i.e. every traffic unit is
delivered to the single destination port.
>From the perspective of the client layer functions behind the mp2p trail's
destination port, it does not matter behind which ingress port those clients
are located. The only important thing is that two client instances must not
have the same client label value; if such would be the case we would loose
important information and we will not be able to disentangle the two client
instnaces.

In a mp2mp trail, a client label represents again a client instance
identifier like in the three previous cases. If implicitly also represents a
source port identifier and destination port or destination port group
identifier. If you assume that all traffic units in such mp2mp trail are
broadcast, then all traffic units will be delivered to all destination ports
of the mp2mp trail. If only a subset of client labels is registered behind
each destination port, then all traffic units with non-registered client
label values are discarded at a destination port. In this latter case, the
client label's implicit source and destination information is important as
it provides filtering control.

As you can see, a client label's main purpose is to identify each client
instance within an aggregate. This to my knowledge also applies to the PW
label in an LDP created mp2p LSP. I.e. the implicit source port identifier
associated with each PW label is of no interest to the data plane
processing; the uniqueness of the PW label within the mp2p LSP is of
interest.

The same applies to e.g. the VCI within the scope of a mp2p ATM VP trail.

---------

Concerning the expansion of SS-PWs into MS-PWs I fully agree with you that
this is about the addition of a new layer network. In my opinion, such
addition should have been done already years ago. It is insane to develop a
transport netowrk technology in which you specify that tunnels have to be
set up between UNI-N ports. A transort network expert knows that this will
not scale... So, it is very urgent that MPLS-TP is equipped with a
service/channel layer in which connections are set up between UNI-N ports,
and that those MPLS-TP service/channel layer instances are multiplexed into
MPLS-TP tunnels at (metro, core) domain boundaries.

As I wrote in an email yesterday, the introduction of a MPLS-TP
service/channel layer requires that the mapping of a client signal and the
mulitplexing into a tunnel are separated into two steps. Such separation can
be performed in two ways as described yesterday. One alternative is to
associate the PW label stack entry header with the new service/channel layer
signal, the other alternative is to associate the PW label stack entry
header with the client layer signal.

I have the impression that you prefer to latter alternative and that you
would like to get a new label stack entry header to identify the new MPLS-TP
service/channel layer instances. Those new service/channel layer instances
would then be using a LSP label stack entry header when multiplexed into a
tunnel.

If we would specify that such multiplexing label stack entry headers have
their S bit set to 1, then the minimum label stack would inlcude a PW label
with S=1 that identifies the client type, a service/channel instance
identfiing label stack entry header with S=1 and a tunnel instance
identifying label stack entry header with S=1.

Between the PW and service label stack entry headers we can get one or more
service/channel layer sublayer/MEG level identifying label stack entry
headers with S=0. In most cases such sublayer/MEG level indentifying label
stack entry headers with S=0 are not present in the between the service and
tunnel labels and above the tunnel label; i.e. no need for tunnel segment
monitoring or section segment monitoring in a single carrier network.

As you are aware I am a main advocate of MEG related sublayers. Those
sublayers are necessary to give the differnet owners of a service/channel
layer the ability to monitor the status/performance of the segment they own
or are responsible for, and support for it is required by your company
according to your companies internet-draft. The encoding of the associated
information is a separate issue; so far there are the following encodings
being used in the different transport network technologies:
- specific overhead fields (SDH, OTN)
- specific reserved VCI and PTI values (ATM)
- MEG level field (Ethernet)
- label stacking (MPLS-TP).
Multiple encodings, but same functionality.

Regards,
Maarten
PS. NOTE: a similar expansion has been performed on the basis of the ISID
and the <SA,DA> labels. In PBB originally there was only the B-VLAN layer
that was designed to act as tunnel layer for S-VLANs. Because the B-VLAN
would have many input/output ports, there would be more then 4k S-VLANs to
be carried. This required a larger identifier space, and the 24-bit I-SID
was providing this. Then halfway the development it was decided to promote
the large S-VLAN idnetifer (i.e. ISID) to become a complete layer network
with its own independent BSI transport entities and its own BSI OAM. It took
3 meetings to get the impact of this decision undertood and to build in the
necessary management and OAM support (it introduced many changes in the
draft standard). Then in PBB-TE the <SA,DA> label which identified so far a
set of client instances with the same source and destination ports on a VLAN
were promoted to identify the instances in a new layer network (i.e. the ESP
layer network). As such, the promotion of a client isntance identifying PW
label into a label for a new service layer network is just the third time
that such expansion is occuring in our industry. As we did it already twice,
it should be possible to do it a third time. Main decision to make for the
PW expansion is to decide if the PW label stack entry header is a client
related label stack entry header, or is a MPLS-TP serivce instance related
label stack entry header. Once this is decided the rest of the frame format
will follow naturally.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 28 augustus 2009 1:46
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]

I agree Maarten.  I am also trying to get folks on this same page.  But to
do this I have to keep going back though 'how we got here' history to know
what is right/wrong going forwards.  I remain hopeful however, because the
logic is quite compelling once understood.

I've tried oh so many times to get the point across that a PW label is there
primarily to recover lost source information due to LDP merging....why this
gets resisted beats me, because its so plainly obvious from simple
information considerations.  Now whilst I know loads of folks who get this
from the off (ie folks who have good func arch background...and I'm quite
sure you get this) many still don't.  Some (I
think) still don't see the huge impact of PWs moving from SS to MS.....this
is not a minor change, this generates a PW layer network as I am sure you
recognise.  And it has the accompanying issue that the PW label that
originally MUST have a source (demerging) semantic in the SS case really now
needs a destination/forwarding semantic in the MS case.

Then we get into the small detail of S bit sublayering.....which is where we
are now at.  Transport networks don't need sublayers as I am sure you know
better than most.  But given how important the S bit is to the original MPLS
arch I am trying to find an elegant way to keep this concept whilst
addressing the important MPLSoverMPLS case.  One can but try!

regards, neil 

> I am aware of that, and try to reduce the amount of context such that 
> it starts looking like a normal transport network design.
> 
> Regards,
> Maarten
> 
> NH=> Are you serious?  If you are you have not understood MPLS.  A 
> label in MPLS has anything but singular semantics!  This is nothing 
> like you are thinking about.
> 
> regards, neil
> 
>

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 28 Aug 2009 02:57:22 +0200

Neil,

> In a co-ps (or co-cs mode for that matter) network we do NOT 
> need to add a PID function IFF the connection carries a single client.

Actually our SDH and OTN networks do carry a PID function for the case the
connection carries a single client. The reason we require such PID function
is the design of interface ports that can support more then one client type
(but only one client can be carried at any given time). The connection
doesn't carry the client type information as such, and a configuration
mistake at one endpoint can connect two different clients with each other.
Without PID you can be looking for days to uunderstand why there is a funny
alarm condition (it took a SDH development team 3 days to figure out why
there were code violations reported by a 2 Mbit/s interface port, wihtout
any alarms present in the SDH network itself ==> the third day the team
noticed that the "PID" mismatch alarm was disabled and that both ends of the
VC12 had a different client encapsulation configured).

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: vrijdag 28 augustus 2009 1:46
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]

In a co-ps (or co-cs mode for that matter) network we do NOT need to add a
PID function IFF the connection carries a single client.  The client (ie
'who') knowledge is held in the CP/MP.  It is only if we want to carry
multiple client per single server connection that we have to add a PID
function (CF GFP for co-cs mode server transport networks that has a PID
function for just such a case).

The problem (let me call it that) in MPLS-TP is that we don't need S bit
sublayering, but its such a strong concept in regular MPLS that we need to
try and cater for it.  And this is exactly what I am trying to do with my
proposal to use a reserved label. 

BTW - we strictly should only use the GAL/G-ACH channel for CP/MP protocols
and not DP protocols.  This is why OAM should not appear under the GAL/G-ACH
as OAM is a DP protocol.  If we really wanted to get this right (though I am
for sure not at all hopeful on this one) the 'OAM indicate' flag SHOULD be
part of the normal DP fowarding header.  You may care to note that the 8 bit
TTL field is strictly redundant in a properly designed/operated co-ps mode
layer network....that is, 8 bits
of a quite scarce O/H resource is doing nothing useful.   And as a
further aside here, one might like to observe that a connection should only
have a single QoS class....this is a little more subtle theoretically (all
about preserving information ordering in transport
networks) BUT it will have a major practical impact (==complexity) once
folks get round to trying to define entry/exit of unavailable states for an
LSP.  One can but warn.

regards, Neil 

> I would agree with you that we can't allocate a reserved label per 
> payload (transported network layer) type.
> But can't we use for example GAL/G-ACH for all types of traffic 
> carried in MPLS-TP? G-ACH includes a payload field that can be used to 
> identify the Transported Network layer.
> Although I know the MPLS-TP framework uses G-ACH only for Management 
> and Control traffic.
> 
> Shahram
> 
> layer type.  I didn't interpret Neil as saying this (and certainly for 
> the non-MPLS case).  Is this your proposal?  The reserved label space 
> is awfully small...
> 
> Lou
> 
> of the label is going to tell us the type of payload, while if we use 
> a reserved label, it is the reserved label that tells us what is the 
> payload. As Neil mentioned the former is prone to mis-connection 
> because the context of a label has different meaning at different 
> locations of a network. So if one of these packets ends up at a wrong 
> terminating node, then it might be wrongly forwarded onward, while a 
> reserve label is always interpreted the same.
> > 
> > Regards,
> > Shahram
> > 
> >>> risk is larger with a normal fowarding
> label (drawn from
> >>>>>> payload. Therefore, if what follows is another label stack, 
> >>>>>> this is just fine, and that separate label stack will also have 
> >>>>>> its S-bit set to 1 at the bottom of the stack.
> >>>>>> over MPLS-TP) is to set S=1 at the bottom of the MPLS-TP stack. 
> >>>>>> In this view, the client MPLS stack is the "network layer 
> >>>>>> header."
> >>>>>>
> >>>>>> payload is carried native or via a packet-PW. I suggest we try 
> >>>>>> to answer one question before embarking on the second
> >>>> question!]
> >>>>>> Opinions?
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Adrian
> >>>>>>

---

From: Lou Berger <[email-masked]>
Date: Thu, 27 Aug 2009 21:48:12 -0400

Shahram,
	Sure this is possible, but why?  Part of the value of MPLS has been its
simplicity/flexibility with respect to what is a 'network layer' from
the perspective of MPLS (label stack).  I think we should stick with the
MPLS architecture and no go in this direction.

Now, TP does allow you to use PWs to transport client traffic.  I think
this would be more in line with where you're headed.

Lou

---

From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
Date: Fri, 28 Aug 2009 08:42:12 +0200

Lou, please see in line
tnx

[ll>] --------snipped---------

[ll>] except that you have more possibilities with the limited-in-space reserved label.

[ll>] Lou, I don't understand your last sentence, would you mind to elaborate?
tnx
Lou

---

From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
Date: Fri, 28 Aug 2009 08:50:49 +0200

Hi Maarten
You mention twice that " Normal deployment is to carry either EVCs, or MVCs in a MPLS-TP tunnel
layer signal, not a mix of the two."
I am not sure why? There seems to be an dependency between the client type and the used tunnel.
./
Lieven

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: 28 August 2009 00:41
To: 'Lou Berger'; 'Shahram Davari'
Cc: [email-masked]
Subject: Re: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]

[ll>] Not sure I understand why to  limit the use and dictate that use of clients type per tunnel?

Regards,
Maarten

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

Shahram,

Lou

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 28 Aug 2009 10:05:12 +0200

Lieven,

In the past months we discussed the layer stack alternatives for the MPLS-TP
domains within a packet transport network. At one poitn in time there were 4
alternative stacks on the table. Two of those stack alternatives seem not to
be favoured, leaving only two alternatives. Those two alternatives are the
EVC only and EVC+MVC service layer alternatives. In the EVC only alternative
there are only EVC signals carried inside a MVP. In the EVC+MVC service
layer alternative only the MVC is carried in the MVP and the EVC is carried
in a MVC. See attached slides illustrating these two cases.

As you will see in the layer stack figures, the tunnel layer is independent
of the service layer. But with two types of service layer, it is possible to
make carry over a tunnel either the signals of one service layer, or the
signals of the other service layer.

Regards,
Maarten

-----Original Message-----
From: LEVRAU, LIEVEN (LIEVEN) [mailto:[email-masked]] 
Sent: vrijdag 28 augustus 2009 8:51
To: Maarten Vissers; 'Lou Berger'; 'Shahram Davari'
Cc: [email-masked]
Subject: RE: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]

Hi Maarten
You mention twice that " Normal deployment is to carry either EVCs, or MVCs
in a MPLS-TP tunnel layer signal, not a mix of the two."
I am not sure why? There seems to be an dependency between the client type
and the used tunnel.
./
Lieven

-----Original Message-----
Of Maarten Vissers

[ll>] Not sure I understand why to  limit the use and dictate that use of
clients type per tunnel?

Regards,
Maarten

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

Shahram,

Lou

>> How can S=1 prevent forwarding? AFAIK all LSRs forward MPLS packets 
>> with
S=1.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 28 Aug 2009 12:25:31 +0100

Guessing Lou's answer :-)

>>>From what you wrote you seem to agree with that. Sorry for a naïve
>>>question, but could you help me understand why do we need S-bit
>>> at all?
>>
> Lou, I don't understand your last sentence, would you mind to elaborate?

In TE, the LSPs are very definite. They are specifically and "statically" 
provisioned either by the management plane or the control plane. Therefore, 
the instructions in the LFIB will inform the processor of exactly what to do 
when it pops a label in terms of looking at the next label (equivalent to 
S=0) or forwarding the payload (equivalent to S=1).

Personally, I don't think it is quite so simple.

Certainly, if there are ECMP or DPI excuses within the network, the S bit 
can be handy.

Another consideration (that Neil's solution circumvents) is what to do is an 
LSP carries more than one payload, and one of the payloads is MPLS from 
within the same network. In that case, on label pop we might find (e.g.) IP 
or MPLS. The MPLS would be indicated by S=0, the IP by S=1.

That said, RFC3032 provided a provision to identify that the payload is IPv4 
or IPv6 using a protocol-specific bottom of stack label.

Of course, in the case of misconfiguration, the label pop might take place 
at some point other than the intended egress. In this case, the S bit might 
help prevent certain accidents, but I think it might help cause others!

In this respect, the S bit is maybe not heavily used (if at all). It would 
be really interesting to hear from implementers what use they make of the S 
bit in their implementations. Is it acted on, checked against, or ignored?

Notwithstanding all of this, the question seems to be whether there is a 
benefit (even if only a moral one!) in demarking client header encoding from 
server header encoding.

I wonder if the same question could be applied in MAC-in-MAC? Suppose a 
network provider uses Ethernet and, in part of the network applies 
MAC-in-MAC to traverse part of its network. Suppose further that the 
provider's customer operates an Ethernet network itself; it wants to carry 
its Ethernet traffic over the provider network. *If* the provider used 
MAC-in-MAC to carry the customers traffic, would there be any distinction 
between customer and provider headers in the stack?

(Oh, I could have used IP-in-IP as an example here as well.)

Thanks,
Adrian

---

From: <[email-masked]>
Date: Fri, 28 Aug 2009 13:46:17 +0100

Thanks Maarten...but what I stated still stands as technically accurate,
no PID = 1 client per server connection instance...you are talking about
implementation and bad config issues.   regards, Neil

> Sent: 28 August 2009 01:57
> To: Harrison,N,Neil,DEY2 R; [email-masked]; [email-masked]
> Cc: [email-masked]
> [mailto:[email-masked]] On Behalf
> need to add a
> if we use 
> misconnectivity 
> > >>>>    server stack).  The server stack is entirely under 
> the control 
> > >>>> of the
> > >>>>    label, with the 'bottom of stack' bit set to '1', 
> defines the 
> > >>>> network
> > >>>>    network protocol stack (which may be an MPLS label 
> stack and 
> > >>>> payload)
> > >>>>    is carried over as a network layer transport 
> service over an 
> > >>>> MPLS-TP
> > >>>>    transport network.
> > >>>>

---

From: <[email-masked]>
Date: Fri, 28 Aug 2009 14:15:09 +0100

Hi Adrian,

Many thanks for these comments....wrt to your last one on MACinMAC (or indeed IPinIP) this is most definitely a true client/server relationship.

QinQ is NOT a client/server relationship however.....this is all a single Ethernet layer network (if it helps think 'single address space of access points').  So the concerns here are not simply 'scalability' limits (as some folks often say, eg VLAN code-space) but there are other issues, like security concerns, when trying to operate a single layer network across multiple different parties.  And IMO strong opinion this is a very good reason to seek out good client/server solutions.....one should be very circumspect and think very carefully about entering into peering relationships, especially if we are considering a network mode/technology that is not top-of-stack, ie does not support external message/file/stream applications.

Stacked LSPs in MPLS are NOT like Ethernet QinQ however.  MPLS uses a digital wrapper technique and *adds/removes* headers.  So whilst this is not a true client/server relationship it is most definitely a (vertical) sublayering  hierarchy...QinQ is not like this at all (obvious I think).

Aside=> MPLS is not a top of stack network (IP of course is).  But we could make it so by extending it to end systems to directly support external message/file/stream applications.  And if one ran a cl-ps (IP) and co-ps (MPLS-TP) pair of core parallel networks where an external application could choose the transport mode there are some rather amazing simplifications to the thorny QoS (urgency) and Importance (survivability priority) problems that drop out of this....it can also address the other thorny problem for operators of arbitrage.  I'm happy to explain this idea further if anyone is interested, but I am only mentioning it here 'in passing' to try and make folks think a little outside the box.

So, returning to the main theme,.....if we want to see MPLS-TP become a truly successful transport network the one thing we really do need to solve elegantly/efficiently is an MPLS-TPoverMPLS-TP client/server relationship.  This will allow operating party X to 'lease' server capacity off operating party Y without any concerns (such a security) that one gets when trying to force a same-layer peering relationship.

I've given my/one view on what I think would be a good approach here (ie use a reserved label so that folks can keep the 'normal' S bit sublayering concept *within* a single MPLS network)......but the key point we need to address as a community is what is the best way to effect this important MPLSoverMPLS client/server relationship.  I am confident it will pay dividends if we get it right.

regards, Neil

> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 28 August 2009 12:26
> To: LEVRAU, LIEVEN (LIEVEN)
> Cc: [email-masked]

---

From: Lou Berger <[email-masked]>
Date: Fri, 28 Aug 2009 10:07:27 -0400

Adrian,
	See below...

> Guessing Lou's answer :-)

Always a risky proposition ;-)

>> Lou, I don't understand your last sentence, would you mind to elaborate?

I'm not sure which part of the sentence you are referring to.  If you're
asking about 'in the TE context' then what I was refering to is that in
some non-TE, LDP controlled, LSP cases there is an expectation that once
you hit the bottom of the stack you may want to forward based on the
network layer headers (i.e., IP).  Of course this doesn't work in many
cases (VPNs, PWs, etc).  I think the S bit provides value here, although
the use of reserved labels here is also important...

> In TE, the LSPs are very definite. They are specifically and
> "statically" provisioned either by the management plane or the control
> plane. Therefore, the instructions in the LFIB will inform the processor
> of exactly what to do when it pops a label in terms of looking at the
> next label (equivalent to S=0) or forwarding the payload (equivalent to
> S=1).
> 

agree,

> Certainly, if there are ECMP or DPI excuses within the network, the S
> bit can be handy.

ECMP on TE LSPs, do you really mean this?  DPI is another discussion,
but there are technologies out there that don't need the S bit...

> 
> Another consideration (that Neil's solution circumvents) is what to do
> is an LSP carries more than one payload, and one of the payloads is MPLS
> from within the same network. In that case, on label pop we might find
> (e.g.) IP or MPLS. The MPLS would be indicated by S=0, the IP by S=1.

Neil said he's use 1 in both cases, not sure where you're going here
though..,.

> 
> That said, RFC3032 provided a provision to identify that the payload is
> IPv4 or IPv6 using a protocol-specific bottom of stack label.
> 

right and the S bit really provides no value here!

> Of course, in the case of misconfiguration, the label pop might take
> place at some point other than the intended egress. In this case, the S
> bit might help prevent certain accidents, but I think it might help
> cause others!
> 
> In this respect, the S bit is maybe not heavily used (if at all). It
> would be really interesting to hear from implementers what use they make
> of the S bit in their implementations. Is it acted on, checked against,
> or ignored?
> 
> 
> benefit (even if only a moral one!) in demarking client header encoding
> from server header encoding.
> 

I think there is a real benefit to such demarcation (whether 1 or n bits
long) in the missconnection case as it allows the transport network to
identify when it has run off the transport's label stack unexpectedly
(and drop packets, due to either OAM information or insufficient label
stack depth).

Lou

> provider's customer operates an Ethernet network itself; it wants to
> carry its Ethernet traffic over the provider network. *If* the provider
> used MAC-in-MAC to carry the customers traffic, would there be any
> distinction between customer and provider headers in the stack?
>

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 28 Aug 2009 10:34:45 -0400

Adrian and Lou,

[SNIP]

IB=> What you are saying here is that if an LSR receives a labeled packet and it finds a valid entry in its ILM for this label instructing to pop the label, but the label happens to have S-bit set to 1, the LSR will not forward the packet, rather discard it and possibly notify MP.

But this sounds like a very unlikely and in any case ridiculously tiny fraction of what could happen in case of a missconnection. It does not really justify setting and honoring S-bit. So, I am still struggling to understand as to why do we need it.

Igor

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 28 Aug 2009 10:41:34 -0400

Sorry, in the example I described I meant to say "pop & swap" instead of "pop"

Igor

Adrian and Lou,

[SNIP]

> would be really interesting to hear from implementers what use they 
> make of the S bit in their implementations. Is it acted on, checked 
> against, or ignored?
> 
> 
> Notwithstanding all of this, the question seems to be whether there is 
> a benefit (even if only a moral one!) in demarking client header 
> encoding from server header encoding.
> 

I think there is a real benefit to such demarcation (whether 1 or n bits
long) in the missconnection case as it allows the transport network to identify when it has run off the transport's label stack unexpectedly (and drop packets, due to either OAM information or insufficient label stack depth).

Igor

Lou

> I wonder if the same question could be applied in MAC-in-MAC? Suppose 
> a network provider uses Ethernet and, in part of the network applies 
> carry its Ethernet traffic over the provider network. *If* the 
> provider used MAC-in-MAC to carry the customers traffic, would there 
> be any distinction between customer and provider headers in the stack?
>

---

From: "David Allan" <[email-masked]>
Date: Fri, 28 Aug 2009 10:42:55 -0400

HI Igor et.al.

Is it agreed that something that indicates start of payload is
required...be it S bit or reserved label value....

Else if you have reserved labels, then the stack depth cannot be known
apriori for all frames. Some packets may have reserved label
functions...

Cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Igor Bryskin
Sent: Friday, August 28, 2009 10:35 AM
To: Lou Berger; Adrian Farrel
Cc: [email-masked]
Subject: Re: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]

Adrian and Lou,

[SNIP]

IB=> What you are saying here is that if an LSR receives a labeled
packet and it finds a valid entry in its ILM for this label instructing
to pop the label, but the label happens to have S-bit set to 1, the LSR
will not forward the packet, rather discard it and possibly notify MP.

But this sounds like a very unlikely and in any case ridiculously tiny
fraction of what could happen in case of a missconnection. It does not
really justify setting and honoring S-bit. So, I am still struggling to
understand as to why do we need it.

Igor

Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 28 Aug 2009 10:47:52 -0400

Sure. This is one of the uses of an in-packet layer boundary identifier.
 This is true for both a 1 bit (S bit) or n bit (reserved label) identifier.

Lou

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 28 Aug 2009 10:56:04 -0700

Hi Maarten,

How about IP and MPLS pay load? Are you proposing to carry them in MPLS-TP using PW?

Thanks,
Shahram

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Friday, August 28, 2009 1:05 AM
To: 'LEVRAU, LIEVEN (LIEVEN)'; 'Lou Berger'; Shahram Davari
Cc: [email-masked]
Subject: RE: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]

Lieven,

Regards,
Maarten

-----Original Message-----
From: LEVRAU, LIEVEN (LIEVEN) [mailto:[email-masked]]
Sent: vrijdag 28 augustus 2009 8:51
To: Maarten Vissers; 'Lou Berger'; 'Shahram Davari'
Cc: [email-masked]
Subject: RE: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]

Hi Maarten

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

Regards,
Maarten

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

Shahram,

Lou

S=1.
>> Behalf Of Lou Berger

---

From: Yong Lucy <[email-masked]>
Date: Fri, 28 Aug 2009 14:22:42 -0500

IMO: one label stack can apply to several layers in the extended MPLS. The
bottom label in the label stack also means the bottom label for the layer,
but the reverse logic is not true. 1 bit (S bit) should be used as
indication of the bottom label of a layer, which applies to the bottom label
in the stack as well (backward complaint). Reserved labels need to be used
for encoding protocol types (MPLS-TP PW, IP, MPLS, etc). If the bottom label
has MPLS-TP PW indication, the label value gives MPLS-TP PW ID for egress to
use. If the bottom label has IP or MPLS protocol indication, egress pulls
out the server label from the label stack and send the packet to the right
protocol processors based on the protocol indication in the service label.

Regards,
Lucy

> Sent: Friday, August 28, 2009 9:48 AM
> To: Igor Bryskin
> Cc: [email-masked]
> identify when it has run off the transport's label stack unexpectedly (and
> drop packets, due to either OAM information or insufficient label stack
> depth).
> >
> packet and it finds a valid entry in its ILM for this label instructing to
> pop the label, but the label happens to have S-bit set to 1, the LSR will
> not forward the packet, rather discard it and possibly notify MP.
> >

---

From: Igor Bryskin <[email-masked]>
Date: Sat, 29 Aug 2009 11:50:48 -0400

Thanks Dave.

I am not an MPLS DP specialist, but the way I see it, from the point of view of an MPLS LSR, processing a received labeled packet, the packet's payload starts immediately after the outer label (that is to say that the rest of the label stack and actual payload are equally opaque). So I struggle to see how the LSR can benefit from the S-bit.

The only useful thing about the S-bit in my mind is that when a human or automated tool investigates a miss-connection problem S-bits can outline the intended set of layers of, say, dropped packet and, thus, help the investigation.

Now, if you think about MPLS-TP as a traffic engineered transport for the MPLS Service layer, and, especially if you are stacking MPLS-TP layers, then I largely agree with Neil (if, of course, I understood him correctly) when he is saying that properly defined transport co-ps layer does not require more that one label per layer (whether we are talking about MPLS-TP or PBB-TE).

So, IMO there should be exactly one label per MPLS-TP layer, and it should be possible to stack an arbitrary number of MPLS-TP layers. Obviously whether S- bit is set or not is immaterial in this case.

Cheers and have a great weekend.
Igor     

-----Original Message-----
From: David Allan [mailto:[email-masked]] 
Sent: Friday, August 28, 2009 10:43 AM
To: Igor Bryskin; Lou Berger; Adrian Farrel
Cc: [email-masked]
Subject: RE: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]

HI Igor et.al.

Cheers
Dave

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

Adrian and Lou,

[SNIP]

Igor

Lou

---

From: "David Allan" <[email-masked]>
Date: Sat, 29 Aug 2009 12:58:23 -0400

HI Igor:

Replies in line...

> I am not an MPLS DP specialist, but the way I see it, from the point
of view of an MPLS LSR, processing a received 
> labeled packet, the packet's payload starts immediately after the
outer label (that is to say that the rest of the label 
> stack and actual payload are equally opaque). So I struggle to see how
the LSR can benefit from the S-bit.

A counter example, presence of the GAL nested beneath the outer label.
The forwarding process at the egress LSR would need to know that what
followed the last forwarding label was other than payload in order to
recognize the presence of an OAM PDU. 

> The only useful thing about the S-bit in my mind is that when a human
or automated tool investigates a miss-connection 
> problem S-bits can outline the intended set of layers of, say, dropped
packet and, thus, help the investigation.

> Now, if you think about MPLS-TP as a traffic engineered transport for
the MPLS Service layer, and, especially if you are > stacking MPLS-TP
layers, then I largely agree with Neil (if, of course, I understood him
correctly) when he is saying 
> that properly defined transport co-ps layer does not require more that
one label per layer (whether we are talking about > MPLS-TP or PBB-TE).

If you had a PID rather than using labels to infer payload type that
would be true (and we would not need a GAL). Else (for example) IP/MPLS
as a MPLS_TP client would need two LSPs between end points to correctly
disambiguate that the payload was IP or was MPLS. Rather than install
state, OAM & instrumentation etc. for two exactly symmetric and
contiguous LSPs, I'd be inclined to wrap them in a common label but it
means the stack for the LSP for all practical purposes is 2 deep at the
termination. IP/MPLS being the interesting example where protocol
multiplexing is the common case, and less the exception. I also agree
with Neil that in the general case of a single payload type, both
fowarding and payload should be inferrable from a common layer. But
there are still other reasons for needing a start of payload indicator,
primarily the aforementioned presence of a GAL/ACH as an OAM/ channel
associated signalling path, or for DCN purposes...

> So, IMO there should be exactly one label per MPLS-TP layer, and it
should be possible to stack an arbitrary number of 
> MPLS-TP layers. Obviously whether S- bit is set or not is immaterial
in this case.

IMO PIDs and reserved functions distort that view as I hope the
preceeding discussion illustrates...

> cheers and have a great weekend.

Yourself as well

Best
D     

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: Friday, August 28, 2009 10:43 AM
To: Igor Bryskin; Lou Berger; Adrian Farrel
Cc: [email-masked]
Subject: RE: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]

HI Igor et.al.

Cheers
Dave

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

Adrian and Lou,

[SNIP]

Igor

Lou

---

From: <[email-masked]>
Date: Sat, 29 Aug 2009 20:48:33 +0100

Thanks Igor...spot-on wrt analysis and why I arrive at the conclusions I
do.

In strict arch terms the S bit (0 until 1) means 'sublayer within same
layer network'....this is the nature of the digital wrapper design of
the original MPLS arch.   It holds the tantalising falsehood that 'we
can create server layer topology at will - just add a new header', but
if we ignore this illusion, then under defect-free conditions we can
assign arbitrary semantics to a label and create some very useful
behaviours/services.  Indeed we have to do this in MPLS, given the
sparse nature of the MPLS header, ie the label field is really all we
have to assign semantics to.

But we should be careful.  Varying DP label semantics (ie non-consistent
DP Charac Info) is OK as long as the OAM associated with each level of
LSP is consistent...obviously, as this means consistent defect handling
under any case of misconnectivity.....a rather important point if one is
an operator, and esp one wearing an Operational hat.

In a transport network role (ie "I build the topology of other layer
networks, and I am for sure not a top-of-stack layer network myself")
then it is not so clear that the S bit (ie sublayering) is that
useful....at least as unbounded stacking with varying label semantics.

My personal view is that I would not have the S bit (nor indeed TTL...a
rather more painfully obvious unnecessary function) in a proper co
transport network.  Each LSP should be a layer network in its own right.
GMPLS folks have had to deal with this (and no TTL) for the co-cs mode,
so why is it not also true for the co-ps mode? (it is true, I am asking
a rhetorical question, just to make an important point).

But since I can really (and honestly) understand why MPLS-TP in a
transport role can cause a bit of shock then I am happy to see some
compromises here.  Keep the TTL...even if it is unnecessary.  Keep the S
bit sublayering....but recognise it for what it is.  But PLEASE don't
promulgate the error of creating an unnecessary PW layer network above
MPLS-TP....that scuppers any claim for MPLS-TP to be a transport
network...we might as well say the PW layer network is also a transport
network!

The main reason I suggested a special label for the MPLS(TP)overMPLS(TP)
case was to allow sublayering to continue to exist with at least what I
thought was the original constraint on this, ie S=1 was only allowed to
appear once to mark the end of any MPLS sublayer headers, ie no MPLS
headers follow.  If this is not true (ie S=1 can have MPLS headers that
follow, that are not sublayers), then I question the value of the S bit
at all in MPLS....just what does S=1 signify?  

And as I have already observed, in a transport role each LSP should be
its own layer network anyway, ie no MPLS sublayering means S = Don't
Care.  However, I can see that the S bit might be a jolly useful 'OAM
indicate' flag instead ;-)...and very seriously guys, we should NOT be
putting DP OAM under a reserved label (the GAL=13) that is primarily
there to allow us to create an OOB CP/MP channel between MPLS-TP
nodes....that is not good arch design I am afraid.  I know this is what
many are intending, but it's really not good design practice.  Please
reflect on this.

The other reason I wanted to use a reserved label for marking a
functional DP/CP/MP break between different MPLS layer network stacks
was that so I (as an operator) have a much stronger isolation wrt
detecting/handling any misconnectivity defects.  It's one thing having
these in one's own MPLS LSP stack but to have these between the LSPs
stacks of different operating parties is not a great idea IMO.  A
well-known global label should help significantly in this respect.

regards, Neil

> [mailto:[email-masked]] On Behalf Of Igor Bryskin
> Sent: 29 August 2009 16:51
> To: David Allan; Lou Berger; Adrian Farrel
> Cc: [email-masked]
> I am not an MPLS DP specialist, but the way I see it, from 
> the point of view of an MPLS LSR, processing a received 
> labeled packet, the packet's payload starts immediately after 
> the outer label (that is to say that the rest of the label 
> stack and actual payload are equally opaque). So I struggle 
> to see how the LSR can benefit from the S-bit.
> 
> The only useful thing about the S-bit in my mind is that when 
> a human or automated tool investigates a miss-connection 
> problem S-bits can outline the intended set of layers of, 
> say, dropped packet and, thus, help the investigation.
> 
> Now, if you think about MPLS-TP as a traffic engineered 
> transport for the MPLS Service layer, and, especially if you 
> are stacking MPLS-TP layers, then I largely agree with Neil 
> (if, of course, I understood him correctly) when he is saying 
> that properly defined transport co-ps layer does not require 
> more that one label per layer (whether we are talking about 
> MPLS-TP or PBB-TE).
> 
> So, IMO there should be exactly one label per MPLS-TP layer, 
> and it should be possible to stack an arbitrary number of 
> MPLS-TP layers. Obviously whether S- bit is set or not is 
> immaterial in this case.
>

---

From: <[email-masked]>
Date: Sat, 29 Aug 2009 21:21:40 +0100

> recognize the presence of an OAM PDU. 

NH=> I think is very bad arch/design practice not to have clear
isolation between DP and CP/MP protocols/functions in any co mode
network.  Good arch/design practice is forced when dealing with the
co-cs mode (ie GMPLS respects this, but then it has no choice!), and we
should strive to re-use that good arch/design practice with the co-ps
mode.......can someone please give me a good technical reason not to?  

In the case of MPLS-TP the GAL SHOULD only be used to identify that
CP/MP protocols follow.....*DP* protocols, which is what OAM is, should
never reside under the GAL. 

Being slightly architecturally brutal here (if only to make a point), we
are wasting 8 bits (25%) of precious MPLS overhead on a TTL function
that is totally unnecessary in a co-ps mode network.  I could add the S
bit if I was being very uncharitable...that is also not required in a
transport network.  And finally, I could also observe that a connection
MUST only have a single QoS class (something that will really bite later
in its complexity implications, eg entry/exit of unavailable state, if
not understood now in the design phase).  So I am staring at 12 bits of
precious overhead that are going to be 'compromised' at best...and we
can't find a single bit to provide the much needed operational 'OAM
indicate' function here?!?!  This is not great design folks (ie one we
can be proud of) no matter how one looks at it.

> say, dropped
> transport for
> would be true (and we would not need a GAL).

NH=> Understood.  However, we strictly only need a PID function in a co
mode network (it is always needed in a cl-ps mode network) if we mux
more than a single/same client type into the (parent) connection.

As noted in an earlier mail tonight and above, we really should restrict
the GAL (reserved label 13) to CP/MP protocols.  To carry DP OAM under
this is just very bad (expedient?) design IMO. 

regards, Neil 

> Else (for 
> example) IP/MPLS