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

[Jouni Korhonen <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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:[e-mail]] On Behalf Of Jouni Korhonen
> Sent: Friday, February 24, 2017 4:04 PM
> To: Jiangyuanlong
> Cc: Balázs Varga A; [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]> 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]
>> 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]>om>; 
>> [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]> 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]
>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
> 
> _______________________________________________
> Detnet-dp-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt