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

[Balázs Varga A <[e-mail]>]

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]<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