[prev in list] [next in list] [prev in thread] [next in thread]
List: mpls
Subject: Re: [mpls] Question on avoiding TLVs
From: Loa Andersson <loa.pi.nu () gmail ! com>
Date: 2022-02-03 4:39:49
Message-ID: DC49F075-A888-48ED-AC79-913EF773775C () gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Greg,
Sent from my iPhone
> On 2 Feb 2022, at 11:45, Greg Mirsky <gregimirsky@gmail.com> 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
>
> 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 <haoyu.song@futurewei.com> 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 <loa@pi.nu>
> > Sent: Monday, January 31, 2022 6:14 PM
> > To: Haoyu Song <haoyu.song@futurewei.com>; Tony Li <tony.li@tony.li>
> > Cc: mpls@ietf.org
> > 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 <loa@pi.nu>
> > > Sent: Monday, January 31, 2022 12:00 PM
> > > To: Haoyu Song <haoyu.song@futurewei.com>; Tony Li <tony.li@tony.li>
> > > Cc: mpls@ietf.org
> > > 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 <tony1athome@gmail.com> On Behalf Of Tony Li
> > > > Sent: Monday, January 31, 2022 9:03 AM
> > > > To: Haoyu Song <haoyu.song@futurewei.com>
> > > > Cc: Loa Andersson <loa@pi.nu>; mpls@ietf.org
> > > > 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 <haoyu.song@futurewei.com> 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 <loa@pi.nu>
> > > > > Sent: Monday, January 31, 2022 3:27 AM
> > > > > To: mpls@ietf.org; Haoyu Song <haoyu.song@futurewei.com>
> > > > > 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: 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > > > > w
> > > > > .ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%
> > > > > 4
> > > > > 0futurewei.com%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b24018
> > > > > 9
> > > > > c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb3d
> > > > > 8
> > > > > eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> > > > > C
> > > > > 3000&sdata=o%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE%3D&
> > > > > r
> > > > > eserved=0
> > > >
> > >
> >
> > --
> > 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://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
[Attachment #5 (text/html)]
<html><head><meta http-equiv="content-type" content="text/html; \
charset=utf-8"></head><body dir="auto">Greg,<div><br><br><div dir="ltr">Sent from my \
iPhone</div><div dir="ltr"><br><blockquote type="cite">On 2 Feb 2022, at 11:45, Greg \
Mirsky <gregimirsky@gmail.com> wrote:<br></blockquote><br></div><div \
dir="ltr">Are assuming that all "containers" for ancillary data are tje same \
size?</div><div dir="ltr">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"?</div><div dir="ltr"><br></div><div dir="ltr">Is this the implication of \
"fixed length" ?</div><div dir="ltr"><br></div><div dir="ltr">/Loa</div><blockquote \
type="cite"><div dir="ltr"><div dir="ltr">Hi Haoyu,<div>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.</div><div><br></div><div>Regards,</div><div>Greg</div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 31, 2022 at 7:28 PM \
Haoyu Song <<a href="mailto:haoyu.song@futurewei.com">haoyu.song@futurewei.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Loa,<br> <br>
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.<br> Please clarify if I misunderstood your question.<br>
<br>
Best,<br>
Haoyu <br>
<br>
-----Original Message-----<br>
From: Loa Andersson <<a href="mailto:loa@pi.nu" target="_blank">loa@pi.nu</a>> \
<br>
Sent: Monday, January 31, 2022 6:14 PM<br>
To: Haoyu Song <<a href="mailto:haoyu.song@futurewei.com" \
target="_blank">haoyu.song@futurewei.com</a>>; Tony Li <<a \
href="mailto:tony.li@tony.li" \
target="_blank">tony.li@tony.li</a>><br>
Cc: <a href="mailto:mpls@ietf.org" target="_blank">mpls@ietf.org</a><br>
Subject: Re: [mpls] Question on avoiding TLVs<br>
<br>
Haoyu,<br>
<br>
So when we look at what goes on the wire, there is no T and no L?<br>
<br>
/Loa<br>
<br>
On 01/02/2022 04:22, Haoyu Song wrote:<br>
> Hi Loa,<br>
> <br>
> When designing new headers, it's good enough to simply organize them <br>
> 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.<br> > IPv6 EH \
follows such a structure, our proposed MPLS EH also follows such a structure.<br> \
> 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).<br> > <br>
> Haoyu<br>
> <br>
> <br>
> <br>
> -----Original Message-----<br>
> From: Loa Andersson <<a href="mailto:loa@pi.nu" \
target="_blank">loa@pi.nu</a>><br> > Sent: Monday, January 31, 2022 12:00 \
PM<br> > To: Haoyu Song <<a href="mailto:haoyu.song@futurewei.com" \
target="_blank">haoyu.song@futurewei.com</a>>; Tony Li <<a \
href="mailto:tony.li@tony.li" target="_blank">tony.li@tony.li</a>><br> > Cc: <a \
href="mailto:mpls@ietf.org" target="_blank">mpls@ietf.org</a><br> > Subject: Re: \
[mpls] Question on avoiding TLVs<br> > <br>
> Haoyu, Tony,<br>
> <br>
> I appreciate the difference in TLVs for the forwarding plane and for the control \
plane.<br> > <br>
> So looking at the forwarding exactly what should not be TLV encoded?<br>
> <br>
> Can you give examples?<br>
> <br>
> /Loa<br>
> <br>
> On 01/02/2022 01:25, Haoyu Song wrote:<br>
>> Hi Tony,<br>
>><br>
>> Yes you are right. Here we are discussing the headers designed for data \
plane fast path processing.<br> >> Most of the TLVs designed before are for \
control plane to use.<br> >> 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.<br> >> 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.<br> >><br>
>> Best,<br>
>> Haoyu<br>
>><br>
>> -----Original Message-----<br>
>> From: Tony Li <<a href="mailto:tony1athome@gmail.com" \
target="_blank">tony1athome@gmail.com</a>> On Behalf Of Tony Li<br> >> Sent: \
Monday, January 31, 2022 9:03 AM<br> >> To: Haoyu Song <<a \
href="mailto:haoyu.song@futurewei.com" \
target="_blank">haoyu.song@futurewei.com</a>><br> >> Cc: Loa Andersson \
<<a href="mailto:loa@pi.nu" target="_blank">loa@pi.nu</a>>; <a \
href="mailto:mpls@ietf.org" target="_blank">mpls@ietf.org</a><br> >> Subject: \
Re: [mpls] Question on avoiding TLVs<br> >><br>
>><br>
>> Haoyu, Loa,<br>
>><br>
>> 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.<br> >><br>
>> Tony<br>
>><br>
>><br>
>>> On Jan 31, 2022, at 8:46 AM, Haoyu Song <<a \
href="mailto:haoyu.song@futurewei.com" \
target="_blank">haoyu.song@futurewei.com</a>> wrote:<br> >>><br>
>>> Hi Loa,<br>
>>><br>
>>> 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.<br> >>> 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.<br> >>><br>
>>> 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.<br> >>><br>
>>> Best,<br>
>>> Haoyu<br>
>>><br>
>>> -----Original Message-----<br>
>>> From: Loa Andersson <<a href="mailto:loa@pi.nu" \
target="_blank">loa@pi.nu</a>><br> >>> Sent: Monday, January 31, 2022 \
3:27 AM<br> >>> To: <a href="mailto:mpls@ietf.org" \
target="_blank">mpls@ietf.org</a>; Haoyu Song <<a \
href="mailto:haoyu.song@futurewei.com" \
target="_blank">haoyu.song@futurewei.com</a>><br> >>> Subject: Question \
on avoiding TLVs<br> >>><br>
>>> Haoyu,<br>
>>><br>
>>> In the slides you uploaded to the "We should try the best to avoid TLV \
style and variable sized header".<br> >>><br>
>>> MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you \
suggesting we'd change this?<br> >>><br>
>>> Given your advice above what should we do?<br>
>>><br>
>>> /Loa<br>
>>> -- <br>
>>> Loa Andersson \
email: <a href="mailto:loa@pi.nu" \
target="_blank">loa@pi.nu</a><br> >>> Senior MPLS Expert \
<a \
href="mailto:loa.pi.nu@gmail.com" target="_blank">loa.pi.nu@gmail.com</a><br> \
>>> Bronze Dragon Consulting \
phone: +46 739 81 21 64<br> >>> \
_______________________________________________<br> >>> mpls mailing \
list<br> >>> <a href="mailto:mpls@ietf.org" \
target="_blank">mpls@ietf.org</a><br> >>> <a \
href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww" \
rel="noreferrer" target="_blank">https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww</a><br>
>>> w<br>
>>> .<a href="http://ietf.org" rel="noreferrer" \
target="_blank">ietf.org</a>%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%<br>
>>> 4<br>
>>> <a href="http://0futurewei.com" rel="noreferrer" \
target="_blank">0futurewei.com</a>%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b24018<br>
>>> 9<br>
>>> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb3d<br>
>>> 8 <br>
>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7<br>
>>> C <br>
>>> 3000&amp;sdata=o%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE%3D&amp;<br>
>>> r<br>
>>> eserved=0<br>
>><br>
> <br>
<br>
-- <br>
Loa Andersson \
email: <a href="mailto:loa@pi.nu" target="_blank">loa@pi.nu</a><br> \
Senior MPLS Expert \
<a href="mailto:loa.pi.nu@gmail.com" \
target="_blank">loa.pi.nu@gmail.com</a><br> Bronze Dragon Consulting \
phone: +46 739 81 21 64<br> <br>
_______________________________________________<br>
mpls mailing list<br>
<a href="mailto:mpls@ietf.org" target="_blank">mpls@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/mpls" rel="noreferrer" \
target="_blank">https://www.ietf.org/mailman/listinfo/mpls</a><br> \
</blockquote></div> <span>_______________________________________________</span><br><span>mpls \
mailing list</span><br><span>mpls@ietf.org</span><br><span>https://www.ietf.org/mailman/listinfo/mpls</span><br></div></blockquote></div></body></html>
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic