发件人: nvo3 [mailto:[email protected]] 代表 Black, David 发送时间: 2014年3月12日 3:14 收件人: Lucy yong; [email protected] 抄送: [email protected] 主题: Re: [nvo3] 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. [Xiaohu] As said in draft-quinn-sfc-nsh, “…The presence of NSH is indicated via protocol type or other indicator in the outer encapsulation.” Hence, to indicate whether a SFC header (a.k.a. NSH) is present in a VXLAN packet, it would be better to add a protocol type field in the VXLAN header. The following two drafts (i.e., draft-yong-l3vpn-nvgre-vxlan-encap-03 and draft-quinn-vxlan-gpe-02) have proposed very similar approaches for adding a protocol type field in the VXLAN header. IMHO, it’s the SFC’s responsibility to define a transport-independent SFC header (e.g., NSH in VXLAN, NSH in MPLS, NSH in UDP, etc.), just as what has been done by draft-quinn-sfc-nsh. However, the transport itself should has the potential capability of indicating the presence of the SFC header (e.g., having a protocol type field), which should be considered as early as possible. In this way, the IEEE EtherType, 0x894F, which has been allocated for NSH could be directly used by VXLAN to indicate the presence of the NSH. Best regards, Xiaohu 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
