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 BB2FD43B45; Mon, 19 Feb 2024 04:17:02 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4600E4029B; Mon, 19 Feb 2024 04:17:02 +0100 (CET) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2055.outbound.protection.outlook.com [40.107.223.55]) by mails.dpdk.org (Postfix) with ESMTP id 1368240278 for ; Mon, 19 Feb 2024 04:17:01 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PBx9uCOU81pCyzFAAxr1ikmkZIDPho+5kw5umrtCw0g89jebjMtcxd2qWpwgtJHM2uBxwV/i1WoXpTUPm01y2DN5fHx9LTWNH08DnNl5PMvwn7lTy64IitH+FCE3aD7XmmlV8bNIFezldAvDcLJPFjSm6q+9AW1J5STXkvois0WK2z+4aRPfyF6NpRqvvRaErml98VllkOwXCMBlawjV/sUSW23Sfunr7gS54TTBxP1cXU0j7WXKN9XQCPTfAVigrnIPEE1wZZp6xf4mYmGPWMgsjK4VB+wWgLqX18L02jyI9+xIG6bqlurVYeaHPAzrtxuHwFxrcs5+km0RZx74Tw== 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=K1FIDhOSoztwVhZlQnn48P3WcIek7z4hfUH/BHkOF70=; b=d/DJkY2bZnV0Tp+TfVvw1YxTVwroyty/89AYeObuXi8DlYK+BrKrevwsspbQQ4LCBP93c77lp/LWngoN10iKA3AR9sv3oVuAZO3T+Tw946iSyYZI+VVuD3N2ofeJaBZKC5Lebic3LJSl4iZz7Iu1T+Ab9vOQelV8XLiC/EvJgLx57RIilKGaGi01etGxwjoMDiiS5dyMA5WHolhfjGM/nIDdlKIjsXB3s6UeTbjqcATbWGQR1TWGHZmPNpgUaWdEOu4osfhCw4zZUHq4AywcQRuicpyHRWx6TaDTMOlDefl5NJPLlR7JgYk49bvMYyjgm9lS1OCBFsHHCAIVjSL8/Q== 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=K1FIDhOSoztwVhZlQnn48P3WcIek7z4hfUH/BHkOF70=; b=ia6OkrnDxou49HwLnzv2pl6D2hO+WmxAWwDx8oUtHq2yb66r0X85QS5s9FYMIvsb+9LFUodUWPYYKVaEuINdXsLpCwAT8zj0UZy7vyY+6S3Vcd9Bb6swiUqElPixVLkzvdUq9AP/GVf9Uzek4p7vaExFys1bHduyx/BXpjdwmhJ6GFAbAHtrS8EnDHk7pYOv4wwy/N8qQNo8p9XMUeiI2tDffBYROL8urrLFAV8wpq6EVuf8+gTHVdCy380I+U0fo0vodYYd5GhpCGjnHBBaeBj8EO4FBsQ858EIIv5xd7BlQ5lzoRkkFBln0j2fnsLcAIHBEnfbGIh50RyKr2THMA== 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 BL1PR12MB5802.namprd12.prod.outlook.com (2603:10b6:208:392::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7316.17; Mon, 19 Feb 2024 03:16:58 +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:16:58 +0000 Message-ID: Date: Mon, 19 Feb 2024 11:16:48 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [RFC V1 1/1] net: extend VXLAN header to support more extensions 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> Content-Language: en-US From: Gavin Li In-Reply-To: <27994279.gRfpFWEtPU@thomas> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SG2PR02CA0121.apcprd02.prod.outlook.com (2603:1096:4:188::21) To IA1PR12MB6019.namprd12.prod.outlook.com (2603:10b6:208:3d5::16) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA1PR12MB6019:EE_|BL1PR12MB5802:EE_ X-MS-Office365-Filtering-Correlation-Id: f0994036-7e99-4d9a-713f-08dc30f93b58 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: Qc+8TFypMGFuJqcH0kg6YIiGJN1etOmzo9Fx/cEdsH6sg0QsrNiByEdPEa3BBT3aHpQea/DkMTJX2hPMZH+vPcaMwE75JAZ62Oix+RlSZde3/MTdPQsJGVMKXjecTnVty/MPSwNuhBlB5QUNkWeLPzjXic6skGTj/LYpw/G6VFnvzl/XT3qVuAZPbmxBaHsQthc/BITL1a3qAwdJFp87vg7YXcvYAed5DmfeBfnpIjn+1/vNZxvYO1BaNLiqHwsZKh8iVJFXZVFN9VC438aj8wd8JTuZamn71dtesQ0UUrbSfaazm7UgJA6yP2sT0F2saZEv2Z4SBNhWPUl/UAXWZVmGpIf2QdM2k8e/2zHXKkgGEnb1X0uGpXIRWWfgIXh7ZbU1b5Mym9PAgXI4xC18Ex0ASteyJgVv/pHeksPzWjQb6xZZzh399H3ixswbHhKW4rddpVT9B7scyZ3rErXoTuSR6Hgh4ndrIuRG8Lkz5dbPp3v7kOnsLTYaGRZ651iJ2+4UxoyDJ7SMeC+EucMtG7nCvWj6+DbDWK1Uo3PYiP0Qf/4ADd/gOXMSeinq5QsqCqfa7yAK+RzCSEg1N27vStBAULT1hHHJDqn9uWHOZf4= 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)(376002)(39860400002)(346002)(136003)(366004)(396003)(230922051799003)(186009)(451199024)(64100799003)(1800799012)(83380400001)(86362001)(31696002)(38100700002)(6486002)(478600001)(966005)(66476007)(66556008)(66946007)(110136005)(26005)(316002)(2616005)(107886003)(6506007)(53546011)(6666004)(36756003)(6512007)(41300700001)(5660300002)(8936002)(4326008)(8676002)(31686004)(2906002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ei9tY1UwTUF3dEJZN0FBYXFZSjdvRFRrcUxMWlN6ZHpLdmFKZVJtQ1NSd29S?= =?utf-8?B?QkQyYUpIRnNxb3ZOZkpReG1hMUl5Q3o4TnEza0htTXZZMHR1UTdpNC9VUm5m?= =?utf-8?B?eWREL3YvWmxTS2xrWU1RRVRET1J6TEd0ZDlxbEg0VnRpUjhCdXNOeWRxb3hF?= =?utf-8?B?RldzUndQbXJWTVhHTndsdlQ4bGd5eEJkNmtjcXhPTCtqdlYrdVMyNGU0Ylpx?= =?utf-8?B?d1kzTkVOaFNmcFJDU016UE4rWmNKOHpPYmVXM1BjWFZ2c2NZQzFBcy9yUlBC?= =?utf-8?B?TytOZy90cnVIaHRYeFh4QVhkbG9pMzNUclY5MFFnSGRmTVBXcTJRdmlNa1BU?= =?utf-8?B?bTJlVklhQjVQWmJ3bURWQ2pvRUFaRlhPU3NXMG14czZrbCszU1hUWjVlZ1c2?= =?utf-8?B?K29ZT0lMbXVJbDNrNjcvcG5wUEQwME42U2FwSndvam9uYmdEcFRtdHlPc3Rq?= =?utf-8?B?Nzl0b2tqNmhwQjFZVTNWOEhtK3grODJCRHVDSk4vTXJESllla3dvWnNvMjJs?= =?utf-8?B?Y1U0V2VQWlhBNVJ6OFViallPbWNPOFN4bkxOUGtOOU9FY2JOaDczRHcvZDEx?= =?utf-8?B?KzdBSzJkZEYwbzFWYklOL3ZaL0xXNlN6Vk14dzRDUWNTUVJsWHFVYlpGKzRG?= =?utf-8?B?dDg1RFhDbmRUWGpxaWlQYmlkdGxMbUtwanR0Nk1XK1pUM3ByU1oyZnZ2Zmk5?= =?utf-8?B?cDU1T1VkSmw3UXVRbXU5d2N3QWNkT044V2FLam1KZXlBWDJ5RGZqb3pzVWZK?= =?utf-8?B?VWtDa3BBYmV3VitQSEVJU0cvd1B6RE5zbkRGeUtxaExUWXFJN1pZZkpJQ1Ro?= =?utf-8?B?SWMxcDRBOFJPblFrWHE2cUE3MFFQYTJ1cVBXYklDMHpieDh0dFo3YWlueE4y?= =?utf-8?B?WHc1cUdKcm8vNkdWSDQ3YnpuLzhJRm9yMjRrZ2ZiTytldGswdG90YjZaQUI5?= =?utf-8?B?U1pRVklzc3czNHVzRzRZWHlSVTYxUlVlK0NkcXdMcXJYQWZiaWN3dU1PTXhJ?= =?utf-8?B?OEovc2poWGZEeXRyYVEzRkRNQXpJSWdXa0NiZDIyMHk1Y2c2Q1FDQy9JV3V3?= =?utf-8?B?c2U5S2lQRFErZEh6eDFIemRoY05mYUVOVC9qbk1TYkF6M3VMcDhqQm04b25m?= =?utf-8?B?eFNFbnJzY0R1ejIrV0lwK0dJbjZxaVlSZVRqL2l6K01jNlhYM1FqMDJGN3BK?= =?utf-8?B?MnZTZHRPZkxUdDhIZkFZaFA5MmRnd1lHd3JRS3ROcGs1RFdRTWkvUG1pT2J1?= =?utf-8?B?NW1aWmp4ejhnVzBiVWIveEZMUUlDR3owVnF2YVl6d05rRzk1TkNmNnJuaE1r?= =?utf-8?B?eEp5cnVIWHNOdVpvYXVCblVjME1nZDhxbkhLaFhudDJ2aWxWZzRYL1RraHVz?= =?utf-8?B?S0pFTnY1YmhlV29CaUlPcGkyY1dTY09IamdGU2VsQUFKaDhRTUpMbUNNUWNG?= =?utf-8?B?YmRsUEU3YVo2RVdFVFJ6SmljVFFUV2oxeVlhWm0wWW84NWhpWTRzaG9CajQ4?= =?utf-8?B?N2Y3QS95U1BZN01xQ3M5QjZkNnY3bDU0T0NDeXRwY1BnNFFEWisyWlVVeFJu?= =?utf-8?B?SCszeEZtM2FSeFJEdGN5MXZIY2NPWG5DemZpNDBBMEtiNk5rb3hRK2EwbnUw?= =?utf-8?B?OXBwVFU5cS93TmJiRU1DZ0F5NDZLSUVDT2hUbkJONHNXd1ZJKzhmOHVEQTFu?= =?utf-8?B?eUxHK2NadE5tdk4rVmRUdWlqSU1ueWI4WEt6dHNXZDlFejI0MkQ2ZndOSmsv?= =?utf-8?B?UCtRSUFQV1lWUElCRitlU2tHek91bFV4elZFUWRJaDZsRS9xRHBhd25XS1B5?= =?utf-8?B?K1Q5czZpdjA2OVlJcXZ2RlJSWHpyRE1HTThmQTBJL2Y1VC9wazRQSnhUbUZ3?= =?utf-8?B?TVJhS3dqOGtuREZjNCtUMjNJTHlWNHlZMDdTeGRQTk1waTFGbjNHb2FMRFZw?= =?utf-8?B?L2FOclZKWlRoMGZwaGs1L2ZUdEhDOUphMURwT1hYck9oM2NiVkRUVkhzM3k5?= =?utf-8?B?OU15YUpNZ1FWWUpvMlBIS3ErcE41bnhCMkVJYXpOdVpQaUJSZmpPZXIvVDdV?= =?utf-8?B?WWNzQkp1UXQ1WklodVpvdEd3TkExNkpTU1R3Ny94V3JMSVpRdDhLSHZlMjlL?= =?utf-8?Q?xU0hyaSbfOcypavMz7HzAjIkL?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: f0994036-7e99-4d9a-713f-08dc30f93b58 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:16:58.3520 (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: NwaXJmaOnooJiCu2U6l4H6y2v+sMj/pJ4+qmJ0COOTIogmphCMsv3Zwh8FykjirJylwOnLOEkS2E8sPA446abg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5802 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 expertThe 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. > >