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

From: Loa Andersson <[email-masked]>
Date: Tue, 7 Sep 2021 10:46:07 +0200

MPLS Open DT,

We will have our meeting as usual meeting on Thursday (CEST 5pm).

Please find the agenda a:

https://trac.ietf.org/trac/mpls/wiki/2021-09-09-agenda

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: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: John E Drake <[email-masked]>
Date: Wed, 8 Sep 2021 15:35:20 +0000

Loa,

Regarding your "Thoughts on Encapsulating ancillary data", I think we need to define for a given forwarding action whether it requires ancillary data.  I agree with Kireeti that any ancillary data required by forwarding actions should be encoded in the MPLS label stack.  So, what we should have is an LSE containing the forwarding actions followed by LSEs for each forwarding action that requires ancillary data.  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.

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.   

Yours Irrespectively,

John

Juniper Business Use Only

> -----Original Message-----
> From: mpls <[email-masked]> On Behalf Of Loa Andersson
> Sent: Tuesday, September 7, 2021 4:46 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; DetNet Chairs <detnet-
> [email-masked]>
> Subject: [mpls] Open DT agenda for 2021-09-09
> 
> [External Email. Be cautious of content]
> 
> 
> MPLS Open DT,
> 
> 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
> --
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!
> NEt6yMaO-gk!WANhHodAhWZuqCjTWdq1kjMWURaq8utN7dc--
> 65c9lu71w2JUVib03NgxXHPQ7M$

---

From: Loa Andersson <[email-masked]>
Date: Wed, 8 Sep 2021 21:05:36 +0200

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…

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

--

---

From: John E Drake <[email-masked]>
Date: Wed, 8 Sep 2021 19:29:11 +0000

Loa,

Comments inline below.

Yours Irrespectively,

John

> From: Loa Andersson <[email-masked]>
> Sent: Wednesday, September 8, 2021 3:06 PM
> To: John E Drake <[email-masked]>; [email-masked]
> Subject: Re: [mpls] Open DT agenda for 2021-09-09
> 
> 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".
> 
> 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.
> 
> > 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:
> 
> 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. 

> >> Cc: [email-masked]; [email-masked]; DetNet Chairs
> >> <detnet- [email-masked]>

---

From: Loa Andersson <[email-masked]>
Date: Wed, 8 Sep 2021 21:38:27 +0200

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=[email-masked]> wrote:
> 
> Loa,
> 
> Comments inline below.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> https://www.ietf.org/mailman/listinfo/mpls

---

From: John E Drake <[email-masked]>
Date: Wed, 8 Sep 2021 19:41:24 +0000

Loa,

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

Yours Irrespectively,

John

> From: Loa Andersson <[email-masked]>
> Sent: Wednesday, September 8, 2021 3:38 PM
> To: John E Drake <[email-masked]>
> Cc: Loa Andersson <[email-masked]>; [email-masked]; [email-masked]; mpls-
> [email-masked]; DetNet Chairs <[email-masked]>
> 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
> 
> >> 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".
> >>
> >> Yes so I agree, actually we need to specify which variant of data
> >> that is needed when a flag is specified.
> >>
> >> 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.
> >
> >>
> >> 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.
> >>>
> >> 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.
> >
> >>>> https://urldefense.com/v3/__https://trac.ietf.org/trac/mpls/wiki/20
> >>>> 21
> >>>> -09-09-
> >>>> agenda__;!!NEt6yMaO-
> >>>> received some comments, both off-line and on-line. I have added
> >>>> some responses at the end of the text.
> >>>>
> >>>> /Loa
> >>>> --
> >>>>
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls
> > __;!!NEt6yMaO-
> gk!U9lc_yZbwa3GJzplYtJcCYbrxwbcU0nBrMQOisbOwCT6zMdTOC22S
> > ZAmNranjxA$

---

From: Loa Andersson <[email-masked]>
Date: Wed, 8 Sep 2021 21:42:40 +0200

Sure, it is on the agenda. 

/Loa

Sent from my iPhone

> On 8 Sep 2021, at 21:41, John E Drake <[email-masked]> wrote:
> 
> Loa,
>

---

From: Balázs Varga A <[email-masked]>
Date: Thu, 9 Sep 2021 08:19:12 +0000

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 <[email-masked]> On Behalf Of Loa Andersson
Sent: Wednesday, September 8, 2021 9:43 PM
To: John E Drake <[email-masked]>
Cc: [email-masked]; DetNet Chairs <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [mpls] Open DT agenda for 2021-09-09

/Loa

Sent from my iPhone

>> Cc: Loa Andersson <[email-masked]>; [email-masked]; [email-masked]; 
>> mpls- [email-masked]; DetNet Chairs <[email-masked]>
>> 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=[email-masked]>
>> wrote:
>>> 
>>> Loa,
>>> 
>>> Comments inline below.
>>> 
>>> Yours Irrespectively,
>>> 
>>> John
>>> 
>>> 
>>>> Both you and me seem to mean what Kireeti call "post stack data" 
>>>> when we say "ancillary 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.
>>>> 
>>>>> 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]  If the ancillary data applies to forwarding actions I was 
>>> placing it in the
>> label stack.
>>> 
>>>> 
>>>> 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
>>>>> 
>>>>> 
>>>>>> 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-
>> 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__;!!
>>> 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-

---

From: Loa Andersson <[email-masked]>
Date: Thu, 9 Sep 2021 10:44:36 +0200

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 <[email-masked]> wrote:
> 
> Hi Loa/All,
>

---

From: John E Drake <[email-masked]>
Date: Sun, 12 Sep 2021 22:53:49 +0000

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

> From: John E Drake
> Sent: Wednesday, September 8, 2021 3:29 PM
> To: Loa Andersson <[email-masked]>; [email-masked]
> Subject: RE: [mpls] Open DT agenda for 2021-09-09
> 
> Loa,
> 
> Comments inline below.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> [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.
> 
> >
> > 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.
> >
> > 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.
> > >
> > constructing the FAI LSEs the ingress node should only include