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

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

Loa,

A few more thoughts.  Initially, the ancillary data for FAI was always carried in MPLS LSEs.  Adding the capability to have function flags for functions not directly related to forwarding as well as the capability to have ancillary data below BoS were subsequently added, with the understanding that these two capabilities were coupled;  i.e., ancillary data, if needed, for a function directly related to forwarding needs to be carried as MPLS LSEs.  So, when we define a new function, we should be very careful in deciding where to place its ancillary data and we should define whether the new function is end-to-end or hop-by-hop.

Given that we are now allowing functions not directly related to forwarding to be defined, we should consider renaming 'forwarding actions' to 'network functions'.

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: John E Drake
> Sent: Wednesday, September 8, 2021 3:29 PM
> To: Loa Andersson <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; DetNet Chairs <detnet-
> [e-mail]>
> Subject: RE: [mpls] Open DT agenda for 2021-09-09
> 
> 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/20
> > >> 21
> > >> -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]