Hi Linda Good point and I agree on DCI use case.
Thanks Gyan On Wed, Mar 31, 2021 at 11:23 AM Linda Dunbar <[email protected]> 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 <[email protected]> > *Sent:* Wednesday, March 31, 2021 12:12 AM > *To:* Pengshuping (Peng Shuping) <[email protected]> > *Cc:* Linda Dunbar <[email protected]>; [email protected]; > [email protected]; [email protected] > *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) < > [email protected]> 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:[email protected]] > Sent: Monday, March 29, 2021 4:54 PM > To: Pengshuping (Peng Shuping) <[email protected]> > Cc: Linda Dunbar <[email protected]>; [email protected]; > [email protected] > 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) < > [email protected]> 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:[email protected]] > > *Sent:* Tuesday, March 23, 2021 11:16 AM > > *To:* Pengshuping (Peng Shuping) <[email protected]>; > > [email protected]; [email protected] > > *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) <[email protected]> > > *Sent:* Sunday, March 21, 2021 8:39 PM > > *To:* Linda Dunbar <[email protected]>; > > [email protected]; [email protected] > > *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:[email protected] > > <[email protected]>] > > *Sent:* Saturday, March 20, 2021 11:31 AM > > *To:* Pengshuping (Peng Shuping) <[email protected]>; > > [email protected]; [email protected] > > *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 [email protected] <[email protected]>* > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
