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

[Loa Andersson <[e-mail]>]

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:
> 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:[e-mail]] On Behalf Of
> Loa Andersson
> Sent: Friday, February 24, 2017 5:27 PM
> To: [e-mail]
> Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw
>
>
>
> 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.
>
>> 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:[e-mail]] On Behalf Of Jouni Korhonen
>
>> Sent: Friday, February 24, 2017 4:04 PM
>
>> To: Jiangyuanlong
>
>> Cc: Balázs Varga A; [e-mail] <mailto:[e-mail]>
>
>> Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw
>
>>
>
>> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>
>>>
>
>>> 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)
>
>>> +========+================+=================================+
>
>>> |        |                |      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) |                 |               |
>
>>> +========+================+=================+===============+
>
>>>
>
>>>
>
>>> 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)
>
>>> +========+================+===============+===========================
>
>>> +========+
>
>>> |        |                | Elimination   |        Forwarding Semantics       |
>
>>> | 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:[e-mail]] On Behalf Of
>
>>> Balázs Varga A
>
>>> Sent: Thursday, February 23, 2017 10:47 PM
>
>>> To: Jouni Korhonen; [e-mail] <mailto:[e-mail]>
>
>>> Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw
>
>>>
>
>>> 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:[e-mail]]
>
>>> Sent: Wednesday, February 22, 2017 8:21 PM
>
>>> To: Balázs Varga A <[e-mail]
> <mailto:[e-mail]>>;
>
>>> [e-mail] <mailto:[e-mail]>
>
>>> Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw
>
>>>
>
>>> Hi,
>
>>>
>
>>> Thank you for this. It is very useful. Few comments inline.
>
>>>
>
>>>> On Feb 22, 2017, at 8:08 AM, Balázs Varga A <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>>>>
>
>>>> Hi,
>
>>>>
>
>>>> d-pw collision can be solved if the MS-PW concept is used for the DetNet-PW.
>
>>>
>
>>> 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?
>
>>>
>
>>>> 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.
>
>>>
>
>>> 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
>
>>>> [e-mail] <mailto:[e-mail]>
>
>>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>
>>
>
>> _______________________________________________
>
>> Detnet-dp-dt mailing list
>
>> [e-mail] <mailto:[e-mail]>
>
>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>
>> _______________________________________________
>
>> Detnet-dp-dt mailing list
>
>> [e-mail] <mailto:[e-mail]>
>
>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>
>>
>
>
>
> --
>
>
>
>
>
> Loa Andersson                        email: [e-mail]
> <mailto:[e-mail]>
>
> Senior MPLS Expert                          [e-mail] <mailto:[e-mail]>
>
> Huawei Technologies (consultant)     phone: [phone]
>
>
>
> _______________________________________________
>
> Detnet-dp-dt mailing list
>
> [e-mail] <mailto:[e-mail]>
>
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]