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

From: Jouni Korhonen <[email-masked]>
Date: Wed, 1 Mar 2017 18:51:07 -0800

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: +1-408-391-7160

> On Feb 27, 2017, at 2:55 AM, Balázs Varga A <[email-masked]> 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:[email-masked]] On Behalf Of Loa Andersson
> Sent: Monday, February 27, 2017 5:43 AM
> To: [email-masked]
> 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; [email-masked]
>> 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 [[email-masked]] on behalf of Loa 
>> Andersson [[email-masked]]
>> Sent: Sunday, February 26, 2017 2:34 AM
>> To: [email-masked]
>> 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: [email-masked]
>> Senior MPLS Expert                          [email-masked]
>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>> 
>> 
>> 
>> _______________________________________________
>> Detnet-dp-dt mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>> 
> 
> -- 
> 
> 
> Loa Andersson                        email: [email-masked]
> Senior MPLS Expert                          [email-masked]
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
> 
> _______________________________________________
> Detnet-dp-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
> 
> _______________________________________________
> Detnet-dp-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 2 Mar 2017 23:47:41 -0800

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 <[email-masked]> wrote:
> 
> Folks,
>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sat, 04 Mar 2017 11:01:31 +0100

Hi Jouni,

On Wed, 2017-03-01 at 18:51 -0800, Jouni Korhonen 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.
> 

I share your view. I like more the approach in which we avoid having
the additional d-id (and we use globally unique d-pw labels). I
acknowledge see all the advantages it brings, but I also share the
concerns about the extra label layer and the potentially cumbersome
processing. There have been also some discussions about the size of the
label pool if they need to be globally unique. I think we need to have
some discussion documented in the draft about this if we go in this
direction.

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sat, 04 Mar 2017 11:11:06 +0100

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

> > 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
> > 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.
> > 
> > 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.
> > 
> > That one had the downside of fixed allocations put into nodes by
> > the network administrator.
> > 
> > - Jouni
> > 
> > -- 
> > > > 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 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"
> > > > 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)."
> > > 
> > > > 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.
> > > 
> > > 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.
> > > 
> > > > 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.
> > > > 
> > > 
> > > 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.
> > > 
> > > 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.
> > > > 
> > > 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.
> > > > 
> > > 
> > > 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: Loa Andersson <[email-masked]>
Date: Sat, 4 Mar 2017 19:21:53 +0800

Jouni and Carlos,

I see that this could work, but we need to go over how this will be
established for every signaling protocol we think in scope.

Please see inline.

> some discussion documented in the draft about this if we go in this

This begs the question of what "globally unique d-pw labels" means above

Is it

- global as the special purpose labels, seems unlikely
- global as unique with in the domain, though we know there is a scaling
   problem
- global for one sender, not that different from d-id, other that the
   placment in the stack

???

/Loa

--

---

From: Jiangyuanlong <[email-masked]>
Date: Sun, 5 Mar 2017 03:27:56 +0000

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

> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of
> Jouni Korhonen
> Sent: Friday, March 03, 2017 3:48 PM
> 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.
> 
> 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
> 
> 
> > 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
> >
> > --
> >> - 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
> >>
> >>> 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 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"?
> >>
> 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"
> >> 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)."
> >>
> >>> 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.
> >>>
> >> 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"!
> >>
> >> 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.
> >>
> >> 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.
> >>
> >>> 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.
> >>>
> >> 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.
> >>
> processing. Potentially we would have to change all existing PWs. Andy talked
> a bit about this earlier.
> >>>
> >> 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
> >>>
> >>> 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.
> >>>

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 5 Mar 2017 15:36:14 -0800

Loa, others,

> - global for one sender, not that different from d-id, other that the

In my small mind I reasoned it to be unique within one domain. Since the identity would now be 32 bits (there is no need to restrict it to 20 bits since it is part of the _encapsulation_header_ not the label stack), the scaling concern is more relaxed. Assuming each node in the domain would like to be able to name 4k unique detnet flows of their own then the domain could host 1M such detnet nodes.. not too bad for one domain.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 5 Mar 2017 15:58:10 -0800

Hi Yuanlong,

> On Mar 4, 2017, at 7:27 PM, Jiangyuanlong <[email-masked]> wrote:
> 
> Hi Jouni,
> 

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

---

From: Loa Andersson <[email-masked]>
Date: Mon, 6 Mar 2017 10:06:48 +0800

Jouni,

On 2017-03-06 07:36, Jouni Korhonen wrote:
<snip>
> In my small mind I reasoned it to be unique within one domain. Since the identity would now be 32 bits (there is no need to restrict it to 20 bits since it is part of the _encapsulation_header_ not…

My earlier calculations estimated that we would have about the number of 
PWs between any pair of T-DetNet-PEs would be about 400 and the
number T-DetNet-PEs about 1000.

32 bits is  4 000 millions, so there is ample number of flow id's even 
if we would have to configure a range on each T-DetNet-PE.

So you look at the flow-id and then compare the CW/Seq #, right?

Now, range configuration is a kludge, can we find a way to avoid it,
maybe d-pw + node-id would work, all this would have to happen in the
context of the (outgoing) d-pw anyway, right?

/Loa

--

---

From: Balázs Varga A <[email-masked]>
Date: Mon, 6 Mar 2017 17:49:16 +0000

Hi Jouni,

just for clarification: Do we intend to list all options in the draft ???

They all have pros and cons ...

Anyway I think we need a structure like below in the draft for example

in section 4. Is it inline with your intention? Shall I prepare some text

around this items for the call on Wednesday?

4.x DP solution requirements

List of prerequisites for a proper solution on an x-PE:

1, to distinguish PWs going through (operation label-swap) and PWs need DetNet serving (e.g., FRER)

2, to handle PW-label collisions (without major implementation difficulties)

3, to work with both centralized control and distributed control (signaling)

4.y DP solution toolset

Description of the toolset discussed so far:

A, L-label: additional label between t-label and PW-label

B, different PW-labels per segment: similar to the MS-PW label allocation mechanism

C, e2e PW label: no change of the PW-label (same PW-label value between T-PE nodes)

D, d-id label: additional label used as T-PE identification

E, Flow-ID outside of the label stack

Cheers

Bala'zs

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Monday, March 06, 2017 3:07 AM
To: Jouni Korhonen <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Detnet-dp-dt] about identity labels.. was Re: new versions of my slides

Jouni,

On 2017-03-06 07:36, Jouni Korhonen wrote:

<snip>

>> - global as unique with in the domain, though we know there is a

>> scaling  problem

> In my small mind I reasoned it to be unique within one domain. Since the identity would now be 32 bits (there is no need to restrict it to 20 bits since it is part of the _encapsulation_header_ not…

My earlier calculations estimated that we would have about the number of PWs between any pair of T-DetNet-PEs would be about 400 and the number T-DetNet-PEs about 1000.

32 bits is  4 000 millions, so there is ample number of flow id's even if we would have to configure a range on each T-DetNet-PE.

Now, range configuration is a kludge, can we find a way to avoid it, maybe d-pw + node-id would work, all this would have to happen in the context of the (outgoing) d-pw anyway, right?

/Loa

>>> [email-masked]<mailto:[email-masked]>

>> Loa Andersson                        email: [email-masked]<mailto:[email-masked]>

>> Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>

Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>

[email-masked]<mailto:[email-masked]>

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 6 Mar 2017 10:23:04 -0800

Balazs,

Your proposed Section 4.x would definitely be good to have. I am not too 
much for Section 4.y since I do not see it would not be needed in the 
final document, except for the definitions that should go to Section 2.

Regarding the two choices we have now I just add prologue text and 
describe (graphically both). The logic of the "identity label/tag" is 
mostly the same independent of the location in the stack. The processing 
is of course different.

- Jouni

3/6/2017, 9:49 AM, Balázs Varga A kirjoitti:
> *4.x DP solution requirements*
>
> *4.y DP solution toolset*
>
> Loa Andersson
>> In my small mind I reasoned it to be unique within one domain. Since
> the identity would now be 32 bits (there is no need to restrict it to 20
> bits since it is part of the _encapsulation_header_ not the label
> stack), the scaling concern is more relaxed. Assuming each node in the
> domain would like to be able to name 4k unique detnet flows of their own
> then the domain could host 1M such detnet nodes.. not too bad for one
> domain.
>
>
>
> PWs between any pair of T-DetNet-PEs would be about 400 and the number
> T-DetNet-PEs about 1000.
>
>
>
>>>> [email-masked] <mailto:[email-masked]>
>
> <mailto:[email-masked]>
>
>>> Senior MPLS Expert                          [email-masked] <mailto:[email-masked]>
>
>> [email-masked] <mailto:[email-masked]>
>
> <mailto:[email-masked]>
>
> Senior MPLS Expert                          [email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>
>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 7 Mar 2017 12:26:31 +0800

Folks,

> final document, except for the definitions that should go to Section 2.

I tend to agree with Jouni on this.

> mostly the same independent of the location in the stack. The processing

OK - that is the right way of doing it! However I'd like to see a walk 
through on establishing the "DetNet PW" for both choices, and
eventually a clear statement of which control plane protocols we allow
for.

Given that LDP is the protocol of choice for PWs, I think we should have
a hard time to move away from LDP.

We should converge on one choice.

BTW . whatever we have in terms of a draft when we get closer to the
cut-off, just post that. If we feel that it necessary we can put in a
disclaimer saying that the jury is still out.

/Loa
>>>> <mailto:[email-masked]>

--