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

[Loa Andersson <[e-mail]>]

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"

  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.

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.

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