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

[Jiangyuanlong <[e-mail]>]

Hi Jouni,

It seems L-Label is not needed for IP PSN tunnel, nor needed for MPLS LSP tunnel if RSVP-TE is used for signaling.
The only scenario I can imagine is when LDP is used for signaling (helped by routing with no traffic engineering?).

Is flow identity used to avoid PW collision? For global E2E PW or MS-PW approach, it seems we don't need this field.
If we do use flow identity and enable FRER for each flow, then forwarding is still based on PW+flow_id.

Thanks,
Yuanlong

> -----Original Message-----
> From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of
> Jouni Korhonen
> Sent: Friday, March 03, 2017 3:48 PM
> To: [e-mail]
> Subject: Re: [Detnet-dp-dt] about identity labels.. was Re: new versions of my
> slides
> 
> 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?
> 
> - Jouni
> 
> 
> > On 01 Mar 2017, at 18:51, Jouni Korhonen
> <[e-mail]> 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
> <[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
> >
> > _______________________________________________
> > 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