Re: [mpls] Open DT agenda for 2021-09-09

[John E Drake <[e-mail]>]

Loa,

Comments inline below.

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: Loa Andersson <[e-mail]>
> Sent: Wednesday, September 8, 2021 3:06 PM
> To: John E Drake <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; DetNet Chairs <detnet-
> [e-mail]>
> Subject: Re: [mpls] Open DT agenda for 2021-09-09
> 
> [External Email. Be cautious of content]
> 
> 
> John,
> 
> Tnx for comments.
> 
> There is a couple of thing we need to converged on. For example how we use
> "Ancillary data".
> 
> Both you and me seem to mean what Kireeti call "post stack data" when we say
> "ancillary data".
> 
> To me it seem that Kireeti works with three "variants" of ancillary data
> - no data
> - in stack data
> - post stack data
> 
> In an earlier mail I pointed to an addition to my text I promised to align my text
> with whatever terminology we agreed to on Thursday.
> 
> We might even include a terminology section in the Framework/Architecture
> document.
> 
> On 08/09/2021 17:35, John E Drake wrote:
> > Loa,
> >
> > Regarding your "Thoughts on Encapsulating ancillary data", I think we need to
> define for a given forwarding action whether it requires ancillary data.
> Yes - I say that in my text also. A bit cryptic, but the assumption section says:
> 
>     "Which flags that are "no-data", "in-stack-data" or "after-the-BoS-
>      data" is not decided here, but when the flags flags are specified.
>      This is just EXAMPLES to be used for explanatory purpose."
> 
> Yes so I agree, actually we need to specify which variant of data that is needed
> when a flag is specified.
> 
>   I agree with Kireeti that any ancillary data required by forwarding actions
> should be encoded in the MPLS label stack.
> 
> I don't think Kireeti says that, he operates with three variants, "no data", "in-
> stack data", and "post-stack"
 
[JD]  My recollection is that Kireeti said this in a DT meeting and I think it makes sense, given that some implementations have trouble finding the BoS.
 
> 
>   So, what we should have is an LSE containing the forwarding actions followed
> by LSEs for each forwarding action that requires ancillary data.
> 
> Here I don't follow, the post stack data is not an LSE. But the TLV structure I
> defined does that, kind of.

[JD]  If the ancillary data applies to forwarding actions I was placing it in the label stack. 

> 
> These LSEs should be in the same order in which the forwarding actions are
> defined;  if forwarding actions 1, 3, and 5 require ancillary data, then following
> the LSE containing the forwarding actions there should be three LSEs, for
> forwarding actions 1, 3, and 5.
> 
> Yes, that could work, if the flag position is put in the flag field in the order they
> are defined. I think that is the same thing as to say as the flags representing the
> forwarding action appears in flag field.
> >
> > I also think we need to specify that a transit node should only process the
> forwarding actions it understands and ignore the others, and that when
> constructing the FAI LSEs the ingress node should only include forwarding
> actions understood both by it and by the egress node.  I think the implication of
> these rules is that a every node needs to understand every bit in the forwarding
> actions up to a given bit position.  I.e., it can't selectively support individual
> forwarding actions.
> 
> I think this is a strong possibility, but it wasoutside the the scope of the present
> text, when I wrote it. We could discuss and include if we converge.

[JD]  I was proposing this because it is the only way of which I could think that would enable incremental deployment. 

> 
> /Loa
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > Juniper Business Use Only
> >
> >> -----Original Message-----
> >> From: mpls <[e-mail]> On Behalf Of Loa Andersson
> >> Sent: Tuesday, September 7, 2021 4:46 AM
> >> To: [e-mail]
> >> Cc: [e-mail]; [e-mail]; DetNet Chairs
> >> <detnet- [e-mail]>
> >> Subject: [mpls] Open DT agenda for 2021-09-09
> >>
> >> [External Email. Be cautious of content]
> >>
> >>
> >> MPLS Open DT,
> >>
> >> We will have our meeting as usual meeting on Thursday (CEST 5pm).
> >>
> >> Please find the agenda a:
> >>
> >> https://urldefense.com/v3/__https://trac.ietf.org/trac/mpls/wiki/2021
> >> -09-09-
> >> agenda__;!!NEt6yMaO-gk!WANhHodAhWZuqCjTWdq1kjMWURaq8utN7dc--
> >> 65c9lu71w2JUVib03Ng1RrdKKk$
> >>
> >> For the text on "Thoughts on Encapsulating ancillary data" I have
> >> received some comments, both off-line and on-line. I have added some
> >> responses at the end of the text.
> >>
> >> /Loa
> >> --
> >>
> >> Loa Andersson                        email: [e-mail]
> >> Senior MPLS Expert                          [e-mail]
> >> Bronze Dragon Consulting             phone: [phone]
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> [e-mail]
> >>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!
> >> NEt6yMaO-gk!WANhHodAhWZuqCjTWdq1kjMWURaq8utN7dc--
> >> 65c9lu71w2JUVib03NgxXHPQ7M$
> 
> --
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Bronze Dragon Consulting             phone: [phone]