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

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 12 Mar 2014 15:08:18 +0000

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

---

From: "Black, David" <[email-masked]>
Date: Wed, 12 Mar 2014 12:04:56 -0400

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 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]
Cc: [email-masked]
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Wed, 12 Mar 2014 19:52:33 +0000

David,

Chip in here and share my 2 cent. Please see below.

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

Jim,

      - Is that change in outer transport encapsulation just addition/removal
            of VXLAN, or does VXLAN replace the original Ethernet header transport
encapsulation?
[Lucy] IMO, it is the first case. When you add VXLAN header on the original Ethernet header, you still have to fill some parameters on the VXLAN header. If SFC needs to be present, you also add SFC header on the original Ethernet header before adding VXLAN header.

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.
[Lucy] The Ethertype we talked here is the Ethertype field on VXLAN+, not the one in original Ethernet header. The goal is not to change the original Ethernet packet when adding SFC header on the packets. In fact, I prefer to use a flag in VXLAN header to indicate the presence of SFC header not the Ethertype on VXLAN+.

If so do VXLAN implementations anticipate this sort of L2 packet reformatting on encap/decap?
[Lucy] hope my explanation make this clear. No change on the original Ethernet packet, it is just adding.

Lucy

Thanks,
--David

To: Black, David; Xuxiaohu; [email-masked]<mailto:[email-masked]>

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

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,

> 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:

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 13 Mar 2014 04:02:56 +0000

David,

Inilne.

From: <Black>, David <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 12, 2014 9:04 AM
To: "Jim Guichard (jguichar)" <[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

Jim,

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.
SK> SFC does not prevent carrying the native ethernet frame and leaves the ether type intact for (original/native) L2 frames.

Surendra.

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: "Black, David" <[email-masked]>
Date: Sun, 16 Mar 2014 13:28:21 -0400

Surendra,

> intact for (original/native) L2 frames.

Thank you, now for a couple of follow-up questions.

There are at least 3 cases to which these questions apply:

a) The (original/native L2) frame received by the ingress NVE already contains an SFC header.
b) The ingress NVE adds an SFC header that is expected to be removed by the egress NVE.
c) The ingress NVE adds an SFC header that is expected to remain beyond the egress NVE.

(1) Does VXLAN *require* any modifications to support SFC, or are we just talking about optimizations to notice the presence of something like SFC earlier?

(2) Do the resulting VXLAN/SFC encapsulations differ among the above cases.  If so, why?

Thanks,
--David

From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Thursday, March 13, 2014 12:03 AM
To: Black, David; Jim Guichard (jguichar); [email-masked]
Cc: [email-masked]
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

David,

Inilne.

Jim,

Surendra.

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Mon, 17 Mar 2014 14:35:56 +0000

David,

Express my 2 cents.  See inline.

From: nvo3 [mailto:[email-masked]] On Behalf Of Black, David
Sent: Sunday, March 16, 2014 12:28 PM
To: Surendra Kumar (smkumar); Jim Guichard (jguichar); [email-masked]
Cc: [email-masked]
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

Surendra,

a) The (original/native L2) frame received by the ingress NVE already contains an SFC header.
[lucy] this is the case that TS is a network appliance. How SFC info is conveyed between TS and ingress NVE is orthogonal to the way SFC info conveyed between ingress and egress NVEs. The latter uses overlay encapsulation such as VXLAN. The former is down via VAP and via a local mechanism. NVE needs to perform SFC info translation between two.
b) The ingress NVE adds an SFC header that is expected to be removed by the egress NVE.
c) The ingress NVE adds an SFC header that is expected to remain beyond the egress NVE.
[Lucy] b) and c) are the case that TS is not a network appliance. Ingress NVE has a policy to some traffic may need to go a network appliance attached to an egress NVE.

(1) Does VXLAN *require* any modifications to support SFC, or are we just talking about optimizations to notice the presence of something like SFC earlier?
[Lucy] IMO: VXLAN only needs indication of presence.

[Lucy] No.

Lucy

Thanks,
--David

To: Black, David; Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>

David,

Inilne.

Jim,

Surendra.

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Tue, 18 Mar 2014 02:40:13 +0000

Having read through this thread a couple of times now, I feel it is getting way off track with multiple people talking past each other with assumptions about how SFC may work; However, I really feel that SFC should work completely independently of whatever transport is used (whether this is an overlay like VXLAN, simply VLANs, or IP).  I suggest that we abandon the use case of SFC for motivating the presence of metadata in an NVO3 encapsulation.

I have heard a few usages of metadata at the network overlay layer (not the SFC service forwarding layer), such as OAM, performance, and security.  I think these are sufficient use cases without bringing SFC into it.  Given these use cases, I think it is valid for the NVO3 data plane requirements to optionally support the ability to carry a metadata shim header between the encapsulation and the tenant payload.

 - Larry

From: <Black>, David Black <[email-masked]<mailto:[email-masked]>>

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 18 Mar 2014 02:59:38 +0000

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

[Xiaohu] Fully agree. BTW, assume there may be multiple types of metadata shim header between the encapsulation and the tenant payload in the future, it would be desirable to have a protocol type field in the encapsulation header to indicate the presence of a given type of metadata shim header.

Best regards,
Xiaohu

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 18 Mar 2014 06:14:47 +0000

David,

Inline.

From: <Black>, David <[email-masked]<mailto:[email-masked]>>
Date: Sunday, March 16, 2014 10:28 AM
To: Surendra Kumar <[email-masked]<mailto:[email-masked]>>, "Jim Guichard (jguichar)" <[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

Surendra,

a) The (original/native L2) frame received by the ingress NVE already contains an SFC header.
b) The ingress NVE adds an SFC header that is expected to be removed by the egress NVE.
c) The ingress NVE adds an SFC header that is expected to remain beyond the egress NVE.
SK1>  a) & c) are relevant to SFC and I can think of use cases. In fact, they are one and the same, just being visualized from different ends as I see it. Not so sure about the use cases for b) specifically for SFC; it may be relevant for non-SFC use cases requiring metadata. Although, a case could be made for SFC with b) as well - if NVE is co-located or part of a Service (Function) Node.

(1) Does VXLAN *require* any modifications to support SFC, or are we just talking about optimizations to notice the presence of something like SFC earlier?
SK1> A way to signal the next 'protocol' is needed.

(2) Do the resulting VXLAN/SFC encapsulations differ among the above cases.  If so, why?
SK1> Yes. If I look at it on the wire in between two NVEs a) and c) would be same but b) would be different.
a) and c) would have a [VXLAN | L2/L3/L3-L4 HDR | SFC HDR | original payload(with or without L2-hdr) ]
b) would have [VXLAN | SFC HDR | original payload (with or without L2-hdr)].

Surendra.
PS: I can imagine esoteric use cases with b) involving proprietary means of metadata exchange between NVE & TS – standards relevant, no.

Thanks,
--David

David,

Inilne.

Jim,

Surendra.

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: "Black, David" <[email-masked]>
Date: Tue, 18 Mar 2014 08:47:52 -0400

Surendra,

SK1>  a) & c) are relevant to SFC and I can think of use cases.
SK1>  A way to signal the next 'protocol' is needed.
SK1>  a) and c) would have a [VXLAN | L2/L3/L3-L4 HDR | SFC HDR | original payload(with or without L2-hdr) ]

Thank you - that’s what I was expecting, especially that the encap would be the same independent of whether the SFC header is applied at the NVE or upstream.

In these cases, SFC is encapsulated by another header, e.g. L2, so VXLAN needs to signal that header as the next protocol, and not SFC.  I.e., there is no need for VXLAN to signal the presence of the SFC header - for L2, VXLAN signals the presence of the L2 header, and that L2 header signals the presence of the SFC header.

I’m also not so sure about b), but included it for completeness.

Thanks,
--David

From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Tuesday, March 18, 2014 2:15 AM
To: Black, David; Jim Guichard (jguichar); [email-masked]
Cc: [email-masked]
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

David,

Inline.

Surendra,

Surendra.

Thanks,
--David

David,

Inilne.

Jim,

Surendra.

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Tue, 18 Mar 2014 15:03:53 +0000

Hi Larry,

Agree that we don’t have to use SFC as the use case to justify the support of metadata shim header between the encapsulation and the tenant frame. However, NVO3 arch already specified that Tenant Systems could be Overlay-Aware Network Service Appliances, we should not exclude the use of SFC header to convey path and/or SF metadata info. Current Arch. has not yet described forwarding the traffic through such tenant systems.

Thanks,
Lucy

From: nvo3 [mailto:[email-masked]] On Behalf Of Larry Kreeger (kreeger)
Sent: Monday, March 17, 2014 9:40 PM
To: Black, David; Jim Guichard (jguichar); [email-masked]
Cc: [email-masked]
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Wed, 19 Mar 2014 01:26:57 +0000

Hi Lucy,

Are you referring to section 5.1 "Overlay-Aware Network Service Appliances"?  If so, note that this section is referring to a network service appliance that supports multi-tenancy.  These are not Tenant Systems, but can provide network services on the behalf of tenants.  This section also states that these network service appliance may have an integrated NVE or may make use of a split-NVE (e.g. with the encap/decap being done by the access switch).

I don't believe anything in the NVO3 architecture prevents an SFC header from being conveyed to such a service appliance.  The SFC header should still be present even after decapsulation by an external NVE when delivering the packet to a service appliance.  For this reason, the SFC header should not be tied to the overlay transport header, but instead be inside the NVO3 overlay payload (but probably outside the tenant payload).  e.g. for an L2 service the packets might look like the following as they traverse from a TS to the Network service appliance along the path of:

TS->SFC Classifier->NVE->NVE->Service Appliance

TS->SFC Classifier:  Original L2 frame (dest=another TS)
SFC Classifier->NVE: L2 header (dest=SFC Service Appliance)|SFC Header|Original L2 frame
NVE->NVE: VXLAN header|L2 header|SFC Header|Original L2 frame
NVE->Service Appliance: L2 header|SFC Header|Original L2 frame

Note that the Service Chain is yet another overlay connecting the service graph.  This overlay is above any Network Virtualization overlay that may or may not be present.  SFC should work over Ethernet or a pure IP network without any dependency on a NVO3 network.  IMO, as long as NVO3 can provide an L2 or L3 service, the Service Function overlay should work and we should not try to build in any dependencies.

 - Larry

From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 18, 2014 8:03 AM
To: Larry Kreeger <[email-masked]<mailto:[email-masked]>>, David Black <[email-masked]<mailto:[email-masked]>>, "Jim Guichard (jguichar)" <[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

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Wed, 19 Mar 2014 15:30:25 +0000

Hi Larry,

Yes, I am referring to section 5.1 which is under Tenant System Types (section 5). I still think that that description means that Tenant System can be a Network Service Appliance.  Yes, a network service appliance may be built into NVE. These only mean that a network service appliance may be implemented in different ways for different use cases. For example, GW or distributed GW on NVE.

Regarding the solution, I do not agree what you proposed below. I don’t see that, when SFC applies to NVO3 network, it has to be another overlay on top of NVO3 (although it can be done that way). This is like the same argument that SP people keep screaming on: we can use today’s transport network to support SFC without using an overlay transport. We should have a very simple way for NV03 to transport both non-SFC traffic and SFC traffic. I agree that NVO3 should not build a dependency on SFC because it needs to carry non-SFC traffic at first. But the solution needs easily carry SFC traffic as well so we will not have to work on this future in NVO3 as that we are working on SFC over existing transport networks.

Thanks,
Lucy

From: Larry Kreeger (kreeger) [mailto:[email-masked]]
Sent: Tuesday, March 18, 2014 8:27 PM
To: Lucy yong; Black, David; Jim Guichard (jguichar); [email-masked]
Cc: [email-masked]
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Wed, 19 Mar 2014 18:44:05 +0000

Replies inline. - Larry

Date: Wednesday, March 19, 2014 8:30 AM

Hi Larry,

Yes, I am referring to section 5.1 which is under Tenant System Types (section 5).

LK> Yes, it is under the section Tenant System Types, but I think it is misplaced given that it describes it discussed a service appliance that has an embedded NVE (or split NVE).  It would be a terrible idea for tenant's to have NVEs and interact with the NVA.

I still think that that description means that Tenant System can be a Network Service Appliance.

LK> I do think that tenant's should have the ability to deploy network services on top of NVO3, I just think they MUST be unaware that they are running over NVO3.

 Yes, a network service appliance may be built into NVE. These only mean that a network service appliance may be implemented in different ways for different use cases. For example, GW or distributed GW on NVE.

LK> Anything directly integrated with an NVE (e.g. distributed GW within an NVE) should not be controlled by a tenant.

Regarding the solution, I do not agree what you proposed below. I don’t see that, when SFC applies to NVO3 network, it has to be another overlay on top of NVO3 (although it can be done that way).

LK> One of the goals of SFC (that I completely agree with) is that it must be transport agnostic.  To me this means that the Service Function Forwarding layer cannot be intertwined with the transport, whether it is NVO3, MPLS, PBR or whatever.  I don't see any other way to keep the layers independent without SFC encapsulating the original payload (along with the SFC header) in a header suitable for being carried over whatever transport service is available (either an L3 header for an L3 transport service, or an L2 header for an L2 transport service).

This is like the same argument that SP people keep screaming on: we can use today’s transport network to support SFC without using an overlay transport. We should have a very simple way for NV03 to transport both non-SFC traffic and SFC traffic.

LK> Yes, and the simple way is for SFC to be designed so it will work across any kind of transport.  NVO3 should have no idea whether it is carrying traffic with or without and SFC header.

I agree that NVO3 should not build a dependency on SFC because it needs to carry non-SFC traffic at first. But the solution needs easily carry SFC traffic as well so we will not have to work on this future in NVO3 as that we are working on SFC over existing transport networks.

LK> I would really like to hear the requirements coming from the SFC WG on how NVO3 needs to be modified to accommodate SFC.  Can you optimize a specific solution by collapsing layers?  Yes.  Is a good idea architecturally?  Probably not.  I prefer a clean architecture.

Thanks,
Lucy

To: Lucy yong; Black, David; Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Wed, 19 Mar 2014 20:41:45 +0000

Hi Larry,

[snip]
LK> One of the goals of SFC (that I completely agree with) is that it must be transport agnostic.  To me this means that the Service Function Forwarding layer cannot be intertwined with the transport, whether it is NVO3, MPLS, PBR or whatever.  I don't see any other way to keep the layers independent without SFC encapsulating the original payload (along with the SFC header) in a header suitable for being carried over whatever transport service is available (either an L3 header for an L3 transport service, or an L2 header for an L2 transport service).
[Lucy] I agree this goal. But this goal is not equivalent to that transport is not aware of SFC packet; it only means that SFC solution should not depend on the transport solution. How each non-overlay transport is aware of SFC packet can be different because there are existing technologies. For the overlay transport, it is good to have one way to be aware of it because NVO3 is new technology and we are working on both NVO3 and SFC now (in different WGs). If a Tenant implementing some SFC that is unaware by NVO3, which means that Tenant Systems only send L2 or L3 header to attached NVEs, which is the different case where, from NVE perspective, these tenant systems are not network service appliances.

If tenant requests DC provider to implement special NVO3 topologies to forward tenant traffic via a special path (not full mesh), DC provider has to configure NVEs properly at both VAP and Tunnel interfaces to achieve it, do you think this case as NVO3 agnostic or not?

Regards,
Lucy

Thanks,
Lucy

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 19 Mar 2014 22:15:34 +0000

SFC header cannot be communicated to the end-point from an NVE unless wrapped in another transport within VXLAN. Accommodating this (or not requiring such wrapping) requires tightly integrating SFC into NVE, which blends service and transport layers: requires NVE to add a new transport header as per SFC, between NVE and the end point.

There is an architectural difference in how the overlay is realized with VXLAN when compared to UDP/GRE/NVGRE as transports.

Surendra.

From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 19, 2014 1:41 PM
To: "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>, "Jim Guichard (jguichar)" <[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

Hi Larry,

[snip]

Regards,
Lucy

Thanks,
Lucy

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Wed, 19 Mar 2014 22:21:39 +0000

Please see inline below.
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Wednesday, March 19, 2014 5:16 PM
To: Lucy yong; Larry Kreeger (kreeger); Black, David; Jim Guichard (jguichar); [email-masked]
Cc: [email-masked]
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

SFC header cannot be communicated to the end-point from an NVE unless wrapped in another transport within VXLAN. Accommodating this (or not requiring such wrapping) requires tightly integrating SFC into NVE, which blends service and transport layers: requires NVE to add a new transport header as per SFC, between NVE and the end point.
[Lucy] I am not clear what is your point here?

There is an architectural difference in how the overlay is realized with VXLAN when compared to UDP/GRE/NVGRE as transports.
[Lucy] VXLAN is an UDP application!

Lucy
Surendra.

Hi Larry,

[snip]

Regards,
Lucy

Thanks,
Lucy

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: Rajeev Manur <[email-masked]>
Date: Wed, 19 Mar 2014 15:43:35 -0700

Hi Lucy,

NVO3 like any other transport, needs to carry next_proto_type=SFC. SFC
looks no different than any other protocol that is carried over NVO3
transport. I still dont see the need for adding any more awareness about
SFC into NVO3.

Thanks!
--Rajeev

On Wed, Mar 19, 2014 at 1:41 PM, Lucy yong <[email-masked]> wrote:

>  Hi Larry,
>
>
>
> [snip]
>
> LK> One of the goals of SFC (that I completely agree with) is that it must
> be transport agnostic.  To me this means that the Service Function
> Forwarding layer cannot be intertwined with the transport, whether it is
> NVO3, MPLS, PBR or whatever.  I don't see any other way to keep the layers
> independent without SFC encapsulating the original payload (along with the
> SFC header) in a header suitable for being carried over whatever transport
> service is available (either an L3 header for an L3 transport service, or
> an L2 header for an L2 transport service).
>
> *[Lucy] I agree this goal. But this goal is not equivalent to that
> transport is not aware of SFC packet; it only means that SFC solution
> should not depend on the transport solution. How each non-overlay transport
> is aware of SFC packet can be different because there are existing
> technologies. For the overlay transport, it is good to have one way to be
> aware of it because NVO3 is new technology and we are working on both NVO3
> and SFC now (in different WGs). If a Tenant implementing some SFC that is
> unaware by NVO3, which means that Tenant Systems only send L2 or L3 header
> to attached NVEs, which is the different case where, from NVE perspective,
> these tenant systems are not network service appliances. *
>
>
>
> *If tenant requests DC provider to implement special NVO3 topologies to
> forward tenant traffic via a special path (not full mesh), DC provider has
> to configure NVEs properly at both VAP and Tunnel interfaces to achieve it,
> do you think this case as NVO3 agnostic or not?*
>
>
>
> *Regards,*
>
> *Lucy*
>
>
>
> This is like the same argument that SP people keep screaming on: we can
> use today’s transport network to support SFC without using an overlay
> transport. We should have a very simple way for NV03 to transport both
> non-SFC traffic and SFC traffic.
>
>
>
> LK> Yes, and the simple way is for SFC to be designed so it will work
> across any kind of transport.  NVO3 should have no idea whether it is
> carrying traffic with or without and SFC header.
>
>
>
> I agree that NVO3 should not build a dependency on SFC because it needs to
> carry non-SFC traffic at first. But the solution needs easily carry SFC
> traffic as well so we will not have to work on this future in NVO3 as that
> we are working on SFC over existing transport networks.
>
>
>
> LK> I would really like to hear the requirements coming from the SFC WG on
> how NVO3 needs to be modified to accommodate SFC.  Can you optimize a
> specific solution by collapsing layers?  Yes.  Is a good idea
> architecturally?  Probably not.  I prefer a clean architecture.
>
>
>
> Thanks,
>
> Lucy
>
>
>
> *From:* Larry Kreeger (kreeger) [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Tuesday, March 18, 2014 8:27 PM
> *To:* Lucy yong; Black, David; Jim Guichard (jguichar);
> [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [nvo3] needed data plane encap requirement in
> draft-ietf-nvo3-dataplane-requirements
>
>
>
> Hi Lucy,
>
>
>
> Are you referring to section 5.1 "Overlay-Aware Network Service
> Appliances"?  If so, note that this section is referring to a network
> service appliance that supports multi-tenancy.  These are not Tenant
> Systems, but can provide network services on the behalf of tenants.  This
> section also states that these network service appliance may have an
> integrated NVE or may make use of a split-NVE (e.g. with the encap/decap
> being done by the access switch).
>
>
>
> I don't believe anything in the NVO3 architecture prevents an SFC header
> from being conveyed to such a service appliance.  The SFC header should
> still be present even after decapsulation by an external NVE when
> delivering the packet to a service appliance.  For this reason, the SFC
> header should not be tied to the overlay transport header, but instead be
> inside the NVO3 overlay payload (but probably outside the tenant payload).
>  e.g. for an L2 service the packets might look like the following as they
> traverse from a TS to the Network service appliance along the path of:
>
>
>
> Note that the Service Chain is yet another overlay connecting the service
> graph.  This overlay is above any Network Virtualization overlay that may
> or may not be present.  SFC should work over Ethernet or a pure IP network
> without any dependency on a NVO3 network.  IMO, as long as NVO3 can provide
> an L2 or L3 service, the Service Function overlay should work and we should
> not try to build in any dependencies.
>
>
>
>  - Larry
>
>
>
> *From: *Lucy yong <[email-masked]>
> *Date: *Tuesday, March 18, 2014 8:03 AM
> *To: *Larry Kreeger <[email-masked]>, David Black <[email-masked]>,
> "Jim Guichard (jguichar)" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *RE: [nvo3] needed data plane encap requirement in
> draft-ietf-nvo3-dataplane-requirements
>
>
>
> Hi Larry,
>
>
>
> Agree that we don’t have to use SFC as the use case to justify the support
> of metadata shim header between the encapsulation and the tenant frame.
> However, NVO3 arch already specified that Tenant Systems could be
> Overlay-Aware Network Service Appliances, we should not exclude the use of
> SFC header to convey path and/or SF metadata info. Current Arch. has not
> yet described forwarding the traffic through such tenant systems.
>
>
>
> Thanks,
>
> Lucy
>
>
>
> *From:* nvo3 [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Larry Kreeger (kreeger)
> *Sent:* Monday, March 17, 2014 9:40 PM
> *To:* Black, David; Jim Guichard (jguichar);
> [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [nvo3] needed data plane encap requirement in
> draft-ietf-nvo3-dataplane-requirements
>
>
>
> Having read through this thread a couple of times now, I feel it is
> getting way off track with multiple people talking past each other with
> assumptions about how SFC may work; However, I really feel that SFC should
> work completely independently of whatever transport is used (whether this
> is an overlay like VXLAN, simply VLANs, or IP).  I suggest that we abandon
> the use case of SFC for motivating the presence of metadata in an NVO3
> encapsulation.
>
>
>
> I have heard a few usages of metadata at the network overlay layer (not
> the SFC service forwarding layer), such as OAM, performance, and security.
>  I think these are sufficient use cases without bringing SFC into it.
>  Given these use cases, I think it is valid for the NVO3 data plane
> requirements to optionally support the ability to carry a metadata shim
> header between the encapsulation and the tenant payload.
>
>
>
>  - Larry
>
>
>
> *From: *<Black>, David Black <[email-masked]>
> *Date: *Wednesday, March 12, 2014 9:04 AM
> *To: *"Jim Guichard (jguichar)" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *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
> 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
> encapsulator/decapsulator (nvo3 NVE) converts between them.  With that
> “outer transport encapsulation” framing of SFC behavior, my question about
> SFC is:
>
>
>
> 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.
>
>
>
> *From:* Jim Guichard (jguichar) [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Wednesday, March 12, 2014 11:08 AM
> *To:* Black, David; Xuxiaohu;
> [email-masked]
> *Cc:* [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
> *From: *<Black>, David <[email-masked]>
> *Date: *Wednesday, March 12, 2014 at 9:59 AM
> *To: *Xuxiaohu <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
> *Cc: *"[email-masked]" <[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] <[email-masked]>]
> *Sent:* Wednesday, March 12, 2014 3:45 AM
> *To:* Black, David; Lucy yong;
> [email-masked]
> *Cc:* [email-masked]
> *Subject:* 答复: needed data plane encap requirement in
> draft-ietf-nvo3-dataplane-requirements
>
>
>
>
>
>
>
> *发件人**:* nvo3 [mailto:[email-masked] <[email-masked]>] *代表 *Black,
> David
> *发送时间:* 2014年3月12日 3:14
> *收件人:* Lucy yong; [email-masked]
> *抄送:* [email-masked]
> *主题:* Re: [nvo3] needed data plane encap requirement in
> draft-ietf-nvo3-dataplane-requirements
>
>
>
> Lucy,
>
>
>
> 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] <[email-masked]>]
> *Sent:* Tuesday, March 11, 2014 3:08 PM
> *To:* Black, David; [email-masked]
> *Cc:* [email-masked]
> *Subject:* RE: needed data plane encap requirement in
> draft-ietf-nvo3-dataplane-requirements
>
>
>
> David,
>
>
>
> *From:* Black, David [mailto:[email-masked] <[email-masked]>]
> *Sent:* Tuesday, March 11, 2014 1:48 PM
> *To:* Lucy yong; [email-masked]
> *Cc:* [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] <[email-masked]>]
> *Sent:* Tuesday, March 11, 2014 11:41 AM
> *To:* Black, David; [email-masked]
> *Cc:* [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] <[email-masked]>] *On
> Behalf Of *Lucy yong
> *Sent:* Monday, March 10, 2014 11:46 AM
> *To:* [email-masked]
> *Cc:* [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
>
>
>
>
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>
>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 19 Mar 2014 22:44:55 +0000

Inline.

From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 19, 2014 3:21 PM
To: Surendra Kumar <[email-masked]<mailto:[email-masked]>>, "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>, "Jim Guichard (jguichar)" <[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

Please see inline below.
To: Lucy yong; Larry Kreeger (kreeger); Black, David; Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>

SFC header cannot be communicated to the end-point from an NVE unless wrapped in another transport within VXLAN. Accommodating this (or not requiring such wrapping) requires tightly integrating SFC into NVE, which blends service and transport layers: requires NVE to add a new transport header as per SFC, between NVE and the end point.
[Lucy] I am not clear what is your point here?
SK> You are making VXLAN more than just a transport.

There is an architectural difference in how the overlay is realized with VXLAN when compared to UDP/GRE/NVGRE as transports.
[Lucy] VXLAN is an UDP application!
SK> SFC header can be signaled (directly) via UDP port# as well. In that sense it is a transport/overlay for SFC.
Eg.: [L2-L3-UDP|SFC HDR| Orig. Payload]

Lucy
Surendra.

Hi Larry,

[snip]

Regards,
Lucy

Thanks,
Lucy

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

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

发件人: nvo3 [mailto:[email-masked]] 代表 Rajeev Manur
发送时间: 2014年3月20日 6:44
收件人: Lucy yong
抄送: Jim Guichard (jguichar); Black, David; [email-masked]; Larry Kreeger (kreeger); [email-masked]
主题: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

Hi Lucy,

NVO3 like any other transport, needs to carry next_proto_type=SFC. SFC looks no different than any other protocol that is carried over NVO3 transport. I still dont see the need for adding any more awareness about SFC into NVO3.

[Xiaohu] If so, does it mean that the nvo3 transport should at least have a “next_proto_type” field?

Best regards,
Xiaohu

Thanks!
--Rajeev
On Wed, Mar 19, 2014 at 1:41 PM, Lucy yong <[email-masked]<mailto:[email-masked]>> wrote:
Hi Larry,

[snip]

Regards,
Lucy

Thanks,
Lucy

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Pankaj Garg <[email-masked]>
Date: Thu, 20 Mar 2014 03:48:35 +0000

I would change the wording a little bit to say: NVO3 like any other transport, need to carry SFC information. The information can be encoded as NextProtocol or embedded in fixed header itself or encoded as TLV in the frame etc. I can understand that the SFC metadata must be transport agnostic but I don’t see the need to mandate the exact mechanism (like NextProtocol) to carry the SFC metadata especially since there can be more than one type of metadata to be carried by the transport.

Thanks,
Pankaj

From: nvo3 [mailto:[email-masked]] On Behalf Of Rajeev Manur
Sent: Thursday, March 20, 2014 4:14 AM
To: Lucy yong
Cc: Jim Guichard (jguichar); Black, David; [email-masked]; Larry Kreeger (kreeger); [email-masked]
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

Hi Lucy,

Thanks!
--Rajeev

[snip]

Regards,
Lucy

Thanks,
Lucy

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: Rajeev Manur <[email-masked]>
Date: Thu, 20 Mar 2014 18:15:42 +0000

NextProto seems to do the job for currently proposed SFC encapsulation. If you mean non-SFC metadata then yes, there may be a few use-cases where people may want to carry such metadata E2E directly over NVO3. For such cases we could make a provision in the NVO3 hdr to carry optional EXT_HDR with metadata.
Alternatively we could explore possibility of making SFC the generic mechanism to carry any type of metadata.
Thanks!
--Rajeev

--------Original Message-------------
From: Pankaj Garg <[email-masked]<mailto:[email-masked]>>
Date: Wed, Mar 19, 2014 at 8:48 PM
Subject: RE: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements
To: Rajeev Manur <[email-masked]<mailto:[email-masked]>>, Lucy yong <[email-masked]<mailto:[email-masked]>>
Cc: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Thanks,
Pankaj

From: nvo3 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Rajeev Manur
Sent: Thursday, March 20, 2014 4:14 AM
To: Lucy yong
Cc: Jim Guichard (jguichar); Black, David; [email-masked]<mailto:[email-masked]>; Larry Kreeger (kreeger); [email-masked]<mailto:[email-masked]>

Hi Lucy,

Thanks!
--Rajeev

[snip]

Regards,
Lucy

Thanks,
Lucy

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: "Black, David" <[email-masked]>
Date: Thu, 20 Mar 2014 16:59:02 -0400

More to the point is that for VXLAN’s current L2 service, the existing VXLAN implicit indication of Ethernet as the next protocol suffices, as the SFC header should be wrapped in an Ethernet header inside the VXLAN encapsulation so that the encapsulated packed can be forwarded immediately upon VXLAN decapsulation.

Having VXLAN directly indicate SFC as next protocol causes the SFC header to be the outer header after VXLAN decapsulation, and the resulting packet cannot be forwarded until the NVE removes or moves the SFC header; that seems like a rather unfortunate restriction and coupling of functionality (NVO3 and SFC) that ought to be separable.

Thanks,
--David

From: Rajeev Manur [mailto:[email-masked]]
Sent: Thursday, March 20, 2014 2:16 PM
To: Pankaj Garg
Cc: Lucy yong; Jim Guichard (jguichar; Black, David; [email-masked]; Larry Kreeger (kreeger; [email-masked]
Subject: RE: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

--------Original Message-------------
From: Pankaj Garg <[email-masked]<mailto:[email-masked]>>
Date: Wed, Mar 19, 2014 at 8:48 PM
Subject: RE: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements
To: Rajeev Manur <[email-masked]<mailto:[email-masked]>>, Lucy yong <[email-masked]<mailto:[email-masked]>>
Cc: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Thanks,
Pankaj

Hi Lucy,

Thanks!
--Rajeev

[snip]

Regards,
Lucy

Thanks,
Lucy

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Thu, 20 Mar 2014 21:26:27 +0000

I agree with David, which is why I said that we should not use SFC as a use case to motivate the need for metadata that would essentially add value at the NVO3 layer.  If the metadata is being used for NVO3 OAM/performance optimizations, then it should directly follow the NVO3 encap, and using a protocol type field to do this is a well understood/implemented method.

 - Larry

From: <Black>, David Black <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 20, 2014 1:59 PM
To: Rajeev Manur <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

Thanks,
--David

From: Rajeev Manur [mailto:[email-masked]]
Sent: Thursday, March 20, 2014 2:16 PM
To: Pankaj Garg
Cc: Lucy yong; Jim Guichard (jguichar; Black, David; [email-masked]<mailto:[email-masked]>; Larry Kreeger (kreeger; [email-masked]<mailto:[email-masked]>
Subject: RE: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

--------Original Message-------------
From: Pankaj Garg <[email-masked]<mailto:[email-masked]>>
Date: Wed, Mar 19, 2014 at 8:48 PM
Subject: RE: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements
To: Rajeev Manur <[email-masked]<mailto:[email-masked]>>, Lucy yong <[email-masked]<mailto:[email-masked]>>
Cc: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Thanks,
Pankaj

Hi Lucy,

Thanks!
--Rajeev

[snip]

Regards,
Lucy

Thanks,
Lucy

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

发件人: 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,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Thu, 20 Mar 2014 21:30:39 +0000

Inline. - Larry

From: Rajeev Manur <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 20, 2014 11:15 AM
To: Pankaj Garg <[email-masked]<mailto:[email-masked]>>
Cc: Lucy yong <[email-masked]<mailto:[email-masked]>>, "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, David Black <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Larry Kreeger <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

NextProto seems to do the job for currently proposed SFC encapsulation. If you mean non-SFC metadata then yes, there may be a few use-cases where people may want to carry such metadata E2E directly over NVO3. For such cases we could make a provision in the NVO3 hdr to carry optional EXT_HDR with metadata.
Alternatively we could explore possibility of making SFC the generic mechanism to carry any type of metadata.
LK> This makes sense to me.  It would be nice to have a common header that could be general enough to serve multiple purposes to cut down on a proliferation of single purpose headers.

Thanks!
--Rajeev

--------Original Message-------------
From: Pankaj Garg <[email-masked]<mailto:[email-masked]>>
Date: Wed, Mar 19, 2014 at 8:48 PM
Subject: RE: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements
To: Rajeev Manur <[email-masked]<mailto:[email-masked]>>, Lucy yong <[email-masked]<mailto:[email-masked]>>
Cc: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Thanks,
Pankaj

Hi Lucy,

Thanks!
--Rajeev

[snip]

Regards,
Lucy

Thanks,
Lucy

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: John E Drake <[email-masked]>
Date: Thu, 20 Mar 2014 21:39:05 +0000

David,

I agree.  Since service chaining is handled in a different WG and since NVO3 is not chartered to do protocol development, why are we even discussing this?

Yours Irrespectively,

John

From: nvo3 [mailto:[email-masked]] On Behalf Of Black, David
Sent: Thursday, March 20, 2014 1:59 PM
To: Rajeev Manur
Cc: [email-masked]; [email-masked]
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

Thanks,
--David

--------Original Message-------------
From: Pankaj Garg <[email-masked]<mailto:[email-masked]>>
Date: Wed, Mar 19, 2014 at 8:48 PM
Subject: RE: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements
To: Rajeev Manur <[email-masked]<mailto:[email-masked]>>, Lucy yong <[email-masked]<mailto:[email-masked]>>
Cc: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Thanks,
Pankaj

Hi Lucy,

Thanks!
--Rajeev

[snip]

Regards,
Lucy

Thanks,
Lucy

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 21 Mar 2014 01:00:33 +0000

发件人: nvo3 [mailto:[email-masked]] 代表 Larry Kreeger (kreeger)
发送时间: 2014年3月21日 5:26
收件人: Black, David; Rajeev Manur
抄送: [email-masked]; [email-masked]
主题: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

[Xiaohu] If so, isn’t it better to mention the necessity for a protocol type field in the NVo3 encap?

Best regards,
Xiaohu

 - Larry

Thanks,
--David

--------Original Message-------------
From: Pankaj Garg <[email-masked]<mailto:[email-masked]>>
Date: Wed, Mar 19, 2014 at 8:48 PM
Subject: RE: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements
To: Rajeev Manur <[email-masked]<mailto:[email-masked]>>, Lucy yong <[email-masked]<mailto:[email-masked]>>
Cc: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Thanks,
Pankaj

Hi Lucy,

Thanks!
--Rajeev

[snip]

Regards,
Lucy

Thanks,
Lucy

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 21 Mar 2014 01:19:35 +0000

From: Xuxiaohu <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 20, 2014 6:00 PM
To: Larry Kreeger <[email-masked]<mailto:[email-masked]>>, David Black <[email-masked]<mailto:[email-masked]>>, Rajeev Manur <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

发件人: nvo3 [mailto:[email-masked]] 代表 Larry Kreeger (kreeger)
发送时间: 2014年3月21日 5:26
收件人: Black, David; Rajeev Manur
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

LK> Yes, it makes sense to me.  I've never object to it (only to the discussions around its relation to SFC).

Best regards,
Xiaohu

 - Larry

Thanks,
--David

--------Original Message-------------
From: Pankaj Garg <[email-masked]<mailto:[email-masked]>>
Date: Wed, Mar 19, 2014 at 8:48 PM
Subject: RE: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements
To: Rajeev Manur <[email-masked]<mailto:[email-masked]>>, Lucy yong <[email-masked]<mailto:[email-masked]>>
Cc: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Thanks,
Pankaj

Hi Lucy,

Thanks!
--Rajeev

[snip]

Regards,
Lucy

Thanks,
Lucy

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: Pankaj Garg <[email-masked]>
Date: Fri, 21 Mar 2014 01:34:02 +0000

Inline.

From: Rajeev Manur [mailto:[email-masked]]
Sent: Thursday, March 20, 2014 11:46 PM
To: Pankaj Garg
Cc: Lucy yong; Jim Guichard (jguichar; David; [email-masked]; Larry Kreeger (kreeger; [email-masked]
Subject: RE: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

NextProto seems to do the job for currently proposed SFC encapsulation. If you mean non-SFC metadata then yes, there may be a few use-cases where people may want to carry such metadata E2E directly over NVO3. For such cases we could make a provision in the NVO3 hdr to carry optional EXT_HDR with metadata.
[PG] NextProto can do the job but it breaks hardware offloads and would always break hardware offloads as more headers are chained together. So while it does the job, it is only _one_ way to do it and may not be the _best_ way.
Alternatively we could explore possibility of making SFC the generic mechanism to carry any type of metadata.
[PG] Or define a way in NVO3 to carry generic meta-data and SFC meta-data just becomes one of the use case of that?
Thanks!
--Rajeev

--------Original Message-------------
From: Pankaj Garg <[email-masked]<mailto:[email-masked]>>
Date: Wed, Mar 19, 2014 at 8:48 PM
Subject: RE: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements
To: Rajeev Manur <[email-masked]<mailto:[email-masked]>>, Lucy yong <[email-masked]<mailto:[email-masked]>>
Cc: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Thanks,
Pankaj

Hi Lucy,

Thanks!
--Rajeev

[snip]

Regards,
Lucy

Thanks,
Lucy

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: Pankaj Garg <[email-masked]>
Date: Fri, 21 Mar 2014 01:37:31 +0000

Inline.

From: nvo3 [mailto:[email-masked]] On Behalf Of Larry Kreeger (kreeger)
Sent: Friday, March 21, 2014 2:56 AM
To: Black, David; Rajeev Manur
Cc: [email-masked]; [email-masked]
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

I agree with David, which is why I said that we should not use SFC as a use case to motivate the need for metadata that would essentially add value at the NVO3 layer.  If the metadata is being used for NVO3 OAM/performance optimizations, then it should directly follow the NVO3 encap, and using a protocol type field to do this is a well understood/implemented method.
[PG] I agree that using header chaining is one way to carry metadata. However, across a range of protocols, all possible methods to carry meta-data are used, for example, putting the meta-data in fixed headers, to carry it via header chaining, to carrying it via TLV options etc. So in some sense, all of these methods are well understood and implemented. It is a matter of picking the one that fits the bill the best.

 - Larry

Thanks,
--David

--------Original Message-------------
From: Pankaj Garg <[email-masked]<mailto:[email-masked]>>
Date: Wed, Mar 19, 2014 at 8:48 PM
Subject: RE: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements
To: Rajeev Manur <[email-masked]<mailto:[email-masked]>>, Lucy yong <[email-masked]<mailto:[email-masked]>>
Cc: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Thanks,
Pankaj

Hi Lucy,

Thanks!
--Rajeev

[snip]

Regards,
Lucy

Thanks,
Lucy

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Fri, 21 Mar 2014 01:51:27 +0000

I think success of any protocol or encap depends on the simplicity. Please do not take away that., way this is swinging I am feared that we will include 1KB of meta header to transmit 64Byte packet and in turn increase latency of my data plane.

From: nvo3 [mailto:[email-masked]] On Behalf Of Pankaj Garg
Sent: Thursday, March 20, 2014 6:38 PM
To: Larry Kreeger (kreeger); Black, David; Rajeev Manur
Cc: [email-masked]; [email-masked]
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

Inline.

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

 - Larry

Thanks,
--David

--------Original Message-------------
From: Pankaj Garg <[email-masked]<mailto:[email-masked]>>
Date: Wed, Mar 19, 2014 at 8:48 PM
Subject: RE: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements
To: Rajeev Manur <[email-masked]<mailto:[email-masked]>>, Lucy yong <[email-masked]<mailto:[email-masked]>>
Cc: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Thanks,
Pankaj

Hi Lucy,

Thanks!
--Rajeev

[snip]

Regards,
Lucy

Thanks,
Lucy

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: Pankaj Garg <[email-masked]>
Date: Fri, 21 Mar 2014 02:20:51 +0000

I agree with you in spirit that carrying 1K of metadata to transport 64B payload won’t make sense. The question is, how do we need the right size of metadata ahead of time such as 16-bytes or 4-bytes or 64-bytes? Hence the argument for flexibility in the metadata size and definition. I am sure that when metadata proposals are floated around, there would be enough scrutiny to make sure that the impact on data plane is minimal. There are use cases of metadata that can actually improve data plane performance, instead of reducing it, so the proposals to carry metadata should not prohibit such flexibility.

From: Tissa Senevirathne (tsenevir) [mailto:[email-masked]]
Sent: Friday, March 21, 2014 7:21 AM
To: Pankaj Garg; Larry Kreeger (kreeger); Black, David; Rajeev Manur
Cc: [email-masked]; [email-masked]
Subject: RE: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

Inline.

 - Larry

Thanks,
--David

--------Original Message-------------
From: Pankaj Garg <[email-masked]<mailto:[email-masked]>>
Date: Wed, Mar 19, 2014 at 8:48 PM
Subject: RE: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements
To: Rajeev Manur <[email-masked]<mailto:[email-masked]>>, Lucy yong <[email-masked]<mailto:[email-masked]>>
Cc: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Thanks,
Pankaj

Hi Lucy,

Thanks!
--Rajeev

[snip]

Regards,
Lucy

Thanks,
Lucy

Hi Lucy,

 - Larry

Hi Larry,

Thanks,
Lucy

 - Larry

Jim,

Thanks,
--David

Thanks,
--David

Lucy,

Thanks,
--David

David,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: Tom Herbert <[email-masked]>
Date: Fri, 21 Mar 2014 08:20:45 -0700

On Thu, Mar 20, 2014 at 7:20 PM, Pankaj Garg <[email-masked]> wrote:
> I agree with you in spirit that carrying 1K of metadata to transport 64B
> payload won’t make sense. The question is, how do we need the right size of
> metadata ahead of time such as 16-bytes or 4-bytes or 64-bytes? Hence the
> argument for flexibility in the metadata size and definition. I am sure that
> when metadata proposals are floated around, there would be enough scrutiny
> to make sure that the impact on data plane is minimal. There are use cases
> of metadata that can actually improve data plane performance, instead of
> reducing it, so the proposals to carry metadata should not prohibit such
> flexibility.
>
It's not just the size of all the metadata that is an issue, it's also
the number of individual items, the overhead for each item, the
processing algorithm, and the necessary validation that must be done--
all these will add up to determine how fast packet processing is.

> I think success of any protocol or encap depends on the simplicity. Please
> do not take away that., way this is swinging I am feared that we will
> include 1KB of meta header to transmit 64Byte packet and in turn increase
> latency of my data plane.
>
>
>
> I agree with David, which is why I said that we should not use SFC as a use
> case to motivate the need for metadata that would essentially add value at
> the NVO3 layer.  If the metadata is being used for NVO3 OAM/performance
> optimizations, then it should directly follow the NVO3 encap, and using a
> protocol type field to do this is a well understood/implemented method.
>
> [PG] I agree that using header chaining is one way to carry metadata.
> However, across a range of protocols, all possible methods to carry
> meta-data are used, for example, putting the meta-data in fixed headers, to
> carry it via header chaining, to carrying it via TLV options etc. So in some
> sense, all of these methods are well understood and implemented. It is a
> matter of picking the one that fits the bill the best.
>
>
>
>  - Larry
>
>
>
> From: <Black>, David Black <[email-masked]>
> To: Rajeev Manur <[email-masked]>
> Cc: "[email-masked]"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>
> More to the point is that for VXLAN’s current L2 service, the existing VXLAN
> implicit indication of Ethernet as the next protocol suffices, as the SFC
> header should be wrapped in an Ethernet header inside the VXLAN
> encapsulation so that the encapsulated packed can be forwarded immediately
> upon VXLAN decapsulation.
>
>
>
> Having VXLAN directly indicate SFC as next protocol causes the SFC header to
> be the outer header after VXLAN decapsulation, and the resulting packet
> cannot be forwarded until the NVE removes or moves the SFC header; that
> seems like a rather unfortunate restriction and coupling of functionality
> (NVO3 and SFC) that ought to be separable.
>
>
>
> Thanks,
> --David
>
>
>
> Cc: Lucy yong; Jim Guichard (jguichar; Black, David;
> [email-masked]; Larry Kreeger
> (kreeger; [email-masked]
> NextProto seems to do the job for currently proposed SFC encapsulation. If
> you mean non-SFC metadata then yes, there may be a few use-cases where
> people may want to carry such metadata E2E directly over NVO3. For such
> cases we could make a provision in the NVO3 hdr to carry optional EXT_HDR
> with metadata.
>
> From: Pankaj Garg <[email-masked]>
> To: Rajeev Manur <[email-masked]>, Lucy yong <[email-masked]>
> Cc: "Jim Guichard (jguichar)" <[email-masked]>, "Black, David"
> <[email-masked]>,
> "[email-masked]"
> <[email-masked]>, "Larry Kreeger
> (kreeger)" <[email-masked]>, "[email-masked]" <[email-masked]>
>
> I would change the wording a little bit to say: NVO3 like any other
> transport, need to carry SFC information. The information can be encoded as
> NextProtocol or embedded in fixed header itself or encoded as TLV in the
> frame etc. I can understand that the SFC metadata must be transport agnostic
> but I don’t see the need to mandate the exact mechanism (like NextProtocol)
> to carry the SFC metadata especially since there can be more than one type
> of metadata to be carried by the transport.
>
>
>
> Thanks,
>
> Pankaj
>
>
>
> Cc: Jim Guichard (jguichar); Black, David;
> [email-masked]; Larry Kreeger
> (kreeger); [email-masked]
>
>
> NVO3 like any other transport, needs to carry next_proto_type=SFC. SFC looks
> no different than any other protocol that is carried over NVO3 transport. I
> still dont see the need for adding any more awareness about SFC into NVO3.
>
>
>
> Thanks!
>
> --Rajeev
>
> service is available (either an L3 header for an L3 transport service, or an
> L2 header for an L2 transport service).
>
> [Lucy] I agree this goal. But this goal is not equivalent to that transport
> is not aware of SFC packet; it only means that SFC solution should not
> depend on the transport solution. How each non-overlay transport is aware of
> SFC packet can be different because there are existing technologies. For the
> overlay transport, it is good to have one way to be aware of it because NVO3
> is new technology and we are working on both NVO3 and SFC now (in different
> WGs). If a Tenant implementing some SFC that is unaware by NVO3, which means
> that Tenant Systems only send L2 or L3 header to attached NVEs, which is the
> different case where, from NVE perspective, these tenant systems are not
> network service appliances.
>
>
>
> If tenant requests DC provider to implement special NVO3 topologies to
> do you think this case as NVO3 agnostic or not?
>
>
>
> Regards,
>
> Lucy
>
>
>
> This is like the same argument that SP people keep screaming on: we can use
> today’s transport network to support SFC without using an overlay transport.
> We should have a very simple way for NV03 to transport both non-SFC traffic
> and SFC traffic.
>
>
>
> LK> Yes, and the simple way is for SFC to be designed so it will work across
> any kind of transport.  NVO3 should have no idea whether it is carrying
> traffic with or without and SFC header.
>
>
>
> To: Lucy yong; Black, David; Jim Guichard (jguichar);
> Are you referring to section 5.1 "Overlay-Aware Network Service Appliances"?
> If so, note that this section is referring to a network service appliance
> that supports multi-tenancy.  These are not Tenant Systems, but can provide
> network services on the behalf of tenants.  This section also states that
> these network service appliance may have an integrated NVE or may make use
> of a split-NVE (e.g. with the encap/decap being done by the access switch).
>
>
>
> still be present even after decapsulation by an external NVE when delivering
> the packet to a service appliance.  For this reason, the SFC header should
> not be tied to the overlay transport header, but instead be inside the NVO3
> overlay payload (but probably outside the tenant payload).  e.g. for an L2
> service the packets might look like the following as they traverse from a TS
> to the Network service appliance along the path of:
>
>
>
> graph.  This overlay is above any Network Virtualization overlay that may or
> may not be present.  SFC should work over Ethernet or a pure IP network
> From: Lucy yong <[email-masked]>
> To: Larry Kreeger <[email-masked]>, David Black <[email-masked]>,
> "Jim Guichard (jguichar)" <[email-masked]>,
> "[email-masked]"
> <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> SFC header to convey path and/or SF metadata info. Current Arch. has not yet
> described forwarding the traffic through such tenant systems.
>
>
>
> Thanks,
>
> Lucy
>
>
>
> To: Black, David; Jim Guichard (jguichar);
> Having read through this thread a couple of times now, I feel it is getting
> way off track with multiple people talking past each other with assumptions
> about how SFC may work; However, I really feel that SFC should work
> completely independently of whatever transport is used (whether this is an
> overlay like VXLAN, simply VLANs, or IP).  I suggest that we abandon the use
> case of SFC for motivating the presence of metadata in an NVO3
> encapsulation.
>
>
>
> I have heard a few usages of metadata at the network overlay layer (not the
> SFC service forwarding layer), such as OAM, performance, and security.  I
> think these are sufficient use cases without bringing SFC into it.  Given
> these use cases, I think it is valid for the NVO3 data plane requirements to
> optionally support the ability to carry a metadata shim header between the
> encapsulation and the tenant payload.
>
>
>
>  - Larry
>
>
>
> From: <Black>, David Black <[email-masked]>
> To: "Jim Guichard (jguichar)" <[email-masked]>,
> "[email-masked]"
> <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Ethernet changes the original Ethernet packet in order to move the Ethertype
> for SFC between the unencapsulated Ethernet header and the VXLAN header.
>
>
>
> To: Black, David; Xuxiaohu;
> 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]>
> To: Xuxiaohu <[email-masked]>,
> "[email-masked]"
> <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>> indicated via protocol type or
>
> To: Black, David; Lucy yong;
> 收件人: Lucy yong; [email-masked]
> 抄送:[email-masked]
> 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
>
>
>
> To: Black, David; [email-masked]
> Cc: [email-masked]
> To: Lucy yong; [email-masked]
> Cc: [email-masked]
> [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.
>
>
>
> 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?
>
>
>
> To: Black, David; [email-masked]
> Cc: [email-masked]
> 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.
>
> [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
>
>
>
>
>
> To: [email-masked]
> Cc: [email-masked]
> 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.
>
>
>
> 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

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Mar 2014 11:00:50 -0700

On 3/17/14 7:40 PM, Larry Kreeger (kreeger) wrote:
> getting way off track with multiple people talking past each other 
> with assumptions about how SFC may work; However, I really feel that 
> SFC should work completely independently of whatever transport is used 
> (whether this is an overlay like VXLAN, simply VLANs, or IP). I 
> suggest that we abandon the use case of SFC for motivating the 
> presence of metadata in an NVO3 encapsulation.
>
> I have heard a few usages of metadata at the network overlay layer 
> (not the SFC service forwarding layer), such as OAM, performance, and 
> security. I think these are sufficient use cases without bringing SFC 
> into it.

Larry,
I agree.
> requirements to optionally support the ability to carry a metadata 
> shim header between the encapsulation and the tenant payload.

That is merely one possible "encoding" of such meta-data, thus I don't 
think the dp requirement should be that specific.
In IETF protocols we have a mixture of
1. header length (see IPv4, TCP)
2. option length (TRILL is a recent example)
3. next header (e.g., IPv6 using IP protocol types, others using 
Ethernet types)
3a. next header chain where each header is fixed length (IEEE 802.1 
seems to follow this pattern)
3b. next header chain with variable length headers (e.g., IPv6)

Part of the reason folks seem to have different opinions of those have 
to do with history and different views on what might be implemented in 
hardware. I don't understand whether there are any technical differences 
in implementing those different schemes in hardware, beyond the 
questions of "how many headers do I need to handle" and "what is the 
total depth in the packet which might have headers". Clearly 3b is 
problematic on those.
And Ethernet switches seem to implement 3a in hardware (e.g., Q-in-Q and 
many different variants of stacking headers whether standard or not).

All that to say that I don't think we have any firm technical basis to 
prefer any of the above encodings (except to avoid 3b perhaps).
Whether options/extensions get implemented in hardware might have more 
to do with the benefits to the hardware implementation than the details 
of the encoding.

Regards,
Erik

> To: "Jim Guichard (jguichar)" <[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]>>
> > 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
> Ethernet packet and VXLAN for the encapsulated Ethernet packet; a 
> VXLAN encapsulator/decapsulator (nvo3 NVE) converts between them. With 
> that “outer transport encapsulation” framing of SFC behavior, my 
> question about SFC is:
>
> 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.
>
> *From:*Jim Guichard (jguichar) [mailto:[email-masked]]
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> 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 
> *From: *<Black>, David <[email-masked] <mailto:[email-masked]>>
> *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]>>
> *> 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]]
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *发件人**:*nvo3 [mailto:[email-masked]] *代表 *Black, David
> *发送时间:* 2014年3月12日 3:14
> *收件人:* Lucy yong; 
> <mailto:[email-masked]>
> *抄送:* [email-masked] <mailto:[email-masked]>
> 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.
>
>
>   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]]
> *To:* Black, David; 
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *From:*Black, David [mailto:[email-masked]]
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> */[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]]
> *To:* Black, David; 
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> 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./*
>
> */[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. /*
>
> 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
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> 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.
>
> 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
>
>
>