From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id D050E43B45; Mon, 19 Feb 2024 04:44:31 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A42724029B; Mon, 19 Feb 2024 04:44:31 +0100 (CET) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2057.outbound.protection.outlook.com [40.107.94.57]) by mails.dpdk.org (Postfix) with ESMTP id A864140278 for ; Mon, 19 Feb 2024 04:44:29 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L9CPhnr8HkUGvG7a7AAZMer42WTi3ruEKYbZGkBC2PGZ/DKNC3M8IWH1/Ln5LS8oAMrUutHgthaaQ2fgEAEZkWd/n+V/Lu1M+LbX9fBZFX3pbLvNk7pS/FdIpZRwys+MZ987GJbtZwrq1PtH9kxn3KGBcpsOEagfdLixW/fn9JzxWBv42iMdh/8vNTlylc3PeB5P5BnbP4mvu6MQosohzd2Tlyi/zvnJ0tiBMbIr5aiNRSHTm953rdKOJscb2VL+HIohKhmmMi6lYpwXZMUoYZsFjDYvaggu78yjA/ks/7LQnSbn97Qr2CgSjaWzE4IzJqoZ49hUFV4GhreQdGf4cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MQdaDhGr+V6mx5WuJoeBR9orYHhqezf88AwWeV9VyZo=; b=EKOYYqqrAcx/n9GEOqJvaQQhiNTptU6ruN3hACwuNKHYlYMN41Ahdv6FEMjaqmyBcLFB2PuhcieUOKXzsEepkWPMqWYELKpHUba9cQJcGfG1NMvtlhGImloaoeFXsdBkV+sNZuLipzuFzVRe2HI0EwTCDo4MV2mED3Xfkf6WrDgbqo8BOFCt/TyDZwRuhK0JgyWneohwB1MZMwz+nhPzM2qrNPgqOchvamVN2fHpEUnvWN9b32YS68O1Qq+TGjo6T+86aGOFszf9XIcfvoSHW2x0zwMK1SlbJt4g8mJDkSmZDYQW0xAWUOSZ3dKmel7M585gLssDzBPq16lpQ8nw9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MQdaDhGr+V6mx5WuJoeBR9orYHhqezf88AwWeV9VyZo=; b=mDDuuIkPVjv4pJ4bmhp6p3czInWNsjQKTXraH6QaVZ+/Ux/VcdZISswLpBtqiyyciTB82p1aTeMoiLzsFu3+g/Qvo24WX9PZMoEdVBwvzLpO9Y0jMr3Szex2cYFseHaSVvo0bKKYfwE3GuCq4/SK1GC3HHN6MzawinSwdnX02prmQuq4ODrFAqNH4coGQlOtuWUBsulQ7KKs4SPx1f0YnAkBieCsS24+7igsNrBfaVFxpJe7qy9d1kbYpr3ZnfpwT+JbxPUK0OyHwDwIwsQEGEU7Qrqa//fU1urL1x07/WworkNb7xGBTMF3kjd/gCFzyQ4X2NMyHMUSfZYPNREp2w== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Received: from IA1PR12MB6019.namprd12.prod.outlook.com (2603:10b6:208:3d5::16) by MN6PR12MB8514.namprd12.prod.outlook.com (2603:10b6:208:474::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7316.19; Mon, 19 Feb 2024 03:44:26 +0000 Received: from IA1PR12MB6019.namprd12.prod.outlook.com ([fe80::8c2e:f7e8:e736:4370]) by IA1PR12MB6019.namprd12.prod.outlook.com ([fe80::8c2e:f7e8:e736:4370%2]) with mapi id 15.20.7292.022; Mon, 19 Feb 2024 03:44:26 +0000 Message-ID: <6f109cc9-87a1-43a0-8b13-190ee263be1c@nvidia.com> Date: Mon, 19 Feb 2024 11:44:17 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [RFC V1 1/1] net: extend VXLAN header to support more extensions Content-Language: en-US To: Thomas Monjalon , orika@nvidia.com, andrew.rybchenko@oktetlabs.ru, Ferruh Yigit Cc: dev@dpdk.org, jiaweiw@nvidia.com References: <20240130112520.1971315-1-gavinl@nvidia.com> <4126957.6PsWsQAL7t@thomas> <27994279.gRfpFWEtPU@thomas> From: Gavin Li In-Reply-To: <27994279.gRfpFWEtPU@thomas> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SG2PR06CA0182.apcprd06.prod.outlook.com (2603:1096:4:1::14) To IA1PR12MB6019.namprd12.prod.outlook.com (2603:10b6:208:3d5::16) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA1PR12MB6019:EE_|MN6PR12MB8514:EE_ X-MS-Office365-Filtering-Correlation-Id: ef0ca9a9-6050-4b80-b899-08dc30fd11c9 X-LD-Processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: lwEcnDz1NAEKU60Bf7zLpliB8OeHKpu1RuSW/qNM38glt9A9/MSOXTNacJbaDHWnCVCsyeMKE7Ni7ICjlJ4P9BVS8S4KvDHAf/ChZAnAgnlZ7mdJxUCwNGtYzjwXS8gGkaYraq6LCBEAk+1iHAz49+lS4mjcxN6Eyf9YS0YKqCzCBYH5TmpvIrmXn4XP0VFUI+GaL3pObj9JF76dEvkhUwRppX0iCKwJ4EpMreGUmv09aucrVjUJi9to7wqUA9XQLznlfXGicG1WYVs1YOcf0rPJyW7qgPsf4V2A9uDDaWdoEz4DcozZmdTM1UT9EUuMCftYF3CmWOSmVjDEOXv260HAGtMOMgiqP8w71Y00lwF9Pu1HX8Tkz3DDXdtZ1KoRGl/GVs9MNPpBb+GV+r3i5L3Yowi1mGtTFD3nTM3Wj1+renQBrGyXCSiqLp0+dS5B97d0yUgQXvddI9r+ZOnRgdQqeQHGt58Bzge7g4RAr8z5iNuiF8FOlIZlp10liFijt/DI1IUDeN91Fcw5n2CYUaNDeei+Z0LNwqmG9eEtKUU4Hgk9cKnsldVjhwN+cdlMl6/wo+lNDCsj3nATJ2S+E360nyb+h5Ix911dJZ7f9tk= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:IA1PR12MB6019.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(136003)(346002)(366004)(376002)(39860400002)(396003)(230922051799003)(451199024)(1800799012)(64100799003)(186009)(2906002)(5660300002)(4326008)(107886003)(36756003)(2616005)(41300700001)(26005)(478600001)(38100700002)(83380400001)(31696002)(86362001)(8936002)(8676002)(66556008)(66476007)(66946007)(966005)(53546011)(6486002)(6512007)(6506007)(6666004)(316002)(110136005)(31686004); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MkNodTFpV2tvbkRKWE5mMGowR3Juem95U1Y0VmRCdlBBZ283b1BkcEkwcC92?= =?utf-8?B?N1pWM1ZaZ1NPWkR6SjNrTmc3ZFRjaXZKcTFkdkxFK2FqdHdLZGdQTkV6NGJr?= =?utf-8?B?WlBXcThJeVNpVlhYTDNhSGE3M2VrcXg0YmFUQXdVOHRnV001bWFhRXZLZ1ky?= =?utf-8?B?UFpXUnYybWJGYXBZS0U5UTgzMXV2S3B6QXpDSzIwQkI3NkYwbHFYb3lsck9W?= =?utf-8?B?c1dJQnBwdG9TMUhRbnhwMVRya0ZicDB0NUtrVzM4Y2k0K2xkMlBRclJ4V2VC?= =?utf-8?B?TkNhMkRMdHVmOEpFbjducjE5OGxyZ21heHFROG5ZSnQ0bDJTZkZvZG8vZE1T?= =?utf-8?B?UEZWeFhBbDduUU1UK1RlVzVsWWgwSytiQkZHNjRhSmc1QVJkaXg5aHNuV21T?= =?utf-8?B?NzVBc1I4NUQ4WWsxaXdQYWxyMjhYVm1ybG1aNzZjcktueXlJVnhEY0c2NTZV?= =?utf-8?B?YzcvMEora1JTQnJEVFNWYUpmeFpCZGdjS05UdHhMcDBFTlM0ZUFFdXZtcGlO?= =?utf-8?B?M0cyUzFlMGVvdFc5QVJDYWpSWmxDbW1ia05FL2g2RkN4QWJ3M3A1K21oWjRF?= =?utf-8?B?VVF6OHB6SUk1RVdZd251ZGpPa0xET29KOE9EVUhtak10dytWb2VTcnphdldN?= =?utf-8?B?R2dmKzAwK2oyM3ZoSyswcHY1U0dmQ2xJbWhMdTduMGtRdDExVEZ4WjZ0T2VH?= =?utf-8?B?M0JqK3gzcDQ4WG5GQWUwaXlIc0hkNjNnWUJYa1RCQnczMitHTHVLd3pGZDl0?= =?utf-8?B?Q1JYeTc3UmRRZzZtSmdINW5YQVJONTFjNEhGdWlrN0NjWVUxZ1lSOFpiUGVR?= =?utf-8?B?WktvYTczQS9sL2JzcDhQWndlMmpSQ3NPWTRiOWFOVWw1NkgvT3ovTVB1SlBZ?= =?utf-8?B?ckFlUWpFcGpCdW9jSkRNMlMxaU12WTJCSlE3cDUzUFJDT1FFVmE5SkozRkFk?= =?utf-8?B?cUhpK25sREJPUlNtaEt5aGZac05MTUJINTdodERBLzNJT3lBWUpENlpTZCtI?= =?utf-8?B?OGxyYldRZXRaYXBhdUJjekY1Y0t2REhDWHRxWXhtOGMzdDBBWjhKQ1FDN3pI?= =?utf-8?B?YzE5L0FNTVA2U2dEUENqUVV6OGE0Yy9iTU53ME1uakhYeEZTamtybWRGZUxU?= =?utf-8?B?ZjIyTHExTXFlbHJSUmV1L0VrRzJQOFFyQlFHY1RSTk80L0pNQ1d3Wlg4dWx6?= =?utf-8?B?WDhsYWFqS25NOHI4Z0NEK3hhSXFWRHFCV0hhdzB3dERwaHBHYmQyYVBEYjNh?= =?utf-8?B?NGNmKy9GcldoNXJkckhiV2ZRdVJpM2NoNm83d3ZMdmNsU2luK3pMUUdFNDc2?= =?utf-8?B?a0lzR3ZMOFE1SEJ6WFZMOVpET0g4aC83NS8rSjNqREtWQUVCZ282TWw4aXR1?= =?utf-8?B?TkNwMTlZdnpkRnoxUlJBT2kwQ013RytZOUZKWS8rbDhMVjh1TEZFZml1OEVo?= =?utf-8?B?NnBBcEUzWE1FYWtkK2plL2JQdFVUa1VhUUVPaFovUStRZEM3RDdrYzFRTTMx?= =?utf-8?B?QXF2dVp1djd2dkZzeVdVTEVqZ0xhYXY3aEZQcXF5OUVXU1BiV0x3LytVUU01?= =?utf-8?B?ditsU3lsdXVvT2pzRkw3RDJaZDIvVVlMVWdBdHFYTDc3VndTSXdTaytDaVNX?= =?utf-8?B?OFpaZ3hqeitQdlIvYzdyR3lCRnBuNXJsRHpQYkJHYzBCMlQ5Vk9IUnZ2eHVx?= =?utf-8?B?cGJVcHlwbnJOU3k1emxzVEwwSlpkVHp5bld4OFp2cVNCdmwrRFF2UE53emFv?= =?utf-8?B?dnk3UFM3SDNoOTU3VG5QVGlpd2VIY0pkWERsRGN6OVYxTUZJRlNZWUVrMWZq?= =?utf-8?B?VEJKcDIxOXI1WEtqZTZrZEliQVpqNFZKTjh2QUZYSm8wUGZlR0NFN3VZeHBz?= =?utf-8?B?UDZScE91SVlkRVc1blo4SndUb1FtRngvUFgva3lTVmxlak5ONitpUG1FSDNp?= =?utf-8?B?TWl6VU1OZ01mZkFOTnBMemhNOWU1eU5FM2tzME94V3pNUTFzbEFCZnNSYVZt?= =?utf-8?B?a0wyeFpVcHpwUG5EeWJjU213bzlCUHJHYVh2aHhac1NaVDRiY3E0K2NUR3E5?= =?utf-8?B?QXVucENCVXQzTTdwOURwNGo2dTkzUjFoT3Z3NjlCUkl6MktFYlJQL2FyZ0xW?= =?utf-8?Q?iAa9u1OjzI+WCiiM8p40ic+6R?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: ef0ca9a9-6050-4b80-b899-08dc30fd11c9 X-MS-Exchange-CrossTenant-AuthSource: IA1PR12MB6019.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Feb 2024 03:44:26.4578 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: vno5MTUqQFTn1ej1nTBQoT7y50mQXpXFbpLXEDi9fhHUBiOxugTBcD9ZADKYPyTayz7RSNr+RwtyswgdUbH2Ew== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR12MB8514 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 2/9/2024 11:32 PM, Thomas Monjalon wrote: > 09/02/2024 15:58, Ferruh Yigit: >> On 2/9/2024 1:44 PM, Thomas Monjalon wrote: >>> 09/02/2024 13:11, Ferruh Yigit: >>>> On 2/9/2024 10:12 AM, Thomas Monjalon wrote: >>>>> 09/02/2024 00:54, Ferruh Yigit: >>>>>> On 1/30/2024 11:25 AM, Gavin Li wrote: >>>>>>> Currently, DPDK supports VXLAN and VXLAN-GPE with similar header >>>>>>> structures and we are working on adding support for VXLAN-GBP which is >>>>>>> another extension to VXLAN. More extension of VXLAN may be added in the >>>>>>> future. >>>>>>> >>>>>>> VXLAN and VXLAN-GBP use the same UDP port(4789) while VXLAN-GPE uses a >>>>>>> different one, 4790. The three protocols have the same header length and >>>>>>> overall similar header structure as below. >>>>>>> 0 1 2 3 >>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> |R|R|R|R|I|R|R|R| Reserved | >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | VXLAN Network Identifier (VNI) | Reserved | >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> >>>>>>> Figure 1: VXLAN Header >>>>>>> >>>>>>> 0 1 2 3 >>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> |R|R|Ver|I|P|B|O| Reserved |Next Protocol | >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | VXLAN Network Identifier (VNI) | Reserved | >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> >>>>>>> Figure 2: VXLAN-GPE Header >>>>>>> >>>>>>> 0 1 2 3 >>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> |G|R|R|R|I|R|R|R|R|D|R|R|A|R|R|R| Group Policy ID | >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | VXLAN Network Identifier (VNI) | Reserved | >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> >>>>>>> Figure 3: VXLAN-GBP Extension >>>>>>> >>>>>>> Both VXLAN-GPE and VXLAN-GBP extended VXLAN by redefining its reserved >>>>>>> bits, which means the packets can be processed with same pattern and most >>>>>>> of the code can be reused. Instead of adding more new items by >>>>>>> copying/pasting code for the VXLAN extensions in the future, it’s better >>>>>>> to use existing VXLAN infrastructure and add support code in it. >>>>>>> >>>>>> >>>>>> Hi Gavin, >>>>>> >>>>>> The motivation is to prevent code duplication, and the code mentioned is >>>>>> the driver code, right? >>>>> >>>>> The motivation is mainly to provide a unified and more explicit API. >>>>> >>>> >>>> From user perspective, I think existing approach is more explicit, >>>> because it sets VXLAN or VXLAN_GPE flow types. >>>> >>>> I am trying to understand the benefit, how unifying flow type in the API >>>> helps to the user? >>>> >>>>>> Overall OK to unify "struct rte_vxlan_hdr" although it makes the struct >>>>>> a little complex, perhaps we can consider extraction some nested structs >>>>>> as named struct, no strong opinion. >>>>>> >>>>>> >>>>>> But not sure about removing the flow item types for VXLAN-GPE, or not >>>>>> adding for VXLAN-GBP. >>>>>> >>>>>> Think about a case user adding a rule, which has a item type as VXLAN >>>>>> and in the protocol header some bits are set, lets say first word, last >>>>>> byte is set, how driver will know if to take it as GPE "next protocol" >>>>>> or "group policy id". >>>>> >>>>> The driver may decide depending on the UDP port and some distinguishing flags. >>>>> If you want to match on GBP, you should includes the GBP flag in your pattern, >>>>> no need to use a separate item. >>>>> >>>> >>>> Why not be more explicit? >>>> It helps to driver to know more about the pattern to be able to create >>>> proper flow rule, if there is an obvious way for driver to differentiate >>>> these protocol extensions, and flow item type is redundant, I can >>>> understand the proposal, but otherwise I think better to keep flow items >>>> for extensions. >>> >>> In any case we need the simple VXLAN item. >>> If we have GPE and GBP specialized items, >>> what means a match on the simple VXLAN? >>> Does it include packets with other extensions or exclude them? >>> Matching the bits in the protocol make such decision explicit. >>> >>>> When a rule is set in HW, HW may not care about the protocol, as long as >>>> bits in the rule match with the packet, HW can apply the action. >>>> But for driver to be able to set the rule properly, it needs more >>>> explicit information. >>> >>> Yes information is in the pattern to match. >>> >>>> Lets assume driver API get a pattern with 'RTE_FLOW_ITEM_TYPE_VXLAN' >>>> type and "struct rte_flow_item_vxlan", at this point driver doesn't know >>>> if it is VXLAN or any of the extensions. >>> >>> Yes it knows because of the matched bits in the pattern. >>> If the rule specify a match on GBP flag = 1, it is GBP only. >>> If the rule specify a match on GBP flag = 0, it excludes GBP. >>> If the rule does not mask GBP flag, it includes GBP. >>> >> >> >> OK, VXLAN-GBP protocol has a GBP flag that gives a way to differentiate >> the extension, so flow item for it becomes redundant and we can get rid >> of it. > > Yes I think so. > >> Is it same for the other extensions? >> If we use VXLAN flow item and by setting specific field in pattern can >> we differentiate VXLAN and any other extension? >> Or in some cases other information, like UDP port, needs to be taken >> into account to differentiate protocol/extension? > > For VXLAN-GPE, differentiation is on UDP port. > Remember we have an API to fill some UDP ports: > rte_eth_dev_udp_tunnel_port_add with RTE_ETH_TUNNEL_TYPE_VXLAN_GPE > > The UDP port value/mask may be part of the flow rule pattern. > > >> I found a spec for VXLAN-GBP, but it shows as sub-header for VXLAN-GPE, >> different than what this RFC describes: >> https://datatracker.ietf.org/doc/html/draft-lemon-vxlan-gpe-gbp >> >> Can you please share link for VXLAN-GBP Extension spec? > > I will let Gavin explain here, I'm not an expert. Sorry for the wrong format of my last mail. Let me try again. The RFC mentioned, aka draft-lemon-vxlan-gpe-gbp was to define VXLAN-GBP as a sub header of VXLAN-GPE by assigning a next protocol num of VXLAN-GPE for VXLAN-GBP, which has been obsoleted since draft-ietf-nvo3-vxlan-gpe-09, the latest is draft-ietf-nvo3-vxlan-gpe-13. It was temporarily valid from draft-ietf-nvo3-vxlan-gpe-05 to draft-ietf-nvo3-vxlan-gpe-08. The VXLAN-GBP we are discussing in this thread is an VXLAN extension parallel to VXLAN-GPE. The RFC introduced VXLAN-GBP sub header to VXLAN-GPE is https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-05. The RFC obsoleted the sub header is https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-09. The latest RFC of VXLAN-GPE is https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-13. > >