Subject: [mpls] Question on avoiding TLVs

From: Loa Andersson <[email-masked]>
Date: Mon, 31 Jan 2022 19:26:33 +0800

Haoyu,

In the slides you uploaded to the "We should try the best to avoid TLV 
style and variable sized header".

MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you 
suggesting we'd change this?

Given your advice above what should we do?

/Loa
-- 
Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Haoyu Song <[email-masked]>
Date: Mon, 31 Jan 2022 16:46:24 +0000

Hi Loa,

Usually TLV is used as a substructure in a header. For sub fields in a header, usually we don't have other choices than using TLV.  But for each header, the type of it is better to be indicated by the previous header to save a parsing state. 
So all what I say is: as a principle, when designing a header, try not to embed its type in the header itself. Instead, before we get to this header, we should already know its type.

Moreover, TLV options in a header also increases the parsing cost. Each fixed size TLV needs two states. Each variable size TLV needs multiple states depending on the size of the option. So another advice is: if it is meant to be processed in hardware, then we should try to limit the use of TLV, and especially variable sized TLV, unless absolutely necessary.

Best,
Haoyu

-----Original Message-----
From: Loa Andersson <[email-masked]> 
Sent: Monday, January 31, 2022 3:27 AM
To: [email-masked]; Haoyu Song <[email-masked]>
Subject: Question on avoiding TLVs

Haoyu,

In the slides you uploaded to the "We should try the best to avoid TLV style and variable sized header".

MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you suggesting we'd change this?

/Loa

---

From: Tony Li <[email-masked]>
Date: Mon, 31 Jan 2022 09:03:27 -0800

Haoyu, Loa,

I think the important point here is that the parsing discussion is focused on the forwarding plane.  TLVs are pervasive in the control plane, where parsing is not a significant cost.

Tony

> On Jan 31, 2022, at 8:46 AM, Haoyu Song <[email-masked]> wrote:
> 
> Hi Loa,
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Haoyu Song <[email-masked]>
Date: Mon, 31 Jan 2022 17:25:26 +0000

Hi Tony,

Yes you are right. Here we are discussing the headers designed for data plane fast path processing. 
Most of the TLVs designed before are for control plane to use. 
But as you see, some current work for supposed fast path processing also suggests to use TLV options (e.g., in IPv6 EH) due to the lack of options. We need to be careful here, because for the parser point of view, each TLV options equals to at least 2 headers.
Now for MPLS EH, all I suggest is to avoid the issue because we are still at the early stages and have the opportunity to avoid some costly mistakes. 

Best,
Haoyu

-----Original Message-----
From: Tony Li <[email-masked]> On Behalf Of Tony Li
Sent: Monday, January 31, 2022 9:03 AM
To: Haoyu Song <[email-masked]>
Cc: Loa Andersson <[email-masked]>; [email-masked]
Subject: Re: [mpls] Question on avoiding TLVs

Haoyu, Loa,

Tony

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C232fd182783044649c3e08d9e4db9be9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637792454153079557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=W6r3NyEsUEcQzpreWqQR5ad4I%2FYRVA%2FJ3QaVqDZRkuo%3D&amp;reserved=0

---

From: Loa Andersson <[email-masked]>
Date: Tue, 1 Feb 2022 04:00:13 +0800

Haoyu, Tony,

I appreciate the difference in TLVs for the forwarding plane and for the 
control plane.

So looking at the forwarding exactly what should not be TLV encoded?

Can you give examples?

/Loa

---

From: Haoyu Song <[email-masked]>
Date: Mon, 31 Jan 2022 20:22:05 +0000

Hi Loa,

When designing new headers, it's good enough to simply organize them in a chain, which means
the current header would include a field (in some cases, such a field is not needed. For example, in an MPLS label stack, as long as the BoS is not set, you know the next header is still a label) to tell what's the next header, so the parser directly know the format of the next header. 
IPv6 EH follows such a structure, our proposed MPLS EH also follows such a structure. 
One current issue is that people tend to add variable sized TLV sub structures into EH to support fast path functions. This needs to be done very carefully, otherwise, it will never fly  (for example IPv4 options).

Haoyu

-----Original Message-----
From: Loa Andersson <[email-masked]> 
Sent: Monday, January 31, 2022 12:00 PM
To: Haoyu Song <[email-masked]>; Tony Li <[email-masked]>
Cc: [email-masked]
Subject: Re: [mpls] Question on avoiding TLVs

Haoyu, Tony,

I appreciate the difference in TLVs for the forwarding plane and for the control plane.

Can you give examples?

/Loa

On 01/02/2022 01:25, Haoyu Song wrote:
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%4
>> 0futurewei.com%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189
>> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb3d8
>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
>> 3000&amp;sdata=o%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE%3D&amp;r
>> eserved=0
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 31 Jan 2022 12:38:34 -0800

Hi Haoyu,
could you please clarify for me if your recommendation for avoiding using
the TLV construct is for all scenarios considered, i.e., ISD and PSD, or
for one of them? I agree that the random order of appearance of
variable-size data has a performance impact. On the other hand, if the
order of TLVs is deterministic, they are flexible and the performance cost
of parsing is much lower. So, perhaps, the recommendation could be refined
suggesting the use of ordered TLVs.
What are your thoughts?

Regards,
Greg

On Mon, Jan 31, 2022 at 12:22 PM Haoyu Song <[email-masked]>
wrote:

> the current header would include a field (in some cases, such a field is
> not needed. For example, in an MPLS label stack, as long as the BoS is not
> set, you know the next header is still a label) to tell what's the next
> header, so the parser directly know the format of the next header.
> One current issue is that people tend to add variable sized TLV sub
> structures into EH to support fast path functions. This needs to be done
> very carefully, otherwise, it will never fly  (for example IPv4 options).
>
> Haoyu
>
>
>
> > But as you see, some current work for supposed fast path processing also
> suggests to use TLV options (e.g., in IPv6 EH) due to the lack of options.
> We need to be careful here, because for the parser point of view, each TLV
> options equals to at least 2 headers.
> > Now for MPLS EH, all I suggest is to avoid the issue because we are
> still at the early stages and have the opportunity to avoid some costly
> mistakes.
> >
> > Best,
> > Haoyu
> >
> > I think the important point here is that the parsing discussion is
> focused on the forwarding plane.  TLVs are pervasive in the control plane,
> where parsing is not a significant cost.
> >
> > Tony
> >
> >
> >> Usually TLV is used as a substructure in a header. For sub fields in a
> header, usually we don't have other choices than using TLV.  But for each
> header, the type of it is better to be indicated by the previous header to
> save a parsing state.
> >> So all what I say is: as a principle, when designing a header, try not
> to embed its type in the header itself. Instead, before we get to this
> header, we should already know its type.
> >>
> >> Moreover, TLV options in a header also increases the parsing cost. Each
> fixed size TLV needs two states. Each variable size TLV needs multiple
> states depending on the size of the option. So another advice is: if it is
> meant to be processed in hardware, then we should try to limit the use of
> TLV, and especially variable sized TLV, unless absolutely necessary.
> >>
> >> Best,
> >> Haoyu
> >>

---

From: Haoyu Song <[email-masked]>
Date: Mon, 31 Jan 2022 20:45:22 +0000

Hi Greg,

The question is how to enforce the TLV orders?

  1.  People keep inventing new TLV options, some future options may have higher priority
  2.  If what you means is to provide a catalog in advance to list the TLVs in order. Then strictly speaking, you don't need the T in the TLV option any more. But as my last presentation shows, such a design shows no benefit in terms of parser size and performance.

Haoyu
From: Greg Mirsky <[email-masked]>
Sent: Monday, January 31, 2022 12:39 PM
To: Haoyu Song <[email-masked]>
Cc: Loa Andersson <[email-masked]>; Tony Li <[email-masked]>; [email-masked]
Subject: Re: [mpls] Question on avoiding TLVs

Hi Haoyu,
could you please clarify for me if your recommendation for avoiding using the TLV construct is for all scenarios considered, i.e., ISD and PSD, or for one of them? I agree that the random order of appearance of variable-size data has a performance impact. On the other hand, if the order of TLVs is deterministic, they are flexible and the performance cost of parsing is much lower. So, perhaps, the recommendation could be refined suggesting the use of ordered TLVs.
What are your thoughts?

Regards,
Greg

On Mon, Jan 31, 2022 at 12:22 PM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi Loa,

Haoyu

-----Original Message-----
From: Loa Andersson <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 31, 2022 12:00 PM
To: Haoyu Song <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Question on avoiding TLVs

Haoyu, Tony,

Can you give examples?

/Loa

On 01/02/2022 01:25, Haoyu Song wrote:
> From: Tony Li <[email-masked]<mailto:[email-masked]>> On Behalf Of Tony Li
> To: Haoyu Song <[email-masked]<mailto:[email-masked]>>
> Cc: Loa Andersson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>> On Jan 31, 2022, at 8:46 AM, Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Hi Loa,
>>
>> From: Loa Andersson <[email-masked]<mailto:[email-masked]>>
>> To: [email-masked]<mailto:[email-masked]>; Haoyu Song <[email-masked]<mailto:[email-masked]>>
>> Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
>> Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
>> .ietf.org<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C0d7802fe5b874046ebca08d9e4f9ae49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792583313396757%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BHLr7o%2FgxJlqA9qxYhuoBBLatQC9AziwYDMDCmFDlHI%3D&reserved=0>%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%4
>> 0futurewei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F0futurewei.com%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C0d7802fe5b874046ebca08d9e4f9ae49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792583313396757%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HcOCqw0dFJf01ojcjiz7D7SfUgSX6nOeBGe5QmonWSc%3D&reserved=0>%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189

--
Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
Bronze Dragon Consulting             phone: +46 739 81 21 64

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C0d7802fe5b874046ebca08d9e4f9ae49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792583313396757%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uYbMKHYIl8LwG8AarThZo3Kv4Y1j17j0qD4dFztuzwE%3D&reserved=0>

---

From: John E Drake <[email-masked]>
Date: Mon, 31 Jan 2022 20:59:56 +0000

Greg,

In the proposal from Adrian and me,  for every network action that is defined, we will define its bit position in the network action flags, whether it has ancillary data, if so what is that ancillary data, and whether that ancillary data is in-stack or post-stack.  When a P router receives a packet, then based upon which network action flags are set, it will know the format of the in-stack and post-stack ancillary data, because we stipulate that it must be in the same order as the network actions whose flags are set.

Yours Irrespectively,

John

Juniper Business Use Only
From: mpls <[email-masked]> On Behalf Of Greg Mirsky
Sent: Monday, January 31, 2022 3:39 PM
To: Haoyu Song <[email-masked]>
Cc: [email-masked]
Subject: Re: [mpls] Question on avoiding TLVs

[External Email. Be cautious of content]

Hi Haoyu,

Regards,
Greg

Haoyu

-----Original Message-----
From: Loa Andersson <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 31, 2022 12:00 PM
To: Haoyu Song <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Question on avoiding TLVs

Haoyu, Tony,

Can you give examples?

/Loa

On 01/02/2022 01:25, Haoyu Song wrote:
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww__;JSUl!!NEt6yMaO-gk!UQBwBfuS1f7lCEKzXcTXsGHzfpNTha67nwZC7ZdjiEp7nqm_cA-hkTzTQyKJxHY$>
>> .ietf.org<https://urldefense.com/v3/__http:/ietf.org__;!!NEt6yMaO-gk!UQBwBfuS1f7lCEKzXcTXsGHzfpNTha67nwZC7ZdjiEp7nqm_cA-hkTzTtlTp1zM$>%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%4
>> 0futurewei.com<https://urldefense.com/v3/__http:/0futurewei.com__;!!NEt6yMaO-gk!UQBwBfuS1f7lCEKzXcTXsGHzfpNTha67nwZC7ZdjiEp7nqm_cA-hkTzTiZPrSVg$>%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!UQBwBfuS1f7lCEKzXcTXsGHzfpNTha67nwZC7ZdjiEp7nqm_cA-hkTzTUnLO3rI$>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 31 Jan 2022 13:01:57 -0800

Hi Haoyu,
I think that an ordered list of TLVs has some benefits. For example,
consider an IP address. It can be identified by a single code point of a
variable-length TLV or by two code points for each address family.
Also, you could have missed my question about the use case, ISD vs. PSD,
you are considering when suggesting not to use a TLV. Personally, I see
fewer issues using TLV in PSD.

Regards,
Greg

On Mon, Jan 31, 2022 at 12:45 PM Haoyu Song <[email-masked]>
wrote:

>    2. If what you means is to provide a catalog in advance to list the
>    TLVs in order. Then strictly speaking, you don’t need the T in the TLV
>    option any more. But as my last presentation shows, such a design shows no
>    benefit in terms of parser size and performance.
>
>
>
> Haoyu
>
> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Monday, January 31, 2022 12:39 PM
> *To:* Haoyu Song <[email-masked]>
> *Cc:* Loa Andersson <[email-masked]>; Tony Li <[email-masked]>; [email-masked]
> *Subject:* Re: [mpls] Question on avoiding TLVs
>
>
>
> Hi Haoyu,
>
> >> .ietf.org
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C0d7802fe5b874046ebca08d9e4f9ae49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792583313396757%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BHLr7o%2FgxJlqA9qxYhuoBBLatQC9AziwYDMDCmFDlHI%3D&reserved=0>
> %2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%4
> >> 0futurewei.com
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F0futurewei.com%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C0d7802fe5b874046ebca08d9e4f9ae49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792583313396757%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HcOCqw0dFJf01ojcjiz7D7SfUgSX6nOeBGe5QmonWSc%3D&reserved=0>
> %7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C0d7802fe5b874046ebca08d9e4f9ae49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792583313396757%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uYbMKHYIl8LwG8AarThZo3Kv4Y1j17j0qD4dFztuzwE%3D&reserved=0>
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 31 Jan 2022 13:11:24 -0800

Hi John,
thank you for the clarification. I agree that the strict order of
indicators (actions and ancillary data) defines the order of ancillary
data. The question, as I understand it, is how the P node accesses the
ancillary data. If not using a TLV, I imagine, the node must know the
format of all defined indicated ancillary data elements. On the other hand,
TLV encoding of ancillary data allows relax that requirement and the node
can support only some, ones that it advertises while it can easily skip
over others.

Regards,
Greg

On Mon, Jan 31, 2022 at 1:00 PM John E Drake <[email-masked]> wrote:

> Greg,
>
>
>
> In the proposal from Adrian and me,  for every network action that is
> defined, we will define its bit position in the network action flags,
> whether it has ancillary data, if so what is that ancillary data, and
> whether that ancillary data is in-stack or post-stack.  When a P router
> receives a packet, then based upon which network action flags are set, it
> will know the format of the in-stack and post-stack ancillary data, because
> we stipulate that it must be in the same order as the network actions whose
> flags are set.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> *From:* mpls <[email-masked]> *On Behalf Of * Greg Mirsky
> *Sent:* Monday, January 31, 2022 3:39 PM
> *Cc:* [email-masked]
> *[External Email. Be cautious of content]*
>
>
>
> Hi Haoyu,
>
> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww__;JSUl!!NEt6yMaO-gk!UQBwBfuS1f7lCEKzXcTXsGHzfpNTha67nwZC7ZdjiEp7nqm_cA-hkTzTQyKJxHY$>
> >> .ietf.org
> <https://urldefense.com/v3/__http:/ietf.org__;!!NEt6yMaO-gk!UQBwBfuS1f7lCEKzXcTXsGHzfpNTha67nwZC7ZdjiEp7nqm_cA-hkTzTtlTp1zM$>
> <https://urldefense.com/v3/__http:/0futurewei.com__;!!NEt6yMaO-gk!UQBwBfuS1f7lCEKzXcTXsGHzfpNTha67nwZC7ZdjiEp7nqm_cA-hkTzTiZPrSVg$>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!UQBwBfuS1f7lCEKzXcTXsGHzfpNTha67nwZC7ZdjiEp7nqm_cA-hkTzTUnLO3rI$>
>
>

---

From: Haoyu Song <[email-masked]>
Date: Mon, 31 Jan 2022 21:14:13 +0000

Hi Greg,

In a parser, IP address family is not identified by the version number, but by a field in the previous L2 header (e.g., EtherType).
As long as the parser needs to parse the TLVs, it doesn't matter where they are (ISD or PSD). The cost is the same.

In essence, the catalog bitmap is like to gather all the Ts together and then list the LVs later according to the T's order. Again, there's no benefits in terms of parser size and performance but limitations on extensiblity based on my analysis.

Haoyu

Sent: Monday, January 31, 2022 1:02 PM

Hi Haoyu,
I think that an ordered list of TLVs has some benefits. For example, consider an IP address. It can be identified by a single code point of a variable-length TLV or by two code points for each address family.
Also, you could have missed my question about the use case, ISD vs. PSD, you are considering when suggesting not to use a TLV. Personally, I see fewer issues using TLV in PSD.

Regards,
Greg

On Mon, Jan 31, 2022 at 12:45 PM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Haoyu
From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 31, 2022 12:39 PM
To: Haoyu Song <[email-masked]<mailto:[email-masked]>>
Cc: Loa Andersson <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Question on avoiding TLVs

Hi Haoyu,

Regards,
Greg

Haoyu

-----Original Message-----
From: Loa Andersson <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 31, 2022 12:00 PM
To: Haoyu Song <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Question on avoiding TLVs

Haoyu, Tony,

Can you give examples?

/Loa

On 01/02/2022 01:25, Haoyu Song wrote:
>> .ietf.org<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C65a69dfc26fb4cc6693a08d9e4fcf2fe%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792597342312961%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4PUp%2Bjg9Ae8kdvcznZtczJv70uKrxaSf2IkB64lgw94%3D&reserved=0>%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%4
>> 0futurewei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F0futurewei.com%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C65a69dfc26fb4cc6693a08d9e4fcf2fe%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792597342312961%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2B1WNaIGtmVu3Xx7kqX3lqtZctKxXXd9gpmdf2yKDYpY%3D&reserved=0>%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C65a69dfc26fb4cc6693a08d9e4fcf2fe%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792597342312961%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nRR4e%2FqnhrHTiokvc0KaXiWqizW5WXuvcHf0baWX6bU%3D&reserved=0>

---

From: John E Drake <[email-masked]>
Date: Mon, 31 Jan 2022 21:27:37 +0000

Greg,

I think what we said was that a given P router needs to understand all of the network actions up to a given bit position in the network actions flags but it does not have necessarily support all of them.  This allows it to skip over the in-stack and post-stack ancillary data for network actions it does not support.

Yours Irrespectively,

John

Juniper Business Use Only
From: Greg Mirsky <[email-masked]>
Sent: Monday, January 31, 2022 4:11 PM
To: John E Drake <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Question on avoiding TLVs

Hi John,
thank you for the clarification. I agree that the strict order of indicators (actions and ancillary data) defines the order of ancillary data. The question, as I understand it, is how the P node accesses the ancillary data. If not using a TLV, I imagine, the node must know the format of all defined indicated ancillary data elements. On the other hand, TLV encoding of ancillary data allows relax that requirement and the node can support only some, ones that it advertises while it can easily skip over others.

Regards,
Greg

On Mon, Jan 31, 2022 at 1:00 PM John E Drake <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

Yours Irrespectively,

John

From: mpls <[email-masked]<mailto:[email-masked]>> On Behalf Of Greg Mirsky

Hi Haoyu,

Regards,
Greg

Haoyu

-----Original Message-----
From: Loa Andersson <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 31, 2022 12:00 PM
To: Haoyu Song <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Question on avoiding TLVs

Haoyu, Tony,

Can you give examples?

/Loa

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 31 Jan 2022 15:25:48 -0800

Hi Haoyu,
thank you for correcting the terminology. Indeed, it would be LV construct.
RE: the example of communicating an IP address in ancillary data. I cannot
see how the EtherType of an MPLS packet can be used to deduce the address
family in the ancillary data block.

Regards,
Greg

On Mon, Jan 31, 2022 at 1:14 PM Haoyu Song <[email-masked]> wrote:

> Hi Greg,
>
>
>
> In a parser, IP address family is not identified by the version number,
> but by a field in the previous L2 header (e.g., EtherType).
>
> As long as the parser needs to parse the TLVs, it doesn’t matter where
> they are (ISD or PSD). The cost is the same.
>
>
>
> In essence, the catalog bitmap is like to gather all the Ts together and
> then list the LVs later according to the T’s order. Again, there’s no
> benefits in terms of parser size and performance but limitations on
> extensiblity based on my analysis.
>
>
>
> Haoyu
>
>
>
> *Sent:* Monday, January 31, 2022 1:02 PM
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C65a69dfc26fb4cc6693a08d9e4fcf2fe%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792597342312961%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4PUp%2Bjg9Ae8kdvcznZtczJv70uKrxaSf2IkB64lgw94%3D&reserved=0>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F0futurewei.com%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C65a69dfc26fb4cc6693a08d9e4fcf2fe%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792597342312961%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2B1WNaIGtmVu3Xx7kqX3lqtZctKxXXd9gpmdf2yKDYpY%3D&reserved=0>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C65a69dfc26fb4cc6693a08d9e4fcf2fe%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792597342312961%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nRR4e%2FqnhrHTiokvc0KaXiWqizW5WXuvcHf0baWX6bU%3D&reserved=0>
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 31 Jan 2022 15:30:58 -0800

John,
such discipline is certainly possible and will work. But how it would be
maintained over time as new types of ancillary data are introduced. It
seems that all nodes in the domain will require SW updates in order for a
node to reach the end of the ancillary data block. Do you think I am
missing something?

Regards,
Greg

On Mon, Jan 31, 2022 at 1:27 PM John E Drake <[email-masked]> wrote:

> Greg,
>
>
>
> I think what we said was that a given P router needs to understand all of
> the network actions up to a given bit position in the network actions flags
> but it does not have necessarily support all of them.  This allows it to
> skip over the in-stack and post-stack ancillary data for network actions it
> does not support.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> *Sent:* Monday, January 31, 2022 4:11 PM
> *To:* John E Drake <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *From:* mpls <[email-masked]> *On Behalf Of *Greg Mirsky

---

From: John E Drake <[email-masked]>
Date: Mon, 31 Jan 2022 23:51:06 +0000

Greg,

Once a P router reaches the last network action flag that it understands, the rest of the network actions label stack block becomes opaque to it and it locates the end of the network actions label stack block either by finding another special purpose label or a label with BoS set.

The whole point is to allow incremental deployment of new network action into a network without requiring all of the P routers to be upgraded.

Yours Irrespectively,

John

Sent: Monday, January 31, 2022 6:31 PM

John,
such discipline is certainly possible and will work. But how it would be maintained over time as new types of ancillary data are introduced. It seems that all nodes in the domain will require SW updates in order for a node to reach the end of the ancillary data block. Do you think I am missing something?

Regards,
Greg

On Mon, Jan 31, 2022 at 1:27 PM John E Drake <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

Yours Irrespectively,

John

Juniper Business Use Only
From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 31, 2022 4:11 PM
To: John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Question on avoiding TLVs

Hi John,

Regards,
Greg

Yours Irrespectively,

John

Hi Haoyu,

Regards,
Greg

Haoyu

-----Original Message-----
From: Loa Andersson <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 31, 2022 12:00 PM
To: Haoyu Song <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Question on avoiding TLVs

Haoyu, Tony,

Can you give examples?

/Loa

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 31 Jan 2022 15:58:25 -0800

John,
but that means that ancillary data MUST NOT include a four-octet-long word
that has the TC bit set or can be mistaken for a bSPL (a sequence of two
such words might be mistaken for an eSPL). Not sure that is easy to ensure.

Regards,
Greg

On Mon, Jan 31, 2022 at 3:51 PM John E Drake <[email-masked]> wrote:

> Greg,
>
>
>
> Once a P router reaches the last network action flag that it understands,
> the rest of the network actions label stack block becomes opaque to it and
> it locates the end of the network actions label stack block either by
> finding another special purpose label or a label with BoS set.
>
>
>
> The whole point is to allow incremental deployment of new network action
> into a network without requiring all of the P routers to be upgraded.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> *Sent:* Monday, January 31, 2022 6:31 PM

---

From: John E Drake <[email-masked]>
Date: Tue, 1 Feb 2022 00:15:25 +0000

Greg,

Good point.  We stipulated that the definition of the BoS bit cannot be redefined by an ancillary data label stack entry and that we expect that ancillary data label stack entry would have non-zero bits in bit positions 4 - 20 of the label field.

Yours Irrespectively,

John

Sent: Monday, January 31, 2022 6:58 PM

John,
but that means that ancillary data MUST NOT include a four-octet-long word that has the TC bit set or can be mistaken for a bSPL (a sequence of two such words might be mistaken for an eSPL). Not sure that is easy to ensure.

Regards,
Greg

On Mon, Jan 31, 2022 at 3:51 PM John E Drake <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

Yours Irrespectively,

John

John,

Regards,
Greg

Yours Irrespectively,

John

Hi John,

Regards,
Greg

Yours Irrespectively,

John

Hi Haoyu,

Regards,
Greg

Haoyu

-----Original Message-----
From: Loa Andersson <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 31, 2022 12:00 PM
To: Haoyu Song <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Question on avoiding TLVs

Haoyu, Tony,

Can you give examples?

/Loa

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 31 Jan 2022 16:29:51 -0800

Sorry, I meant the S bit, not TC.

Regards,
Greg

On Mon, Jan 31, 2022, 15:58 Greg Mirsky <[email-masked]> wrote:

>> > But as you see, some current work for supposed fast path processing
>> also suggests to use TLV options (e.g., in IPv6 EH) due to the lack of
>> options. We need to be careful here, because for the parser point of view,
>> each TLV options equals to at least 2 headers.
>> >> Moreover, TLV options in a header also increases the parsing cost.
>> Each fixed size TLV needs two states. Each variable size TLV needs multiple

---

From: Loa Andersson <[email-masked]>
Date: Tue, 1 Feb 2022 10:13:50 +0800

Haoyu,

So when we look at what goes on the wire, there is no T and no L?

/Loa

---

From: Haoyu Song <[email-masked]>
Date: Tue, 1 Feb 2022 03:06:03 +0000

Hi Greg,

MPLS is indeed an exception. We have no way to know what follows from the label stack, which can be fixed with the MPLS extension header.

Regards,
Haoyu

Sent: Monday, January 31, 2022 3:26 PM

Hi Haoyu,
thank you for correcting the terminology. Indeed, it would be LV construct.
RE: the example of communicating an IP address in ancillary data. I cannot see how the EtherType of an MPLS packet can be used to deduce the address family in the ancillary data block.

Regards,
Greg

On Mon, Jan 31, 2022 at 1:14 PM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Haoyu

Hi Haoyu,

Regards,
Greg

Haoyu

Hi Haoyu,

Regards,
Greg

Haoyu

-----Original Message-----
From: Loa Andersson <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 31, 2022 12:00 PM
To: Haoyu Song <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Question on avoiding TLVs

Haoyu, Tony,

Can you give examples?

/Loa

On 01/02/2022 01:25, Haoyu Song wrote:
>> .ietf.org<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C263c8c984e3e4fabf6f208d9e5110ba3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792683663206889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=WROQuePDy4f17c%2FBnX4xm1YP3SWzoFMYlgy4%2BLXUu1k%3D&reserved=0>%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%4
>> 0futurewei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F0futurewei.com%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C263c8c984e3e4fabf6f208d9e5110ba3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792683663206889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MxcmXQ%2FSDiuNOylbKUWX2xRqQaYH%2BihvMUIMh4uoR%2Fw%3D&reserved=0>%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C263c8c984e3e4fabf6f208d9e5110ba3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792683663206889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sgpRbOgr8tkuZpwWlMDi%2BPeZktZpjHufVVCOXSJHb78%3D&reserved=0>

---

From: Haoyu Song <[email-masked]>
Date: Tue, 1 Feb 2022 03:28:09 +0000

Hi Loa,

I'm not sure I understand your question. In most packet header chains, T of the next header is a field in the current header. L of the next header is implied by T so it's not explicitly given at all. For such a chain, the parser can parse one header in one step. Simple and efficient.
Please clarify if I misunderstood your question.

Best,
Haoyu 

-----Original Message-----
From: Loa Andersson <[email-masked]> 
Sent: Monday, January 31, 2022 6:14 PM
To: Haoyu Song <[email-masked]>; Tony Li <[email-masked]>
Cc: [email-masked]
Subject: Re: [mpls] Question on avoiding TLVs

Haoyu,

/Loa

On 01/02/2022 04:22, Haoyu Song wrote:
> Hi Loa,
> 
> When designing new headers, it's good enough to simply organize them 
> in a chain, which means the current header would include a field (in some cases, such a field is not needed. For example, in an MPLS label stack, as long as the BoS is not set, you know the next header is still a label) to tell what's the next header, so the parser directly know the format of the next header.