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

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hi Jouni,

On Thu, 2017-03-02 at 23:47 -0800, Jouni Korhonen wrote:
> One approach could be.. shuffling around the identity label function.
> This is preliminary thinking, thus big holes are possible.
> 
>   +-------------------------------+
>   |            T-Label(s)         |
>   +-------------------------------+
>   |      L-Label (when needed)    |
>   +-------------------------------+
>   |           d-pw label          |
>   +-------------------------------+
>   |      DetNet Control Word      | \
>   +-------------------------------+  > follow RFC4553/5083 style
>   |  32 bit unique flow identity  | /  ‘encapsulation header’
> approach
>   +-------------------------------+
>   |                               |
>   |          DetNet Flow          |
>   |        Payload  Packet        |
>   |                               |
>   +-------------------------------+
> 
> Now the burden of seqnum association is on the seqnum handling
> “function” and would not mess MPLS forwarding & LFIB logic. Also we
> would not “eat” label space for flow identification purposes.. I have
> not yet looked at the gory details of impacts but as a way forward I
> would like to leave it still open where the _field_ that guarantees
> the uniqueness (d-idlabel or flow identity field as shown above) is
> located in the detnet encapsulation. Document both and have the
> discussion in the WG.
> 
> Opinions?
> 

I like this approach. One question: the flow identity, is it unique
globally or per d-pw?

Thanks,

Carlos

> - Jouni
> 
> 
> > On 01 Mar 2017, at 18:51, Jouni Korhonen <jouni.korhonen@broadcom.c
> > om> wrote:
> > 
> > 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 <balazs.a.varga@erics
> > > son.com> 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].c
> > > > om
> > > > 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
> > 
> > _______________________________________________
> > 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