Re: [Apn] should add the gap analysis for GENEVE (RFC8926)

"Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Wed, 31 March 2021 02:55 UTC

Return-Path: <pengshuping@huawei.com>
X-Original-To: apn@ietfa.amsl.com
Delivered-To: apn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CF83A12EC; Tue, 30 Mar 2021 19:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 NoNwncFxQ2xo; Tue, 30 Mar 2021 19:55:38 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D183A12F1; Tue, 30 Mar 2021 19:55:38 -0700 (PDT)
Received: from fraeml735-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4F99mC5xHPz684dg; Wed, 31 Mar 2021 10:50:35 +0800 (CST)
Received: from fraeml735-chm.china.huawei.com (10.206.15.216) by fraeml735-chm.china.huawei.com (10.206.15.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 31 Mar 2021 04:55:30 +0200
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by fraeml735-chm.china.huawei.com (10.206.15.216) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Wed, 31 Mar 2021 04:55:30 +0200
Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.141]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0513.000; Wed, 31 Mar 2021 10:55:24 +0800
From: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
CC: Linda Dunbar <linda.dunbar@futurewei.com>, "apn@ietf.org" <apn@ietf.org>, "draft-peng-apn-scope-gap-analysis@ietf.org" <draft-peng-apn-scope-gap-analysis@ietf.org>, "nvo3@ietf.org" <nvo3@ietf.org>
Thread-Topic: [Apn] should add the gap analysis for GENEVE (RFC8926)
Thread-Index: AdccUkbaMIFshIzhRci6WKwwf8chKwARl3NAAA20H/AAFwFhwAADW9NQAGCp+CAANUQHoAAw/EegAPhX2YAAaIV+QA==
Date: Wed, 31 Mar 2021 02:55:23 +0000
Message-ID: <4278D47A901B3041A737953BAA078ADE19A5C148@DGGEML532-MBX.china.huawei.com>
References: <SN6PR13MB2334C4F7D2306EF8907229F485699@SN6PR13MB2334.namprd13.prod.outlook.com> <4278D47A901B3041A737953BAA078ADE199E8C18@dggeml512-mbx.china.huawei.com> <SN6PR13MB2334ACCFC53BBF53A8A0EB0685689@SN6PR13MB2334.namprd13.prod.outlook.com> <4278D47A901B3041A737953BAA078ADE199F59E6@dggeml512-mbs.china.huawei.com> <SN6PR13MB23341B7846E18F07544E864785679@SN6PR13MB2334.namprd13.prod.outlook.com> <4278D47A901B3041A737953BAA078ADE19A09DCA@DGGEML532-MBX.china.huawei.com> <SN6PR13MB23347F5FA76E953DC90B52E485649@SN6PR13MB2334.namprd13.prod.outlook.com> <4278D47A901B3041A737953BAA078ADE19A29075@DGGEML532-MBX.china.huawei.com> <CABNhwV0nrdv7SBqCQDbEK+fW1tftziDZzgujmq3hFJ-BhHxPQw@mail.gmail.com>
In-Reply-To: <CABNhwV0nrdv7SBqCQDbEK+fW1tftziDZzgujmq3hFJ-BhHxPQw@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.114]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/gByyDqyT7_Z8gi6992FOe4S7EEE>
Subject: Re: [Apn] should add the gap analysis for GENEVE (RFC8926)
X-BeenThere: apn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Application-aware Networking <apn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apn>, <mailto:apn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apn/>
List-Post: <mailto:apn@ietf.org>
List-Help: <mailto:apn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apn>, <mailto:apn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Mar 2021 02:55:43 -0000

Hi Gyan,

Thank you for this information. I agree with your following statements. 

"You can see some similarities between the two NVO3 overlays GENEVE and VXLAN-GPE both having the ability carry metadata and so would be perfect for DC environment to carry APN ID in the metadata field for the endpoint characteristics signaling to the network."

Any concrete use cases that could potentially use APN ID with either VxLAN-GPE or GENEVE? 

I also copied NOV3. Hope experts could help here. Thank you! 

Best reards, 
Shuping 



-----Original Message-----
From: Gyan Mishra [mailto:hayabusagsm@gmail.com] 
Sent: Monday, March 29, 2021 4:54 PM
To: Pengshuping (Peng Shuping) <pengshuping@huawei.com>
Cc: Linda Dunbar <linda.dunbar@futurewei.com>; apn@ietf.org; draft-peng-apn-scope-gap-analysis@ietf.org
Subject: Re: [Apn] should add the gap analysis for GENEVE (RFC8926)

Hi Shuping

This is in similar context to use of VXLAN-GPE to carry APN APP ID marking information

https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-11


   The capabilities of the VXLAN-GPE protocol can be extended by
   defining next protocol "shim" headers that are used to implement new
   data plane functions.  For example, Group-Based Policy (GBP) or In-
   situ Operations, Administration, and Maintenance (IOAM) metadata
   functionalities can be added as specified in
   [I-D.lemon-vxlan-lisp-gpe-gbp
<https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-11#ref-I-D.lemon-vxlan-lisp-gpe-gbp>]
and
   [I-D.brockners-ippm-ioam-vxlan-gpe
<https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-11#ref-I-D.brockners-ippm-ioam-vxlan-gpe>].


GENEVE

https://tools.ietf.org/html/rfc8926

Work such as "VL2: A Scalable and Flexible Data Center Network" [VL2 <https://tools.ietf.org/html/rfc8926#ref-VL2>]
   and "NVO3 Data Plane Requirements" [NVO3-DATAPLANE <https://tools.ietf.org/html/rfc8926#ref-NVO3-DATAPLANE>] have described
   some of the properties that the data plane must have to support
   network virtualization.  However, one additional defining requirement
   is the need to carry metadata (e.g., system state) along with the
   packet data; example use cases of metadata are noted below.  The use
   of some metadata is certainly not a foreign concept -- nearly all
   protocols used for network virtualization have at least 24 bits of
   identifier space as a way to partition between tenants.  This is
   often described as overcoming the limits of 12-bit VLANs; when seen
   in that context or any context where it is a true tenant identifier,
   16 million possible entries is a large number.  However, the reality
   is that the metadata is not exclusively used to identify tenants, and
   encoding other information quickly starts to crowd the space.  In
   fact, when compared to the tags used to exchange metadata between
   line cards on a chassis switch, 24-bit identifiers start to look
   quite small.  There are nearly endless uses for this metadata,
   ranging from storing input port identifiers for simple security
   policies to sending service-based context for advanced middlebox
   applications that terminate and re-encapsulate Geneve traffic.



You can see some similarities between the two NVO3 overlays GENEVE and VXLAN-GPE both having the ability carry metadata and so would be perfect for DC environment to carry APN ID in the metadata field for the endpoint characteristics signaling to the network.

Kind Regards


Gyan

On Tue, Mar 23, 2021 at 10:26 PM Pengshuping (Peng Shuping) < pengshuping@huawei.com> wrote:

> Thank you, Linda!
>
>
>
> When we start exploring the solution using GENEVE, we would need to 
> know more about the use cases. Thank you for the information!
>
>
>
> BR,
>
> Shuping
>
>
>
> *From:* Linda Dunbar [mailto:linda.dunbar@futurewei.com]
> *Sent:* Tuesday, March 23, 2021 11:16 AM
> *To:* Pengshuping (Peng Shuping) <pengshuping@huawei.com>; 
> draft-peng-apn-scope-gap-analysis@ietf.org; apn@ietf.org
> *Subject:* RE: should add the gap analysis for GENEVE (RFC8926)
>
>
>
> Shuping,
>
>
>
> Here is one example: for 5G Edge Computing, the edge devices have 
> limited capacity. It can use GENEVE to carry information about the 
> characteristics of the App, such as Types, Edge device information, etc.
>
> Linda
>
>
>
>
>
> *From:* Pengshuping (Peng Shuping) <pengshuping@huawei.com>
> *Sent:* Sunday, March 21, 2021 8:39 PM
> *To:* Linda Dunbar <linda.dunbar@futurewei.com>; 
> draft-peng-apn-scope-gap-analysis@ietf.org; apn@ietf.org
> *Subject:* RE: should add the gap analysis for GENEVE (RFC8926)
>
>
>
> Hi Linda,
>
>
>
> I was wondering about the concrete usage scenarios since I am not 
> familiar with those with GENEVE. For example, in what scenario 
> carrying what information to do what?
>
>
>
> Any references on the IoT case you mentioned about?
>
>
>
> Thank you!
>
>
>
> Best regards,
>
> Shuping
>
>
>
> *From:* Linda Dunbar [mailto:linda.dunbar@futurewei.com
> <linda.dunbar@futurewei.com>]
> *Sent:* Saturday, March 20, 2021 11:31 AM
> *To:* Pengshuping (Peng Shuping) <pengshuping@huawei.com>; 
> draft-peng-apn-scope-gap-analysis@ietf.org; apn@ietf.org
> *Subject:* RE: should add the gap analysis for GENEVE (RFC8926)
>
>
>
> ShuPing,
>
>
>
> GENEVE is to carry metadata associated with the packet. Metadata can 
> be location information, compute information, service ID, App category, etc.