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

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