Subject: [Detnet-dp-dt] Using MS-PW concept for the d-pw

From: Balázs Varga A <[email-masked]>
Date: Wed, 22 Feb 2017 16:08:22 +0000

Hi,

d-pw collision can be solved if the MS-PW concept is used for the DetNet-PW.
d-pws between x-PE nodes have their own d-pw label. X-PE nodes do d-pw label swap.
Replicas of a detnet flow have to use different d-pw label.

I have attached a simplified figure:
- detnet-flow1: A -- > D (B is just a segment-stitching point, C does elimination)
- detnet-flow2: F -- > G (E is just a segment-stitching point, B does elimination)

There is no d-pw label collision at B as it allocates the d-pw label for the segments of the
DetNet-PW. So B can ensure that no collision occurs.

You can treat as a drawback that you need a state for each segment, but that is the same as for
"normal" MS-PW scenarios.

As a side effect l-labels are not needed at all. Comments are welcome.

Cheers
Bala'zs

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 22 Feb 2017 11:21:23 -0800

Hi,

Thank you for this. It is very useful. Few comments inline.

> On Feb 22, 2017, at 8:08 AM, Balázs Varga A <[email-masked]> wrote:
> 
> Hi,
>  

Am I missing something here.. We have been talking about MS-PW with required DetNet modifications from the beginning. What has changed since apart excluding the L-labels (no need to pop those to expose d-pw in this proposal) and using s2s d-pw labels instead of e2e d-pw label value?

> “normal” MS-PW scenarios.

Except that you need more state than in a “normal” MS-PW scenario. Each x-PE has to have an additional many-to-one mapping of d-pw labels to be able to associate a single seqnum & duplicate elimination function to a set of incoming PWs. For this purpose I added a ‘virtual label’ column.

I hope I got the following drawings correct ;)

Sketching LFIB for S-DetNet-PE (for detnet-flow2):

+========+================+===============+================================+
|        |                |  Elimination  |     Forwarding Semantics       |
| Device | Incoming-Label |---------------|--------------------------------|
|        |                | Virtual-label | Outgoing-Label | Outgoing-Link |
+========+================+===============+================+===============+
| F      | N/A (from AC)  | d-pw0 (2)     | swap d-pw4 (3) | F->E          |
|        |                |               | swap d-pw3     | F->B          |
+========+================+===============+================+===============+
| E      | d-pw4          | d-pw4 (1)     | swap d-pw7     | E->B          |
+========+================+===============+================+===============+
| B      | d-pw4          | d-pw3 (1)     | swap d-pw8     | B->G          |
|        | d-pw3          | d-pw3         |                |               |
+========+================+===============+================+===============+
| G      | d-pw8          | d-pw8 (1)     | N/A (to   AC)  | G->AC         |
+========+================+===============+================+===============+

(1) For elimination purposes we need to associate all incoming d-pw labels
    that belong to the same detnet flow to a single “virtual label”. Here the
    “virtual label” to which the seqnum and elimination book keeping is
    associated with is just one of the active d-pw labels, for example, the
    first that gets configured in the device for a detnet flow (i.e., the master
    label). The label could also be truly a virtual label value that is never
    seen on wire..
(2) The ‘virtual label’ the seqnum etc logic is associated with for a
    given detnet flow.
(3) Replication is more or less equivalent to existing 1+1 protection. One
    replica of the packet is done and outgoing labels are swapped accordingly.

So, if we had a “global” e2e d-pw label for each detnet flow, the ‘elimination’
label mapping column would not be needed -> smaller LFIB and and less processing
step. Also, the ‘outgoing-label’ column would not be needed, however, there
would not be any LFIB savings since the same amount of information would be
needed for d-pw to L-Labels mapping. Basically the LFIB for e2e d-pws would 
look like this (slide 4 from detnet-frer-loa.pptx):

+========+================+=================================+
|        |                |      Forwarding Semantics       |
| Device | Incoming-Label |---------------------------------|
|        |                | Outgoing-Label  | Outgoing-Link |
+========+================+=================+===============+
| A      | N/A (from AC)  | create d-pw     |               |
|        |                | push L1         | A->B          |
|        |                | push L3         | A->C          |
+========+================+=================+===============+
| B      | d-pw           | push L2         | B->D          |
|        | (L1/L6 popped) | push L5         | B->C          |
+========+================+================+===============+
| C      | d-pw           | push L6         | C->B          |
|        | (L3/L5 popped) | push L4         | C->D          |
+========+================+=================+===============+
| D      | d-pw           | N/A (to   AC)   | G->AC         |
|        | (L2/L7 popped) |                 |               |
+========+================+=================+===============+

> As a side effect l-labels are not needed at all. Comments are welcome.

I could like this (one less label layer and somewhat cleaner), however, is there a deployment scenario or an overlay topology that we cannot get working without L-label-layer? 

- JOuni

>  
> Cheers
> Bala’zs
> <detnet-frer-balazs_v0222.pptx>_______________________________________________
> Detnet-dp-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 23 Feb 2017 01:36:15 +0000

Balazs,

I agree with you that MS-PW is the good candidate. Since B will allocate platform-unique PW label for each PW segment (terminated on B), there is no collision of PW label value.
Furthermore, DetNet Id label is not needed if we use MS-PW concept.
My slides sent the day before yesterday discusses in more details how the MS-PW approach can work.

Thanks,
Yuanlong

From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Balázs Varga A
Sent: Thursday, February 23, 2017 12:08 AM
To: [email-masked]
Subject: [Detnet-dp-dt] Using MS-PW concept for the d-pw

Hi,

Cheers
Bala’zs

---

From: Balázs Varga A <[email-masked]>
Date: Thu, 23 Feb 2017 14:46:36 +0000

Hi,

Thanks for the details, the “virtual label” is a good visualization of the problem.

The “virtual label” is practically the local-ID of the detnet-(compound)-flow.

So, if I understand it correctly, You intend to use the d-pw as local-ID to have
less label operation cycle. However counting the number of label operations

I do not see the difference, please correct me if I have not counted correctly.

S-PE packet processing tasks:

Solution-1, MS-PW case, no “l-label”

  a, ingress packet has single label “d-pw1”

  b, label operation: swap “d-pw1” -- > “virtual-label1” = local-ID

  c, duplicate elimination using the local-ID

  d, replication + swap “virtual-label1” -- > “d-pw2”

  e, push outgoing labels (t-label)

Solution-2, Globally unique d-pw scenario

  a, ingress packet has two labels “d-pw + l1”

  b, label operation: pop “l1” -- > “d-pw” = local-ID

  c, duplicate elimination using the local-ID

  d, replication + push “l2”

  e, push outgoing labels (t-label)

The differences are:

- 1b vs. 2b: it a swap vs. pop operation (they lasting equally)

- 1d vs. 2d: it a swap vs. push operation (they lasting equally)

So these differences does not cause label processing cycle differences.

Have I missed something?

Cheers

Bala’zs

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]]
Sent: Wednesday, February 22, 2017 8:21 PM
To: Balázs Varga A <[email-masked]>; [email-masked]
Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw

Hi,

> On Feb 22, 2017, at 8:08 AM, Balázs Varga A <[email-masked]<mailto:[email-masked]>> wrote:

> - detnet-flow1: A -- > D (B is just a segment-stitching point, C does

> elimination)

> - detnet-flow2: F -- > G (E is just a segment-stitching point, B does

> elimination)

> There is no d-pw label collision at B as it allocates the d-pw label

> for the segments of the DetNet-PW. So B can ensure that no collision occurs.

> You can treat as a drawback that you need a state for each segment,

> but that is the same as for “normal” MS-PW scenarios.

+========+================+===============+=============================+===+

+========+================+===============+================+============+===+

+========+================+===============+================+============+===+

+========+================+===============+================+============+===+

|        | d-pw3          | d-pw3         |                |               |

+========+================+===============+================+============+===+

+========+================+===============+================+============+===+

    seen on wire..

    given detnet flow.

label mapping column would not be needed -> smaller LFIB and and less processing step.

Also, the ‘outgoing-label’ column would not be needed, however, there would not be any

LFIB savings since the same amount of information would be needed for d-pw to L-Labels

mapping. Basically the LFIB for e2e d-pws would look like this (slide 4 from detnet-frer-loa.pptx):

|        |                | push L1         | A->B          |

|        |                | push L3         | A->C          |

|        | (L2/L7 popped) |                 |               |

- JOuni

> <detnet-frer-balazs_v0222.pptx>_______________________________________

> ________

> [email-masked]<mailto:[email-masked]>

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 23 Feb 2017 09:49:29 -0800

Balazs,

Thanks for the below sequence. A very good way to interpret my figures. Yes, you are correct there seems to be no difference in processing steps as whole. I assumed 2b had L-labels already popped and did not count those as part of the FRER processing ;)

One thing still remains. The “virtual label” solution needs the “local-id” mapping information for 1b step, which means more entries in an LFIB and a “wider” lookup (which can also be an issue).

Last, assuming the pipeline implementation would be the same for all x-PE nodes (which it typically is, just that the actions and tables are programmed differently). The 1d replication step would likely need additional/different logic compared to 1+1 protection logic that 2d uses. It might be a tiny tweak but still a change.

- Jouni

-- 
Jouni Korhonen, Broadcom Ltd., Core Switching Group
M: +1-408-391-7160

> On Feb 23, 2017, at 6:46 AM, Balázs Varga A <[email-masked]> wrote:
> 
> Hi,
>

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 24 Feb 2017 07:30:25 +0000

Hi Jouni and Balazs,

IMO, global e2e d-pw is still an MS-PW approach, except that the label value for each PW segment is the same (maybe globally allocated) in this case.
We know that for the traditional PW, the underlying LSP will be terminated on the same pair of PEs (T-LDP can guarantee this), and all interim P nodes only forward packets based on the LSP label.
But now both approaches will require to look into d-pw label so that the S-PE can decide how to eliminate & replicate & forward.

Compared with the LFIB for e2e d-pws as you described: (slide 4 from detnet-frer-loa.pptx)

|        |                | push L1         | A->B          |

|        |                | push L3         | A->C          |

|        | (L2/L7 popped) |                 |               |

The LFIB for MS-PW in segment by segment would look like this (same slide 4)

(Note: for each LSP Lx, a PW segment PWx is assumed to be established; Elimination takes two PWs in this case)

+========+================+===============+===================================+

| Device | Incoming-Label |               +-----------------------------------|

|        |                |  Incoming     | Outgoing-Label    | Outgoing-Link |

+========+================+===============+===================+===============+

| A      | N/A (from AC)  | N/A           | push PW1, push L1 | A->B          |

|        |                |               | push PW3, push L3 | A->C          |

+========+================+===============+===================+===============+

| B      | PW1(L1 popped) | PW1           | swap PW2, push L2 | B->D          |

|        | PW6(L6 popped) | PW6           | swap PW5, push L5 | B->C          |

+========+================+===============+===================+===============+

| C      | PW3(L3 popped) | PW3           | swap PW6, push L6 | C->B          |

|        | PW5(L5 popped) | PW5           | swap PW4, push L4 | C->D          |

+========+================+===============+===================+===============+

| D      | PW2(L2 popped) | PW2           | N/A (to   AC)     | D->AC         |

|        | PW4(L4 popped) | PW4           |                   |               |

+========+================+===============+===================+===============+
It seems 2nd and 3rd column may be combined. Thus, the LFIB will be almost the same as in the e2e case.
Whatsoever, new forwarding semantics cannot be supported by the traditional MS-PW, and need to be developed in IETF.

Cheers,
Yuanlong

From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Balázs Varga A
Sent: Thursday, February 23, 2017 10:47 PM
To: Jouni Korhonen; [email-masked]
Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw

Hi,

The differences are:

Have I missed something?

Cheers

Bala’zs

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]]
Sent: Wednesday, February 22, 2017 8:21 PM
To: Balázs Varga A <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw

Hi,

|        | d-pw3          | d-pw3         |                |               |

    seen on wire..

    given detnet flow.

|        |                | push L1         | A->B          |

|        |                | push L3         | A->C          |

|        | (L2/L7 popped) |                 |               |

- JOuni

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 24 Feb 2017 00:03:53 -0800

Hi Yuanlong,

In the latter "MS-PW in segment by segment” how is the elimination done i.e., how do you associate two different incoming PWs to the same elimination function? What is the lookup mechanism?

- JOuni

> On 23 Feb 2017, at 23:30, Jiangyuanlong <[email-masked]> wrote:
> 
> Hi Jouni and Balazs,
>

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 24 Feb 2017 09:08:14 +0000

Jouni,

The elimination function can be regarded as a queuing system (e.g., indexed by a "virtual label" as you said) and redundant packets in the queue are eliminate by their sequence number); two different incoming PWs are directed to the same queue for elimination.
The lookup is still based on the PW label (that is, two PW label value are mapped to the same queue index). This is similar to the scenario that an output port accepts packets from two input ports.

Cheers,
Yuanlong

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Friday, February 24, 2017 4:04 PM
To: Jiangyuanlong
Cc: Balázs Varga A; [email-masked]
Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw

Hi Yuanlong,

- JOuni

> +========+================+===============+===========================
> +========+
> +========+================+===============+===================+=======
> +========+
> +========+================+===============+===================+=======
> +========+
> +========+================+===============+===================+=======
> +========+
> +========+================+===============+===================+=======
> +========+
> +========+================+===============+===================+=======
> +========+
> So, if I understand it correctly, You intend to use the d-pw as 
> local-ID to have less label operation cycle. However counting the 
> number of label operations I do not see the difference, please correct me if I have not counted correctly.
>  
> +========+================+===============+===========================
> +==+===+
> +========+================+===============+================+==========
> +==+===+
> +========+================+===============+================+==========
> +==+===+
> +========+================+===============+================+==========
> +==+===+
> +========+================+===============+================+==========
> +==+===+
> +========+================+===============+================+==========
> +==+===+
>  
> Also, the ‘outgoing-label’ column would not be needed, however, there 
> would not be any LFIB savings since the same amount of information 
> would be needed for d-pw to L-Labels mapping. Basically the LFIB for e2e d-pws would look like this (slide 4 from detnet-frer-loa.pptx):
>  

_______________________________________________
Detnet-dp-dt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet-dp-dt

---

From: Loa Andersson <[email-masked]>
Date: Fri, 24 Feb 2017 17:27:25 +0800

Yuanlong,

I still don't get it

On 2017-02-24 17:08, Jiangyuanlong wrote:
> Jouni,
>
> The elimination function can be regarded as a queuing system (e.g., indexed by a "virtual label"
so we have incoming packets with MS-PW labels on top, let us say that
there are 101 MS-PWs (50 on one port and 51 on the other) and 250 
packets per port, the function that sticks the "virtual label" on how 
does that work?

/Loa

as you said) and redundant packets in the queue are eliminate by their 
sequence number); two different incoming PWs are directed to the same 
queue for elimination.

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 24 Feb 2017 01:48:47 -0800

Hi Yuanlong,

Okay thanks. I don’t really see the advantage over previous proposals because I still need an additional mapping for elimination purposes.

- JOuni

> On 24 Feb 2017, at 01:08, Jiangyuanlong <[email-masked]> wrote:
> 
> Jouni,
>

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 24 Feb 2017 09:49:41 +0000

Hi Loa,

I appended the picture here:

In our scenario, the Elimination function on B accept two PWs in parallel, so the detnet PWs are attached to B (or C) in pairs.

Note that pw5 and pw6 are actually a single PW with two label value (one for upstream, and the other for the downstream).

Thus, we will not have odd number of detnet PWs in this case.

Thanks,

Yuanlong

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Friday, February 24, 2017 5:27 PM
To: [email-masked]
Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw

Yuanlong,

I still don't get it

> The elimination function can be regarded as a queuing system (e.g., indexed by a "virtual label"

so we have incoming packets with MS-PW labels on top, let us say that there are 101 MS-PWs (50 on one port and 51 on the other) and 250 packets per port, the function that sticks the "virtual label" on how does that work?

/Loa

as you said) and redundant packets in the queue are eliminate by their sequence number); two different incoming PWs are directed to the same queue for elimination.

> Cc: Balázs Varga A; [email-masked]<mailto:[email-masked]>

>> On 23 Feb 2017, at 23:30, Jiangyuanlong <[email-masked]<mailto:[email-masked]>> wrote:

>> Compared with the LFIB for e2e d-pws as you described: (slide 4 from

>> detnet-frer-loa.pptx)

>> The LFIB for MS-PW in segment by segment would look like this (same

>> slide 4)

>> (Note: for each LSP Lx, a PW segment PWx is assumed to be established;

>> Elimination takes two PWs in this case)

>> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of

>> Balázs Varga A

>> To: Jouni Korhonen; [email-masked]<mailto:[email-masked]>

>> To: Balázs Varga A <[email-masked]<mailto:[email-masked]>>;

>> [email-masked]<mailto:[email-masked]>

>>> - detnet-flow1: A -- > D (B is just a segment-stitching point, C

>>> does

>>> - detnet-flow2: F -- > G (E is just a segment-stitching point, B

>>> does

>>> <detnet-frer-balazs_v0222.pptx>_____________________________________

>>> __

--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>

Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 24 Feb 2017 09:57:13 +0000

Agreed, but it does not need global labels. For a large metro network, labels may become precious.

Thanks,
Yuanlong
-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Friday, February 24, 2017 5:49 PM
To: Jiangyuanlong
Cc: Balázs Varga A; [email-masked]
Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw

Hi Yuanlong,

- JOuni

> Jouni Korhonen
>> (Note: for each LSP Lx, a PW segment PWx is assumed to be 
>> established; Elimination takes two PWs in this case)
>> +========+================+===============+==========================
>> +=
>> +========+
>> +========+================+===============+===================+======
>> +=
>> +========+
>> +========+================+===============+===================+======
>> +=
>> +========+
>> +========+================+===============+===================+======
>> +=
>> +========+
>> +========+================+===============+===================+======
>> +=
>> +========+
>> +========+================+===============+===================+======
>> +=
>> +========+
>> c, duplicate elimination using the local-ID  d, replication + swap 
>> “virtual-label1” -- > “d-pw2”
>> Solution-2, Globally unique d-pw scenario  a, ingress packet has two 
>> labels “d-pw + l1”
>>  b, label operation: pop “l1” -- > “d-pw” = local-ID  c, duplicate 
>> elimination using the local-ID  d, replication + push “l2”
>> +========+================+===============+==========================
>> +=
>> +==+===+
>> +========+================+===============+================+=========
>> +=
>> +==+===+
>> +========+================+===============+================+=========
>> +=
>> +==+===+
>> +========+================+===============+================+=========
>> +=
>> +==+===+
>> +========+================+===============+================+=========
>> +=
>> +==+===+
>> +========+================+===============+================+=========
>> +=
>> +==+===+
>>

---

From: Loa Andersson <[email-masked]>
Date: Fri, 24 Feb 2017 18:27:20 +0800

Yuanlong,

So B, C and D needs to do elimination.

B needs to know that pw1 (except for swapping to pw2) is equivalent with
pw6 if it comes in from C but not if it comes A.

C needs to know that pw3 (except for swapping to pw2) is equivalent with
pw4 if it comes in from C but not if it comes A.

And so on,  ....
How is this simpler??

Adding the end-to-end label is both hardware friendly (that is at lest 
what Jouni said) and only normal MPLS config, and possible to
use with existing control plane.

It seems like you solve the problem I had with the same d-pw value comes 
in from two different nodes, if you can get the mapping mechanism right, 
but just now I don't see how this should be done.

/Loa

On 2017-02-24 17:49, Jiangyuanlong wrote:
> In our scenario, the Elimination function on B accept two PWs in
> parallel, so the detnet PWs are attached to B (or C) in pairs.
>
> Note that pw5 and pw6 are actually a single PW with two label value (one
> for upstream, and the other for the downstream).
>
> Loa Andersson
>> Cc: Balázs Varga A; [email-masked] <mailto:[email-masked]>
>
>> In the latter "MS-PW in segment by segment”how is the elimination done i.e., how do you associate two different
> incoming PWs to the same elimination function? What is the lookup mechanism?
>
>>
>
>> - JOuni
>
>>
>
>>
>
>>
>
>>
>
>>> On 23 Feb 2017, at 23:30, Jiangyuanlong <[email-masked] <mailto:[email-masked]>> wrote:
>
>>>
>
>>> Hi Jouni and Balazs,
>
>>>
>
>>> To: Jouni Korhonen; [email-masked] <mailto:[email-masked]>
>
>>> Thanks for the details, the “virtual label”is a good visualization of the problem.
>
>>> The “virtual label”is practically the local-ID of the detnet-(compound)-flow.
>
>>>
>
>>>   b, label operation: swap “d-pw1”-- > “virtual-label1”= local-ID
>
>>>   d, replication + swap “virtual-label1”-- > “d-pw2”
>
>>>   b, label operation: pop “l1”-- > “d-pw”= local-ID
>
>>> [email-masked] <mailto:[email-masked]>
>
>>>> On Feb 22, 2017, at 8:08 AM, Balázs Varga A <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>>>>
>
>>>> Hi,
>
>>>>
>
>>>> but that is the same as for “normal”MS-PW scenarios.
>
>>>
>
>>> Except that you need more state than in a “normal”MS-PW scenario. Each x-PE has to have an additional many-to-one
> mapping of d-pw labels to be able to associate a single seqnum &
> duplicate elimination function to a set of incoming PWs. For this
> purpose I added a ‘virtual label’column.
>
>>>
>
>>>     “virtual label”to which the seqnum and elimination book keeping is
>
>>> (2) The ‘virtual label’the seqnum etc logic is associated with for a
>
>>>     given detnet flow.
>
>>> So, if we had a “global”e2e d-pw label for each detnet flow, the ‘elimination’
>
>>> Also, the ‘outgoing-label’column would not be needed, however, there
>
>>>> [email-masked] <mailto:[email-masked]>
>
>> [email-masked] <mailto:[email-masked]>
>
>> [email-masked] <mailto:[email-masked]>
>
> <mailto:[email-masked]>
>
> Senior MPLS Expert                          [email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>
>

--

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 24 Feb 2017 08:46:39 -0800

Hi,

Global labels was one proposal alternative. The other was the 'virtual
label'. What's the advantage  of your proposal over it?

Jouni

Sent from a smart phone.. Mind the typos..

> On Feb 24, 2017, at 01:57, Jiangyuanlong <[email-masked]> wrote:
>

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 24 Feb 2017 14:44:36 -0800

Folks,

Let’s try to get to a rough agreement here. We are going around very similar approaches. I would like to progress with the draft text further where I am now. There’s other stuff to dig into still.

We seem have three candidates on table (all based on MS-PWs):

1) Global d-pw labels, L-Labels necessary (Jouni)
2) Per PW d-pw labels, virtual labels (or local-id), no L-Labels necessary (Balazs + Jouni)
3) Per PW d-pw labels, virtual labels/queue (or local-id), L-Labels (Yuanlong)

Alternatives 2 and 3 are very close. The difference in elimination whether it uses a “virtual label” or a “internal port/queue” that achieves the same is technically minor. For clarity and documentation purpose a virtual label or node-id is probably cleaner. The difference to me between 2 and 3 is how the replication is done. Alternative 2 swaps d-pw labels only after the replication. Alternative 3 pushes L-labels in addition to d-pw label swaps. I would say it is safe to merge alternatives 2 and 3, and let the L-label layer to be an operational decision.

Alternative 1 is more straight forward from the hw point of view than 2 and 3. No label swaps for the elimination and replication. Replication also pushes L-labels. HOWEVER, I am not sure how much headache it introduces to the control plane. Someone more knowledgeable in that domain than me should bring facts in (e.g., lecture us of RFC4447, 5003 and some 5036). With a static control plane (“god box”/PCE approach) one does not care since everything is just programmed from a single point that has a full view of the topology, every flow and label in use. Dynamic control plane (LDP, BGP, etc) is a different beast. However, whatever we do some work is needed on the control plane protocols i.e., bringing in the concept of the DetNet flow over MS-PW, replication and elimination. That may be as simple as new PW Types, Status Codes, etc, but can also be more..

Any preferences? I am actually OK with both 1 and 2 (with optional L-labels). My decision between the two will eventually be impacted by the control plane complexity (the analysis is still to-do).

- Jouni

> On Feb 24, 2017, at 2:27 AM, Loa Andersson <[email-masked]> wrote:
> 
> Yuanlong,
> 
> Adding the end-to-end label is both hardware friendly (that is at lest what Jouni said) and only normal MPLS config, and possible to
> It seems like you solve the problem I had with the same d-pw value comes in from two different nodes, if you can get the mapping mechanism right, but just now I don't see how this should be done.
> 
> /Loa
>

---

From: Jiangyuanlong <[email-masked]>
Date: Sat, 25 Feb 2017 02:03:27 +0000

Jouni,

Thank a lot for the summary. Please see my further comments inline.

Cheers,
Yuanlong
-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Saturday, February 25, 2017 6:45 AM
To: [email-masked]
Cc: Jiangyuanlong; Loa Andersson
Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw

Folks,

1) Global d-pw labels, L-Labels necessary (Jouni)
2) Per PW d-pw labels, virtual labels (or local-id), no L-Labels necessary (Balazs + Jouni)
3) Per PW d-pw labels, virtual labels/queue (or local-id), L-Labels (Yuanlong)
[YJ] I regard the L-Labels and T-labels are the same LSP layer. If we look into the full MPLS label stack of a packet in a PW, normally there is an LSP label at the top (unless PHP is enabled for the last hop). 
Not sure what is the L-Label in your picture, is it different from LSP label? 

Alternatives 2 and 3 are very close. The difference in elimination whether it uses a “virtual label” or a “internal port/queue” that achieves the same is technically minor. For clarity and documentation purpose a virtual label or node-id is probably cleaner. The difference to me between 2 and 3 is how the replication is done. Alternative 2 swaps d-pw labels only after the replication. Alternative 3 pushes L-labels in addition to d-pw label swaps. I would say it is safe to merge alternatives 2 and 3, and let the L-label layer to be an operational decision.
[YJ] LSP labels are pushed to a packet upon egress port to a PW.

- Jouni

> what Jouni said) and only normal MPLS config, and possible to use with existing control plane.
> 
>> Note that pw5 and pw6 are actually a single PW with two label value 
>> (one for upstream, and the other for the downstream).
>> 
>> as you said) and redundant packets in the queue are eliminate by 
>> their sequence number); two different incoming PWs are directed to 
>> the same queue for elimination.
>> 
>>> <mailto:[email-masked]>
>> 
>>> In the latter "MS-PW in segment by segment”how is the elimination 
>>> done i.e., how do you associate two different
>>>> established;
>>>> +========+================+===============+========================
>>>> +===
>> 
>>>> +========+
>> 
>>>> +========+================+===============+===================+====
>>>> +===
>> 
>>>> +========+
>> 
>>>> +========+================+===============+===================+====
>>>> +===
>> 
>>>> +========+
>> 
>>>> +========+================+===============+===================+====
>>>> +===
>> 
>>>> +========+
>> 
>>>> +========+================+===============+===================+====
>>>> +===
>> 
>>>> +========+
>> 
>>>> +========+================+===============+===================+====
>>>> +===
>> 
>>>> +========+
>> 
>>>> <mailto:[email-masked]>
>> 
>>>> Except that you need more state than in a “normal”MS-PW scenario. 
>>>> Each x-PE has to have an additional many-to-one
>>>> +========+================+===============+========================
>>>> +===
>> 
>>>> +==+===+
>> 
>>>> | Device | Incoming-Label 
>>>> | |---------------|--------------------------------|
>> 
>>>> +========+================+===============+================+=======
>>>> +===
>> 
>>>> +==+===+
>> 
>>>> +========+================+===============+================+=======
>>>> +===
>> 
>>>> +==+===+
>> 
>>>> +========+================+===============+================+=======
>>>> +===
>> 
>>>> +==+===+
>> 
>>>> +========+================+===============+================+=======
>>>> +===
>> 
>>>> +==+===+
>> 
>>>> +========+================+===============+================+=======
>>>> +===
>> 
>>>> +==+===+
>> 
>>>> 
>>

---

From: Loa Andersson <[email-masked]>
Date: Sat, 25 Feb 2017 12:54:16 +0800

Folks,

I think every step to try summarize is good.

I still miss some corner stones and some context.

If we want to design existing control planes out, we can almost
anything.

If we want design existing control planes in, we have to consider
what they'll do and take that into account.

I think, but is not sure, that we now have both "god box" and LDP,
RSVP-TE and segment routing in scope. I'd like to keep it that way.

If we can agree on that we can start evaluating the different proposal 
against this back ground, or whatever control we think is appropriate.

/Loa

--

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 24 Feb 2017 23:06:32 -0800

Hi,

> Not sure what is the L-Label in your picture, is it different from LSP label? 

L-labels have been so far in the discussion between MS-PW PEs. T-labels are between any LSR. L-labels are not PHPed i.e., even if PHP is enable the L-Label stays and the label above it gets popped (that we have been referring as T-Labels). T- and L-labels are just a naming convention. IF you don’t have “between MS-PW PEs” semantic associated with the L-Label, it is the same as T-Label ;)

case L-labels are present.. (alternative 1)
   
                     PHP
                   -------->
+------------+                  +------------+
|  T-labels  |                  |  L-label   |
+------------+                  +------------+
|  L-label   |                  | d-pw label |
+------------+                  +------------+
| d-pw label |                  |            |
+------------+                  |  Payload   |
|            |                  |            |
|  Payload   |                  +------------+
|            |
+------------+

case no L-labels.. (alternative 2.. and also alternative 3 if you think T- and L-labels are the same)

                     PHP
                   -------->
+------------+                  +------------+
|  T-labels  |                  | d-pw label |
+------------+                  +------------+
| d-pw label |                  |            |
+------------+                  |  Payload   |
|            |                  |            |
|  Payload   |                  +------------+
|            |
+------------+

- Jouni

---

From: Jiangyuanlong <[email-masked]>
Date: Sat, 25 Feb 2017 07:18:07 +0000

I agreed to alternative 2. L-label is not needed, S-PE must look into the PW label (further, extract sequence number in the CW) of a packet, and all FRER semantics can be coupled with the PW label.

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Saturday, February 25, 2017 3:07 PM
To: Jiangyuanlong
Cc: [email-masked]; Loa Andersson
Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw

Hi,

   
                     PHP
                   -------->

                     PHP
                   -------->

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 24 Feb 2017 23:23:28 -0800

Hi,

> On 24 Feb 2017, at 23:18, Jiangyuanlong <[email-masked]> wrote:
> 

Ok. Just note that alternative 1 also looks into d-pw label etc. There is no difference regarding FRER logic in that sense. The T-PE or S-PE just has to pop L-Label _within_ the node before it looks into d-pw.

- Jouni

---

From: Loa Andersson <[email-masked]>
Date: Sat, 25 Feb 2017 15:34:08 +0800

Yuanlong,

The L-laabel is ther to make the the intermediate not (S-PE) know what
to do whit the packet, the d-pw label was not allocated by the S-PE, so
it does not ahve any knowledge what it means.

If you let the S-PEs allocate and swap d-pw's, the next S-PE or a T-PE 
can't coordinate for the same packet coming in on from tow different
nodes.

But I feel like we are going in circles, can we agree on the corner 
stones first?

Do we want all possible/conceivable control mechanism be within scope?

/Loa

--

---

From: Jiangyuanlong <[email-masked]>
Date: Sat, 25 Feb 2017 10:02:13 +0000

Loa,

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Saturday, February 25, 2017 3:34 PM
To: Jiangyuanlong; Jouni Korhonen
Cc: [email-masked]
Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw

Yuanlong,

The L-laabel is ther to make the the intermediate not (S-PE) know what to do whit the packet, the d-pw label was not allocated by the S-PE, so it does not ahve any knowledge what it means.
[YJ] d-pw can be allocated by the S-PE in MS-PW, just as you would like to allocate the L-labels. Very similarly, I think the same T-LDP protocol can be used.
[YJ] As I said in the previous email, using PW to trigger FRER will be cleaner compared with using L-label since CW is inspected.

If you let the S-PEs allocate and swap d-pw's, the next S-PE or a T-PE can't coordinate for the same packet coming in on from tow different nodes.
[YJ] It's like the 1+1 PW protection case, though the operations of elimination and replication in the S-PE and the T-PE need to be specified.
[YJ]Take VPLS as an example, several PWs can be directed into the same VSI in a PE and PW packets are processed there (for detnet, the processing is FRER now).

But I feel like we are going in circles, can we agree on the corner stones first?

Do we want all possible/conceivable control mechanism be within scope?
[YJ] maybe we can take LDP as a first step. It seems the difficulty is how to decide the S-PEs for a detnet flow (a routing protocol may be needed for automatic selection). 
[YJ] if all T-PEs and S-PEs are determined for a detnet flow, it is quite easy to set up PW segments and LSPs respectively with the help of LDP protocol. 
Cheers,
Yuanlong

/Loa

On 2017-02-25 15:18, Jiangyuanlong wrote:
> L-labels have been so far in the discussion between MS-PW PEs. 
> T-labels are between any LSR. L-labels are not PHPed i.e., even if PHP 
> is enable the L-Label stays and the label above it gets popped (that 
> we have been referring as T-Labels). T- and L-labels are just a naming 
> convention. IF you don’t have “between MS-PW PEs” semantic associated 
> with the L-Label, it is the same as T-Label ;)
>
>
>

--

---

From: Loa Andersson <[email-masked]>
Date: Sat, 25 Feb 2017 18:30:04 +0800

Yuanlong,

> [YJ] d-pw can be allocated by the S-PE in MS-PW, just as you would like to allocate the L-labels. Very similarly, I think the same T-LDP protocol can be used.

If you do that the S-PE will swap the d-pw, packets will come in from
two different directions with differnt d-pws to the egress, and there
is no way for the egress to identify packets to eliminate.

/Loa
and the egress will have no way

> [YJ] As I said in the previous email, using PW to trigger FRER will be cleaner

compared with using L-label since CW is inspected.

--

---

From: Jouni Korhonen <[email-masked]>
Date: Sat, 25 Feb 2017 20:36:56 -0800

Yuanlong,

> On 25 Feb 2017, at 02:02, Jiangyuanlong <[email-masked]> wrote:
> 
> Loa,
> 

I think you are still getting it wrong what was intended with L-labels. They were specifically thought in the context of detnet global d-pw labels.

L-labels connected MS-PW nodes over the network topology. All FRER “triggering” etc is still and has always been tied to the d-pw. Within a S- or T-PE you need to pop the L-label and then inspect the top of stack d-pw label.. 

                                                 within
    LSR                         |------------- S- or T-PE -------------|
                    PHP                            POP 
                  -------->                     -------->
+------------+                  +------------+            +------------+
|  T-labels  |                  |  L-label   |            | d-pw label |
+------------+                  +------------+            +------------+
|  L-label   |                  | d-pw label |            |            |
+------------+                  +------------+            |  Payload   |
| d-pw label |                  |            |            |            |
+------------+                  |  Payload   |            +------------+
|            |                  |            |
|  Payload   |                  +------------+
|            |
+------------+

This allowed also bypassing S-PE easily for some L-labels.. instead of an L-label pop one would do a swap and just forward after that.

- Jouni

---

From: Loa Andersson <[email-masked]>
Date: Sun, 26 Feb 2017 13:05:34 +0800

Jouni,

> I think you are still getting it wrong what was intended with L-labels. They were specifically thought in the context of detnet global d-pw labels.

hmmmm -yes, but not in the sense that the mpls wg use "global", the
special purpose labels are global, they mean the same thing where ever
you find them. Here we have end-to-end labels, labels that stays the
same all through the forwarding process in the network.

/Loa

--

---

From: Jouni Korhonen <[email-masked]>
Date: Sat, 25 Feb 2017 21:10:30 -0800

Loa,

Ok. Point taken. Global is bad wording. I try to remember to use e2e from now on.

- Jouni

> On 25 Feb 2017, at 21:05, Loa Andersson <[email-masked]> wrote:
> 
> Jouni,
>

---

From: Balázs Varga A <[email-masked]>
Date: Sun, 26 Feb 2017 15:45:39 +0000

Hi, 
Maybe even more precise: "e2e (and globally unique) d-pw labels"
Cheers
Bala'zs

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Sunday, February 26, 2017 6:11 AM
To: Loa Andersson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw

Loa,

- Jouni

>>>> T-labels are between any LSR. L-labels are not PHPed i.e., even if 
>>>> PHP is enable the L-Label stays and the label above it gets popped 
>>>> (that we have been referring as T-Labels). T- and L-labels are just 
>>>> a naming convention. IF you don’t have “between MS-PW PEs” semantic 
>>>> associated with the L-Label, it is the same as T-Label ;)
>>>> 
>>>> 
>>>>

---

From: Balázs Varga A <[email-masked]>
Date: Sun, 26 Feb 2017 15:46:03 +0000

Hi,

Jumping back to Jouni's original questions combined with the results of the weekend

mailings & Loa's comment on label allocation.

We seem to have three parameters and trying to cover all possible combinations:

1, d-pw label: e2e (and globally unique)  vs.  per PW-segment

2, l-label: mandatory  vs.  optional

3, label allocation: central (god-box)  vs.  distributed (protocol driven)

Current state of discussion, regarding dependencies:

1, e2e label requires somewhat less resources on the chip (no virtual-label). Per

PW-segment labels are from label maintenance perspective same as current

MS-PW implementations. FRER (replication and elimination) requires additional

resources, but it is the same for both options.

2, l-labels are mandatory for e2e d-pw labels.

3, Central label allocation works for any combination of "1" and "2". Distributed

(protocol driven) label allocation has challenges for the "e2e d-pw label" to ensure

collision-free allocation. In case of "per PW-segment d-pw label" the MS-PW

related label distribution methods can be used. For the "l-label" current TE tunnel

setup methods can be considered (I am not sure we have all the required functions).

Summarizing it in a table:

        |   with     |  without   |

        |  l-label   |  l-label   |

--------+------------+------------+

        | SDN | Prot |            |

  e2e   |     |      |     \/     |

   d-pw | OK  | ??+  |     /\     |

        |     | TE(?)|            |

--------+------------+------------+

        | SDN | Prot | SDN | Prot |

per-PW |     |      |     |      |

segment| OK  |MS-PW | OK  |MS-PW |

        |     |+TE(?)|     |      |

--------+------------+------------+

Based on the above one possible conclusion is:

- God-box (SDN) based label allocation works for any "d-pw + l-label" combinations.

- Protocol based allocation needs extensions of current protocols for "e2e d-pw"
(and maybe for "l-label") scenarios.

Cheers

Bala'zs

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Friday, February 24, 2017 11:45 PM
To: [email-masked]
Cc: Jiangyuanlong <[email-masked]>; Loa Andersson <[email-masked]>
Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw

Folks,

- Jouni

--

M: +1-408-391-7160

> On Feb 24, 2017, at 2:27 AM, Loa Andersson <[email-masked]<mailto:[email-masked]>> wrote:

> B needs to know that pw1 (except for swapping to pw2) is equivalent

> with

> C needs to know that pw3 (except for swapping to pw2) is equivalent

> with

>> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf

>> Of Loa Andersson

>> To: [email-masked]<mailto:[email-masked]>

>>> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf

>>> Of Jouni Korhonen

>>>> On 23 Feb 2017, at 23:30, Jiangyuanlong <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>> wrote:

>>>> Compared with the LFIB for e2e d-pws as you described: (slide 4

>>>> from

>>>> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf

>>>> Of

>>>> To: Balázs Varga A <[email-masked]

>> <mailto:[email-masked]>>;

>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>>>>> On Feb 22, 2017, at 8:08 AM, Balázs Varga A

>>>>> <[email-masked]

>>>>> There is no d-pw label collision at B as it allocates the d-pw

>>>>> label

>>>>> You can treat as a drawback that you need a state for each

>>>>> segment,

>>>> (1) For elimination purposes we need to associate all incoming d-pw

>>>> labels

>>>>    that belong to the same detnet flow to a single “virtual label”.

>>>> Here the

>>>>    “virtual label”to which the seqnum and elimination book keeping

>>>> is

>>>>    associated with is just one of the active d-pw labels, for

>>>> example, the

>>>>    first that gets configured in the device for a detnet flow

>>>> (i.e., the master

>>>>    label). The label could also be truly a virtual label value that

>>>> is never

>>>> (2) The ‘virtual label’the seqnum etc logic is associated with for

>>>> a

>>>> (3) Replication is more or less equivalent to existing 1+1

>>>> protection. One

>>>> Also, the ‘outgoing-label’column would not be needed, however,

>>>> there

>>>>> <detnet-frer-balazs_v0222.pptx>___________________________________

>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>> Senior MPLS Expert                          [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 26 Feb 2017 17:07:16 -0800

Thanks Balazs,

That was a great summary. 

- Jouni

> On 26 Feb 2017, at 07:46, Balázs Varga A <[email-masked]> wrote:
> 
> Hi,
>

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 27 Feb 2017 08:41:02 +0000

Jouni,

I must admit that I am confused by the use of "T-label" and "L-label". But, whatever it calls, I mean the label that stands for the MPLS path from T-PE to the S-PE.
Please note that the LSP (Label Switching Path) from T-PE to the S-PE does not require that the same label value be used for each node on the path, but may change hop by hop.
For example, S-PE node (B) receives label 10 from node 2, while the label sent by node (A) is 20, node (B) knows that the packets originated from node (A) if these two labels belong to the same LSP.
Since LSP can be an hierarchy itself (i.e., LSP over another LSP tunnel), I suggest not to use both terms to simplify the problem space.

Thanks,
Yuanlong

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Sunday, February 26, 2017 12:37 PM
To: Jiangyuanlong
Cc: [email-masked]
Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw

Yuanlong,

                                                 within

- Jouni

>> (that we have been referring as T-Labels). T- and L-labels are just a 
>> naming convention. IF you don’t have “between MS-PW PEs” semantic

---

From: Loa Andersson <[email-masked]>
Date: Mon, 27 Feb 2017 18:54:35 +0800

Yuanlong,

On 2017-02-27 16:41, Jiangyuanlong wrote:
> Jouni,
>
> I must admit that I am confused by the use of "T-label" and "L-label".
This is from one point of correct, it is labels in the same label stack.
Naming the outermost label T-label is a long standing convention.
Naming the label below the T-label L-labels is also somewhat of a
convention.
But, whatever it calls, I mean the label that stands for the MPLS path 
from T-PE to the S-PE.
Slightly incorrect, the LSP takes from the T.DetNet-PE to a
S-DettNet-PE (I think we need to agree on terminology to communcate).
The outer label only takes you one hop.
> Please note that the LSP (Label Switching Path) from T-PE to the S-PE does not require that the same label value be used for each node on the path,
this is correct, the requirement is the opposite, the label changes
every hop.
but may change hop by hop.
As I said - it will change at every hop. One reason (not the only) to
have a label below the outer label in the stack is that the receiving
node might have reason to know where the packet came from, the T-label
does not give that info, the L-label does.
> For example, S-PE node (B) receives label 10 from node 2,
We normally don't use special purpose labels in examples

while the label sent by node (A) is 20,

The label operations are correct (hop-by-hop)
node (B) knows that the packets originated from node (A) if these two 
labels belong to the same LSP.

Let us say that you have used LDP to set up the LSP, when B receives
the label you call 10, exactly how does it know that the LSP originated
from A?

> Since LSP can be an hierarchy itself (i.e., LSP over another LSP tunnel), I suggest not to use both terms to simplify the problem space.

Well, I guess you are about two decades to late for that terminology
reform. We have lived with it almost all the time MPLS has been around,
it is not a coincidence that e.g. RFC 3209 was called  RSVP-TE: 
Extensions to RSVP for LSP Tunnels (draft-ietf-mpls-rsvp-lsp-tunnel).

/Loa

--

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 27 Feb 2017 11:25:55 +0000

Loa, 

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Monday, February 27, 2017 6:55 PM
To: [email-masked]
Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw

Yuanlong,

This is from one point of correct, it is labels in the same label stack.
Naming the outermost label T-label is a long standing convention.
Naming the label below the T-label L-labels is also somewhat of a convention.
But, whatever it calls, I mean the label that stands for the MPLS path from T-PE to the S-PE.
Slightly incorrect, the LSP takes from the T.DetNet-PE to a S-DettNet-PE (I think we need to agree on terminology to communcate).
The outer label only takes you one hop.
[JY] Thanks much for the clarification. Then for all options, we will need this L-label, right?

> Please note that the LSP (Label Switching Path) from T-PE to the S-PE 
> does not require that the same label value be used for each node on 
> the path,
this is correct, the requirement is the opposite, the label changes every hop.
but may change hop by hop.
As I said - it will change at every hop. One reason (not the only) to have a label below the outer label in the stack is that the receiving node might have reason to know where the packet came from, the T-label does not give that info, the L-label does.
[YJ] Good to know that;)

The label operations are correct (hop-by-hop) node (B) knows that the packets originated from node (A) if these two labels belong to the same LSP.

Let us say that you have used LDP to set up the LSP, when B receives the label you call 10, exactly how does it know that the LSP originated from A?

> Since LSP can be an hierarchy itself (i.e., LSP over another LSP tunnel), I suggest not to use both terms to simplify the problem space.

Well, I guess you are about two decades to late for that terminology reform. We have lived with it almost all the time MPLS has been around, it is not a coincidence that e.g. RFC 3209 was called  RSVP-TE: 
Extensions to RSVP for LSP Tunnels (draft-ietf-mpls-rsvp-lsp-tunnel).

[YJ] We need to setup two paths from T-PE1 to T-PE2 (not sharing fate if possible), traversing S-PE1 and S-PE2. I think RSVP-TE would be more likely to serve our purpose than LDP, it also provides bandwidth reservation and QoS guarantee.

Thanks again,
Yuanlong

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Mon, 27 Feb 2017 22:03:10 +0800

Yuanlong,

> [YJ] We need to setup two paths from T-PE1 to T-PE2 (not sharing fate if possible), traversing S-PE1 and S-PE2. I think RSVP-TE would be more likely to serve our purpose than LDP, it also provides…

Two comments

1. It is likely that RSVP-TE will be used for everything that involves
QOS and BW.I don't think the an LSR takes the destination from the
EXPLICIT ROUTE object and put it into the LIB; if it doesn't the node
will have to pull the packet from the fast path and do forwarding in HW.
Anyone that know the exact behavior of RSVP-TE.
So in the data plane I don't think an LSR has the information onm

2. LDP is still in scope and will be used for PWs, so the question is
still valid. If you use LDP how do you know the ingress.

/Loa
--