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

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

Loa,

Perhaps this is something we can discuss at an upcoming DT meeting?

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: Loa Andersson <[e-mail]>
> Sent: Wednesday, September 8, 2021 3:38 PM
> To: John E Drake <[e-mail]>
> Cc: Loa Andersson <[e-mail]>; [e-mail]; [e-mail]; mpls-
> [e-mail]; DetNet Chairs <[e-mail]>
> Subject: Re: [mpls] Open DT agenda for 2021-09-09
> 
> [External Email. Be cautious of content]
> 
> 
> John,
> 
> Please look at what Kireeti wrote on the MIAD page on the wiki. I think is his
> latest contribution to that discussion. After that I have mail and addition to my
> “thoughts” (at the bottom.
> 
> /Loa
> 
> Sent from my iPhone
> 
> > On 8 Sep 2021, at 21:29, John E Drake <jdrake=[e-mail]>
> wrote:
> >
> > 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]
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls
> > __;!!NEt6yMaO-
> gk!U9lc_yZbwa3GJzplYtJcCYbrxwbcU0nBrMQOisbOwCT6zMdTOC22S
> > ZAmNranjxA$