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

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 25 Aug 2009 23:20:40 +0100

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

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 25 Aug 2009 15:39:38 -0700

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.
> 
> 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 
> [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
>

---

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 25 Aug 2009 15:45:27 -0700

Hi Arian and John,

Please see inline:

> section 3.4.1 of the overview I-D.

Agreed.

> can be part of a network layer payload.  Section 3.4.1 explicitly states

Agreed.

> start with a client MPLS stack.

Agreed.

rahul

---

From: Mach Chen <[email-masked]>
Date: Wed, 26 Aug 2009 11:36:28 +0800

Hi,

Tow questions(maybe naive):

1. For MPLS over MPLS, if this is the case that there could be separate 
label stack for each "layer", does it apply to VPN, VPLS, PW...?( Tunnel 
label stack and service label stack).

2. If there are two label stacks, after processing one stack, how does a 
device know that there is another stack exist? Does it mean that the bottom 
label of last stack should have some implicit meaning or be a spcial reserve 
label?

Best regards,
Mach Chen

--------------------------------------------------
From: "Rahul Aggarwal" <[email-masked]>
Sent: Wednesday, August 26, 2009 6:45 AM
To: "Drake, John E" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [mpls-tp] That S-bit discussion (again)

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 26 Aug 2009 08:39:27 +0300

Adrian,

I agree with your reading of 3032: a label stack is something that ends with n S-bit set to 1.

I would also like to note  that Section 2.2 of the RFC explains which rules must be followed so hat the network layer (a.k.a. payload) protocol can be determined. The PWE3 requirement for the PW label being allocated from the per-platform label space is one obvious application of these rules IMO.

However, the having two label stacks in the same packet looks problematic to me, because the context of labels in the 2nd stack may be not clear. (If the two stacks share the same label space on a given router, the meaning of splitting the stack is not clear to me.)

As is duly noted in Section 3 of 5331, 3031 defines two label contexts for downstream label allocation: per-platform and per-interface. It also explains (in full agreement with the text of Section 3.14 of 3031) that applicability of the latter is limited to the top label of the stack received from a point-to-point interface between a pair of adjacent routers.

Section 7 of 5331 discusses the situations when the label context for the next label can be inferred from the incoming MPLS tunnel in which the problematic label has been received. In order to apply these consideration to MPLS-TP, we should, IMO, answer the following questions (not necessarily in the order of importance):

 1.  Which link types can be used in MPLS-TP: is it going to be restricted to P2P links, or does it also support LAN links? In other words, is it acceptable to connect several LSRs to a single Ethernet bridge that would provide LAN-like connectivity between all of them? So far, I've only seen some comments that "there is no such intention", but this is not enough IMO
 2.  What is the context of MPLS-TP labels? My gut feeling is that neither per-interface nor per-platform label space is really applicable even for P2P LSPs in MPLS-TP because these spaces are specific to the downstream label allocation scheme, and MPLS-TP MUST support label allocation by the MP. I see three possible options to resolve this issue:
    *   MP of MPLS-TP can be restricted to use the downstream label allocation scheme for P2P LSPs. This approach:
       *   Must be explicitly defined in the MPLS-TP management drafts
       *   May result in poor performance (as the OSS would have to request label allocation from the downstream router)
    *   MPLS-TP can use the upstream label allocation scheme for all kinds of LSPs.
       *   The 3rd para in Section 3 of 5332 suggests this approach
       *   Its implications require careful analysis. (AFAIK, 5331 and 5332 have been rarely referenced in the MPLS-TP discussions)
    *   MPLS-TP can define its own label context. This should bring us back to square 1 (allocate a dedicated Ethertype for MPLS-TP etc.).
 3.  How many label spaces within the MPLS-TP context must be supported by a TP-capable LSR, and how these label spaces (within whatever context MPLS-TP is going to use) could be identified? IMO this has direct impact on implementations. (If tunnels define label spaces within the MPLS-TP context, the number of these spaces would be potentially unlimited...).

IMHO and FWIW, we have not addressed these issues so far, but I do not understand how MPLS-TP can evolve into a viable technology without addressing them in a straightforward manner. I also think that "classic" GMPLS (controlling non-packet networks) did not have to handle these issues because its "labels" (lambdas or timeslots) come from a very special (physical) space. But this is not the case with MPLS-TP.

My 2c,

     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Adrian Farrel [[email-masked]]
Sent: Wednesday, August 26, 2009 1:20 AM
To: [email-masked]
Subject: [mpls-tp] That S-bit discussion (again)

      1. Bottom of Stack (S)

Opinions?

Cheers,
Adrian

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 26 Aug 2009 09:27:02 +0200

Mach,

Can you clarify what your thoughts are when you wrote your second
question... The reason I ask this is that from a transport network's (data
plane) perspective the activated/configured funcitonality on the interface
ports in the network elements determine each processing step to be
performed. If the incoming signal does not have the expected frame/signal
format, then one of the functions will detect a mismatch, generates an alarm
and stops forwarding the packets of this signal.

>From this transport network processing perspective, it does not matter if
the stack of Label Stack Entry (LSE) headers includes only one or more then
one LSE header with its S-bit set to 1. From this transport network
processing perspective it does not matter even how each LSE header is called
(i.e. PW, LSP, other...) and/or if it is used as a multiplex identifier or
as a MEG level identifier. The data plane fucntions in the interface ports
also do not care what considerations the management/control plane used to
choose a value for the 20-bit label field in a LSE header.

The functions in an input port just peels of the "layers of the union" in a
one for one case and processes the remaining information as dictated by the
current function (e.g. a tunnel MEP function, a tunnel demultiplexer
function, a service segment MEP function, etc).

If it is decided to set S=1 in an LSE header that carries a multiplex
identifier, and set S=0 in LSE headers that carry a sublayer/MEG level
identifier, then there is additional information present in the LSE headers
that can be used to verify if the frame/signal format received at the input
of a function on e.g. an input port is correct.

E.g. If there would be 3 layers (X,Y,Z) active in a MPLS-TP network, and
layer X signals carry clients, layer Y signals carry a multiplex of layer X
signals and layer Z signals carry a multiplex of layer Y signals, then we
can have the following stack of LSE headers on the wire:

- zero or more Z-LSE headers with S=0 (sublayer/MEG level)
- one Z/Y-LSE header with S=1 (with Y multiplex identifier)
- zero or more Y-LSE headers with S=0 (sublayer/MEG level)
- one Y/X-LSE header with S=1 (with X multiplex identifier)
- zero or more X-LSE headers with S=0 (sublayer/MEG level)

If the X layer signals can carry a bundle of client layer signals, then
these client layer signals may be identified by a client specific identifier
(e.g. VLAN ID). Alternatively those client layer signals may be identified
by a server (i.e. MPLS-TP) specific identifier (i.e. 20-bit label in the LSE
header). If this latter is selected, then there will be 

- one X/client-LSE header with S=1 (client multiplex identifier)

more in the LSE header stack (at the bottom).

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mach Chen
Sent: woensdag 26 augustus 2009 5:36
To: Rahul Aggarwal; Drake, John E; Adrian Farrel
Cc: [email-masked]
Subject: Re: [mpls-tp] That S-bit discussion (again)

Hi,

Best regards,
Mach Chen

>> 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.
>>
>
> Agreed.
>
>> 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.
>>
>
> Agreed.
>
> rahul
>
>> Thanks,
>>
>> John
>>
>> > 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.
>> >
>> > 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: Mach Chen <[email-masked]>
Date: Wed, 26 Aug 2009 18:22:23 +0800

Hi Maarten,

Thanks for your detailed explanation!

In the current MPLS forwarding implement, after processing the bottom label, 
there MUST be an indication(an item in the LFIB indexed by the bottom label 
and the item should inlcude such an indication, or using a dedicated reserve 
label) for directing on how to process next step(e.g., IP forwarding, 
MAC-based forwarding or other process). With this multiple stacks case, 
seems that there also should be an indication (no matter using the 
indication in the LFIB or a dedicated reserve label) for the same purpose.

In your example, in my understanding, the indication is actually included 
implicitly in the bottom label of a stack and there should an item in the 
LFIB related to the label.

Best regards,
Mach

--------------------------------------------------
From: "Maarten Vissers" <[email-masked]>
Sent: Wednesday, August 26, 2009 3:27 PM
To: "'Mach Chen'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [mpls-tp] That S-bit discussion (again)

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 26 Aug 2009 13:35:47 +0100

Mach Chen wrote:
> 1. For MPLS over MPLS, if this is the case that there could be 
> separate label stack for each "layer", does it apply to VPN, VPLS, 
> PW...?( Tunnel label stack and service label stack).
For these cases the existing RFCs define that there will be a single
S=1bit for this group of labels.

>
> 2. If there are two label stacks, after processing one stack, how does 
> a device know that there is another stack exist? Does it mean that the 
> bottom label of last stack should have some implicit meaning or be a 
> spcial reserve label?
Remember that in MPLS each label provides the context
for processing what follows. Thus the lowest label
in the outer stack would reference context that indicated
that an MPLS label stack followed. This is normal
MPLS label semantics.

Whilst one could make this a reserved label, that
would loose much of the generality of MPLS, since
there may be some other characteristic of the
of the nested label stack that we may wish to
indicate.

- Stewart

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 26 Aug 2009 14:43:36 +0200

If it would be decided to set the S-bit to 1 in the Z/Y-LSE, Y/X-LSE and
possibly the X/client-LSE headers, then it will be possible that the Z/Y
adaptation sink, Y/X adaptation sink and X/client adaptation sink functions
check for the presence of a top LSE Header with S=1. 

If such demultiplexing adaptation sink function receives a packet with S=0,
this will indicate that there is a sublayer/OAM endpoint missing; i.e. some
of the segment OAM is not terminated. There are now two options:

1) the demultiplexing adaptation sink function discards all packets (OAM and
data) with a top LSE header carrying S=0

2) the demultiplexing adaptation sink function can now trow away the
non-terminated segment OAM, but forward the actual data (i.e. same as is
done today with Ethernet OAM). To forward the data, the adaptation sink
function will have to strip of the LSE headers with S=0 that are on top of
the first LSE header with S=1. 

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: woensdag 26 augustus 2009 9:27
To: 'Mach Chen'
Cc: [email-masked]
Subject: Re: [mpls-tp] That S-bit discussion (again)

Mach,

Regards,
Maarten

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

Hi,

Best regards,
Mach Chen