[Detnet-dp-dt] about identity labels.. was Re: new versions of my slides

[Jouni Korhonen <[e-mail]>]

Folks,

Back to d-id.. I understand the intent and need for the d-id label. What I cannot immediately see it is going to help the FRER implementation. Using Loa’s slides as a reference: assume G and D both assign the same d-pw1 label values to F and A. Fortunately the combination of d-id+d-pw is unique. However, when packets arrive at B, the seqnum+history lookup would need to use both d-id+d-pw as a combined key. This is getting cumbersome. One would need to map d-id+d-pw to something that is locally unique in LFIB or use d-id as an indirect index to separate LFIB tables holding d-pw associated information. Since d-id and d-pw are separate labels this ends up two-three lookups and carrying along the history metadata. Depending on the flexibility of the memory sub-system one might face interesting restrictions, for example on the size of the LFIB tables first indexed by d-id.

I know this was very implementation dependent rant, but how I currently see d-id, it has made life easier for a control plane and a provisioning. At the same time it seems to make the life of the hw and data structure design hard.

So far the “cleanest” solution for me has been the one with d-pw ranges configured into T-DetNet-PE devices - to prevent collisions. That one had the downside of fixed allocations put into nodes by the network administrator.

- Jouni

-- 
Jouni Korhonen, Broadcom Ltd., Core Switching Group
M: [phone]

> On Feb 27, 2017, at 2:55 AM, Balázs Varga A <[e-mail]> wrote:
> 
> Hi,
> 
> Two more additions to the "d-id + d-pw" scenario and the "PW-type discussion":
> 
> - As the "d-id + d-pw" identifies the flow (see slide6), for the data plane implementation
> we will need a "virtual-label" in the x-PE nodes (based on our mailing with Jouni). 
> Furthermore mapping two labels to the internal "virtual-label" seems not to be a simple 
> "label swap" operation.
> 
> - PW-type: as a detnet-PW requires special handling on x-PE nodes, I am afraid that we
> need a new PW-type, in order to distinguish it from a traditional PW.
> 
> Cheers
> Bala'zs
> 
> -----Original Message-----
> From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of Loa Andersson
> Sent: Monday, February 27, 2017 5:43 AM
> To: [e-mail]
> Subject: Re: [Detnet-dp-dt] new versions of my slides
> 
> Norm,
> 
> 
> On 2017-02-27 06:44, Norman Finn wrote:
>> Sorry!!  Attachment here.
>> 
>> -- Norm
>> ________________________________________
>> From: Norman Finn
>> Sent: Sunday, February 26, 2017 2:42 PM
>> To: Loa Andersson; [e-mail]
>> Subject: RE: [Detnet-dp-dt] new versions of my slides
>> 
>> Loa,
>> 
>> Slides 2, 4, 7, and 9 (the diagrams) had lots of very minor typos.  I made all fo the labels consistent in the attached version.
>> 
>> Slide 3: "Consider the replicated packet that reaches B  from E and 8,"  I think you meant, "E and 6".
> 
> right!
>> 
>> Slide 5: 2nd sub-bullet.  "LB-3 because it is an L-level label taking the packet from F to E".  I think you meant, "A to E"?
> 
> The devil is in the details -  the syntax was intended to put the destination node after the "L" (type of label) so what ( should have said "LB-3 because it is an L-level label taking the packet from A to B"
> the number after the "LB" indicates that there are more than one L-level label taking packets to B.
> 
>> 
>> One question:
>> 
>> Who guarantees d-id1 != d-id2?  Maybe I missed it, but I don't see that in the discussions in the slides.
> 
> Well I said: "config of a DetNet ID (only shown for A and F, in real life all nodes that will serve as ingress T-DetNet-Pes will need the DetNet ID)."
> 
> my take is that we will need to configure the d-id
> 
>> 
>> Answering your questions:
>> 
>> Q: Do we agree that this works even if is not optimal.
>> 
>>   Yes, if d-id1 != d-id2.
> 
> see above
>> 
>> Q: Do we want to eliminate any of the control plane alternatives.
>> 
>>   I don't.
> 
> ok - if that is the general agreement, than I think we need the d-id
>> 
>> Q: By using the L-labels as containers for QoS and BW, neither T-Labels or PW-lables can do that, is it clear that we need L-Labels?
> 
> I won't argue that realty need the L-labels, but getting rid of them means that we lose the way to distinguish between L-level LSPs that needs to go through replication and elimination, I guess that we could tie that to the d-pw label, but my take is that it will incease the amount of processing that needs to be done on the d-pw level.
>> 
>> As far as the data plane is concerned, I think we need either the L-labels or the d-id labels, but not both.
> 
> There I'm just now (allowing for existing control planes) I think that we need the d-id, and that L-labels are open for debate.
> 
> I think the L-labels gives some bells and whistles that are nice and maybe even efficient to have! But I can let me be convinced that they are not "needed"!
> 
>  (Although, without the d-id labels, you have to know that LB-3 + d-pw1 is the same flow as LB-4 + d-pw1, so perhaps it's easier to do without the L-labels.)
> 
> I agree to that.
> 
> Either label could be used for QoS.
> 
> Well I think that all labels will have QoS (one or the other TC). I was talking about QoS-containers. You put all the same QoS packet in the same LSP. This is often used to simplify the LIBs in the nodes that only swap. If TC 001 is a superset of 010 you can put both packets TC-marked
> 001 and 010 in the same L-LSP. The packets marked 010 will get a little better treatment than what is indicated by the marking.
> 
> You can also use L-labels as BW containers. You instantiate the L-LSP with the amount of BW you allocate to DetNet traffic, and then you have BW associated with each pw-label, as you establish the PWs and place them into the L-LSPs you have a book keeping to make sure that the BW for the L-LSP is not exceeded.
> 
> Combining QoS- and BW-containers you can make sure that ample BW is allocated to each TC.
>> 
>> But, perhaps we have an issue when creating d-pw labels and/or d-id labels.  The PW creation exchange operates over a tunnel, right?  We have a complex tunnel, not a point-to-point tunnel.  How does the PW creation exchange know what path to follow?  Over what path are the d-id labels created?  In other words, how are the L-labels stitched together?  Equivalently, how are the d-id labels distributed over the paths.
>> 
> For LDP that is how LDP works, for a God Box there shouldn't be a problem.
> 
> In our figure for LDP A will ask B for a L-label to use for D, B will turn downstream and ask D for the label, when B gets the response from D, it will put that label into the LIB, allocate the label for A, and usew the label for A as incoming label and the label for D as the outgoing label.
> 
> If you remove the L-labels you will have to use the T-labels to do this.
> the d-pw label can't be used since it needs to be end-2-end.
>> Q: We talk about "detnet pseudo wire", is that a new type of pseudo wire?
>> 
>> I wouldn't call it anything different.
> 
> I think this needs to be done, since there is some unique DetNet processing. Potentially we would have to change all existing PWs. Andy talked a bit about this earlier.
>> 
>> Q: How do we handle the already existing pseudo wires?
>> 
>> Same as always.
> The existing PWs does not have DetNet processing, all of them does not (at least not normally) have sequence numbers.
> 
> Again, I think the key is defining how you negotiate the path that the branched pseudowire follows.  In my opinion, (subject to finding a counter example that screws everything up), you nail down the paths, either with L-labels or d-id labels, and each d-pw creation (or perhaps first use) creates an instance of the packet discard machine at each combination point.  But, I'm not sufficiently versed in the label protocols to offer an opinion of how that happens.
>> 
> 
> hmmmm - we will have to create a new TLV for the protocols that are used
>  to branch, replicate and eliminate. When a node gets a Label Requst with that TLV it will understand that branching is needed and set up two disjunct L-LSPs from itself to the destination.
> 
> /Loa
> 
>> -- Norm
>> 
>> ________________________________________
>> From: Detnet-dp-dt [[e-mail]] on behalf of Loa 
>> Andersson [[e-mail]]
>> Sent: Sunday, February 26, 2017 2:34 AM
>> To: [e-mail]
>> Subject: [Detnet-dp-dt] new versions of my slides
>> 
>> Folks,
>> 
>> I gone over my slides and tighten them up a bit.
>> 
>> I think it is time that we start agree on some of the design decisions 
>> we are making and start taking them as the basis for what we are doing 
>> next.
>> 
>> Slides should be self-explaining, but you can jump slide 3 and get 
>> back to it in the end.
>> 
>> /Loa
>> --
>> 
>> 
>> 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
>> 
> 
> -- 
> 
> 
> 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