Subject: [mpls] Extension headers structure

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 22 Apr 2021 17:01:02 +0000

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:

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:[email-masked]] On Behalf Of Fomin, Sergey (Nokia - US/Mountain View)
Sent: Thursday, April 22, 2021 3:57 AM
To: Tarek Saad <tsaad=[email-masked]>; [email-masked]
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Tarek Saad

Sent: Wednesday, April 21, 2021 12:16 PM

To: [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>

Subject: Re: [mpls] Reminder on MPLS Open DT

Hi WG,

A tentative agenda for tomorrow's Open MPLS DT meeting is posted at:

https://trac.ietf.org/trac/mpls/wiki/track2

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" <[email-masked]<mailto:[email-masked]>> wrote:

    All,

    I added some minutes taken during the 1st meeting we held on 4/8 at:

    https://trac.ietf.org/trac/mpls/wiki/meeting20210408

    Regards,

    Tarek/wg chairs

    On 4/13/21, 12:08 PM, "Loa Andersson" <[email-masked]<mailto:[email-masked]>> wrote:

        Design Team'

        We have our first Track 1 meting on 2021-04-15.

        The agenda will be found at:

        https://trac.ietf.org/trac/mpls/wiki/track1-agenda

        WebEx info:

        https://mailarchive.ietf.org/arch/msg/mpls/jU7XZe9UeTQYU_SVSd0qT4YRAZU/

        Loa/wg chairs

        --

        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

    Juniper Business Use Only

Juniper Business Use Only

_______________________________________________

mpls mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________

mpls mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/mpls

---

From: Haoyu Song <[email-masked]>
Date: Thu, 22 Apr 2021 17:21:55 +0000

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://datatracker.ietf.org/doc/draft-song-mpls-extension-header/

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 <[email-masked]> On Behalf Of Vasilenko Eduard
Sent: Thursday, April 22, 2021 10:01 AM
To: [email-masked]
Subject: [mpls] Extension headers structure

Hi all,

Eduard

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Fomin, Sergey (Nokia - US/Mountain View)
Sent: Thursday, April 22, 2021 3:57 AM
To: Tarek Saad <tsaad=[email-masked]<mailto:tsaad=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Reminder on MPLS Open DT

Hi Tarek,

Wiki says:

--

Sergey

-----Original Message-----

Hi WG,

https://trac.ietf.org/trac/mpls/wiki/track2<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fmpls%2Fwiki%2Ftrack2&data=04%7C01%7Chaoyu.song%40futurewei.com%7C4db9ab82c0284306a60b08d905b0462a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637547076938223342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GRXgwIglG1YUhN0mJx1Ea%2B8XYLab%2FbPUull8L3WHt9M%3D&reserved=0>

Regards,

    All,

    https://trac.ietf.org/trac/mpls/wiki/meeting20210408<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fmpls%2Fwiki%2Fmeeting20210408&data=04%7C01%7Chaoyu.song%40futurewei.com%7C4db9ab82c0284306a60b08d905b0462a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637547076938233337%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LCtkR54sgUB%2B6OPmJH23nOdvulrqc1tv%2FIC%2BIVzpLFM%3D&reserved=0>

    Regards,

    Tarek/wg chairs

        Design Team'

        https://trac.ietf.org/trac/mpls/wiki/track1-agenda<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fmpls%2Fwiki%2Ftrack1-agenda&data=04%7C01%7Chaoyu.song%40futurewei.com%7C4db9ab82c0284306a60b08d905b0462a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637547076938233337%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PHh1icBtINZAXkBmIZJewVH%2FqAMr%2F25niasEUq6Ez6Q%3D&reserved=0>

        WebEx info:

        https://mailarchive.ietf.org/arch/msg/mpls/jU7XZe9UeTQYU_SVSd0qT4YRAZU/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmpls%2FjU7XZe9UeTQYU_SVSd0qT4YRAZU%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C4db9ab82c0284306a60b08d905b0462a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637547076938243330%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1pa7cJfgcBvnKq1CDfBSb9Zscr6%2FAPqcWaKBp%2B7WLAw%3D&reserved=0>

        Loa/wg chairs

        --

mpls mailing list

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%7C4db9ab82c0284306a60b08d905b0462a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637547076938243330%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=s9V6gLFf8Te1eSIMDjO%2BAmCWvpveQqufq2Eg8NAYpS8%3D&reserved=0>

mpls mailing list

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%7C4db9ab82c0284306a60b08d905b0462a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637547076938253322%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vwCeWqzdL7gyL2%2BS4G%2FmZiZMbpHFmO8DSHJ5tw%2FpPcg%3D&reserved=0>

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 22 Apr 2021 18:14:18 +0000

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:[email-masked]]
Sent: Thursday, April 22, 2021 8:22 PM
To: Vasilenko Eduard <[email-masked]>; [email-masked]
Subject: RE: Extension headers structure

Hi Eduard and all,

Thanks,
Haoyu

From: mpls <[email-masked]<mailto:[email-masked]>> On Behalf Of Vasilenko Eduard
Sent: Thursday, April 22, 2021 10:01 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [mpls] Extension headers structure

Hi all,

Eduard

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Fomin, Sergey (Nokia - US/Mountain View)
Sent: Thursday, April 22, 2021 3:57 AM
To: Tarek Saad <tsaad=[email-masked]<mailto:tsaad=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Reminder on MPLS Open DT

Hi Tarek,

Wiki says:

--

Sergey

-----Original Message-----

Hi WG,

Regards,

    All,

    Regards,

    Tarek/wg chairs

        Design Team'

        WebEx info:

        Loa/wg chairs

        --

mpls mailing list

mpls mailing list

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 22 Apr 2021 18:35:37 +0000

Hi Haoyu,

If the concept of Header of headers is important (e.g., so that we can quickly find the start of real payload), it can be incorporated into GDF as well – we can define a “GDFH container” type for “this header” and pack all contiguous GDFHs into it.

Hi Eduard,

If I understand you correctly, yours is not TLV (where the T indicates the type of *this* block), but nTLV, where nT indicates the type of *next* block. I am not saying that is unreasonable, but want to clarify it.

The intention of GDFH is to make it applicable to different layers, so it has the “next header” from the IP protocol number space and the “this header” from its own space.

Thanks.
Jeffrey

From: mpls <[email-masked]> On Behalf Of Vasilenko Eduard
Sent: Thursday, April 22, 2021 2:14 PM
To: Haoyu Song <[email-masked]>; [email-masked]
Subject: Re: [mpls] Extension headers structure

[External Email. Be cautious of content]

Hi Haoyu,

Eduard
From: Haoyu Song [mailto:[email-masked]]
Sent: Thursday, April 22, 2021 8:22 PM
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
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://datatracker.ietf.org/doc/draft-song-mpls-extension-header/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-song-mpls-extension-header/__;!!NEt6yMaO-gk!UcPfvQUsT8y6JuiIbJIZK5-vx91IHV4oT4uxIR5hEqwWqK-zXutIGP2bROzCB-EQ$>

Thanks,
Haoyu

Hi all,

Eduard

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Fomin, Sergey (Nokia - US/Mountain View)
Sent: Thursday, April 22, 2021 3:57 AM
To: Tarek Saad <tsaad=[email-masked]<mailto:tsaad=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Reminder on MPLS Open DT

Hi Tarek,

Wiki says:

--

Sergey

-----Original Message-----

Hi WG,

https://trac.ietf.org/trac/mpls/wiki/track2<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Ftrac.ietf.org*2Ftrac*2Fmpls*2Fwiki*2Ftrack2&data=04*7C01*7Chaoyu.song*40futurewei.com*7C4db9ab82c0284306a60b08d905b0462a*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637547076938223342*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=GRXgwIglG1YUhN0mJx1Ea*2B8XYLab*2FbPUull8L3WHt9M*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!UcPfvQUsT8y6JuiIbJIZK5-vx91IHV4oT4uxIR5hEqwWqK-zXutIGP2bRHZfUM45$>

Regards,

    All,

    https://trac.ietf.org/trac/mpls/wiki/meeting20210408<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Ftrac.ietf.org*2Ftrac*2Fmpls*2Fwiki*2Fmeeting20210408&data=04*7C01*7Chaoyu.song*40futurewei.com*7C4db9ab82c0284306a60b08d905b0462a*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637547076938233337*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=LCtkR54sgUB*2B6OPmJH23nOdvulrqc1tv*2FIC*2BIVzpLFM*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!UcPfvQUsT8y6JuiIbJIZK5-vx91IHV4oT4uxIR5hEqwWqK-zXutIGP2bRILavBB7$>

    Regards,

    Tarek/wg chairs

        Design Team'

        https://trac.ietf.org/trac/mpls/wiki/track1-agenda<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Ftrac.ietf.org*2Ftrac*2Fmpls*2Fwiki*2Ftrack1-agenda&data=04*7C01*7Chaoyu.song*40futurewei.com*7C4db9ab82c0284306a60b08d905b0462a*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637547076938233337*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=PHh1icBtINZAXkBmIZJewVH*2FqAMr*2F25niasEUq6Ez6Q*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!UcPfvQUsT8y6JuiIbJIZK5-vx91IHV4oT4uxIR5hEqwWqK-zXutIGP2bRI2Ln_DH$>

        WebEx info:

        https://mailarchive.ietf.org/arch/msg/mpls/jU7XZe9UeTQYU_SVSd0qT4YRAZU/<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Fmpls*2FjU7XZe9UeTQYU_SVSd0qT4YRAZU*2F&data=04*7C01*7Chaoyu.song*40futurewei.com*7C4db9ab82c0284306a60b08d905b0462a*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637547076938243330*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=1pa7cJfgcBvnKq1CDfBSb9Zscr6*2FAPqcWaKBp*2B7WLAw*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!UcPfvQUsT8y6JuiIbJIZK5-vx91IHV4oT4uxIR5hEqwWqK-zXutIGP2bRA9MUsOe$>

        Loa/wg chairs

        --

mpls mailing list

https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fmpls&data=04*7C01*7Chaoyu.song*40futurewei.com*7C4db9ab82c0284306a60b08d905b0462a*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637547076938243330*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=s9V6gLFf8Te1eSIMDjO*2BAmCWvpveQqufq2Eg8NAYpS8*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!UcPfvQUsT8y6JuiIbJIZK5-vx91IHV4oT4uxIR5hEqwWqK-zXutIGP2bRDDxMDVS$>

mpls mailing list

https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fmpls&data=04*7C01*7Chaoyu.song*40futurewei.com*7C4db9ab82c0284306a60b08d905b0462a*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637547076938253322*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=vwCeWqzdL7gyL2*2BS4G*2FmZiZMbpHFmO8DSHJ5tw*2FpPcg*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!UcPfvQUsT8y6JuiIbJIZK5-vx91IHV4oT4uxIR5hEqwWqK-zXutIGP2bRAgnRyhZ$>

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 22 Apr 2021 18:52:13 +0000

Hi Jeffrey,

Yes, “T” means “Type of the Next”. I believe that many data planes have the same meaning now for T. They still call it T, not nT. But it is not principal.
And yes, the last one is better to be from IP protocol number space (pointing to IPv6/v4).
Strictly speaking, my proposal is not TLV, but TOV (Offset), Where TO and V are in different places. But of course, they are related to each other.

Look below at my proposal for your draft: the last T should be from IP protocol space – no problem.
My proposition for your draft could be encoded as “Zero:T:TLV…TLV”
If you would accept what I have proposed to you below then T would mean “Type of the Next” for all solutions discussed here.
It is right because our last T should point to IP protocol.

I am strictly opposite “headers of headers”. This concept has killed IPv6 EH. Much bigger complexity for hardware. Guys producing half-routers/half-switches would not implement it for the next X>Y years.
I propose to keep MPLS EH in the flat stricture: one-by-one without hierarchy.

Ed/
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Thursday, April 22, 2021 9:36 PM
To: Vasilenko Eduard <[email-masked]>; Haoyu Song <[email-masked]>; [email-masked]
Subject: RE: Extension headers structure

Hi Haoyu,

Hi Eduard,

Thanks.
Jeffrey

From: mpls <[email-masked]<mailto:[email-masked]>> On Behalf Of Vasilenko Eduard
Sent: Thursday, April 22, 2021 2:14 PM
To: Haoyu Song <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Extension headers structure

Hi Haoyu,

Eduard

Hi Eduard and all,

Thanks,
Haoyu

Hi all,

Eduard

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Fomin, Sergey (Nokia - US/Mountain View)
Sent: Thursday, April 22, 2021 3:57 AM
To: Tarek Saad <tsaad=[email-masked]<mailto:tsaad=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Reminder on MPLS Open DT

Hi Tarek,

Wiki says:

--

Sergey

-----Original Message-----

Hi WG,

Regards,

    All,

    Regards,

    Tarek/wg chairs

        Design Team'

        WebEx info:

        Loa/wg chairs

        --

mpls mailing list

mpls mailing list

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 22 Apr 2021 20:56:17 +0200

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:
> Extension headers structure would be ???Zero:TO???TO:V???V???
> 
> Eduard
> 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
> 
> 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.
> 
> (I did not say the better ??? I still prefer less redundancy).
> 
> 
> 
> Eduard
> 
> ???On 4/19/21, 10:58 AM, "Tarek Saad" <[email-masked]<mailto:[email-masked]>> wrote:
> 
> 
> 
>     All,
> 
> 
> 
>     ???On 4/13/21, 12:08 PM, "Loa Andersson" <[email-masked]<mailto:[email-masked]>> wrote:
> 
> 
> 
>         Design Team'
> 
> 
> 
> 
> 

> [email-masked]

-- 
---
[email-masked]

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 22 Apr 2021 19:16:14 +0000

Hi Toerless,
How every parameter would be formatted?
If it is a fixed size value - then is it possible to have all parameters of the same size?
If it is variable size then you need TLV for every parameter anyway.
No additional advantage from putting TLVs into the hierarchy.
The only real limit is 255 EHs that we have in the flat structure (byte for Type).

If these 5 parameters are always together - then it is 1 parameter with a fixed structure inside. No problem.
But would be not many such cases.

I do not believe that it is possible to have only a fixed structure for all use cases.
I do agree with you that if it is possible then the fixed structure is much better. MPLS stack has proven it.
But it is a very important question for many people to comment on: Do we need Variable parameters in MPLS metadata?
Do we wont to cover such use cases?
By the way, if you propose only fixed structures - what should be the size of 1 structure? Why?
Ed/
-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]] 
Sent: Thursday, April 22, 2021 9:56 PM
To: Vasilenko Eduard <[email-masked]>
Cc: Haoyu Song <[email-masked]>; [email-masked]
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.

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:
> To: Tarek Saad 
> <tsaad=[email-masked]<mailto:tsaad=[email-masked]
> etf.org>>; [email-masked]<mailto:[email-masked]>
> https://trac.ietf.org/trac/mpls/wiki/track2<https://nam11.safelinks.pr
> otection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fmpls%2F
> wiki%2Ftrack2&data=04%7C01%7Chaoyu.song%40futurewei.com%7C4db9ab82c028
> 4306a60b08d905b0462a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6375
> 47076938223342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GRXgwIglG1YUhN0mJx1Ea
> %2B8XYLab%2FbPUull8L3WHt9M%3D&reserved=0>
> 
> 
> 
> https://trac.ietf.org/trac/mpls/wiki/meeting20210408<https://nam11.saf
> elinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%
> 2Fmpls%2Fwiki%2Fmeeting20210408&data=04%7C01%7Chaoyu.song%40futurewei.
> com%7C4db9ab82c0284306a60b08d905b0462a%7C0fee8ff2a3b240189c753a1d5591f
> edc%7C1%7C0%7C637547076938233337%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LCt
> kR54sgUB%2B6OPmJH23nOdvulrqc1tv%2FIC%2BIVzpLFM%3D&reserved=0>
> 
> 
> 
>     Regards,
> 
>     Tarek/wg chairs
> 
> 
> 
> https://trac.ietf.org/trac/mpls/wiki/track1-agenda<https://nam11.safel
> inks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2F
> mpls%2Fwiki%2Ftrack1-agenda&data=04%7C01%7Chaoyu.song%40futurewei.com%
> 7C4db9ab82c0284306a60b08d905b0462a%7C0fee8ff2a3b240189c753a1d5591fedc%
> 7C1%7C0%7C637547076938233337%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PHh1icB
> tINZAXkBmIZJewVH%2FqAMr%2F25niasEUq6Ez6Q%3D&reserved=0>
> 
> 
> 
>         WebEx info:
> 
> 
> 
> 
> 
>         
> https://mailarchive.ietf.org/arch/msg/mpls/jU7XZe9UeTQYU_SVSd0qT4YRAZU
> /<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> ilarchive.ietf.org%2Farch%2Fmsg%2Fmpls%2FjU7XZe9UeTQYU_SVSd0qT4YRAZU%2
> F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C4db9ab82c0284306a60b08d9
> 05b0462a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6375470769382433
> 30%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1pa7cJfgcBvnKq1CDfBSb9Zscr6%2FAPq
> cWaKBp%2B7WLAw%3D&reserved=0>
> 
> 
> 
>         Loa/wg chairs
> 
> 
> 
>         --
> 
> 
> 
> https://www.ietf.org/mailman/listinfo/mpls<https://nam11.safelinks.pro
> tection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistin
> fo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C4db9ab82c0284306
> a60b08d905b0462a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63754707
> 6938243330%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=s9V6gLFf8Te1eSIMDjO%2BAmC
> WvpveQqufq2Eg8NAYpS8%3D&reserved=0>
> 
> https://www.ietf.org/mailman/listinfo/mpls<https://nam11.safelinks.pro
> tection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistin
> fo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C4db9ab82c0284306
> a60b08d905b0462a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63754707
> 6938253322%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vwCeWqzdL7gyL2%2BS4G%2FmZ
> iZMbpHFmO8DSHJ5tw%2FpPcg%3D&reserved=0>

--
---
[email-masked]

---

From: Haoyu Song <[email-masked]>
Date: Thu, 22 Apr 2021 20:01:08 +0000

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. Second, how would we accommodate the existing ones, such as IOAM, if they didn't follow the format?

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. 

Cheers,
Haoyu

-----Original Message-----
From: Toerless Eckert <[email-masked]> 
Sent: Thursday, April 22, 2021 11:56 AM
To: Vasilenko Eduard <[email-masked]>
Cc: Haoyu Song <[email-masked]>; [email-masked]
Subject: Re: [mpls] Extension headers structure

Cheers
    Toerless

On Thu, Apr 22, 2021 at 06:14:18PM +0000, Vasilenko Eduard wrote:
> 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
> 
> 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>
> 
> 
> 
> 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
> 
> 
> 
> 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
> 
> 
> 
>         --
> 
> 
> 
> 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>
> 
> 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>

> 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

--
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 23 Apr 2021 08:21:27 +0200

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 ma…

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

-- 
---
[email-masked]

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 23 Apr 2021 07:25:16 +0000

Hi Toerless,
There was a big discussion recently in 6man on how to make Hob-by-Hob EH work (draft-hinden-6man-hbh-processing).
Only HbH was analyzed because other headers are considered not so harmful.

The only powerful proposal was: limit HbH to 1 option inside.
It is effectively: limit innovation in this direction. Many people asked: please, do not do it.

Another proposal was: All HbH options should be processed in the Data Plane. The slow path should not be permitted.
Address packet directly to the control plane if you would like to do something in it.

Next proposal: node should disclose in CLI and YANG what it supports in the data plane.
Administrators should not have any doubts about what is possible and what is not. They would block if they are not sure of the result.

I do not think that too many rules could be postulated here.
Hence it is probably the section in the document that would define MPLS EH architecture, not a separate document.
I agree that it is a very important section. Market acceptance is very much dependent on it.
Eduard
-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]] 
Sent: Friday, April 23, 2021 9:21 AM
To: Haoyu Song <[email-masked]>
Cc: Vasilenko Eduard <[email-masked]>; [email-masked]
Subject: Re: [mpls] Extension headers structure

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 ma…

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

> 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
> 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 
> > <tsaad=[email-masked]<mailto:tsaad=40juniper.net@dmarc
> > .i etf.org>>; [email-masked]<mailto:[email-masked]>
> > 1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wCDBT8j%2Fq%2Fiy4UvO8NQWpkMcat
> > L2 FyPJ4iE%2Bl7zyFto%3D&amp;reserved=0>
> > 
> > 
> > 
> >         WebEx info:
> > 
> > 
> > 
> > 
> > 
> >         

--
---
[email-masked]