Please see inline below. From: Pankaj Garg [mailto:[email protected]] Sent: Tuesday, March 11, 2014 11:41 PM To: Black, David; Lucy yong; [email protected] Cc: [email protected] Subject: RE: needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements
I think that SFC meta-data is similar to VNI, whereas VNI is used to carry the context for doing network virtualization, SFC carries context for doing service chaining. Similarly, there may be other context fields to carry OAM meta-data or performance meta-data. In all these cases, NVO encapsulation actually carries the inner frame i.e. the one originated by a VM (in case of a hypervisor based system). The inner frame can be L2, L3, UDP, TCP, HTTP etc. However, VNI, VN context, OAM meta-data, SFC meta-data, Performance meta-data provide the contextual data for doing things like network virtualization, service chaining, OAM etc. [Lucy] I agree. We can use a flag on overlay header to indicate the presence of SFC header on the encapsulated packet. Thus NVO technology supports L2 or L3 based forwarding, and SFC based forwarding. SFC header can be seen as a metadata in the overlay header and it is optional. This is what I try to express in early mails. I am not sure if we should mix SFC meta-data with the inner frame which is what is the actual payload in the encapsulation. [Lucy] IMO, we should separate two cases. If not, it means that NVO carries non-SFC and SFC traffic seamlessly, i.e. egress NVE just forwards a packet to TS based on inner address on the packet, which means that NVO technology does not support SFC or irrelevant to SFC. Lucy From: nvo3 [mailto:[email protected]] On Behalf Of Black, David Sent: Wednesday, March 12, 2014 1:02 AM To: Lucy yong; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements I agree that nvo3 data planes will carry some SFC traffic ... ... and some UDP traffic, and some RTP traffic and some HTTP traffic, etc. Thanks, --David From: nvo3 [mailto:[email protected]] On Behalf Of Lucy yong Sent: Tuesday, March 11, 2014 3:21 PM To: Black, David; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements David, From: Black, David [mailto:[email protected]] Sent: Tuesday, March 11, 2014 2:14 PM To: Lucy yong; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: RE: needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements Lucy, > [Lucy2] An overlay network may carry SFC traffic or non-SFC traffic. Without > an indication in overlay header, > how does egress NVE know what type of inner data a packet has, i.e. SFC, L2 > or L3? IMHO, if SFC is a different type of traffic than L2 or L3, then something is seriously wrong - the SFC header ought to be a shim header that can be added into either L2 or L3 traffic. I believe that egress determination of L2 vs. L3 is already under control (e.g., can't mix those types dynamically in same VN), and beyond that, I think it's SFC's responsibility to specify any needed indication of whether an SFC header is present. [Lucy] Agree that it is SFC WG responsibility to determine how to indicate the SFC presence. But nvo3 data plane will carry some SFC traffic. Lucy Thanks, --David From: Lucy yong [mailto:[email protected]] Sent: Tuesday, March 11, 2014 3:08 PM To: Black, David; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: RE: needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements David, Hope this make sense to you. See below. From: Black, David [mailto:[email protected]] Sent: Tuesday, March 11, 2014 1:48 PM To: Lucy yong; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: RE: needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements Lucy, [Lucy1] My point is about that the overlay header has a way to indicate the SFC header presence in the set of inner headers so ingress may insert SFC header and sets the indication in overlay header; egress NVE can forward the packets whether the SFC header presents or not on the packets. [DLB] My point is that I don't see the necessity for that in the overlay encap header (e.g., VXLAN). After decapsulation at the receiving NVE, the resulting (formerly inner) headers that contain the SFC header already have to have a way to indicate the presence of the SFC header - this is an SFC requirement that is independent of NVO3 decapsulation. Why are you proposing to duplicate this in the overlay encap header in an NVO3-specific fashion? What problem is it solving that SFC doesn't already have to solve? [Lucy2] An overlay network may carry SFC traffic or non-SFC traffic. Without an indication in overlay header, how does egress NVE know what type of inner data a packet has, i.e. SFC, L2 or L3? The payload type field is the part of overlay header. Current data plane requirements have the assumption that processed inner data at egress NVE are either Ethernet frame or IP packets. Am I right on that? Lucy [Lucy1] IMO: current date plane requirements only cover the case without the SFC header presence. If SFC may apply to NVO3, should we document related data plane requirement in this document? [DLB] IMO, only if something specific is needed for NVO3 to support SFC. See above, and Joel's comment about why this topic belongs in SFC. Thanks, --David From: Lucy yong [mailto:[email protected]] Sent: Tuesday, March 11, 2014 11:41 AM To: Black, David; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: RE: needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements Snip.. [lucy1] and more is possible with a full service function chaining approach, but I'd prefer to stay away from service function chaining in the nvo3 WG. [Lucy] I totally agree that we should stay away from SFC from NVO3 WG. But IMO: we properly should specify the key element required in the encapsulation in supporting these kinds of capability in NVO without specify the SFC header. [DLB] So, why would the SFC header need to go into the nvo3-specific encapsulation, as opposed to accompanying the inner (overlay) or outer (underlay) headers? [Lucy] No, SFC header should not go into NVO3 specific encapsulation. It is the indication how egress NVE should forward a received encapsulated packet to be conveyed by ingress NVE. [DLB2] I believe that presence of the SFC header in the set of inner headers that survive decapsulation is that indication. I strongly oppose making nvo3 a special case for SFC unless that's absolutely necessary. [Lucy1] My point is about that the overlay header has a way to indicate the SFC header presence in the set of inner headers so ingress may insert SFC header and sets the indication in overlay header; egress NVE can forward the packets whether the SFC header presents or not on the packets. Do you see the data plane requirement capture this now? IMO: current date plane requirements only cover the case without the SFC header presence. If SFC may apply to NVO3, should we document related data plane requirement in this document? Again, specifying these requirements does not mean we need to work on SFC in NVO3. Lucy Thanks, Lucy Regards, Lucy Thanks, --David From: nvo3 [mailto:[email protected]] On Behalf Of Lucy yong Sent: Monday, March 10, 2014 11:46 AM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements Hi Authors, In NVO3 architecture doc, it specifies that a Tenant System can be a network appliance system such as firewall. If an NVE (say ingress) receives packets from an attached TS and need to send them to a Network appliance that is attached to another NVE (say egress), it is very important for ingress NVE to inform egress NVE that the receiving packets need to reach the network appliance (TS) so egress NVE will perform the proper forwarding. Note that, in this case, the inner address on the packets is not the network appliances address that egress NVE can use in forwarding. People may quickly think that this is related to SFC. I do not deny it but view it more as applying service functions within a virtual network overlay or virtualized environment. Network Virtualization Overlay should support this case. It is important for data plane requirement document to specify the requirements for nvo3 overlay header and identify the key elements in the header that are necessary in a Network Virtualization Overlay solution. It is clear that, in this case, it is the ingress NVE selecting the egress NVE and informing the egress NVE if it (egress) needs to forward to TS based on the inner address on the packet or based on other information. Therefore, it is important for the overlay header to convey this information and it is important for the doc. capture this. Thanks, Lucy
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
