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

[Jouni Korhonen <[e-mail]>]

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