Subject: Re: [mpls] Question on avoiding TLVs

From: Loa Andersson <[email-masked]>
Date: Wed, 2 Feb 2022 10:41:15 +0800

Haoyu,

inline please.

On 01/02/2022 11:28, Haoyu Song wrote:
> Hi Loa,
> 
> I'm not sure I understand your question. 

might be that I don't understand to ask the question correctly, but as 
we say "there are no stupid questions".

In most packet header chains, T of the next header is a field in the 
current header.

Why is that beneficial? The T is there and the info it carries is the same.

L of the next header is implied by T so it's not explicitly given at all.

so that gives us a fixed length pper T, right?

/Loa

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,
> 
> So when we look at what goes on the wire, there is no T and no L?
> 
> /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.
>> 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.
>>
>> So looking at the forwarding exactly what should not be TLV encoded?
>>
>> Can you give examples?
>>
>> /Loa
>>
>> On 01/02/2022 01:25, Haoyu Song wrote:
>>> 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,
>>>
>>> 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,
>>>>
>>>> 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?
>>>>
>>>> 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
>>>> _______________________________________________
>>>> mpls mailing list
>>>> [email-masked]
>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
>>>> w
>>>> .ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%
>>>> 4
>>>> 0futurewei.com%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b24018
>>>> 9
>>>> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb3d
>>>> 8
>>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
>>>> C
>>>> 3000&amp;sdata=o%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE%3D&amp;
>>>> r
>>>> eserved=0
>>>
>>
> 

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

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 1 Feb 2022 19:45:02 -0800

Hi Haoyu,
let's assume that the length of each element in the ancillary data block is
fixed. Furthermore, all nodes in the domain understand N first indicators.
At some point in time, the N+1th indicator is assigned a new type and the
corresponding data length. Now, it appears to me, all nodes in the domain
must be updated to understand that N+1th element of the ancillary data. On
the other hand, if the length of the Value is present in the ancillary
block, a node can skip over elements that it doesn't support. That seems
like a good-to-have functionality.

Regards,
Greg

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

> 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.
> > 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.
> > 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
> >>>
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 2 Feb 2022 17:36:25 +0000

There are two approaches put: the identifier in the preceding header (pre-identification) and put it in the header that it is identifying (self describing).

Give that we are talking about TLV structures at the start of each header you know the type of header (from which you can determine whether it is the final header in the sequence) and you know the length of the structure. Hence you know the location and type of the next TLV type and can look forward and be prepared to process.

Why is pre-identification such a performance advantage over self identification?

- Stewart

> On 31 Jan 2022, at 20:22, Haoyu Song <[email-masked]> 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. 
> From: Loa Andersson <[email-masked] <mailto:[email-masked]>> 
> To: Haoyu Song <[email-masked] <mailto:[email-masked]>>; Tony Li <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
>>> 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 <http://0futurewei.com/>%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189
>>> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb3d8
>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
>>> 3000&amp;sdata=o%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE%3D&amp;r
>>> eserved=0
>> 
> 
> -- 
> Loa Andersson                        email: [email-masked] <mailto:[email-masked]>
> Senior MPLS Expert                          [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>

---

From: Haoyu Song <[email-masked]>
Date: Wed, 2 Feb 2022 17:58:49 +0000

Hi Loa,

As I explained in my shared slides, if T of the next header is not encoded in the current header, you would need at least one more state in the parser FSM. It leads to larger FSM and longer parsing time.
As for L in  a TLV structure, if L is fixed and known, then it will need two states in FSM; if L is variable, then it will need more states (depending on the value range of L). So from the fast-path efficiency point of view, we should avoid TLV structure  if we can, which means T should be indicated by the previous header and L should be fixed.

Best,
Haoyu

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

Haoyu,

inline please.

> I'm not sure I understand your question. 

might be that I don't understand to ask the question correctly, but as we say "there are no stupid questions".

In most packet header chains, T of the next header is a field in the current header.

/Loa

For such a chain, the parser can parse one header in one step. Simple and efficient.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 2 Feb 2022 10:06:25 -0800

Hi Haoyu,
it appears that you've considered the scenario when all nodes in the domain
know of all types of ancillary data. What should happen in the domain if a
new type of ancillary data must be introduced? If the Length is not present
in the ancillary data but expected to be "known", it seems like all nodes
must be updated to support the new type. What do you think? Am I missing
something in your proposal?

Regards,
Greg

On Wed, Feb 2, 2022 at 9:59 AM Haoyu Song <[email-masked]> wrote:

> Hi Loa,
>
> As I explained in my shared slides, if T of the next header is not encoded
> in the current header, you would need at least one more state in the parser
> FSM. It leads to larger FSM and longer parsing time.
> As for L in  a TLV structure, if L is fixed and known, then it will need
> two states in FSM; if L is variable, then it will need more states
> (depending on the value range of L). So from the fast-path efficiency point
> of view, we should avoid TLV structure  if we can, which means T should be
> indicated by the previous header and L should be fixed.
>
> Best,
> Haoyu
>
> >>>> 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
> >>>> 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

---

From: Haoyu Song <[email-masked]>
Date: Wed, 2 Feb 2022 18:13:54 +0000

Hi Greg,

The assumptions are unlikely to be true. Based on the current list of use cases, we can see the size of each type of ancillary data would vary a lot. Also, it seems hard to ensure all nodes must understand N first indicators.

But yes, we should allow a node to skip the ancillary data elements it doesn't support. This is a desired behavior. We should also keep HBH elements before E2E elements.

I'd like to also clarify that while we prefer fix sized header, I didn't say variable sized headers are absolutely not allowed. Sometimes, we can't avoid it and then we have to accept its cost.

Best,
Haoyu

From: Greg Mirsky <[email-masked]>
Sent: Tuesday, February 1, 2022 7:45 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,
let's assume that the length of each element in the ancillary data block is fixed. Furthermore, all nodes in the domain understand N first indicators. At some point in time, the N+1th indicator is assigned a new type and the corresponding data length. Now, it appears to me, all nodes in the domain must be updated to understand that N+1th element of the ancillary data. On the other hand, if the length of the Value is present in the ancillary block, a node can skip over elements that it doesn't support. That seems like a good-to-have functionality.

Regards,
Greg

On Mon, Jan 31, 2022 at 7:28 PM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
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]<mailto:[email-masked]>>
Sent: Monday, January 31, 2022 6:14 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,

/Loa

On 01/02/2022 04:22, Haoyu Song wrote:
> From: Loa Andersson <[email-masked]<mailto:[email-masked]>>
> To: Haoyu Song <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>
>> 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%7C144b4056491f4202ddbf08d9e5fe6c81%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637793703195931738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=YanZMXVg4ixvwdyctvmcjzbzD2%2F2%2F%2FdviGkV4Rj9lNs%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%7C144b4056491f4202ddbf08d9e5fe6c81%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637793703195931738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9p4Mm%2Bh%2FnTgH4gUH1JLWdTqrRI6qKYME39275%2FIRiq4%3D&reserved=0>%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b24018
>>> 9

--
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%7C144b4056491f4202ddbf08d9e5fe6c81%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637793703196087927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=t09%2BTW9K88%2BXhhAhDqMPOirg8XtV4EExXAfIcjdURCU%3D&reserved=0>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 2 Feb 2022 10:24:17 -0800

Hi Haoyu,
thank you for the clarification about your view on whether to use fixed or
variable length of ancillary data element. I agree that the fixed length is
preferable but, sometimes, using the variable-length data is an acceptable
compromise. But my question was slightly different. As I understand your
point of view, it advocates for not encoding Type and Length but only the
Value field into the ancillary data block. Is that the correct
understanding? I agree with you that the Type is implied by the position of
the corresponding indicator. But I don't agree that not encoding Length is
the right approach. Could you please clarify that.

Regards,
Greg

On Wed, Feb 2, 2022 at 10:13 AM Haoyu Song <[email-masked]> wrote:

> Hi Greg,
>
>
>
> The assumptions are unlikely to be true. Based on the current list of use
> cases, we can see the size of each type of ancillary data would vary a lot.
> Also, it seems hard to ensure all nodes must understand N first indicators.
>
>
>
> But yes, we should allow a node to skip the ancillary data elements it
> doesn’t support. This is a desired behavior. We should also keep HBH
> elements before E2E elements.
>
>
>
> I’d like to also clarify that while we prefer fix sized header, I didn’t
> say variable sized headers are absolutely not allowed. Sometimes, we can’t
> avoid it and then we have to accept its cost.
>
>
>
> Best,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Tuesday, February 1, 2022 7:45 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,
>
> let's assume that the length of each element in the ancillary data block
> is fixed. Furthermore, all nodes in the domain understand N first
> indicators. At some point in time, the N+1th indicator is assigned a new
> type and the corresponding data length. Now, it appears to me, all nodes in
> the domain must be updated to understand that N+1th element of the
> ancillary data. On the other hand, if the length of the Value is present in
> the ancillary block, a node can skip over elements that it doesn't support.
> That seems like a good-to-have functionality.
>
>
>
> Regards,
>
> Greg
>
>
>
> >>> .ietf.org
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C144b4056491f4202ddbf08d9e5fe6c81%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637793703195931738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=YanZMXVg4ixvwdyctvmcjzbzD2%2F2%2F%2FdviGkV4Rj9lNs%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%7C144b4056491f4202ddbf08d9e5fe6c81%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637793703195931738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9p4Mm%2Bh%2FnTgH4gUH1JLWdTqrRI6qKYME39275%2FIRiq4%3D&reserved=0>
> %7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b24018
> >>> 9
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C144b4056491f4202ddbf08d9e5fe6c81%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637793703196087927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=t09%2BTW9K88%2BXhhAhDqMPOirg8XtV4EExXAfIcjdURCU%3D&reserved=0>
>
>

---

From: Haoyu Song <[email-masked]>
Date: Wed, 2 Feb 2022 18:57:02 +0000

Hi Stewart,

Here are two examples (if you try to draw an FSM or write the parsing code, it would be immediately clear):
The first is for the simple header chain and the second is for a list of TLV. Each TLV would require at least two states to parse: one to get the type (in order to understand the format of V) and the other to parse the V. (note that this assumes L is fixed. If not, it would need more states)

                                 Ether-type              proto
Ethernet header    ------------->   IPv4  --------------> TCP

                                                    Type                                                                     Type
H1  --------> Type field of H2 -------------> L/V of H2 -------> Type field of H3 ----------> L/V of H3

Best,
Haoyu
From: Stewart Bryant <[email-masked]>
Sent: Wednesday, February 2, 2022 9:36 AM
To: Haoyu Song <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; loa Andersson <[email-masked]>; Tony Li <[email-masked]>; [email-masked]
Subject: Re: [mpls] Question on avoiding TLVs

- Stewart

On 31 Jan 2022, at 20:22, 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

Hi Tony,

Best,
Haoyu

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

Haoyu, Loa,

Tony

Hi Loa,

Best,
Haoyu

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

Haoyu,

/Loa
0futurewei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F0futurewei.com%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cf74c986daef5445c1e1508d9e6728c7c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637794201946873530%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=q%2B9p3hernOJTCnSiOLKR2%2FkGp%2Fr%2B05FEBoGnXT2Ezhw%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%7Cf74c986daef5445c1e1508d9e6728c7c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637794201946873530%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vZaVFwH5UT3qPOhtHilx5xwSrgds9DQFZbE8fMU04Yk%3D&reserved=0>

---

From: Haoyu Song <[email-masked]>
Date: Wed, 2 Feb 2022 19:04:53 +0000

Hi Greg,

I never make that assumption. If you read our MPLS EH draft, you would find each EH has a length field at fixed location which can help a node to skip the current header even if the node doesn't understand or can't support the header.  Otherwise, if the header size is fixed and well-known, the length field is still there but its redundant.

Best,
Haoyu
Sent: Wednesday, February 2, 2022 10:06 AM

Hi Haoyu,
it appears that you've considered the scenario when all nodes in the domain know of all types of ancillary data. What should happen in the domain if a new type of ancillary data must be introduced? If the Length is not present in the ancillary data but expected to be "known", it seems like all nodes must be updated to support the new type. What do you think? Am I missing something in your proposal?

Regards,
Greg

On Wed, Feb 2, 2022 at 9:59 AM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi Loa,

Best,
Haoyu

-----Original Message-----
From: Loa Andersson <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 1, 2022 6:41 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,

inline please.

/Loa

>>>> .ietf.org<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Ce82c09694eb944365bb008d9e676c23b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637794220023618185%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qeniXTgBuhapLG%2BybR%2FOXrAd%2FnSeCs80O7mBfsf1xgk%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%7Ce82c09694eb944365bb008d9e676c23b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637794220023618185%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=09NQAMT%2FbRCoeSh7JVNo3sHw7O6Bz6LXTyIDGSvjMeY%3D&reserved=0>%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b2401
>>>> 8
>>>> 9

_______________________________________________
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%7Ce82c09694eb944365bb008d9e676c23b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637794220023618185%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fF1h9HKeWK7Ju7x%2BSRi%2FHQ62hQWWe3a1hxk9PPEEWjQ%3D&reserved=0>

---

From: Haoyu Song <[email-masked]>
Date: Wed, 2 Feb 2022 19:20:54 +0000

Hi Greg,

Our emails crossed each other. Hopefully my last email answered your question.

Best,
Haoyu
Sent: Wednesday, February 2, 2022 10:24 AM

Hi Haoyu,
thank you for the clarification about your view on whether to use fixed or variable length of ancillary data element. I agree that the fixed length is preferable but, sometimes, using the variable-length data is an acceptable compromise. But my question was slightly different. As I understand your point of view, it advocates for not encoding Type and Length but only the Value field into the ancillary data block. Is that the correct understanding? I agree with you that the Type is implied by the position of the corresponding indicator. But I don't agree that not encoding Length is the right approach. Could you please clarify that.

Regards,
Greg

On Wed, Feb 2, 2022 at 10:13 AM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Best,
Haoyu

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 1, 2022 7:45 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

Best,
Haoyu

-----Original Message-----
From: Loa Andersson <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 31, 2022 6:14 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,

/Loa

On 01/02/2022 04:22, 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%7Cf73852b0037c4cde994a08d9e6794095%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637794230746482158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IRImWy%2F7otHlhqaL%2B7pgg9vIiSRAE0W8MPSVEttph%2B0%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%7Cf73852b0037c4cde994a08d9e6794095%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637794230746482158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=rH2redTDqTEe8d0YEYcYA0DNrahlcnmCEa82crYVCUA%3D&reserved=0>%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b24018
>>> 9

_______________________________________________
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%7Cf73852b0037c4cde994a08d9e6794095%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637794230746482158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qDharir4nNiXeuhU6Jor6L%2BV6zqOzz%2BqzJZVrD0ADPE%3D&reserved=0>

---

From: Loa Andersson <[email-masked]>
Date: Thu, 3 Feb 2022 12:39:49 +0800

Greg,

Sent from my iPhone

> On 2 Feb 2022, at 11:45, Greg Mirsky <[email-masked]> wrote:

Are assuming that all “containers” for ancillary data are tje same size?
If we want to send an IPv4 address we need a 4 bytes  container. Is that the the size of container also if we want to send “a nibble”?

Is this the implication of “fixed length” ?

/Loa