And inline ... From: nvo3 [mailto:[email protected]] On Behalf Of Lucy yong Sent: Monday, March 10, 2014 4:21 PM To: Black, David; [email protected] Cc: [email protected] Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements
Hi David, Please see in-line below. From: Black, David [mailto:[email protected]] Sent: Monday, March 10, 2014 2:22 PM To: Lucy yong; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Black, David Subject: RE: needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements Hi Lucy, I'm not at all sure. For a layer 2 appliance (e.g., firewall), it suffices for the destination MAC to be reachable only through the firewall; the NVA can set up the appropriate address mapping so that the firewall NVE is chosen. [Lucy] Yes, that is good for ingress NVE. How about egress NVE, when it receives a packet, it needs to forward the packet to the firewall (not based on inner MAC address). Do you indicate that this is also NVA responsibility to set up this forwarding ahead? If an NVE has some appliances and some VMs attached, when it receives a packet from remote NVEs, how does it know that the forwarding should be based on inner address or other mechanism? [DLB] If the destination MAC is only visible to the NVE via the firewall-facing port, that's where the packet goes. For layer 3 appliance (e.g., firewall), if the firewall is attached to the default gateway on the exit path from the VN, nothing special is needed. At least the second case applies the service function across VN boundaries. [Lucy] There are many ways to deploy network appliances. DC operator can deploy it, tenant can also deploy it. Is that right? It is true that network appliances are often deployed between VNs and GW sitting between and service functions are local to the GW. [DLB] And IMHO, we should not try to support all of those ways - that's SFC's problem space. In both cases, there are topology restrictions, [Lucy] yes. Do we allow NVEs forwarding some packets to the destination TS directly and other packets to the network appliance TS first based on the policy? If we support this, this is not only the (VN) topology restrictions. It is per flow topology restriction. [DLB] Again, that's SFC's problem space. 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? 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
