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

[Jouni Korhonen <[e-mail]>]

Thanks Balazs,

That was a great summary. 

- Jouni

> On 26 Feb 2017, at 07:46, Balázs Varga A <[e-mail]> wrote:
> 
> Hi,
>  
> Jumping back to Jouni's original questions combined with the results of the weekend
> mailings & Loa's comment on label allocation.
>  
> We seem to have three parameters and trying to cover all possible combinations:
> 1, d-pw label: e2e (and globally unique)  vs.  per PW-segment
> 2, l-label: mandatory  vs.  optional
> 3, label allocation: central (god-box)  vs.  distributed (protocol driven)
>  
> Current state of discussion, regarding dependencies:
> 1, e2e label requires somewhat less resources on the chip (no virtual-label). Per
> PW-segment labels are from label maintenance perspective same as current
> MS-PW implementations. FRER (replication and elimination) requires additional
> resources, but it is the same for both options.
> 2, l-labels are mandatory for e2e d-pw labels.
> 3, Central label allocation works for any combination of "1" and "2". Distributed
> (protocol driven) label allocation has challenges for the "e2e d-pw label" to ensure
> collision-free allocation. In case of "per PW-segment d-pw label" the MS-PW
> related label distribution methods can be used. For the "l-label" current TE tunnel
> setup methods can be considered (I am not sure we have all the required functions).
>  
> Summarizing it in a table:
>  
>         |   with     |  without   |
>         |  l-label   |  l-label   |
> --------+------------+------------+
>         | SDN | Prot |            |
>   e2e   |     |      |     \/     |
>    d-pw | OK  | ??+  |     /\     |
>         |     | TE(?)|            |
> --------+------------+------------+
>         | SDN | Prot | SDN | Prot |
> per-PW |     |      |     |      |
> segment| OK  |MS-PW | OK  |MS-PW |
>         |     |+TE(?)|     |      |
> --------+------------+------------+
>  
> Based on the above one possible conclusion is:
> - God-box (SDN) based label allocation works for any "d-pw + l-label" combinations.
> - Protocol based allocation needs extensions of current protocols for "e2e d-pw" 
> (and maybe for "l-label") scenarios.
>  
> Cheers
> Bala'zs
>  
> -----Original Message-----
> From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of Jouni Korhonen
> Sent: Friday, February 24, 2017 11:45 PM
> To: [e-mail]
> Cc: Jiangyuanlong <[e-mail]>om>; Loa Andersson <[e-mail]>
> Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw
>  
> Folks,
>  
> Let’s try to get to a rough agreement here. We are going around very similar approaches. I would like to progress with the draft text further where I am now. There’s other stuff to dig into still.
>  
> We seem have three candidates on table (all based on MS-PWs):
>  
> 1) Global d-pw labels, L-Labels necessary (Jouni)
> 2) Per PW d-pw labels, virtual labels (or local-id), no L-Labels necessary (Balazs + Jouni)
> 3) Per PW d-pw labels, virtual labels/queue (or local-id), L-Labels (Yuanlong)
>  
> Alternatives 2 and 3 are very close. The difference in elimination whether it uses a “virtual label” or a “internal port/queue” that achieves the same is technically minor. For clarity and documentation purpose a virtual label or node-id is probably cleaner. The difference to me between 2 and 3 is how the replication is done. Alternative 2 swaps d-pw labels only after the replication. Alternative 3 pushes L-labels in addition to d-pw label swaps. I would say it is safe to merge alternatives 2 and 3, and let the L-label layer to be an operational decision.
>  
> Alternative 1 is more straight forward from the hw point of view than 2 and 3. No label swaps for the elimination and replication. Replication also pushes L-labels. HOWEVER, I am not sure how much headache it introduces to the control plane. Someone more knowledgeable in that domain than me should bring facts in (e.g., lecture us of RFC4447, 5003 and some 5036). With a static control plane (“god box”/PCE approach) one does not care since everything is just programmed from a single point that has a full view of the topology, every flow and label in use. Dynamic control plane (LDP, BGP, etc) is a different beast. However, whatever we do some work is needed on the control plane protocols i.e., bringing in the concept of the DetNet flow over MS-PW, replication and elimination. That may be as simple as new PW Types, Status Codes, etc, but can also be more..
>  
> Any preferences? I am actually OK with both 1 and 2 (with optional L-labels). My decision between the two will eventually be impacted by the control plane complexity (the analysis is still to-do).
>  
>  
> - Jouni
>  
>  
> --
> Jouni Korhonen, Broadcom Ltd., Core Switching Group
> M: [phone]
>  
> > On Feb 24, 2017, at 2:27 AM, Loa Andersson <[e-mail]> wrote:
> > 
> > Yuanlong,
> > 
> > So B, C and D needs to do elimination.
> > 
> > B needs to know that pw1 (except for swapping to pw2) is equivalent
> > with
> > pw6 if it comes in from C but not if it comes A.
> > 
> > C needs to know that pw3 (except for swapping to pw2) is equivalent
> > with
> > pw4 if it comes in from C but not if it comes A.
> > 
> > And so on,  ....
> > How is this simpler??
> > 
> > Adding the end-to-end label is both hardware friendly (that is at lest
> > what Jouni said) and only normal MPLS config, and possible to use with existing control plane.
> > 
> > It seems like you solve the problem I had with the same d-pw value comes in from two different nodes, if you can get the mapping mechanism right, but just now I don't see how this should be done.
> > 
> > /Loa
> > 
> > On 2017-02-24 17:49, Jiangyuanlong wrote:
> >> Hi Loa,
> >> 
> >> 
> >> 
> >> I appended the picture here:
> >> 
> >> 
> >> 
> >> 
> >> 
> >> In our scenario, the Elimination function on B accept two PWs in
> >> parallel, so the detnet PWs are attached to B (or C) in pairs.
> >> 
> >> Note that pw5 and pw6 are actually a single PW with two label value
> >> (one for upstream, and the other for the downstream).
> >> 
> >> Thus, we will not have odd number of detnet PWs in this case.
> >> 
> >> 
> >> 
> >> Thanks,
> >> 
> >> Yuanlong
> >> 
> >> 
> >> 
> >> -----Original Message-----
> >> From: Detnet-dp-dt [mailto:[e-mail]] On Behalf
> >> Of Loa Andersson
> >> Sent: Friday, February 24, 2017 5:27 PM
> >> To: [e-mail]
> >> Subject: Re: [Detnet-dp-dt] Using MS-PW concept for the d-pw
> >> 
> >> 
> >> 
> >> Yuanlong,
> >> 
> >> 
> >> 
> >> I still don't get it
> >> 
> >> 
> >> 
> >> On 2017-02-24 17:08, Jiangyuanlong wrote:
> >> 
> >>> Jouni,
> >> 
> >>> 
> >> 
> >>> The elimination function can be regarded as a queuing system (e.g., indexed by a "virtual label"
> >> 
> >> so we have incoming packets with MS-PW labels on top, let us say that
> >> there are 101 MS-PWs (50 on one port and 51 on the other) and 250
> >> packets per port, the function that sticks the "virtual label" on how
> >> does that work?
> >> 
> >> 
> >> 
> >> /Loa
> >> 
> >> 
> >> 
> >> 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]
> >>> <mailto:[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] <mailto:[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]
> >>>> <mailto:[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]
> >> <mailto:[e-mail]>>;
> >> 
> >>>> [e-mail] <mailto:[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
> >> 
> >>> 
> >> 
> >>> _______________________________________________
> >> 
> >>> Detnet-dp-dt mailing list
> >> 
> >>> [e-mail] <mailto:[e-mail]>
> >> 
> >>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
> >> 
> >>> _______________________________________________
> >> 
> >>> Detnet-dp-dt mailing list
> >> 
> >>> [e-mail] <mailto:[e-mail]>
> >> 
> >>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
> >> 
> >>> 
> >> 
> >> 
> >> 
> >> --
> >> 
> >> 
> >> 
> >> 
> >> 
> >> Loa Andersson                        email: [e-mail]
> >> <mailto:[e-mail]>
> >> 
> >> Senior MPLS Expert                          [e-mail] <mailto:[e-mail]>
> >> 
> >> Huawei Technologies (consultant)     phone: [phone]
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> 
> >> Detnet-dp-dt mailing list
> >> 
> >> [e-mail] <mailto:[e-mail]>
> >> 
> >> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
> >> 
> > 
> > --
> > 
> > 
> > Loa Andersson                        email: [e-mail]
> > Senior MPLS Expert                          [e-mail]
> > Huawei Technologies (consultant)     phone: [phone]
> > 
> > _______________________________________________
> > 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