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

Balazs,

Thanks for comment. I think it is a real issue and have to be addressed. It is not only the wiki that says that the ACH immediately follows the label carrying the BoS (see section 4, second bullet).
I have deferred this discussion until Stewart is back next week. 

/Loa

Sent from my iPhone

> On 9 Sep 2021, at 10:19, Balázs Varga A <balazs.a.varga@ericsson.com> wrote:
> 
> Hi Loa/All,
> 
> I have a DetNet (or more general a PW) specific comment regarding
> https://trac.ietf.org/trac/mpls/wiki/thoughts-on-encapsualation
> 
> In case of DetNet there is a mandatory d-CW (DetNet Control Word).
> Also in general, for PWs a CW may follow the label with the BoS indication.
> 
> Based on the Open DT page, ancillary data is intended to be placed 
> immediately after BoS, where the Control Word must be placed:
>    https://trac.ietf.org/trac/mpls/wiki/thoughts-on-encapsualation
>    "...
>    + "ancillary data" is found immediately after the label carrying the BoS
>    ..."
> 
> It would be great to clarify this issue on the call. I think AD-flags should be 
> able to cover the PW with CW scenarios and signal when "ancillary data" 
> is placed immediately after the CW and not the BoS.
> 
> E.g., 
> Flag1: AD is immediately after BoS vs. there is a CW before AD
> Flag2: hbh vs. e2e
> Flag3-4: size (2-4-6-8 bytes)
> 
> Thanks
> Bala'zs
> 
> -----Original Message-----
> From: mpls <mpls-bounces@ietf.org> On Behalf Of Loa Andersson
> Sent: Wednesday, September 8, 2021 9:43 PM
> To: John E Drake <jdrake@juniper.net>
> Cc: mpls@ietf.org; DetNet Chairs <detnet-chairs@ietf.org>; pals-chairs@ietf.org; mpls-chairs@ietf.org
> Subject: Re: [mpls] Open DT agenda for 2021-09-09
> 
> Sure, it is on the agenda. 
> 
> /Loa
> 
> Sent from my iPhone
> 
>> On 8 Sep 2021, at 21:41, John E Drake <jdrake@juniper.net> wrote:
>> 
>> 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 <loa.pi.nu@gmail.com>
>>> Sent: Wednesday, September 8, 2021 3:38 PM
>>> To: John E Drake <jdrake@juniper.net>
>>> Cc: Loa Andersson <loa@pi.nu>; mpls@ietf.org; pals-chairs@ietf.org; 
>>> mpls- chairs@ietf.org; DetNet Chairs <detnet-chairs@ietf.org>
>>> 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=40juniper.net@dmarc.ietf.org>
>>> wrote:
>>>> 
>>>> Loa,
>>>> 
>>>> Comments inline below.
>>>> 
>>>> Yours Irrespectively,
>>>> 
>>>> John
>>>> 
>>>> 
>>>> Juniper Business Use Only
>>>> 
>>>>> -----Original Message-----
>>>>> From: Loa Andersson <loa@pi.nu>
>>>>> Sent: Wednesday, September 8, 2021 3:06 PM
>>>>> To: John E Drake <jdrake@juniper.net>; mpls@ietf.org
>>>>> Cc: pals-chairs@ietf.org; mpls-chairs@ietf.org; DetNet Chairs
>>>>> <detnet- chairs@ietf.org>
>>>>> 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 <mpls-bounces@ietf.org> On Behalf Of Loa Andersson
>>>>>>> Sent: Tuesday, September 7, 2021 4:46 AM
>>>>>>> To: mpls@ietf.org
>>>>>>> Cc: pals-chairs@ietf.org; mpls-chairs@ietf.org; DetNet Chairs
>>>>>>> <detnet- chairs@ietf.org>
>>>>>>> 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://protect2.fireeye.com/v1/url?k=13b060ad-4c2b59a8-13b02036-
>>>>>>> 86d2114eab2f-1ba9121565ef0afc&q=1&e=4979ef90-b284-4095-879d-56cba
>>>>>>> 5489ab4&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Ftra
>>>>>>> c.ietf.org%2Ftrac%2Fmpls%2Fwiki%2F20
>>>>>>> 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: loa@pi.nu
>>>>>>> Senior MPLS Expert                          loa.pi.nu@gmail.com
>>>>>>> Bronze Dragon Consulting             phone: +46 739 81 21 64
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> mpls mailing list
>>>>>>> mpls@ietf.org
>>>>>>> 
>>>>> 
>>> https://protect2.fireeye.com/v1/url?k=efed48c4-b07671c1-efed085f-86d2114eab2f-f53960f57210d1a6&q=1&e=4979ef90-b284-4095-879d-56cba5489ab4&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls__;!!
>>>>>>> NEt6yMaO-gk!WANhHodAhWZuqCjTWdq1kjMWURaq8utN7dc--
>>>>>>> 65c9lu71w2JUVib03NgxXHPQ7M$
>>>>> 
>>>>> --
>>>>> 
>>>>> Loa Andersson                        email: loa@pi.nu
>>>>> Senior MPLS Expert                          loa.pi.nu@gmail.com
>>>>> Bronze Dragon Consulting             phone: +46 739 81 21 64
>>>> _______________________________________________
>>>> mpls mailing list
>>>> mpls@ietf.org
>>>> https://protect2.fireeye.com/v1/url?k=e1fd9f12-be66a617-e1fddf89-86d
>>>> 2114eab2f-a28df3f2c554dfe7&q=1&e=4979ef90-b284-4095-879d-56cba5489ab
>>>> 4&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org
>>>> %2Fmailman%2Flistinfo%2Fmpls
>>>> __;!!NEt6yMaO-
>>> gk!U9lc_yZbwa3GJzplYtJcCYbrxwbcU0nBrMQOisbOwCT6zMdTOC22S
>>>> ZAmNranjxA$
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls