Subject: [sfc] 答复: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

From: Xuxiaohu <[email-masked]>
Date: Thu, 13 Mar 2014 02:02:00 +0000

发件人: nvo3 [mailto:[email-masked]] 代表 Black, David
发送时间: 2014年3月13日 0:05
收件人: Jim Guichard (jguichar); [email-masked]
抄送: [email-masked]
主题: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

Jim,

> The SFC encapsulation may be thought of a ‘shim’ between the original packet payload and the outer transport encapsulation;
> in this case said outer transport encapsulation is vxlan. Using the “protocol type” field as suggested in draft-quinn-vxlan-gpe to carry the ether type for SFC provides the
> indication of the presence of the SFC encapsulation. What am I missing?

I understand the “shim” approach, but there are two “outer transport encapsulations” involved, the Ethernet header for the unencapsulated Ethernet packet and VXLAN for the encapsulated Ethernet packet; a VXLAN

[Xiaohu]IMHO, the inner Ethernet header is a part of the original packet rather than a part of the “outer transport encapsulations”. Furthermore, it’s the NVE, rather than the originator of the Ethernet packet which inserts the NSH, if my understanding about the SFC is correct. I think this may be the place where you are confused.

Best regards,
Xiaohu

encapsulator/decapsulator (nvo3 NVE) converts between them.  With that “outer transport encapsulation” framing of SFC behavior, my question about SFC is:

      - Is that change in outer transport encapsulation just addition/removal
            of VXLAN, or does VXLAN replace the original Ethernet header transport
encapsulation?

Absent SFC, current VXLAN encap/decap is just addition/removal of VXLAN, which preserves the Ethernet packet across VXLAN encapsulation and decapsulation.  Otherwise, the conversion for SFC between VXLAN and native Ethernet changes the original Ethernet packet in order to move the Ethertype for SFC between the unencapsulated Ethernet header and the VXLAN header.

Does that match your understanding?

If so do VXLAN implementations anticipate this sort of L2 packet reformatting on encap/decap?

Thanks,
--David

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Wednesday, March 12, 2014 11:08 AM
To: Black, David; Xuxiaohu; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

I have only just started to try and decode this thread but immediate confusion arises from your comment David. The SFC encapsulation may be thought of a ‘shim’ between the original packet payload and the outer transport encapsulation; in this case said outer transport encapsulation is vxlan. Using the “protocol type” field as suggested in draft-quinn-vxlan-gpe to carry the ether type for SFC provides the indication of the presence of the SFC encapsulation. What am I missing?

From: <Black>, David <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 12, 2014 at 9:59 AM
To: Xuxiaohu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

> [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.

Needless to say, I disagree - IMHO, that Ethertype should be in the inner Ethernet header that is encapsulated by VXLAN.  The result would be SFC functionality that does not depend on presence vs. absence of VXLAN.

Thanks,
--David

From: Xuxiaohu [mailto:[email-masked]]
Sent: Wednesday, March 12, 2014 3:45 AM
To: Black, David; Lucy yong; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: 答复: needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

发件人: nvo3 [mailto:[email-masked]] 代表 Black, David
发送时间: 2014年3月12日 3:14
收件人: Lucy yong; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: 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-masked]]
Sent: Tuesday, March 11, 2014 3:08 PM
To: Black, David; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
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-masked]]
Sent: Tuesday, March 11, 2014 1:48 PM
To: Lucy yong; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
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-masked]]
Sent: Tuesday, March 11, 2014 11:41 AM
To: Black, David; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
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-masked]] On Behalf Of Lucy yong
Sent: Monday, March 10, 2014 11:46 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
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