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

[Jouni Korhonen <[e-mail]>]

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