Re: [mpls] Extension headers structure

Toerless Eckert <tte@cs.fau.de> Thu, 22 April 2021 18:56 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284F83A09A5 for <mpls@ietfa.amsl.com>; Thu, 22 Apr 2021 11:56:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.95
X-Spam-Level:
X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUt_0C0_Pf_C for <mpls@ietfa.amsl.com>; Thu, 22 Apr 2021 11:56:26 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2063A098C for <mpls@ietf.org>; Thu, 22 Apr 2021 11:56:25 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0714F54806A; Thu, 22 Apr 2021 20:56:18 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id F281D4400B2; Thu, 22 Apr 2021 20:56:17 +0200 (CEST)
Date: Thu, 22 Apr 2021 20:56:17 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: Haoyu Song <haoyu.song@futurewei.com>, "mpls@ietf.org" <mpls@ietf.org>
Message-ID: <20210422185617.GH910@faui48f.informatik.uni-erlangen.de>
References: <2557c6829dd046c0b09efa75e5b96a1c@huawei.com> <DM6PR13MB2762B34E064D6E039FBB4CCA9A469@DM6PR13MB2762.namprd13.prod.outlook.com> <eb9f8a1a1d1f49f69060b624beef1c77@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <eb9f8a1a1d1f49f69060b624beef1c77@huawei.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/zpT_2LHqgw8IEufwwmD0eyMfj14>
Subject: Re: [mpls] Extension headers structure
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Apr 2021 18:56:31 -0000

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:haoyu.song@futurewei.com]
> Sent: Thursday, April 22, 2021 8:22 PM
> To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; mpls@ietf.org
> 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/
> 
> 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 <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>> On Behalf Of Vasilenko Eduard
> Sent: Thursday, April 22, 2021 10:01 AM
> To: mpls@ietf.org<mailto:mpls@ietf.org>
> 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:mpls-bounces@ietf.org] On Behalf Of Fomin, Sergey (Nokia - US/Mountain View)
> Sent: Thursday, April 22, 2021 3:57 AM
> To: Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org<mailto:tsaad=40juniper.net@dmarc.ietf.org>>; mpls@ietf.org<mailto:mpls@ietf.org>
> Cc: mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>
> 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 <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>> On Behalf Of Tarek Saad
> 
> Sent: Wednesday, April 21, 2021 12:16 PM
> 
> To: mpls@ietf.org<mailto:mpls@ietf.org>
> 
> Cc: mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>
> 
> 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<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>
> 
> 
> 
> 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" <tsaad@juniper.net<mailto:tsaad@juniper.net>> 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<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
> 
> 
> 
>     ???On 4/13/21, 12:08 PM, "Loa Andersson" <loa@pi.nu<mailto:loa@pi.nu>> 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<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
> 
> 
> 
>         --
> 
> 
> 
>         Loa Andersson                        email: loa@pi.nu<mailto:loa@pi.nu>
> 
>         Senior MPLS Expert                          loa.pi.nu@gmail.com<mailto:loa.pi.nu@gmail.com>
> 
>         Bronze Dragon Consulting             phone: +46 739 81 21 64
> 
> 
> 
> 
> 
>     Juniper Business Use Only
> 
> 
> 
> 
> 
> Juniper Business Use Only
> 
> _______________________________________________
> 
> mpls mailing list
> 
> mpls@ietf.org<mailto:mpls@ietf.org>
> 
> 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
> 
> mpls@ietf.org<mailto:mpls@ietf.org>
> 
> 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>



> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls


-- 
---
tte@cs.fau.de