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

[Gyan Mishra <[e-mail]>]

Hi Linda

Good point and I agree on DCI use case.

Thanks

Gyan

On Wed, Mar 31, 2021 at 11:23 AM Linda Dunbar <[e-mail]>
wrote:

> Gyan, ShuPing,
>
>
>
> GENEVE and VxLAN-GPE encapsulated packets added by DC Leaf nodes can also
> be across different DCs, as long as the Leaf nodes in those DCs agree upon
> the meaning of the Metadata carried by the GENEVE/VxLAN-GPE headers.
>
>
>
> Is the “agreement of the meaning of the metadata” what APN wants to
> achieve?
>
>
>
> Linda Dunbar
>
>
>
> *From:* Gyan Mishra <[e-mail]>
> *Sent:* Wednesday, March 31, 2021 12:12 AM
> *To:* Pengshuping (Peng Shuping) <[e-mail]>
> *Cc:* Linda Dunbar <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> *Subject:* Re: [Apn] should add the gap analysis for GENEVE (RFC8926)
>
>
>
>
>
> Hi Shuping
>
>
>
> My thoughts were that in any Data Center NVO3 environment the APN ID can
> be introduced by the host or in this case can be injected with a policy as
> metadata into the NVO3 overlay GENEVE or VXLN-GPE at the leaf tunnel
> endpoint that does the encapsulation / decapsulation of the overlay
> header.  The App ID encoded as metadata into a Group policy ID shim header
> for VXLAN-GPE and for GENEVE in the data plane extensibility in TLV options
> format for future innovations such as APN.
>
>
>
> The APP ID would provide the signaling for fine grain network treatment
> and mapping to SRv6 SR-TE color mapping instantiation to achieve the
> desired application network treatment QOE.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
>
>
> On Tue, Mar 30, 2021 at 10:55 PM Pengshuping (Peng Shuping) <
> [e-mail]> wrote:
>
> 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:[e-mail]]
> Sent: Monday, March 29, 2021 4:54 PM
> To: Pengshuping (Peng Shuping) <[e-mail]>
> Cc: Linda Dunbar <[e-mail]>; [e-mail];
> [e-mail]
> 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
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-nvo3-vxlan-gpe-11&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce0bea3c9320f407f2ba108d8f40388fe%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637527643322516427%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aZ5ap7Dp55Q7S3roP5TVIa9e0Tz63b3D9BLtNSWQ7yc%3D&reserved=0>
>
>
>    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
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-nvo3-vxlan-gpe-11%23ref-I-D.lemon-vxlan-lisp-gpe-gbp&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce0bea3c9320f407f2ba108d8f40388fe%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637527643322516427%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QRUEjf7X%2Fj1ctXJFw%2BGibNZsjypfJXp%2BbfuM%2FYFNDaM%3D&reserved=0>
> >]
> 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
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-nvo3-vxlan-gpe-11%23ref-I-D.brockners-ippm-ioam-vxlan-gpe&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce0bea3c9320f407f2ba108d8f40388fe%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637527643322526419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=f%2FHmrh6UBBqlb%2FO3VHzHV9THyosfZiquhd5R51Y6sB4%3D&reserved=0>
> >].
>
>
> GENEVE
>
> https://tools.ietf.org/html/rfc8926
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8926&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce0bea3c9320f407f2ba108d8f40388fe%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637527643322526419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jkSRcdX7aD8lnZL7Xi%2F0fEdb%2Fm36xxXVJmBuXWLwemk%3D&reserved=0>
>
> Work such as "VL2: A Scalable and Flexible Data Center Network" [VL2 <
> https://tools.ietf.org/html/rfc8926#ref-VL2
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8926%23ref-VL2&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce0bea3c9320f407f2ba108d8f40388fe%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637527643322536413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LyTsOdYLRhjEqNU0hzsvwa0cBLPs3AcONZz%2FK6n8wQ8%3D&reserved=0>
> >]
>    and "NVO3 Data Plane Requirements" [NVO3-DATAPLANE <
> https://tools.ietf.org/html/rfc8926#ref-NVO3-DATAPLANE
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8926%23ref-NVO3-DATAPLANE&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce0bea3c9320f407f2ba108d8f40388fe%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637527643322536413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jLyFl7x6bNgLQs12prSqcgXqiWrPDfQi2Wng0zXV06Q%3D&reserved=0>>]
> 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) <
> [e-mail]> 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:[e-mail]]
> > *Sent:* Tuesday, March 23, 2021 11:16 AM
> > *To:* Pengshuping (Peng Shuping) <[e-mail]>;
> > [e-mail]; [e-mail]
> > *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) <[e-mail]>
> > *Sent:* Sunday, March 21, 2021 8:39 PM
> > *To:* Linda Dunbar <[e-mail]>;
> > [e-mail]; [e-mail]
> > *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:[e-mail]
> > <[e-mail]>]
> > *Sent:* Saturday, March 20, 2021 11:31 AM
> > *To:* Pengshuping (Peng Shuping) <[e-mail]>;
> > [e-mail]; [e-mail]
> > *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.
>
> --
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce0bea3c9320f407f2ba108d8f40388fe%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637527643322546405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rpM6pXB%2Ftu1myw4XkGfeWIt%2FuGZruoBhSznmGGyqJFk%3D&reserved=0>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*