From: Lucy yong [mailto:[email protected]] Sent: Monday, March 10, 2014 7:29 PM To: Black, David; [email protected] Cc: [email protected] Subject: RE: needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements
Snip.. 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. [Lucy] Not sure how NVO3 arch captures this. Does this require firewall-facing port expressing all MACs to the NVE? [DLB2] Only those MACs whose traffic needs to be sent through the firewall. This is standard L2 forwarding/bridging behavior. 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. [Lucy] There is a high desire to use overlay tunnel to carry the packet that need to be treated at service function. For the packet encapsulation, do you think that we need another encapsulation protocol in SFC to achieve that or enhance VXLAN and NVGRE to achieve both? [DLB2] None of the above - for the discussion in this thread, I fail to see the need for anything beyond an inner SFC header that is used in the usual fashion after decap to figure out where to forward the packet. That SFC header can be applied and removed by NVEs; no encapsulation changes are required because it's an inner header. 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. [Lucy] NVE arch. doc specifies that TS can be network appliance. Does that mean that these network appliances could be only used in special use cases? [DLB2] No: "TS can be network appliance" does not imply that "All network appliances are TSs." See previous comment on inner SFC header - what use cases would that not support? 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. 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
