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

[Jouni Korhonen <[e-mail]>]

Hi Yuanlong,


> On Mar 4, 2017, at 7:27 PM, Jiangyuanlong <[e-mail]> wrote:
> 
> 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?).

Ok thanks. I would leave Norm to speak for the overlay idea he has using L-labels.

> Is flow identity used to avoid PW collision? For global E2E PW or MS-PW approach, it seems we don’t need this field.

Flow identification and associating the PW sequence number to a specific flow. Now I must admit I am not sure whether the protocol police gets upset if we associate the sequence number to a flow-id and not to a PW label..

> If we do use flow identity and enable FRER for each flow, then forwarding is still based on PW+flow_id.

Hmm yes. Or more like forwarding still based on labels (and how LFIB is programmed) and elimination based on flow-id. In my thinking flow-id serves implicitly as the “virtual label” but now being carried in-band. 

- Jouni

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