Re: [mpls] Extension headers structure

[Toerless Eckert <[e-mail]>]

On Thu, Apr 22, 2021 at 08:01:08PM +0000, Haoyu Song wrote:
> It's a good practice to consider the hardware efficiency when designing a header which is supposed to be processed in data plane. It's even better if we can propose some formal guideline for this. However, IMO that would be at best some best-practice recommendation and it would be very difficult to try to enforce the format structure for all the EHs. 

>First, we can't envision the needs of future application, which could be very diversified and supposed to be used in other types of networks.

Just draw he equivalent to how we formalize the syntax at other levels of networking:
e.g.: YANG and NetConf at management plane, CDDL/CBOR at control plane. Yes, of
course, if you come up with requirements that are not well supported by these
"syntax models" then you extend the syntax models.

But lets just look at what we have done in data plane: Its mostly fixed size VVVV headers
(all base headers, ethernet, IP,...). Quite limited amount of variability. IMHO it is
not that difficult to create a simple model that is able to represent all the information
we have in current protocols.

> Second, how would we accommodate the existing ones, such as IOAM, if they didn't follow the format?

It is not the goal to be able to have a syntactical representation
of all posible existing headers, it is only necessary to be able to represent all
the type of information elements of existing headers. Aka: bit-encoding on the
wire IMHO does not need to be idential.

> Also, variable length header processing is not necessarily inefficient, as long as at the beginning we know where the next header is. Even at the age of IPv4, we have header options that already make the header size variable. 

A good understanding of the history is useful here because there are multiple things
at play and i think they can be fixed, but we may need to specify in our RFCs
more than we did in the past.

E.g.: Yes, we already had variability in IPv4, but we also killed most of them
through unsufficient implementations that where punting packets with extensions
headers to "slow-path". There MAY be some options where this is appropriate,
but for most, this is not. We never even attempted to create crisp requirements
about the need to be able to support extensions at some specific level of performance,
or else an implementation would be considered to be non-compliant. I think this
can be done. 

Now, in MPLS, we did not have that much of bad experiences, mostly because
we never had this history of broad-range of platforms supporting MPLS especially
platforms having CPU and accelerated forwarding. But the more we want to expand
MPLS to become more universal, the more we could run into the bad experience
we had with IP unless we are aware and try to avoid them.

Cheers
    Toerless

> Cheers,
> Haoyu
> 
> -----Original Message-----
> From: Toerless Eckert <[e-mail]> 
> Sent: Thursday, April 22, 2021 11:56 AM
> To: Vasilenko Eduard <[e-mail]>
> Cc: Haoyu Song <[e-mail]>; [e-mail]
> Subject: Re: [mpls] Extension headers structure
> 
> Lets say i have 5 service parameters i need to put into a packet.
> If i have a separate extension header for each service parameter, i will venture to guess that i will carry a lot more bits on the wire than if i had a single extension header and put all those
> 5 parameters into that one extension header.
> 
> So now comes the question of "variable length processing". We seem to be clear that different extension headers will hve different lengths. But then when we go down into multiple parameters within a single extension header, we traditional shied away more from variable length. I think this is not justified by technology of forwarders today: If a parser in a forwarder can efficiently parse a set of different size extension headers, then so can it parse a set of equivalently flexible parameters within a single extension header. But we would likely end up with much more efficient encoding on the wire.
> 
> To make parsing easy, it would ultimately be best if we could apply the same parsing requirements across extension headers as inside an extension header. I am not saying i have a full solution for this in my head though. But i think it would be very prudent to not brush aside discussing howto encode parameters of an extension header. That exactly is what IMHO made IPv6 extension headers fail to get consisten high-speed implementations.
> 
> Instead of just thinking about TLV in extension headers like we have done it in SRH, one might consider to apply what made MPLS successful: You can have a sequence of predefined VVVV (different size V) and sill be flexible and extensible, if the size and semantic of the V was not defined by a protocol spec but was defined by the control plane. Thats effectively what an MPLS label stack already is, except for the fixed-length.
> 
> Aka: In very much the same way as i signal in OSPF/ISIS the semantic of labels/SIDs, i could signal the encoding/semantic of a particular extension header.
> 
> Example: Extension header with some identifier (maybe even label):
> 
> Encoding: V1(16)V2(8)V3(4)V4(4)V5(32)
> Semantic: V1=latency,V2=ECMP-hash,V3=priority,V5=...
> 
> Semantics like "latency", "ECMP-hash", "priority" would be defined by standards and get into a registry, but would never need to show up in the forwarding plane (much like a lot of what we also do AFAIK in SR). But in control plane. Maybe initially platforms may also only be able to support very few and slow change of this, e.g.: just initially from NetConf instead of OSPF/ISIS, because any extension header structure defined this way might need to trigger some compilation of HW-forwarding structures (P4 parser code for example). More like
> e.g.: HW-ACL creation in forwarding plane (slow) than MTRIE creation for routing (better be fast, although its often not).
> 
> Cheers
>     Toerless
> 
> On Thu, Apr 22, 2021 at 06:14:18PM +0000, Vasilenko Eduard wrote:
> > Hi Haoyu,
> > In reality, your HEH is half of the step to what I propose (Catalog). Hence, I like it more that was discussed today.
> > It permits to find of the end of all MPLS headers without parsing everything. It is already the big added value for the P that may need to look to IP layer for whatever reason.
> > By the way, EHTLEN in your case is Offset in reality.
> > 
> > I propose to move all TLs to the fixed structure in front and convert Lengths to Offsets.
> > Selective headers processing is the flexibility that is better to have.
> > Extension headers structure would be ???Zero:TO???TO:V???V???
> > 
> > Eduard
> > From: Haoyu Song [mailto:[e-mail]]
> > Sent: Thursday, April 22, 2021 8:22 PM
> > To: Vasilenko Eduard <[e-mail]>; [e-mail]
> > Subject: RE: Extension headers structure
> > 
> > Hi Eduard and all,
> > 
> > Unless I misunderstood something, the following proposal (using TLV instead of the redundant LTTV) has been described in our MPLS Extension Header drafts. In addition, we use a Header of EH to summarize the number and size of the following extension headers, as well as the type of the first extension header.
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > tracker.ietf.org%2Fdoc%2Fdraft-song-mpls-extension-header%2F&amp;data=
> > 04%7C01%7Chaoyu.song%40futurewei.com%7Cafa5f80e5f144b138ff008d905c0538
> > 4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637547145876139926%7CUn
> > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> > wiLCJXVCI6Mn0%3D%7C1000&amp;sdata=mRKlUDDP9%2FJsGFNbqle1CwscoGk7beUv3u
> > mK%2BRHyZWU%3D&amp;reserved=0
> > 
> > Since we have started to discuss individual proposals, I???ll also request the moderator to add an agenda item in the next meeting so I can give a detailed introduction of the MPLS extension header drafts.
> > 
> > Thanks,
> > Haoyu
> > 
> > From: mpls <[e-mail]<mailto:[e-mail]>> On 
> > Behalf Of Vasilenko Eduard
> > Sent: Thursday, April 22, 2021 10:01 AM
> > To: [e-mail]<mailto:[e-mail]>
> > Subject: [mpls] Extension headers structure
> > 
> > 
> > Hi all,
> > 
> > About today's discussion.
> > 
> > I would like to discuss at the subsequent meeting a completely different proposal that I am not sure you would accept.
> > 
> > Hence, it makes sense to improve the current one. I am not happy about ???0LTTV??? structure: redundant ???0??? and one ???T??? in every extension header.
> > 
> > It is just a matter of human interpretation - it does not have any difference for hardware. I propose to return to the ???TLV??? structure.
> > 
> > Look to the attached - it is a little animated. But the essence is probably possible to understand from this picture:
> > 
> > [cid:image002.png@01D737BA.22E05190]
> > 
> > 
> > 
> > Except for alignment. If you are sure that alignment is always possible for the MPLS stack - then the current proposal makes sense.
> > (I did not say the better ??? I still prefer less redundancy).
> > 
> > 
> > 
> > Eduard
> > 
> > -----Original Message-----
> > From: mpls [mailto:[e-mail]] On Behalf Of Fomin, Sergey 
> > (Nokia - US/Mountain View)
> > Sent: Thursday, April 22, 2021 3:57 AM
> > To: Tarek Saad 
> > <tsaad=[e-mail]<mailto:tsaad=40juniper.net@dmarc.i
> > etf.org>>; [e-mail]<mailto:[e-mail]>
> > Cc: [e-mail]<mailto:[e-mail]>
> > Subject: Re: [mpls] Reminder on MPLS Open DT
> > 
> > 
> > 
> > Hi Tarek,
> > 
> > I'm a bit lost between "track1" and "track2" scopes..
> > 
> > 
> > 
> > Wiki says:
> > 
> >               Week 2 and 4: Track 1 "Below the BoS"
> > 
> >               Week 3 and 5: Track 2 "Above the BoS"
> > 
> > 
> > 
> > And the agenda looks like some mix of the two?
> > 
> > 
> > 
> > --
> > 
> > Sergey
> > 
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > 
> > From: mpls <[e-mail]<mailto:[e-mail]>> On 
> > Behalf Of Tarek Saad
> > 
> > Sent: Wednesday, April 21, 2021 12:16 PM
> > 
> > To: [e-mail]<mailto:[e-mail]>
> > 
> > Cc: [e-mail]<mailto:[e-mail]>
> > 
> > Subject: Re: [mpls] Reminder on MPLS Open DT
> > 
> > 
> > 
> > Hi WG,
> > 
> > 
> > 
> > A tentative agenda for tomorrow's Open MPLS DT meeting is posted at:
> > 
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac
> > .ietf.org%2Ftrac%2Fmpls%2Fwiki%2Ftrack2&amp;data=04%7C01%7Chaoyu.song%
> > 40futurewei.com%7Cafa5f80e5f144b138ff008d905c05384%7C0fee8ff2a3b240189
> > c753a1d5591fedc%7C1%7C0%7C637547145876139926%7CUnknown%7CTWFpbGZsb3d8e
> > yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> > 00&amp;sdata=k5ay2Igdf8P%2F3sgOoNEDSbgkBnnt08qusUi%2FkElPpBc%3D&amp;re
> > served=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%
> > 2F%2Ftrac.ietf.org%2Ftrac%2Fmpls%2Fwiki%2Ftrack2&amp;data=04%7C01%7Cha
> > oyu.song%40futurewei.com%7Cafa5f80e5f144b138ff008d905c05384%7C0fee8ff2
> > a3b240189c753a1d5591fedc%7C1%7C0%7C637547145876139926%7CUnknown%7CTWFp
> > bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> > 0%3D%7C1000&amp;sdata=k5ay2Igdf8P%2F3sgOoNEDSbgkBnnt08qusUi%2FkElPpBc%
> > 3D&amp;reserved=0>
> > 
> > 
> > 
> > Let me know if you want to add a discussion point.
> > 
> > 
> > 
> > Regards,
> > 
> > Tarek (for mpls wg chairs)
> > 
> > 
> > 
> > 
> > 
> > ???On 4/19/21, 10:58 AM, "Tarek Saad" <[e-mail]<mailto:[e-mail]>> wrote:
> > 
> > 
> > 
> >     All,
> > 
> > 
> > 
> >     I added some minutes taken during the 1st meeting we held on 4/8 at:
> > 
> >     
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac
> > .ietf.org%2Ftrac%2Fmpls%2Fwiki%2Fmeeting20210408&amp;data=04%7C01%7Cha
> > oyu.song%40futurewei.com%7Cafa5f80e5f144b138ff008d905c05384%7C0fee8ff2
> > a3b240189c753a1d5591fedc%7C1%7C0%7C637547145876139926%7CUnknown%7CTWFp
> > bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> > 0%3D%7C1000&amp;sdata=OfBp0XpFalD2QTCCiHuDi8cRO%2BqM5mFKvsrfrltnS8M%3D
> > &amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=ht
> > tps%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fmpls%2Fwiki%2Fmeeting20210408&amp;d
> > ata=04%7C01%7Chaoyu.song%40futurewei.com%7Cafa5f80e5f144b138ff008d905c
> > 05384%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637547145876139926%
> > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> > 1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=OfBp0XpFalD2QTCCiHuDi8cRO%2BqM5m
> > FKvsrfrltnS8M%3D&amp;reserved=0>
> > 
> > 
> > 
> >     Regards,
> > 
> >     Tarek/wg chairs
> > 
> > 
> > 
> >     ???On 4/13/21, 12:08 PM, "Loa Andersson" <[e-mail]<mailto:[e-mail]>> wrote:
> > 
> > 
> > 
> >         Design Team'
> > 
> > 
> > 
> > 
> > 
> >         We have our first Track 1 meting on 2021-04-15.
> > 
> > 
> > 
> >         The agenda will be found at:
> > 
> > 
> > 
> >         
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac
> > .ietf.org%2Ftrac%2Fmpls%2Fwiki%2Ftrack1-agenda&amp;data=04%7C01%7Chaoy
> > u.song%40futurewei.com%7Cafa5f80e5f144b138ff008d905c05384%7C0fee8ff2a3
> > b240189c753a1d5591fedc%7C1%7C0%7C637547145876149918%7CUnknown%7CTWFpbG
> > Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> > 3D%7C1000&amp;sdata=wCDBT8j%2Fq%2Fiy4UvO8NQWpkMcatL2FyPJ4iE%2Bl7zyFto%
> > 3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=
> > https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fmpls%2Fwiki%2Ftrack1-agenda&amp;d
> > ata=04%7C01%7Chaoyu.song%40futurewei.com%7Cafa5f80e5f144b138ff008d905c
> > 05384%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637547145876149918%
> > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> > 1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wCDBT8j%2Fq%2Fiy4UvO8NQWpkMcatL2
> > FyPJ4iE%2Bl7zyFto%3D&amp;reserved=0>
> > 
> > 
> > 
> >         WebEx info:
> > 
> > 
> > 
> > 
> > 
> >         
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> > archive.ietf.org%2Farch%2Fmsg%2Fmpls%2FjU7XZe9UeTQYU_SVSd0qT4YRAZU%2F&
> > amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Cafa5f80e5f144b138ff008
> > d905c05384%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63754714587614
> > 9918%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> > iI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=neGwPOYQSI8nAJLXFCUAKr%2FM%
> > 2FpSnQvKzZiq5oZ4x4Ww%3D&amp;reserved=0<https://nam11.safelinks.protect
> > ion.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2
> > Fmpls%2FjU7XZe9UeTQYU_SVSd0qT4YRAZU%2F&amp;data=04%7C01%7Chaoyu.song%4
> > 0futurewei.com%7Cafa5f80e5f144b138ff008d905c05384%7C0fee8ff2a3b240189c
> > 753a1d5591fedc%7C1%7C0%7C637547145876149918%7CUnknown%7CTWFpbGZsb3d8ey
> > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
> > 0&amp;sdata=neGwPOYQSI8nAJLXFCUAKr%2FM%2FpSnQvKzZiq5oZ4x4Ww%3D&amp;res
> > erved=0>
> > 
> > 
> > 
> >         Loa/wg chairs
> > 
> > 
> > 
> >         --
> > 
> > 
> > 
> >         Loa Andersson                        email: [e-mail]<mailto:[e-mail]>
> > 
> >         Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>
> > 
> >         Bronze Dragon Consulting             phone: [phone]
> > 
> > 
> > 
> > 
> > 
> >     Juniper Business Use Only
> > 
> > 
> > 
> > 
> > 
> > Juniper Business Use Only
> > 
> > _______________________________________________
> > 
> > mpls mailing list
> > 
> > [e-mail]<mailto:[e-mail]>
> > 
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%40f
> > uturewei.com%7Cafa5f80e5f144b138ff008d905c05384%7C0fee8ff2a3b240189c75
> > 3a1d5591fedc%7C1%7C0%7C637547145876149918%7CUnknown%7CTWFpbGZsb3d8eyJW
> > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> > amp;sdata=5r32McqmgjAuXiMWy0TRUr4xIuXKNtSHtfX4o9Z2ur4%3D&amp;reserved=
> > 0<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%7Cafa5f80e5f144b138ff008d905c05384%7C0fee8ff2a3b240189c
> > 753a1d5591fedc%7C1%7C0%7C637547145876149918%7CUnknown%7CTWFpbGZsb3d8ey
> > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
> > 0&amp;sdata=5r32McqmgjAuXiMWy0TRUr4xIuXKNtSHtfX4o9Z2ur4%3D&amp;reserve
> > d=0>
> > 
> > _______________________________________________
> > 
> > mpls mailing list
> > 
> > [e-mail]<mailto:[e-mail]>
> > 
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%40f
> > uturewei.com%7Cafa5f80e5f144b138ff008d905c05384%7C0fee8ff2a3b240189c75
> > 3a1d5591fedc%7C1%7C0%7C637547145876149918%7CUnknown%7CTWFpbGZsb3d8eyJW
> > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> > amp;sdata=5r32McqmgjAuXiMWy0TRUr4xIuXKNtSHtfX4o9Z2ur4%3D&amp;reserved=
> > 0<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%7Cafa5f80e5f144b138ff008d905c05384%7C0fee8ff2a3b240189c
> > 753a1d5591fedc%7C1%7C0%7C637547145876149918%7CUnknown%7CTWFpbGZsb3d8ey
> > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
> > 0&amp;sdata=5r32McqmgjAuXiMWy0TRUr4xIuXKNtSHtfX4o9Z2ur4%3D&amp;reserve
> > d=0>
> 
> 
> 
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%40f
> > uturewei.com%7Cafa5f80e5f144b138ff008d905c05384%7C0fee8ff2a3b240189c75
> > 3a1d5591fedc%7C1%7C0%7C637547145876149918%7CUnknown%7CTWFpbGZsb3d8eyJW
> > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> > amp;sdata=5r32McqmgjAuXiMWy0TRUr4xIuXKNtSHtfX4o9Z2ur4%3D&amp;reserved=
> > 0
> 
> 
> --
> ---
> [e-mail]

-- 
---
[e-mail]