Subject: Re: [mpls-tp] If a PW is a sublayer, why is it different?

From: Igor Bryskin <[email-masked]>
Date: Mon, 2 Nov 2009 12:13:46 -0500

Hi,

I believe there is a fundamental difference between PW label and MPLS-TP label. When an LSR forwards a labeled packet, it does not just swap labels. It performs a lot of operations: takes the packet from an incoming queue, puts it to an outgoing queue, schedules the packet for delivery, drops the packet sometimes, etc.

MPLS-TP label is a (G)MPLS RSVP-TE label, which is a label of a traffic engineered LSP. It defines concrete network resources (i.e. number of buffers) reserved for the LSP. On the other hand PW label is an LDP label with no particular associated network resources (because PWs are not concerned with the traffic engineering).

I believe there is a fundamental difference in the ways S-PW LSRs and P LSRs switch labeled packets, and this is one important reason why MPLS-TP and PW should be completely different layers.

Cheers,
Igor 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, October 28, 2009 7:53 PM
To: Luca Martini
Cc: [email-masked]
Subject: Re: [mpls-tp] If a PW is a sublayer, why is it different?

Luca,

Perhaps I didn't explain my question clearly enough.

In the data plane of an MPLS-TP network (so it is all one server type - 
MPLS-TP), is there any difference in behavior in an S-PE and P node when 
switching packets?

Let me draw a network...

A==B==C***D***E

Consider that I build two LSP tunnels ABC and CDE.
Now suppose I want an LSP (note: not a PW) form A to E. It runs ACE using 
the two tunnels.
At C, when a packet is received, the top label is popped (end of LSP ABC) 
and the exposed label is used for forwarding. Then a new label is imposed 
(LSP CDE) before the packet is sent onward.

Now, let me draw another network.

A==B==C***D***E

Consider that I build two LSP tunnels ABC and CDE.
Now suppose I want a PW (note: not an LSP) form A to E. It runs ACE using 
the two tunnels.
At C, when a packet is received, the top label is popped (end of LSP ABC) 
and the exposed label is used for forwarding. Then a new label is imposed 
(LSP CDE) before the packet is sent onward.

In the first case, node C is a P-node.
In the second case, node C is an S-PE.
There is nothing that precludes or requires node C to be on any domain 
boundary.

What is the difference in the data plane between node C in the first case 
and node C in the second case?

It is important (to me) to limit this question to the data plane. I don't 
care how the LSPs or PWs are set up or what service they are delivering.

Thanks,
Adrian

----- Original Message ----- 
From: "Luca Martini" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 28, 2009 10:31 PM
Subject: Re: [mpls-tp] If a PW is a sublayer, why is it different?

> Hi Adrian,
>
> An S-PE is very different. A P node has no knowledge of what is in the PW, 
> what specific parameters are incompatible with the 2 PWs. block or fake PW 
> OAM, etc...
> An S-PE is an administrative , and control point for the MS-PW. While a P 
> Router switches all LSP the same , and does not even have to be a MIP.
> Also an S-PE can connect PWs running on completely different server 
> networks, without any interworking function at the network layer.
>
> Luca
>
>
>
> Adrian Farrel wrote:
>> So trying to take this a step further...
>>
>> If a PW is "just a label" making it "just a sub-layer" why do we insist 
>> that it is in any way different within the network?
>>
>> How is an S-PE that switches PW segments any different from a P-node that 
>> switches LSP segments? True, the S-PE must terminate the LSP tunnel (pop 
>> a label) before finding the PW label on which to switch. But this same 
>> function could apply at a P-node that is switching an LSP that was 
>> carried in a tunnel.
>>
>
>> If this is the case, shouldn't we *include* PWs in the Survivability 
>> Framework:
>> - as automatically the same as LSPs
>> - with some examples to show how the function if achieved.
>>
>> To repeat: How are PWs any different within the network.
>>
>
>> [In answering, please recall that we are talking about MPLS-TP networks 
>> only.]
>>
>> Thanks,
>> Adrian
>>
>> ----- Original Message ----- From: "David Allan I" 
>> <[email-masked]>
>> To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>; 
>> <[email-masked]>
>> Sent: Wednesday, October 28, 2009 4:41 PM
>> Subject: Re: [mpls-tp] Is PW a layer of MPLS-TP
>>
>>
>>> Hi Nurit:
>>>
>>> I think you misunderstand me. My comment on whether we supported clients 
>>> besides PWs was to illustrate second order consequences, not to suggest 
>>> that OAM was wagging the dog or was involved in delineation of layers 
>>> and sublayers...
>>>
>>> IMO all labels between the link layer preamble and the label with the S- 
>>> bit set are either reserved functions or sub-layers of the MPLS-TP 
>>> "layer", "sub-layers" AND reserved labels being what was known as 
>>> "levels" in RFC 3031. All sub layers have the potential to be switched 
>>> including the PW sub-layer, ergo a PW is a sub-layer of MPLS-TP...
>>>
>>> I hope I'm clear...
>>>
>>> Cheers
>>> D
>>>
>>> -----Original Message-----
>>> From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
>>> [mailto:[email-masked]]
>>> Sent: Wednesday, October 28, 2009 12:27 PM
>>> To: David Allan I; [email-masked]
>>> Subject: RE: [mpls-tp] Is PW a layer of MPLS-TP
>>>
>>> Hi Dave,
>>> I am afraid again that relying on OAM to distinnguish between the 
>>> clients is a wrong approach.
>>> Best regadrs,
>>> Nurit
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of ext David Allan I
>>> Sent: Wednesday, October 28, 2009 6:02 PM
>>> To: [email-masked]
>>> Subject: [mpls-tp] Is PW a layer of MPLS-TP
>>>
>>> HI Adrian:
>>>
>>> IMO the S-bit is set in the PW label and clear in the encapsulating 
>>> sub-layers, hence it is a sub-layer in the G.805 sense of MPLS-TP.
>>>
>>> IMO it does confuse the landscape as OAM discrimination requires apriori 
>>> knowledge of the label type at bottom of stack IF we assume a BOS can be 
>>> other than a PW...
>>>
>>> My 2 cents
>>> D
>>>
>>> You wrote>>>>
>>>
>>> Hi,
>>>
>>> I am trying this question again with a different subject line.
>>>
>>>
>>> It would be helpful to have more answers than just Neil's (not that I 
>>> don't value his view, but one person doesn't make consensus!)
>>>
>>> My question:
>>>
>>> Hasn't the work on the MPLS-TP Framework draft judged PW to be a client 
>>> of MPLS-TP?
>>> That is, PW is not a layer of MPLS-TP, but the client.
>>>
>>> Doesn't that mean that PW survivability is out of scope for the MPLS-TP 
>>> Survivability I-D?
>>>
>>> Thanks,
>>> 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
>>>
>>
>> _______________________________________________
>> 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: Maarten Vissers <[email-masked]>
Date: Mon, 02 Nov 2009 21:04:50 +0100

Igor,

There is a requirement from operators to traffic engineer the service
instance transport entities, and use tunnel instance transport entities with
unspecified bandwidth. I.e. the tunnel bandwidth is the sum of the bandwidth
of the service isntances. If the PW can't be traffic engineered it can not
be used as service instance transport entity.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Igor Bryskin
Sent: maandag 2 november 2009 18:14
To: Adrian Farrel; Luca Martini
Cc: [email-masked]
Subject: Re: [mpls-tp] If a PW is a sublayer, why is it different?

Hi,

I believe there is a fundamental difference between PW label and MPLS-TP
label. When an LSR forwards a labeled packet, it does not just swap labels.
It performs a lot of operations: takes the packet from an incoming queue,
puts it to an outgoing queue, schedules the packet for delivery, drops the
packet sometimes, etc.

MPLS-TP label is a (G)MPLS RSVP-TE label, which is a label of a traffic
engineered LSP. It defines concrete network resources (i.e. number of
buffers) reserved for the LSP. On the other hand PW label is an LDP label
with no particular associated network resources (because PWs are not
concerned with the traffic engineering).

I believe there is a fundamental difference in the ways S-PW LSRs and P LSRs
switch labeled packets, and this is one important reason why MPLS-TP and PW
should be completely different layers.

Cheers,
Igor 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: Wednesday, October 28, 2009 7:53 PM
To: Luca Martini
Cc: [email-masked]
Subject: Re: [mpls-tp] If a PW is a sublayer, why is it different?

Luca,

Let me draw a network...

A==B==C***D***E

A==B==C***D***E

Thanks,
Adrian

----- Original Message -----
From: "Luca Martini" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 28, 2009 10:31 PM
Subject: Re: [mpls-tp] If a PW is a sublayer, why is it different?

> Hi Adrian,
>
> An S-PE is very different. A P node has no knowledge of what is in the 
> PW, what specific parameters are incompatible with the 2 PWs. block or 
> fake PW OAM, etc...
> An S-PE is an administrative , and control point for the MS-PW. While 
> a P Router switches all LSP the same , and does not even have to be a MIP.
>> If a PW is "just a label" making it "just a sub-layer" why do we 
>> insist that it is in any way different within the network?
>>
>> How is an S-PE that switches PW segments any different from a P-node 
>> that switches LSP segments? True, the S-PE must terminate the LSP 
>> tunnel (pop a label) before finding the PW label on which to switch. 
>> But this same function could apply at a P-node that is switching an 
>> LSP that was carried in a tunnel.
>>
>
>> [In answering, please recall that we are talking about MPLS-TP 
>> networks only.]
>>
>> Thanks,
>> Adrian
>>
>> To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" 
>> <[email-masked]>; <[email-masked]>
>>> I think you misunderstand me. My comment on whether we supported 
>>> clients besides PWs was to illustrate second order consequences, not 
>>> to suggest that OAM was wagging the dog or was involved in 
>>> delineation of layers and sublayers...
>>>
>>> IMO all labels between the link layer preamble and the label with 
>>> the S- bit set are either reserved functions or sub-layers of the 
>>> MPLS-TP "layer", "sub-layers" AND reserved labels being what was 
>>> known as "levels" in RFC 3031. All sub layers have the potential to 
>>> be switched including the PW sub-layer, ergo a PW is a sub-layer of
MPLS-TP...
>>> IMO it does confuse the landscape as OAM discrimination requires 
>>> apriori knowledge of the label type at bottom of stack IF we assume 
>>> a BOS can be other than a PW...
>>>
>>> My 2 cents
>>> D
>>>
>>> You wrote>>>>
>>>
>>> Hi,
>>>
>>> It would be helpful to have more answers than just Neil's (not that 
>>> I don't value his view, but one person doesn't make consensus!)
>>>
>>> My question:
>>>
>>> Hasn't the work on the MPLS-TP Framework draft judged PW to be a 
>>> client of MPLS-TP?
>>> Doesn't that mean that PW survivability is out of scope for the 
>>> MPLS-TP Survivability I-D?
>>>
>>> Thanks,
>>> Adrian

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 2 Nov 2009 22:06:21 +0200

Igor, and all,
If the allocation of certain resources per label is THE criterion for distinguishing between PW and MPLS-TP labels, 
then I'd say they are one and the same. I am aware of multiple implementations that support
hierarchical scheduling towards each specific PW AC, with explicit specification of CIR and PIR, queue depth 
per class of service per PW instance. And these implementation select a TEed tunnel for the PW based
on its BW requirements.

The fact that this label is set by LDP and not by RSVP-TE looks to me like a weak argument in
the MPLS-TP context, where ability to operate without any control plane whatsoever is a mandatory
requirement.

My 2c,
     Sasha

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Igor Bryskin
> Sent: Monday, November 02, 2009 7:14 PM
> I believe there is a fundamental difference between PW label 
> and MPLS-TP label. When an LSR forwards a labeled packet, it 
> does not just swap labels. It performs a lot of operations: 
> takes the packet from an incoming queue, puts it to an 
> outgoing queue, schedules the packet for delivery, drops the 
> packet sometimes, etc.
> 
> MPLS-TP label is a (G)MPLS RSVP-TE label, which is a label of 
> a traffic engineered LSP. It defines concrete network 
> resources (i.e. number of buffers) reserved for the LSP. On 
> the other hand PW label is an LDP label with no particular 
> associated network resources (because PWs are not concerned 
> with the traffic engineering).
> 
> I believe there is a fundamental difference in the ways S-PW 
> LSRs and P LSRs switch labeled packets, and this is one 
> important reason why MPLS-TP and PW should be completely 
> different layers.
> 
> Cheers,
> Igor 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 2 Nov 2009 15:51:42 -0500

Maarten,

That is why you need two layers. The tunnels you create in the server (MPLS-TP) layer are traffic engineered; in particular, they reserve the summary bandwidth on all links, set up the necessary recovery schemes, etc. They are signaled with RSVP-TE (or any protocol with the TE capabilities) or set up via MP. Service instance transport entities are set up as tunnels in the client (PW) layer. They use tunnels set up in the MPLS-TP layer as links, are signaled via LDP or configured via MP.

Cheers,
Igor

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Monday, November 02, 2009 3:05 PM
To: Igor Bryskin; 'Adrian Farrel'; 'Luca Martini'
Cc: [email-masked]
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor,

Regards,
Maarten

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

Hi,

Cheers,
Igor 

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

Luca,

Let me draw a network...

A==B==C***D***E

A==B==C***D***E

Thanks,
Adrian

----- Original Message -----
From: "Luca Martini" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 28, 2009 10:31 PM
Subject: Re: [mpls-tp] If a PW is a sublayer, why is it different?

MPLS-TP...

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 2 Nov 2009 16:06:24 -0500

Sasha, see in-line.

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Monday, November 02, 2009 3:06 PM
To: Igor Bryskin
Cc: [email-masked]; Luca Martini; Adrian Farrel
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor, and all,

IB>> Correct. This is achieved by nesting PWs (usually signaled via LDP or BGP) within strategically placed TE tunnels (usually signaled via RSVP-TE)

the MPLS-TP context,

IB>> You need to signal the necessary end-to-end or segment path protection schemes, link protection requirements, bandwidth parameters, explicit paths, etc. RSVP-TE can do it, while LDP AFAIK cannot (and IMO shouldn't). So. the choice of the signaling protocol for a particular layer is important.

 where ability to operate without any control plane whatsoever is a mandatory
requirement.

IB>> Of course, provided that MP can configure all the things I mentioned above.

Cheers,
Igor

My 2c,
     Sasha

> [mailto:[email-masked]] On

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 2 Nov 2009 13:15:13 -0800

Adrian,

The two cases you mentioned are the same regarding ILM/NHLE forwarding. However, the PW OAM is different from MPLS-TP OAM since MPLS-TP OAM uses GAL and PW OM does not. 

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, October 28, 2009 4:53 PM
To: Luca Martini
Cc: [email-masked]
Subject: Re: [mpls-tp] If a PW is a sublayer, why is it different?

Luca,

Let me draw a network...

A==B==C***D***E

A==B==C***D***E

Thanks,
Adrian

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 3 Nov 2009 09:10:20 +0200

Igor,
I am probably repeating myself, but:

1. MPLS-TP MUST support static provisioning of transport paths via
    the management plane (RFC 5654, R-17). 
2. MPLS-TP MUST support the logical separation of the control and
     management planes from the data plane (RFC 5654, R-15).

Hence differentiation between the MPLS-TP and PW layers cannot, IMHO, be based
on any differences in the control plane - simply because the latter may be absent.

As for "nesting of PWs within strategically placed TE tunnels":

1. This can happen not just to PWs, but also to TE tunnels, right?
2. Per class of service per PW allocation of the data plane resources
    a) Exists in the field
    b) Is orthogonal to nesting in TE tunnels
    c) Is mandatory in order to meet the appropriate SLA.

The bottom line:

My reading of this email thread is that there is exactly one real difference between
MPLS-TP and PW: 

     The former MUST use GAL for its OAM functions, while the latter
     MUST NOT use it.  

And this difference exists only because the authors of RFC 5586
have been careful enough to explicitly prohibit using GAL with PWs; 
otherwise there would be no difference at all.

The following point IMHO illustrates the virtual nature of "layering" in MPLS-TP.

Assuming that FRR with facility protection is allowed in MPLS-TP, does an additional label on the
bypass LSP represent an additional layer in the MPLS-TP network?

I see only three possible answers to this question:

1. FRR with facility protection is NOT allowed in MPLS-TP.
    The main advantage of this answer is that it is absolutely
     unambiguous. Its disadvantage is in prohibiting a highly
     effective protection mechanism which is actually an analog of
     a mechanism that is widely deployed in traditional transport networks
     (BLSR/MS-SPRING).

2. FRR with facility protection is allowed in MPLS-TP, and the
    additional label represents an additional layer. In which case
    layering becomes dynamic (depends on whether FRR is or is not
    operated at any given moment).

3. FRR with facility protection is allowed in MPLS-TP, but an 
    additional label DOES NOT represent an additional layer.
    In which case the next question that comes to mind is "If an
    additional label does not represent an additional layer", then
    what does?"

My 2c,
     Sasha

________________________________________
From: Igor Bryskin [[email-masked]]
Sent: Monday, November 02, 2009 11:06 PM
To: Alexander Vainshtein
Cc: [email-masked]; Luca Martini; Adrian Farrel
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Sasha, see in-line.

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, November 02, 2009 3:06 PM
To: Igor Bryskin
Cc: [email-masked]; Luca Martini; Adrian Farrel
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor, and all,

Cheers,
Igor

My 2c,
     Sasha

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 03 Nov 2009 11:08:57 +0100

Shahram,

Indeed there is this difference in OAM frame formats between PW OAM and LSP
OAM, which requires configuration of the MIP function in S-PE nodes as
described in an earlier reponse. Below you find two figures illustrating
this need to configure the MIP in an S-PE to operate either in PW or in LSP
OAM mode. 

Figure 1 illustrates the case of an unprotected MS-PW connection with
endpoints at T-PE1 and T-PE2 passing through S-PE1, S-PE2, S-PE3 and S-PE4.
The UNI-N Ports in T-PE1 and T-PE2 contain a PW MEP function. The NNI ports
in S-PE1, S-PE2, S-PE3 and S-PE4 contain a PW MIP function.

 T-PE1  S-PE1      S-PE2       S-PE3       S-PE4   T-PE2
---O------O----------O-----------O-----------O-------O---
   |<------------------MS-PW------------------------>|
 PWMEP   PWMIP     PWMIP       PWMIP       PWMIP    PWMEP

Figure 1 - unprotected MS-PW connection 

When there is a requirement to protect this MS-PW between S-PE1 and S-PE4,
you can do this via sublayer monitored Sub-Network Connection (SNC/S)
protection. The S-PE1 and S-PE4 nodes will be equipped with 1:1 SNC/S
protection functionality including a protection bridge/selector process and
LSP MEPs to monitor the Working and Protection LSP connections. The
activation of those LSP MEP functions on two NNI ports in S-PE1 and S-PE4
will require that the PW MIP functions in S-PE2 and S-PE3 are reconfigured
into LSP MIP functions.

 T-PE1  S-PE1      S-PE2       S-PE3       S-PE4   T-PE2
---O------O----------O-----------O-----------O-------O---
   |<------------------MS-PW------------------------>|
           |<-----------W-LSP-------------->|
           |<-----------P-LSP-------------->|
 PWMEP   PWMIP                             PWMIP    PWMEP
        LSPMEPs    LSPMIP     LSPMIP      LSPMEPs

Figure 2 - 1:1 SNC/S protected MS-PW connection

S-PE2 and S-PE3 are in both cases S-PEs. The NNI ports in those nodes
contain the following MEPs and MIPs:
1) PHY MEP
2) Section MEP (includes Tunnel LSP mux/demux)
3) Tunnel LSP MEP (includes PW/LSP mux/demux)
4) LSP (DOWN) MEP (for PW/LSP segment monitoring)
5) Configurable MS-PW/LSP MIP
As S-PE nodes also support VPLS, the NNI ports on those nodes include also
the following MEPs and MIPs:
6) PW MEP (includes ETH encap/decap)
7) ETH DOWN MEP
8) ETH MIP
When the NNI port in a S-PE node is connected to an NNI port in a S-PE in
another administrative domain, then the NNI port must also include the
following MEPs:
9) LSP (UP) MEP (for PW/LSP admin domain segment monitoring)
10) ETH UP MEP (For Ethernet VC admin domain segment monitoring)

The P nodes between two PE nodes have NNI ports with the following MEPs and
MIPs:
1) PHY MEP
2) Section MEP (includes Tunnel LSP mux/demux)
3) Tunnel LSP MIP

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Shahram Davari
Sent: maandag 2 november 2009 22:15
To: Adrian Farrel; Luca Martini
Cc: [email-masked]
Subject: Re: [mpls-tp] If a PW is a sublayer, why is it different?

Adrian,

The two cases you mentioned are the same regarding ILM/NHLE forwarding.
However, the PW OAM is different from MPLS-TP OAM since MPLS-TP OAM uses GAL
and PW OM does not. 

Regards,
Shahram

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

Luca,

Let me draw a network...

A==B==C***D***E

A==B==C***D***E

Thanks,
Adrian

----- Original Message -----
From: "Luca Martini" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 28, 2009 10:31 PM
Subject: Re: [mpls-tp] If a PW is a sublayer, why is it different?

MPLS-TP...

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 03 Nov 2009 11:18:13 +0100

Igor,

If you need a second, i.e. LSP layer, then the first, i.e. PW layer is not
necessary and you just use the second one.

Regards,
Maarten 

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
Sent: maandag 2 november 2009 21:52
To: Maarten Vissers; 'Adrian Farrel'; 'Luca Martini'
Cc: [email-masked]
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Maarten,

That is why you need two layers. The tunnels you create in the server
(MPLS-TP) layer are traffic engineered; in particular, they reserve the
summary bandwidth on all links, set up the necessary recovery schemes, etc.
They are signaled with RSVP-TE (or any protocol with the TE capabilities) or
set up via MP. Service instance transport entities are set up as tunnels in
the client (PW) layer. They use tunnels set up in the MPLS-TP layer as
links, are signaled via LDP or configured via MP.

Cheers,
Igor

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, November 02, 2009 3:05 PM
To: Igor Bryskin; 'Adrian Farrel'; 'Luca Martini'
Cc: [email-masked]
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor,

Regards,
Maarten

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

Hi,

Cheers,
Igor 

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

Luca,

Let me draw a network...

A==B==C***D***E

A==B==C***D***E

Thanks,
Adrian

----- Original Message -----
From: "Luca Martini" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 28, 2009 10:31 PM
Subject: Re: [mpls-tp] If a PW is a sublayer, why is it different?

MPLS-TP...

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 3 Nov 2009 12:03:43 -0000

Sasha,

In your helpful email I see two points for further discussion...

> My reading of this email thread is that there is exactly one real
> difference between MPLS-TP and PW:
>
>    The former MUST use GAL for its OAM functions, while the
>    latter MUST NOT use it.
>

I wonder if the authors of 5586 can remind us why this is the case.
Was it simply because PW OAM exists today without using the GAL, and it was 
thought that changing PW OAM would be a bad thing?

>     management planes from the data plane (RFC 5654, R-15).

Does anyone have a view of the implication of this requirement on the use of 
LDP for PW setup? As I understand it, the use of per-platform labels for PWs 
makes it possible for this separation to occur.

Thanks,
Adrian

----- Original Message ----- 
From: "Alexander Vainshtein" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; "Luca Martini" <[email-masked]>; "Adrian Farrel" 
<[email-masked]>
Sent: Tuesday, November 03, 2009 7:10 AM
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor,

Hence differentiation between the MPLS-TP and PW layers cannot, IMHO, be 
based
on any differences in the control plane - simply because the latter may be 
absent.

The bottom line:

My reading of this email thread is that there is exactly one real difference 
between
MPLS-TP and PW:

The following point IMHO illustrates the virtual nature of "layering" in 
MPLS-TP.

Assuming that FRR with facility protection is allowed in MPLS-TP, does an 
additional label on the
bypass LSP represent an additional layer in the MPLS-TP network?

My 2c,
     Sasha

Sasha, see in-line.

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, November 02, 2009 3:06 PM
To: Igor Bryskin
Cc: [email-masked]; Luca Martini; Adrian Farrel
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor, and all,
If the allocation of certain resources per label is THE criterion for 
distinguishing between PW and MPLS-TP labels,
then I'd say they are one and the same. I am aware of multiple 
implementations that support
hierarchical scheduling towards each specific PW AC, with explicit 
specification of CIR and PIR, queue depth
per class of service per PW instance. And these implementation select a TEed 
tunnel for the PW based
on its BW requirements.

IB>> Correct. This is achieved by nesting PWs (usually signaled via LDP or 
BGP) within strategically placed TE tunnels (usually signaled via RSVP-TE)

The fact that this label is set by LDP and not by RSVP-TE looks to me like a 
weak argument in
the MPLS-TP context,

IB>> You need to signal the necessary end-to-end or segment path protection 
schemes, link protection requirements, bandwidth parameters, explicit paths, 
etc. RSVP-TE can do it, while LDP AFAIK cannot (and IMO shouldn't). So. the 
choice of the signaling protocol for a particular layer is important.

 where ability to operate without any control plane whatsoever is a 
mandatory
requirement.

IB>> Of course, provided that MP can configure all the things I mentioned 
above.

Cheers,
Igor

My 2c,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 3 Nov 2009 15:02:57 +0200

Adrian,
Great questions!

Expanding on the 2nd one:

In MPLS, section 3.14 of RFC 3031 effectively restricts usage of per-interface label spaces to P2P links.

This raises the following questions:

1. Are P2MP and MP2MP (LAN) links allowed in MPLS-TP?

2. If they are allowed, does the above-mentioned restriction apply, i.e.,
    only per-platform labels can be used across LAN links?

3. Which label allocation scheme(s) are allowed in MPLS-TP?

Regards,
     Sasha

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Tuesday, November 03, 2009 2:04 PM
> To: Alexander Vainshtein
> Cc: [email-masked]
> Subject: Two more PW questions [Was: If a PW is a sublayer,
> why is it different?]
>
> Sasha,
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 3 Nov 2009 09:30:40 -0500

Igor,
I think that though PW is not explicitly associated with BW or particular
CoS T- and S- PEs are still made or should be made aware of these TE
parameters so that operator is capable to deliver expected QoE.

Regards,
Greg

On Mon, Nov 2, 2009 at 12:13 PM, Igor Bryskin <[email-masked]>wrote:

> I believe there is a fundamental difference in the ways S-PW LSRs and P
> LSRs switch labeled packets, and this is one important reason why MPLS-TP
> and PW should be completely different layers.
>
> Cheers,
> Igor
>
> PW,
> that
> clients
> apriori

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 03 Nov 2009 15:59:36 +0100

Adrian,

Reading through the mpls-tp framework draft I read in section 3.4.2 that
there are in addition to the "PW label" also an "Encap label", a "Service
label" and an "edge-to-edge LSP label". These latter labels are to be used
in combination with MPLS LSP, MPLS-TP LSP and/or IP services. Not described
is what we have to add when one or more PWs are the client signals. 

Putting this information into a small figure (see below) I notice a
significant difference in treatment of client signals. 
The Ethernet, ATM, FR, PPP, HDLC, SDH and PDH client signals get a Control
Word, PW OAM and then a PW label stack entry (LSE) Header. 
This PW LSE Header contains the PW label, which label has to identify the:
1) Tunnel LSP client Protocol (which is the "PW Protocol")
2) PW instance
3) PW client Protocol.

The MPLS LSP, MPLS-TP LSP and IP client signals get
- an Encap LSE Header with an Encap label to identify the 
  1) Service LSP client protocol (which is MPLS LSP, MPLS-TP LSP or IP)
- a service LSP LSE header with a Service LSP label to identify the 
  1) edge-to-edge or tunnel LSP client protocol (which is Service LSP) and 
  2) Service LSP instance
- an optional edge-to-edge LSP LSE header with an edge2edge LSP label to
identify the 
  1) tunnel LSP client protocol (which is edge-to-edge LSP) and
  2) edge-to-edge LSP instance.

The Tunnel LSP can thus carry a mix of PWs, Service LSPs and edge-to-edge
LSPs.
The Service LSP label and the edge-to-edge LSP label identify only the
immediate client protocol: Service LSP, edge-to-edge LSP.
The PW label identifies the next two client protocols: PW and PW-client
(e.g. Ethernet ATM VC, ATM VP, ...).

What is the rationale for the need of an Encap label in the stack of the
MPLS(-TP) LSP/IP clients, while such Encap label is not specified for the
Ethernet, ATM, etc. clients? I.e. the Service LSP label could (similar to PW
label) identify both the Service LSP Protocol and its client protocol (MPLS
LSP or MPLS-TP LSP or IP).

Furthermore, it seems that the Encap LSE Header is not followed by a Control
Word, which is not in alignment with the other client encapsulation methods.
The 4 bits following the Encap label stack entry header (which has S=1) may
thus contain any value, i.e. not only the values 0000 and 0001.  Wouldn't
this cause problems with some existing functions that inspect the bits
following a label stack entry header with S bit set to 1 in the network?

It seems possible to carry one or more PW signals as client signals over a
MPLS-TP network. What would be the mapping for PW type client signals? Would
it be the same as for MPLS LSP, MPLS-TP LSP and IP? I.e. Encap LSE header,
Service LSP Header and optional edge-to-edge LSP Header?

Ethernet, ATM, FR,          MPLS LSP, IP,
PPP, HDLC, SDH, PDH         MPLS-TP LSP                PW
        |                        |                      |
  Control Word            Encap LSE Header (S=1)        ?
        |                        |                      ?
     PW OAM               Service LSP OAM               ?
        |                        |                      ?
  PW LSE Header (S=1)   Service LSP LSE Header          ?
        |         ---------------|                      ?
        |         |      edge2edge LSP OAM              ?
        |         |              |                      ?
        |         |   edge2edge LSP LSE Header          ?
        |         |              |                      |
    -----------------------------------------------------------
                      Tunnel LSP OAM
                             |
                  Tunnel LSP LSE Header
                             |
                            etc.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: dinsdag 3 november 2009 13:04
To: Alexander Vainshtein
Cc: [email-masked]
Subject: [mpls-tp] Two more PW questions [Was: If a PW is a sublayer,why is
it different?]

Sasha,

> And this difference exists only because the authors of RFC 5586 have 
> been careful enough to explicitly prohibit using GAL with PWs; 

Thanks,
Adrian

----- Original Message -----
From: "Alexander Vainshtein" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; "Luca Martini" <[email-masked]>; "Adrian Farrel"

<[email-masked]>

Igor,

The bottom line:

between
MPLS-TP and PW:

My 2c,
     Sasha

Sasha, see in-line.

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, November 02, 2009 3:06 PM
To: Igor Bryskin
Cc: [email-masked]; Luca Martini; Adrian Farrel
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor, and all,

tunnel for the PW based
on its BW requirements.

weak argument in
the MPLS-TP context,

Cheers,
Igor

My 2c,
     Sasha

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 03 Nov 2009 15:04:48 +0000

Adrian Farrel wrote:
> Was it simply because PW OAM exists today without using the GAL, and 
> it was thought that changing PW OAM would be a bad thing?
Yes, and there was a great deal of expectation that this would be the 
approach.

- Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 3 Nov 2009 17:39:29 +0200

Maarten, Adrian and all,
I think that the description of the functionality associated with the PW label is incorrect.

If you look at the PW Architecture RFC (3985), you will see that a PW actually connects a pair
of Forwarders, and that the PW label identifies a specific destination Forwarder (no more, no less).
IMHO this is exactly what RFC 3032 meant when it stated, in Section 2.2., that "identity of the
network layer protocol must be inferable from the value of the label which is popped from
the bottom of the stack..."

Known forwarders include:
- a public IP forwarder (original MPLS target)
- one of multiple IP forwarders (L3 VPN)
- one of multiple Virtual Switching Instances (VPLS)
- one of multiple "degenerated" forwarders that strip the PW header and send the resulting
  packet to the only egress interface of the specific forwarder instance  (a "regular" PW)
- one of multiple "ACH-aware" forwarders that distinguish between customer packets and ACH ones
  and handle these two types differently.

Note that the forwarder instance is inferred from the last label in the stack only
if the action on this label in the ILM is "Pop". I.e., this is only done in T-PEs

And, of course, if any label above the last is popped, the next label (existing)
is looked up in the ILM.

So neither the "LSP client protocol" nor "PW client type" are, generally speaking,
inferred from the PW label.

My 2c.

Regards,
     Sasha

> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: Tuesday, November 03, 2009 5:00 PM
> To: 'Adrian Farrel'
> Cc: [email-masked]
> Subject: [mpls-tp] Three more PW questions [was: Two more PW
> questions [Was: If a PW is a sublayer, why is it different?]]
>
> Adrian,
>

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 3 Nov 2009 11:03:30 -0500

Sasha,

Because you keep repeating yourself, I have to repeat myself too :=).

It *does not* matter whether CP or MP provisions PWs. If *does* matter whether this MP/CP has traffic engineering capabilities or not.

To see whether PWs is a separate from MPLS-TP layer or not, I think, it is helpful to answer the following questions:

1. Should CP or MP that sets up PWs be concerned with Traffic Engineering and therefore have TE capabilities? (My answer: No)

2. Should CP/MP that controls PWs be different from CP/MP that controls PW server layer? (My answer: Yes, e.g. CP for the former is LDP/BGP based, while CP for the latter is GMPLS RSVP-TE based (no LDP, no BGP)

3. Could PWs have different OAM from OAM in its server layer? (My answer: Yes)

4. Could PWs and its server layer be owned by different operators? (My answers: Yes)

5. Is there future for MPLS-TP devices that do not support PWs, rather provide server layer for them (i.e. provide links interconnecting PEs)? (My answer: Yes)

If you agree with at least some of my answers it should be obvious IMP that PWs and MPLS-TP are separate layers.

Cheers,
Igor

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Tuesday, November 03, 2009 2:10 AM
To: Igor Bryskin
Cc: [email-masked]; Luca Martini; Adrian Farrel
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor,

The bottom line:

My 2c,
     Sasha

Sasha, see in-line.

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, November 02, 2009 3:06 PM
To: Igor Bryskin
Cc: [email-masked]; Luca Martini; Adrian Farrel
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor, and all,

Cheers,
Igor

My 2c,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 3 Nov 2009 18:22:13 +0200

Igor,
A very nice set of questions.
Please see my answers inline below.

Regards,
     Sasha

> Sent: Tuesday, November 03, 2009 6:04 PM
> To: Alexander Vainshtein
> It *does not* matter whether CP or MP provisions PWs. If
> *does* matter whether this MP/CP has traffic engineering
> capabilities or not.
>
> To see whether PWs is a separate from MPLS-TP layer or not, I
> think, it is helpful to answer the following questions:
>
> 1. Should CP or MP that sets up PWs be concerned with Traffic
> Engineering and therefore have TE capabilities? (My answer: No)

[[Sasha: Yes. In addition to per class of service per PW reservation of resources, please
consider routing of MS-PWs via multiple S-PEs. This looks like a pure TE task to me. ]]

>
> 2. Should CP/MP that controls PWs be different from CP/MP
> that controls PW server layer? (My answer: Yes, e.g. CP for
> the former is LDP/BGP based, while CP for the latter is GMPLS
> RSVP-TE based (no LDP, no BGP)

[[Sasha: It can be the same MP, CP happens to be different, but does not really decide in the MPLS-TPcontext. ]]\

> 3. Could PWs have different OAM from OAM in its server layer?

[[Sasha: Yes, because GAL has been forbidden to use with PWs - for backward compatibility with VCCV.]]

> 4. Could PWs and its server layer be owned by different operators? (My answers: Yes)

[[Sasha: Yes. But there is also such a thing as Carrier's Carrier, so I do not see any difference]]

> interconnecting PEs)? (My answer: Yes)

[[Sasha: I do not know, and, IMHO, this is orthogonal to the discussion - again, consider the Carrier's Carrier scenario. ]]
> If you agree with at least some of my answers it should be obvious IMP that PWs and MPLS-TP are separate layers.
[[Sasha: There is exactly one point on which we both fully agree - differences in the OAM. Since the reason for these differences
is historical rather than technical, I remain in doubt.]]
> If the allocation of certain resources per label is THE
> criterion for distinguishing between PW and MPLS-TP labels,
> hierarchical scheduling towards each specific PW AC, with
> explicit specification of CIR and PIR, queue depth
> per class of service per PW instance. And these
> implementation select a TEed tunnel for the PW based
> on its BW requirements.
>
> IB>> Correct. This is achieved by nesting PWs (usually
> signaled via LDP or BGP) within strategically placed TE
> tunnels (usually signaled via RSVP-TE)
>
> IB>> You need to signal the necessary end-to-end or segment
> path protection schemes, link protection requirements,
> bandwidth parameters, explicit paths, etc. RSVP-TE can do it,
> while LDP AFAIK cannot (and IMO shouldn't). So. the choice of
> the signaling protocol for a particular layer is important.
>
>

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 03 Nov 2009 17:43:30 +0100

Igor,

The feeling I get from reading your words is that we can get rid of PW as a
layer and thus also don't need PW OAM. 
- Traffic engineered services need LSPs between the UNI-N ports, making the
MS-PW superfluous, just the UNI-N to UNI-N SS-PW is enough (which does not
require any PW OAM).
- S-PE nodes that do not support PWs implies that services go over Service
LSPs. For VPLS, the Ethernet VLAN signals must then be mapped via SS-PWs
into Tunnel LSPs.
The SS-PW label acts in this case as Encap label.

This would then result in the following relationships:

Ethernet, ATM, FR,          MPLS LSP, IP,
PPP, HDLC, SDH, PDH         MPLS-TP LSP                PW
        |                        |                      |
  Control Word                   |                      ?
        |                        |                      ?          
  PW LSE Header (S=1)     Encap LSE Header (S=1)        ?
        |                        |                      ? 
  Service LSP OAM         Service LSP OAM               ?
        |                        |                      ? 
Service LSP LSE Header  Service LSP LSE Header          ?    Ethernet (VPLS)
        |         ---------------|                      ?          |
        |         |      edge2edge LSP OAM              ?     Control word
        |         |              |                      ?          |
        |         |   edge2edge LSP LSE Header          ?   PW LSE Header
(S=1)
        |         |              |                      |          |
    -----------------------------------------------------------------------
                                  |
                            Tunnel LSP OAM
                                  |
                        Tunnel LSP LSE Header
                                  |
                                 etc.

The above stack maintains the original SS-PW environment, makes it
unnecessary to expand the SS-PW to MS-PW and instead provides service and
tunnel connections via LSPs (service LSPs, edge-to-edge LSPs, tunnel LSPs).
This looks less complex to design and manage to me, specifically the NNI
ports on S-PEs will be less complex.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Igor Bryskin
Sent: dinsdag 3 november 2009 17:04
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] If a PW is a sublayer, why is it different?

Sasha,

It *does not* matter whether CP or MP provisions PWs. If *does* matter
whether this MP/CP has traffic engineering capabilities or not.

To see whether PWs is a separate from MPLS-TP layer or not, I think, it is
helpful to answer the following questions:

1. Should CP or MP that sets up PWs be concerned with Traffic Engineering
and therefore have TE capabilities? (My answer: No)

2. Should CP/MP that controls PWs be different from CP/MP that controls PW
server layer? (My answer: Yes, e.g. CP for the former is LDP/BGP based,
while CP for the latter is GMPLS RSVP-TE based (no LDP, no BGP)

3. Could PWs have different OAM from OAM in its server layer? (My answer:
Yes)

4. Could PWs and its server layer be owned by different operators? (My
answers: Yes)

5. Is there future for MPLS-TP devices that do not support PWs, rather
provide server layer for them (i.e. provide links interconnecting PEs)? (My
answer: Yes)

If you agree with at least some of my answers it should be obvious IMP that
PWs and MPLS-TP are separate layers.

Cheers,
Igor

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Tuesday, November 03, 2009 2:10 AM
To: Igor Bryskin
Cc: [email-masked]; Luca Martini; Adrian Farrel
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor,

Hence differentiation between the MPLS-TP and PW layers cannot, IMHO, be
based on any differences in the control plane - simply because the latter
may be absent.

The bottom line:

between MPLS-TP and PW: 

And this difference exists only because the authors of RFC 5586 have been
careful enough to explicitly prohibit using GAL with PWs; otherwise there
would be no difference at all.

Assuming that FRR with facility protection is allowed in MPLS-TP, does an
additional label on the bypass LSP represent an additional layer in the
MPLS-TP network?

My 2c,
     Sasha

Sasha, see in-line.

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, November 02, 2009 3:06 PM
To: Igor Bryskin
Cc: [email-masked]; Luca Martini; Adrian Farrel
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor, and all,
If the allocation of certain resources per label is THE criterion for
distinguishing between PW and MPLS-TP labels, then I'd say they are one and
the same. I am aware of multiple implementations that support hierarchical
scheduling towards each specific PW AC, with explicit specification of CIR
and PIR, queue depth per class of service per PW instance. And these
implementation select a TEed tunnel for the PW based on its BW requirements.

IB>> Correct. This is achieved by nesting PWs (usually signaled via LDP 
IB>> or BGP) within strategically placed TE tunnels (usually signaled 
IB>> via RSVP-TE)

The fact that this label is set by LDP and not by RSVP-TE looks to me like a
weak argument in the MPLS-TP context,

mandatory requirement.

Cheers,
Igor

My 2c,
     Sasha

> I believe there is a fundamental difference between PW label and 
> MPLS-TP label. When an LSR forwards a labeled packet, it does not just 
> swap labels. It performs a lot of operations:
> takes the packet from an incoming queue, puts it to an outgoing queue, 
> schedules the packet for delivery, drops the packet sometimes, etc.
>
> MPLS-TP label is a (G)MPLS RSVP-TE label, which is a label of a 
> traffic engineered LSP. It defines concrete network resources (i.e. 
> number of buffers) reserved for the LSP. On the other hand PW label is 
> an LDP label with no particular associated network resources (because 
> PWs are not concerned with the traffic engineering).
>
> I believe there is a fundamental difference in the ways S-PW LSRs and 
> P LSRs switch labeled packets, and this is one important reason why 
> MPLS-TP and PW should be completely different layers.
>
> Cheers,
> Igor
>
> In the data plane of an MPLS-TP network (so it is all one server type 
> - MPLS-TP), is there any difference in behavior in an S-PE and P node 
> when switching packets?
>
> Let me draw a network...
>
>
> A==B==C***D***E
>
> Now suppose I want an LSP (note: not a PW) form A to E. It runs ACE 
> using the two tunnels.
> At C, when a packet is received, the top label is popped (end of LSP 
> ABC) and the exposed label is used for forwarding. Then a new label is 
> imposed (LSP CDE) before the packet is sent onward.
>
> Now suppose I want a PW (note: not an LSP) form A to E. It runs ACE 
> using the two tunnels.
> At C, when a packet is received, the top label is popped (end of LSP 
> ABC) and the exposed label is used for forwarding. Then a new label is 
> imposed (LSP CDE) before the packet is sent onward.
>
> What is the difference in the data plane between node C in the first 
> case and node C in the second case?
>
> It is important (to me) to limit this question to the data plane. I 
> don't care how the LSPs or PWs are set up or what service they are 
> delivering.
>
> Thanks,
> Adrian
>

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 3 Nov 2009 11:57:57 -0500

Maarten,

I agree with you. In particular, I never understood the necessity of multi-segment PWs except for addressing certain scalability issues.

What is important I think is to agree that if we do need PWs, they should be *a* client of MPLS-TP layer, rather, then a part of MPLS-TP layer.

Cheers,
Igor

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, November 03, 2009 11:44 AM
To: Igor Bryskin; 'Alexander Vainshtein'
Cc: [email-masked]
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor,

Regards,
Maarten

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

Sasha,

Cheers,
Igor

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Tuesday, November 03, 2009 2:10 AM
To: Igor Bryskin
Cc: [email-masked]; Luca Martini; Adrian Farrel
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor,

The bottom line:

My 2c,
     Sasha

Sasha, see in-line.

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, November 02, 2009 3:06 PM
To: Igor Bryskin
Cc: [email-masked]; Luca Martini; Adrian Farrel
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor, and all,

Cheers,
Igor

My 2c,
     Sasha

---

From: Francesco Fondelli <[email-masked]>
Date: Tue, 3 Nov 2009 18:41:54 +0100

Hi,

> In the second case, node C is an S-PE.
[cut]

> and node C in the second case?

a)
A P-node doesn't play with PW fragmentation, a S-PE might
(rfc5659::section8.2).

b)
A S-PE may play with PW congestion control
(rfc5659::section11), a P-node doesn't.

Implementing a S-PE that performs PW fragmentation/reassembly and
PW congestion control (scaling well) is not a piece of cake,
IMHO.

Ciao
FF

---

From: <[email-masked]>
Date: Tue, 3 Nov 2009 17:59:11 -0000

Brilliant....Igor you are dead right.  I warned PWE3 several times over
many years NOT to go MS with PWs....this just generates a completely
unnecessary new co-ps layer network.

But the real irony however is that even 1-hop PWs (ie adaptation only)
are also not even needed in MPLS done correctly!  PWs are an artefact of
arch flaws, esp a lack of consistent characteristic information in what
a label means (this also impacts the S bit).  

Some of these flaws are blindingly obvious and MUST be removed in
MPLS-TP , eg merging - noting that a PW label MUST be a SA proxy BUT
when MS it needs to change roles and have a forwarding semantic (see my
important post on this to Matthew Bocci/PWE3 29 Nov 2008).

However, I am afraid that I see that many arch flaws that will
remain...the S bit is one if the biggest problems, but it is a little
subtle and not something all folks get immediately.   I'll try and find
time to post something later tonight that explains all this with a bit
more rigour...but the bottom line Igor is you are correct.

regareds, Neil

> Sent: 03 November 2009 16:58
> To: Maarten Vissers; 'Alexander Vainshtein'
> Cc: [email-masked]
> I agree with you. In particular, I never understood the 
> necessity of multi-segment PWs except for addressing certain 
> scalability issues.
> 
> What is important I think is to agree that if we do need PWs, 
> they should be *a* client of MPLS-TP layer, rather, then a 
> part of MPLS-TP layer.
> 
> Cheers,
> Igor
> 
> The feeling I get from reading your words is that we can get 
> rid of PW as a layer and thus also don't need PW OAM.
> - Traffic engineered services need LSPs between the UNI-N 
> ports, making the MS-PW superfluous, just the UNI-N to UNI-N 
> SS-PW is enough (which does not require any PW OAM).
> - S-PE nodes that do not support PWs implies that services go 
> over Service LSPs. For VPLS, the Ethernet VLAN signals must 
> then be mapped via SS-PWs into Tunnel LSPs.
> Control word
> PW LSE Header
> The above stack maintains the original SS-PW environment, 
> makes it unnecessary to expand the SS-PW to MS-PW and instead 
> provides service and tunnel connections via LSPs (service 
> LSPs, edge-to-edge LSPs, tunnel LSPs).
> This looks less complex to design and manage to me, 
> specifically the NNI ports on S-PEs will be less complex.
> 
> Regards,
> Maarten
> 
> 5. Is there future for MPLS-TP devices that do not support 
> PWs, rather provide server layer for them (i.e. provide links 
> interconnecting PEs)? (My
> answer: Yes)
> 
> If you agree with at least some of my answers it should be 
> obvious IMP that PWs and MPLS-TP are separate layers.
> 
> Cheers,
> Igor
> 
> Hence differentiation between the MPLS-TP and PW layers 
> cannot, IMHO, be based on any differences in the control 
> plane - simply because the latter may be absent.
> 
> My reading of this email thread is that there is exactly one 
> real difference between MPLS-TP and PW:
> 
> And this difference exists only because the authors of RFC 
> 5586 have been careful enough to explicitly prohibit using 
> GAL with PWs; otherwise there would be no difference at all.
> 
> Assuming that FRR with facility protection is allowed in 
> MPLS-TP, does an additional label on the bypass LSP represent 
> an additional layer in the MPLS-TP network?
> 
> then I'd say they are one and the same. I am aware of 
> multiple implementations that support hierarchical scheduling 
> towards each specific PW AC, with explicit specification of 
> CIR and PIR, queue depth per class of service per PW 
> instance. And these implementation select a TEed tunnel for 
> the PW based on its BW requirements.
> 
> signaled via LDP 
> The fact that this label is set by LDP and not by RSVP-TE 
> looks to me like a weak argument in the MPLS-TP context,
> 
> IB>> You need to signal the necessary end-to-end or segment path 
> IB>> protection
> schemes, link protection requirements, bandwidth parameters, 
> explicit paths, etc. RSVP-TE can do it, while LDP AFAIK 
> cannot (and IMO shouldn't). So. the choice of the signaling 
> protocol for a particular layer is important.
> 
> 
>  where ability to operate without any control plane 
> whatsoever is a mandatory requirement.
> 
> IB>> Of course, provided that MP can configure all the things I 
> IB>> mentioned
> above.
> 
> Cheers,
> Igor
> 
> 
> 
> My 2c,
>      Sasha
> 
> outgoing queue,

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 03 Nov 2009 21:06:38 +0100

Igor,

You write:
> "if we do need PWs, they should be *a* client of MPLS-TP layer,
> rather, then a part of MPLS-TP layer" 

When I look to this statement from an equipment functionality perspective I
do not understand the idea behind this statement. Interface ports on
equipment are agnostic to the allocation of the PW functionality to be part
of the MPLS-TP layers/sublayers or to be outside of the MPLS-TP
layers/sublayers. For interface ports it is important to know if MPLS-TP PW
OAM has to be supported as this OAM is different from the LSP OAM. This is
specifically important for the UNI-N ports on a T-PE and the NNI ports on a
T-PE and S-PE.

If MPLS-TP networks have to support MS-PW connections, then there is a need
to support 
- a MPLS-TP PW MEP (supporting pro-active and on-demand MPLS-TP PW OAM) on
the UNI-N ports and 
- a MPLS-TP PW MIP (supporting on-demand MPLS-TP OAM) on the the NNI ports
of T-PE/S-PE nodes.

If MPLS-TP networks have to support MS-PW connections underneath of VPLS,
then there is an additional need to support
- a MPLS-TP PW MEP (supporting pro-active and on-demand MPLS-TP PW OAM) on
the NNI ports of T-PE/S-PE nodes (i.e. between the Ethernet fucntionality
associated with VPLS and the tunnel LSP functionaltiy).

If MPLS-TP networks do not include MS-PW connections, but instead deploy
Service LSP connections, then there is no need to support the above set of
MPLS-TP MEP or MIP functions on UNI-N or NNI ports. The PW functionality
will in such case be limited to SS-PW label stack entry headers, which are
inserted/extracted at at:
- UNI-N ports for the case of non-MPLS services (Ethernet, ATM, etc) carried
over a Service LSP
- NNI ports on PEs for the case of mp Ethernet services (VPLS application)
carried over a Tunnel LSP.

If MPLS-TP networks support MS-PW connections, then the service related MIP
function must be configurable to support either PW OAM or LSP OAM. NMS or
control plane will have to configure each MIP function along the MS-PW
connection to operate on the basis of PW OAM or LSP OAM. PW OAM will have to
be used if there is no segment monitoring active, which is the case if the
MS-PW is a single carrier connection and if it is not protected. LSP OAM
will have to be used if there is segment monitoring active, which is the
case if MS-PW is a multi-carrier connection and/or if MS-PW is protected. In
those latter two cases one or more LSPs will be activated to perform the
segment monitoring. NNI ports within such MS-PW segment monitoring domains
will have to respond to LSP OAM, otherwise they have to respond to PW OAM.
Note that it is possible to protect an initial unprotected MS-PW connection;
for such case NMS/control plane will have to change the configuration of the
service related MIP from PW OAM responsive to LSP OAM responsive.

If MPLS-TP networks do not support MS-PW connections, then the service
related MIP functions will always have to respond to LSP OAM, and no
configuration of such service monitoring MIP function on NNI ports in PE
nodes is necessary.

>From a technical perspective there is no need for a MS-PW connection in a
MPLS-TP network. The function of the MS-PW connection can be performed by
the Service LSP connection, which is eitherway to be supported when the
client signal is MPLS LSP, MPLS-TP LSP or IP. From this perspective the
MS-PW connection seems to just introduce additional complexities in MPLS-TP,
without providing any benefit.

I hope the IETF76 meeting decides if MS-PW is to be supported in MPLS-TP
networks (increases complexity), or if Service LSPs will be used instead
(reduces complexity).

Regards,
Maarten

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
Sent: dinsdag 3 november 2009 17:58
To: Maarten Vissers; 'Alexander Vainshtein'
Cc: [email-masked]
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Maarten,

I agree with you. In particular, I never understood the necessity of
multi-segment PWs except for addressing certain scalability issues.

What is important I think is to agree that if we do need PWs, they should be
*a* client of MPLS-TP layer, rather, then a part of MPLS-TP layer.

Cheers,
Igor

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, November 03, 2009 11:44 AM
To: Igor Bryskin; 'Alexander Vainshtein'
Cc: [email-masked]
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor,

Regards,
Maarten

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

Sasha,

Cheers,
Igor

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Tuesday, November 03, 2009 2:10 AM
To: Igor Bryskin
Cc: [email-masked]; Luca Martini; Adrian Farrel
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor,

The bottom line:

My 2c,
     Sasha

Sasha, see in-line.

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, November 02, 2009 3:06 PM
To: Igor Bryskin
Cc: [email-masked]; Luca Martini; Adrian Farrel
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor, and all,

Cheers,
Igor

My 2c,
     Sasha

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 3 Nov 2009 15:17:54 -0500

Maarten,

If I understand you correctly, you are saying that there is no need for MS PW connections, rather, one can always use single hop PWs with (what you call) service LSPs providing links interconnecting PEs. I agree with that.

Cheers,
Igor

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, November 03, 2009 3:07 PM
To: Igor Bryskin
Cc: [email-masked]
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor,

Regards,
Maarten

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: dinsdag 3 november 2009 17:58
To: Maarten Vissers; 'Alexander Vainshtein'
Cc: [email-masked]
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Maarten,

Cheers,
Igor

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, November 03, 2009 11:44 AM
To: Igor Bryskin; 'Alexander Vainshtein'
Cc: [email-masked]
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor,

Regards,
Maarten

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

Sasha,

Cheers,
Igor

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Tuesday, November 03, 2009 2:10 AM
To: Igor Bryskin
Cc: [email-masked]; Luca Martini; Adrian Farrel
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor,

The bottom line:

My 2c,
     Sasha

Sasha, see in-line.

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, November 02, 2009 3:06 PM
To: Igor Bryskin
Cc: [email-masked]; Luca Martini; Adrian Farrel
Subject: RE: [mpls-tp] If a PW is a sublayer, why is it different?

Igor, and all,

Cheers,
Igor

My 2c,
     Sasha

---

From: Mach Chen <[email-masked]>
Date: Wed, 04 Nov 2009 16:19:20 +0800

Hi,

>> Was it simply because PW OAM exists today without using the GAL, and it 
>> was thought that changing PW OAM would be a bad thing?

Does it mean that PW and MPLS-TP will have different OAM?  If so, does it 
mean that the being designed MPLS-TP OAM could not be used for PW? (e.g., 
Performance Monitoring)

Best regards,
Mach

---

From: <[email-masked]>
Date: Wed, 4 Nov 2009 13:36:53 -0000

Igor is quite right to assert that a PW is not like a normal LSP (I'll
show why shortly)...but then what is a 'normal LSP'?  This is a key
question and not at all as obvious as it seems.  It also introduces our
old friend the S bit and the often stated claim that nested MPLS LSPs
are sublayers.  However, this is not strictly correct because MPLS is
not singular.  These are the issues I want to cover in this mail.

This is a longish mail (sorry) but there is a lot of stuff I want to
cover so that we have a fairly comprehensive picture of all the factors
that apply.  

Let's start with some important networking fundamentals.  A layer
network (any mode) needs to have consistent Characteristic Information
(CI).  This is very important and, I hope, intuitively obvious, ie we
want a node that receives traffic units (either by correctly functioning
design or due to defects/errors, eg misconnectivity) to known how to
parse them and interpret the functional fields therein.

Aside=> I am talking mainly of the traffic DP here, but exactly the same
consistent CI issues apply to the CP and MP protocols however they are
instantiated...which of course is different in the cl-ps case to the
co-cs/ps cases.  In the latter co-cs/ps cases there should be a disjoint
DP network (to the traffic/client DP network) purely for the critical
CP/MP protocols.  This is good design practice, and whilst it is forced
in the co-cs mode it has be consciously designed-in for the co-ps mode,
eg MPLS-TP.

When MPLS first came on the scene it was designed as an IP helper
(improved speed of forwarding)...so it really only had 1 cl-ps IP
client.  This allowed (with hindsight) some rather bad architectural
design choices to be made.  Firstly, it allowed merging constructs to be
created which:
-	lose information of source
-	destroy ability to manage resource
-	inflict many operational problems/costs, like complex OAM.

Note also that because we cannot manage resource on a per customer basis
then the WHOLE (merging) network has to be both designed and operated to
the most demanding client SLA in force (not a great operational model
IMO).

LDP LSPs 'self-nucleate' in creating edge-edge mp2p constructs......so
this is not signalling (of LSP 'connection' set-up) in a classical
sense.  We also allowed another form of merging with the PHP
'optimisation' (sic) idea.

Have we a problem yet?  Well no, not as long as we don't care about
being able to manage resource (with all the design/operation issues this
creates) and we only have an IP cl-ps client with unique access point
addressing.  This 'unique access point addressing' is important because
a mp2p merging construct based on label swapping (itself not a great
idea, but park that) loses information of source.  If the client is an
IP layer network with unique access point addressing (the rfc4364 case
is slightly different as client IP addresses may not be unique across
all clients, but again just park that) then source information can be
recovered at the higher IP layer because in a cl-ps mode network there
are no short-cuts allowed on labelling, which means a full SA, full DA
and client PID field MUST be present.  As noted earlier, we still can't
control/manage resource, but this is no different to a normal cl-ps mode
layer network anyway.

Wrt managing traffic load and potential SPF overload it is common to
have proprietary ECMP algorithms operating in the IP layer.  This is a
form of DPI technique.  DPI is anathema to a transport network as it
violates the principal transparency requirement...so just bear that in
mind when we come back to MPLS-TP and also when we touch on QoS later.

ECMP tries to keep IP layer 5-tuple 'conversation' microflows following
the same network routing, and ergo hopes to preserve information symbol
ordering (which is a MUST HAVE behaviour in a transport network...I'll
also come back on this one later as this is another requirement of
transparency and something QoS can wreck).

Again, the ECMP stuff works fine in MPLS as long as IP (either v4 or v6)
is the client.  For non-IP clients however, this is a  serious problem.
The proprietary ECMP DPI transparency violation won't work if the MPLS
LSP client is not IP...since it looks for the 1st nibble IP version
number to allow deeper IP functional field indexing.

Aside=> ECMP is predicated on having consistent IP layer network
CI...which IP has but MPLS does not, now how ironic is that observation
given the topic of this mail, ie the importance of having consistent CI
in a layer network!

So, when the MPLS LDP client is not IP we have 2 quite different
problems:
-	we cannot recover the lost source information due to LDP merging
from the client itself unless it is cl-ps with unique source
addressing...so we MUST add a new PW label to the stack that carries the
semantic of this client's SA.  And this is exactly what a 1-hop PW label
MUST be, ie a client SA proxy.  BTW this proves the point Igor was
making that a PW and a LSP are different...I'll say much more on this
later as it's all about the lack of consistent CI in MPLS;
-	the 1st nibble of the non-IP client payload must not be allowed
to mimic either IPv4 0100 or IPv6 0110 1st nibbles of the ('IP ver')
traffic unit...ergo in the 4 octet CW we set the 1st nibble to 00000 to
tell ECMP to ignore.

The rest of the CW is a fairly poor adaptation functional space, eg
proper connections MUST NOT re-order client traffic units, so a 16 bit
Seq No. field is not required in a proper co-ps mode transport network,
eg MPLS-TP.

This is all bad enough so far, but several years ago some folks wanted
to make PWs multi-hop to 'improve MPLS scaling'.  This is a serious
error of judgement, because what seems a simple change on the face of it
(ie going multi-hop) invokes a massive functional behaviour change in
what PWs represent....they change from a poor 1-hop adaptation function
for non-IP and non-MPLS clients to becoming a full-blown PW co-ps mode
layer network in their own right.  This is not a trivial change.  One
will require to replicate all the important DP/CP/MP components for this
PW layer network.  And note carefully that *all* these components
operate in a different layer network space to the hybrid IP/MPLS network
underneath them, eg there is no common instance of routing across the
MS-PW network and the serving IP/MPLS network.

A corollary of PWs going from 1-hop to multi-hop, which does not seem to
well understood in my experience, is that the original PW label which
MUST be a SA proxy (to recover the source information lost due to lower
level LDP merging) now needs to change roles and become a forwarding
label, ie DA proxy on each hop...which can also be swapped hop-by-hop
like normal forwarding.  So here is a major functional conflict of
interest in what a PW needs to be.

Because this point might not be so obvious to everyone, I went through
it in some detail in a mail to Matthew Bocci/PWE3 on 29 Nov 2008.  So
folks who want to know more about this can look it up in the PWE3 mail
archives (or else ping me and I'll send them a copy).  BTW - this again
reinforces the point Igor made as to why PWs and LSPs are not the
same....but also see later point on inconsistent CI in MPLS. 

Now MPLS-TP is supposed to be a transport network.  It should not
therefore be generating further unnecessary layer networks above
it....if it did that it would a laughing stock as a transport network.
So this means there MUST NOT be MS-PWs in MPLS-TP.

But its actually even more fundamental than this.  MPLS-TP demands that
we remove all the original 'things' as noted above (eg LDP) that created
PWs in the first place.  So the punch-line here is that PWs have no role
in MPLS-TP at all...everything is a PW and nothing is a PW!...or put far
more simply 'we must treat all clients the same in MPLS-TP'...which
neatly brings me to the key point I wanted to discuss in this mail, ie
nested LSPs and the role of the S bit.

There are only 2 'good' labels in MPLS:
-	the very outer label that has a well-known label-swapping
forwarding function (just like FR or ATM say)
-	the 0-15 reserved labels that have a globally well-known
functional 'action' semantic.

All other labelled headers in some arbitrary LSP nested stack can have
variable semantics.  One cannot tell the label semantic by just looking
at the mid-stack label in the DP, eg a PW label is a SA proxy and not a
forwarding label (Igor's point yet again).  The real label semantic is
only known by the CP/MP protocol that issued it....this is also why you
will hear me say that MPLS is not singular.

This brings me back to where I started this mail.....MPLS does not have
consistent CI because the labels only have context wrt to the CP/MP
protocol that generated them.  And this variance in label-meaning is
getting larger all the time, eg upstream/context assigned labels.

So under misconnectivity cases, and with the exception of the 0-15
globally well-known labels, one has no idea how a node that incorrectly
receives MPLS traffic units will respond...it may black hole them (if
label not in use) or it may misdirect/mishandle them (if label in use). 

And this is precisely why the S bit in MPLS does not represent
sublayering.  To be clear:  Sublayers need to have consistent/known CI,
and this is quite obviously not the case in an arbitrary MPLS LSP stack.
This arises because MPLS as-is is not singular, ie each CP/MP protocol
that can generate labels represents a different CI network context of
MPLS.

This is why I have said in the past that we should not use the S bit in
MPLS-TP like it was used in MPLS as-is.  MPLS-TP MUST have consistent CI
if it is to be a useful transport network technology.

Now I want to add a further and rather important message about
QoS...because I can see some downstream mistakes happening here if we
are not careful.

A transport network MUST provide its clients with a transparent
transport service.  Transparency has a precise information theoretic
meaning (just like  a connection has a precise construct meaning).  In
the simplest terms, transparency requires that all client information
symbols (where a 'bit' is the smallest information symbol) MUST be
treated equally.  So let's explore this 'treated equally' point a little
further.

Please also bear in mind that in all networking cases there is always a
top-of-stack layer network present that is interfacing with external
message/file/stream applications....these are the whole raison d'etre
for *all* networking cases.  These applications can assume *any*
survivability importance whilst having fairly static temporal
importance.  This is why in a server transport network, which in
practice can be more than one layer network below the top-of-stack
network, we MUST NOT try and infer any temporal/QoS meaning of client
symbols.

There is also a performance/traffic-behaviour related aspect to
transparency, viz: A transport network MUST NOT allow the traffic
behaviour of client X to impact the SLA enjoyed by client Y.  This too
should be fairly obvious and something most operators should recognise
when dealing with the customers of their transport network services.
This implies 2 things:
-	that client services MUST use proper server layer connections
(this is a necessary requirement of transparency)
-	that the resource allocated to client SHOULD NOT be overbooked
in the server layer (this is a full-sufficiency requirement of
transparency).

Both these requirements are forced to be 'true' when using the co-cs
mode as a transport network...which is of course why the PDH, SDH and
OTN are enduringly successful in this role.  In the co-ps mode however
we have to consciously design-in this behaviour.

Now we can relax the *survivability importance* semantic (ie allow some
level of overbooking) but we MUST NOT change the *temporal importance*
semantic...this is set by the client application and as a transport
network we should not care (and indeed MUST NOT care) about it...DPI is
one way to try and infer client symbol meaning, but it is transparency
violation and transport networks MUST NOT do DPI.

What this means practically is that a MPLS-TP connection/LSP MUST only
have a single QoS level....or put another way, the client bit ordering
MUST be preserved in a MPLS-TP LSP..

I hope this makes sense to everyone because it is very important.  It
also has some nasty practical consequences if we ignore it, eg if we
allow multiple QoS classes in a single connection/LSP then we could very
easily create very complex problems defining entry/exit of the
unavailable and/or degraded state in an MPLS-TP LSP.

I've largely finished what I wanted to say here in covering why the S
bit is not really required in MPLS-TP (which also means each LSP is a
layer network in its own right), but I want to close with a summary of
the things I would do if I had control over the MPLS-TP technical
specification (though I am quite aware not all these things will be
done):

-	logically OOB CP/MP, whose protocols sit under a reserved label
X which can never appear in the traffic DP....note this means we DO NOT
place DP OAM also under label X, though I know folks intend to do this
-	DP traffic and DP OAM should have as-near-as-possible identical
headers...OAM indicate requires 1 bit of information in the common
header.
-	a co-ps mode transport network has no need of a TTL function
-	a co-ps mode transport network MUST have consistent CI and
SHOULD NOT have arbitrary sublayering, ie no need for S bit, each LSP is
a layer network in its own right.
-	MPLS-TP MUST NOT generate a PW layer network above it...in fact
MPLS-TP should not have PWs at all (for reasons given above)
-	a co-ps mode transport network MUST provide its clients with a
transparent transport service...so it MUST use connections and it SHOULD
NOT overbook its resources.
-	An LSP in MPLS-TP MUST only have a single QoS class...this is a
further consequence of the transparency requirement in that all client
symbols have their ordering preserved.
-	a co-ps transport network should not use DPI techniques...this
would be a violation of the transparency requirement.

I hope those who stayed with this got something useful from it and I
hope it helps us do a better job of specifying MPLS-TP.

regards, Neil

> Sent: 03 November 2009 15:00
> To: 'Adrian Farrel'
> Cc: [email-masked]
> Reading through the mpls-tp framework draft I read in section 
> 3.4.2 that there are in addition to the "PW label" also an 
> "Encap label", a "Service label" and an "edge-to-edge LSP 
> label". These latter labels are to be used in combination 
> with MPLS LSP, MPLS-TP LSP and/or IP services. Not described 
> Putting this information into a small figure (see below) I 
> notice a significant difference in treatment of client signals. 
> The Ethernet, ATM, FR, PPP, HDLC, SDH and PDH client signals 
> get a Control Word, PW OAM and then a PW label stack entry 
> (LSE) Header. 
> - an optional edge-to-edge LSP LSE header with an edge2edge 
> LSP label to identify the
> The Tunnel LSP can thus carry a mix of PWs, Service LSPs and 
> edge-to-edge LSPs.
> The Service LSP label and the edge-to-edge LSP label identify 
> only the immediate client protocol: Service LSP, edge-to-edge LSP.
> The PW label identifies the next two client protocols: PW and 
> PW-client (e.g. Ethernet ATM VC, ATM VP, ...).
> 
> MPLS(-TP) LSP/IP clients, while such Encap label is not 
> specified for the Ethernet, ATM, etc. clients? I.e. the 
> Service LSP label could (similar to PW
> label) identify both the Service LSP Protocol and its client 
> protocol (MPLS LSP or MPLS-TP LSP or IP).
> 
> Furthermore, it seems that the Encap LSE Header is not 
> followed by a Control Word, which is not in alignment with 
> the other client encapsulation methods.
> The 4 bits following the Encap label stack entry header 
> (which has S=1) may thus contain any value, i.e. not only the 
> values 0000 and 0001.  Wouldn't this cause problems with some 
> existing functions that inspect the bits following a label 
> stack entry header with S bit set to 1 in the network?
> 
> It seems possible to carry one or more PW signals as client 
> signals over a MPLS-TP network. What would be the mapping for 
> PW type client signals? Would it be the same as for MPLS LSP, 
> MPLS-TP LSP and IP? I.e. Encap LSE header, Service LSP Header 
> and optional edge-to-edge LSP Header?
> 
> 
> Subject: [mpls-tp] Two more PW questions [Was: If a PW is a 
> sublayer,why is it different?]
> 
> Sasha,
> 
> 5586 have 
> Was it simply because PW OAM exists today without using the 
> GAL, and it was thought that changing PW OAM would be a bad thing?
> 
> Does anyone have a view of the implication of this 
> requirement on the use of LDP for PW setup? As I understand 
> it, the use of per-platform labels for PWs makes it possible 
> for this separation to occur.
> 
> Thanks,
> Adrian
> 
> 
> real difference
> instance. And these implementation select a TEed
> 
> tunnel for the PW based
> on its BW requirements.
> 
> IB>> or
> looks to me like a
> explicit paths,
> etc. RSVP-TE can do it, while LDP AFAIK cannot (and IMO 
> shouldn't). So. the choice of the signaling protocol for a 
> particular layer is important.
> 
>