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

[Jouni Korhonen <[e-mail]>]

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: [phone]

> On Feb 23, 2017, at 6:46 AM, Balázs Varga A <[e-mail]> wrote:
> 
> 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