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

From: Lucy yong <[email-masked]>
Date: Mon, 10 Mar 2014 15:46:27 +0000

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: Mon, 10 Mar 2014 15:22:24 -0400

Hi Lucy,

I'm not at all sure.  For a layer 2 appliance (e.g., firewall), it suffices for the destination MAC to be reachable only through the firewall; the NVA can set up the appropriate address mapping so that the firewall NVE is chosen.  For layer 3 appliance (e.g., firewall), if the firewall is attached to the default gateway on the exit path from the VN, nothing special is needed.  At least the second case applies the service function across VN boundaries.

In both cases, there are topology restrictions, 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.

Thanks,
--David

From: nvo3 [mailto:[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,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Mon, 10 Mar 2014 20:20:51 +0000

Hi David,

Please see in-line below.

From: Black, David [mailto:[email-masked]]
Sent: Monday, March 10, 2014 2:22 PM
To: Lucy yong; [email-masked]
Cc: [email-masked]; Black, David
Subject: RE: needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

Hi Lucy,

I'm not at all sure.  For a layer 2 appliance (e.g., firewall), it suffices for the destination MAC to be reachable only through the firewall; the NVA can set up the appropriate address mapping so that the firewall NVE is chosen.
[Lucy] Yes, that is good for ingress NVE. How about egress NVE, when it receives a packet, it needs to forward the packet to the firewall (not based on inner MAC address). Do you indicate that this is also NVA responsibility to set up this forwarding ahead? If an NVE has some appliances and some VMs attached, when it receives a packet from remote NVEs, how does it know that the forwarding should be based on inner address or other mechanism?

For layer 3 appliance (e.g., firewall), if the firewall is attached to the default gateway on the exit path from the VN, nothing special is needed.  At least the second case applies the service function across VN boundaries.
[Lucy] There are many ways to deploy network appliances. DC operator can deploy it, tenant can also deploy it. Is that right?  It is true that network appliances are often deployed between VNs and GW sitting between and service functions are local to the GW.

In both cases, there are topology restrictions,
[Lucy] yes. Do we allow NVEs forwarding some packets to the destination TS directly and other packets to the network appliance TS first based on the policy? If we support this, this is not only the (VN) topology restrictions. It is per flow topology restriction.
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.

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,

Thanks,
Lucy

---

From: "Black, David" <[email-masked]>
Date: Mon, 10 Mar 2014 18:34:06 -0400

And inline ...

From: nvo3 [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Monday, March 10, 2014 4:21 PM
To: Black, David; [email-masked]
Cc: [email-masked]
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

Hi David,

From: Black, David [mailto:[email-masked]]
Sent: Monday, March 10, 2014 2:22 PM
To: Lucy yong; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Black, David
Subject: RE: needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

Hi Lucy,

I'm not at all sure.  For a layer 2 appliance (e.g., firewall), it suffices for the destination MAC to be reachable only through the firewall; the NVA can set up the appropriate address mapping so that the firewall NVE is chosen.
[Lucy] Yes, that is good for ingress NVE. How about egress NVE, when it receives a packet, it needs to forward the packet to the firewall (not based on inner MAC address). Do you indicate that this is also NVA responsibility to set up this forwarding ahead? If an NVE has some appliances and some VMs attached, when it receives a packet from remote NVEs, how does it know that the forwarding should be based on inner address or other mechanism?
[DLB] If the destination MAC is only visible to the NVE via the firewall-facing port, that's where the packet goes.

For layer 3 appliance (e.g., firewall), if the firewall is attached to the default gateway on the exit path from the VN, nothing special is needed.  At least the second case applies the service function across VN boundaries.
[Lucy] There are many ways to deploy network appliances. DC operator can deploy it, tenant can also deploy it. Is that right?  It is true that network appliances are often deployed between VNs and GW sitting between and service functions are local to the GW.
[DLB] And IMHO, we should not try to support all of those ways - that's SFC's problem space.

In both cases, there are topology restrictions,
[Lucy] yes. Do we allow NVEs forwarding some packets to the destination TS directly and other packets to the network appliance TS first based on the policy? If we support this, this is not only the (VN) topology restrictions. It is per flow topology restriction.
[DLB] Again, that's SFC's problem space.

and more is possible with a full service function chaining approach, but I'd prefer to stay away from service function chaining in the nvo3 WG.
[Lucy] I totally agree that we should stay away from SFC from NVO3 WG. But IMO: we properly should specify the key element required in the encapsulation in supporting these kinds of capability in NVO without specify the SFC header.
[DLB] So, why would the SFC header need to go into the nvo3-specific encapsulation, as opposed to accompanying the inner (overlay) or outer (underlay) headers?

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Mon, 10 Mar 2014 23:29:10 +0000

Snip..
I'm not at all sure.  For a layer 2 appliance (e.g., firewall), it suffices for the destination MAC to be reachable only through the firewall; the NVA can set up the appropriate address mapping so that the firewall NVE is chosen.
[Lucy] Yes, that is good for ingress NVE. How about egress NVE, when it receives a packet, it needs to forward the packet to the firewall (not based on inner MAC address). Do you indicate that this is also NVA responsibility to set up this forwarding ahead? If an NVE has some appliances and some VMs attached, when it receives a packet from remote NVEs, how does it know that the forwarding should be based on inner address or other mechanism?
[DLB] If the destination MAC is only visible to the NVE via the firewall-facing port, that's where the packet goes.
[Lucy] Not sure how NVO3 arch captures this. Does this require firewall-facing port expressing all MACs to the NVE?

For layer 3 appliance (e.g., firewall), if the firewall is attached to the default gateway on the exit path from the VN, nothing special is needed.  At least the second case applies the service function across VN boundaries.
[Lucy] There are many ways to deploy network appliances. DC operator can deploy it, tenant can also deploy it. Is that right?  It is true that network appliances are often deployed between VNs and GW sitting between and service functions are local to the GW.
[DLB] And IMHO, we should not try to support all of those ways - that's SFC's problem space.
[Lucy] There is a high desire to use overlay tunnel to carry the packet that need to be treated at service function. For the packet encapsulation, do you think that we need another encapsulation protocol in SFC to achieve that or enhance VXLAN and NVGRE to achieve both?

In both cases, there are topology restrictions,
[Lucy] yes. Do we allow NVEs forwarding some packets to the destination TS directly and other packets to the network appliance TS first based on the policy? If we support this, this is not only the (VN) topology restrictions. It is per flow topology restriction.
[DLB] Again, that's SFC's problem space.
[Lucy] NVE arch. doc specifies that TS can be network appliance. Does that mean that these network appliances could be only used in special use cases?

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.

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: "Black, David" <[email-masked]>
Date: Mon, 10 Mar 2014 21:26:18 -0400

From: Lucy yong [mailto:[email-masked]]
Sent: Monday, March 10, 2014 7:29 PM
To: Black, David; [email-masked]
Cc: [email-masked]
Subject: RE: needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

Snip..
[DLB2] Only those MACs whose traffic needs to be sent through the firewall.  This is standard L2 forwarding/bridging behavior.

[DLB2] None of the above - for the discussion in this thread, I fail to see the need for anything beyond an inner SFC header that is used in the usual fashion after decap to figure out where to forward the packet.  That SFC header can be applied and removed by NVEs; no encapsulation changes are required because it's an inner header.

[DLB2] No: "TS  can be network appliance" does not imply that "All network appliances are TSs."   See previous comment on inner SFC header - what use cases would that not support?

[DLB2] I believe that presence of the SFC header in the set of inner headers that survive decapsulation is that indication.  I strongly oppose making nvo3 a special case for SFC unless that's absolutely necessary.

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 11 Mar 2014 00:03:39 -0400

I know yoiu referred to SFC earlier.
But I am really m,issing why this is NVO3s problem rather than SFCs. 
The topic seems to be precisely matched to the SFC charter and problem 
statement.

 From where I sit, I expect that the SFC solutions will be applicable to 
both domains.  That is one of the reasons that SFC specifies the 
chaining behavior, but not the transport.

Yours,
Joel

On 3/10/14, 4:20 PM, Lucy yong wrote:
> *From:*Black, David [mailto:[email-masked]]
> *Sent:* Monday, March 10, 2014 2:22 PM
> *To:* Lucy yong; [email-masked]
> *Cc:* [email-masked]; Black, David
> *Subject:* RE: needed data plane encap requirement in
> draft-ietf-nvo3-dataplane-requirements
>
> Hi Lucy,
>
> I’m not at all sure.  For a layer 2 appliance (e.g., firewall), it
> suffices for the destination MAC to be reachable only through the
> firewall; the NVA can set up the appropriate address mapping so that the
> firewall NVE is chosen.
>
> */[Lucy] Yes, that is good for ingress NVE. How about egress NVE, when
> it receives a packet, it needs to forward the packet to the firewall
> (not based on inner MAC address). Do you indicate that this is also NVA
> responsibility to set up this forwarding ahead? If an NVE has some
> appliances and some VMs attached, when it receives a packet from remote
> NVEs, how does it know that the forwarding should be based on inner
> address or other mechanism? /*
>
> *//*
>
> For layer 3 appliance (e.g., firewall), if the firewall is attached to
> the default gateway on the exit path from the VN, nothing special is
> needed.  At least the second case applies the service function across VN
> boundaries.
>
> */[Lucy] There are many ways to deploy network appliances. DC operator
> can deploy it, tenant can also deploy it. Is that right?  It is true
> that network appliances are often deployed between VNs and GW sitting
> between and service functions are local to the GW. /*
>
> */[Lucy] yes. Do we allow NVEs forwarding some packets to the
> destination TS directly and other packets to the network appliance TS
> first based on the policy? If we support this, this is not only the (VN)
> topology restrictions. It is per flow topology restriction./*
>
> 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./*
>
> *//*
>
> */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
>
>
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Lucy yong <[email-masked]>
Date: Tue, 11 Mar 2014 15:40:31 +0000

Snip.. [lucy1]
[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

Hi Authors,

Thanks,
Lucy

---

From: "Black, David" <[email-masked]>
Date: Tue, 11 Mar 2014 14:47:55 -0400

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?

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

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Tue, 11 Mar 2014 19:07:50 +0000

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

Lucy,

[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

Thanks,
--David

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

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: "Black, David" <[email-masked]>
Date: Tue, 11 Mar 2014 15:14:22 -0400

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.

Thanks,
--David

From: Lucy yong [mailto:[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,

Lucy,

Lucy

Thanks,
--David

Snip.. [lucy1]

Lucy

Thanks,
Lucy

Regards,
Lucy

Thanks,
--David

Hi Authors,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Tue, 11 Mar 2014 19:20:39 +0000

David,

From: Black, David [mailto:[email-masked]]
Sent: Tuesday, March 11, 2014 2:14 PM
To: Lucy yong; [email-masked]
Cc: [email-masked]
Subject: RE: 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.
[Lucy] Agree that it is SFC WG responsibility to determine how to indicate the SFC presence. But nvo3 data plane will carry some SFC traffic.

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, 11 Mar 2014 15:31:42 -0400

I agree that nvo3 data planes will carry some SFC traffic ...
... and some UDP traffic, and some RTP traffic and some HTTP traffic, etc.

Thanks,
--David

From: nvo3 [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Tuesday, March 11, 2014 3:21 PM
To: Black, David; [email-masked]
Cc: [email-masked]
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

David,

Lucy,

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: Wed, 12 Mar 2014 04:40:57 +0000

I think that SFC meta-data is similar to VNI, whereas VNI is used to carry the context for doing network virtualization, SFC carries context for doing service chaining. Similarly, there may be other context fields to carry OAM meta-data or performance meta-data. In all these cases, NVO encapsulation actually carries the inner frame i.e. the one originated by a VM (in case of a hypervisor based system). The inner frame can be L2, L3, UDP, TCP, HTTP etc. However, VNI, VN context, OAM meta-data, SFC meta-data, Performance meta-data provide the contextual data for doing things like network virtualization, service chaining, OAM etc.

I am not sure if we should mix SFC meta-data with the inner frame which is what is the actual payload in the encapsulation.

From: nvo3 [mailto:[email-masked]] On Behalf Of Black, David
Sent: Wednesday, March 12, 2014 1:02 AM
To: Lucy yong; [email-masked]
Cc: [email-masked]
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

Thanks,
--David

David,

Lucy,

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: Wed, 12 Mar 2014 07:44:54 +0000

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

> 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

David,

Lucy,

[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

[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

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

Hi Authors,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Wed, 12 Mar 2014 14:17:27 +0000

Please see inline below.

From: Pankaj Garg [mailto:[email-masked]]
Sent: Tuesday, March 11, 2014 11:41 PM
To: Black, David; Lucy yong; [email-masked]
Cc: [email-masked]
Subject: RE: needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

I think that SFC meta-data is similar to VNI, whereas VNI is used to carry the context for doing network virtualization, SFC carries context for doing service chaining. Similarly, there may be other context fields to carry OAM meta-data or performance meta-data. In all these cases, NVO encapsulation actually carries the inner frame i.e. the one originated by a VM (in case of a hypervisor based system). The inner frame can be L2, L3, UDP, TCP, HTTP etc. However, VNI, VN context, OAM meta-data, SFC meta-data, Performance meta-data provide the contextual data for doing things like network virtualization, service chaining, OAM etc.
[Lucy] I agree. We can use a flag on overlay header to indicate the presence of SFC header on the encapsulated packet. Thus NVO technology supports L2 or L3 based forwarding, and SFC based forwarding. SFC header can be seen as a metadata in the overlay header and it is optional. This is what I try to express in early mails.

I am not sure if we should mix SFC meta-data with the inner frame which is what is the actual payload in the encapsulation.
[Lucy] IMO, we should separate two cases. If not, it means that NVO carries non-SFC and SFC traffic seamlessly, i.e. egress NVE just forwards a packet to TS based on inner address on the packet, which means that NVO technology does not support SFC or irrelevant to SFC.

Lucy

Thanks,
--David

David,

Lucy,

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: Wed, 12 Mar 2014 10:59:17 -0400

> [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]
Cc: [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,

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 15:20:14 +0000

Hi David,

You missed interpreting what we say. I was saying that SFC can apply to NVO. When applying to it, the overlay header needs a way to indicate the presence of SFC header. I did not say or mean that we have to use VXLAN to implement SFC functionality. SFC traffic can be carried by different networks, not only IP.  Even in IP network, it is not necessarily using VXLAN encapsulation for SFC. But if a VN overlay carries SFC header between NVEs, the overlay header needs to have an indication of SFC header present.

Thanks,
Lucy

From: nvo3 [mailto:[email-masked]] On Behalf Of Black, David
Sent: Wednesday, March 12, 2014 9:59 AM
To: Xuxiaohu; [email-masked]
Cc: [email-masked]
Subject: Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

[Lucy]

Thanks,
--David

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

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 01:43:34 +0000

Hi David,

Did you mean using the Ethertype field in the inner Ethernet header to indicate the presence of the NSH? If so, Needless to say, I disagree as well:)

Best regards,
Xiaohu

发件人: Black, David [mailto:[email-masked]]
发送时间: 2014年3月12日 22:59
收件人: Xuxiaohu; [email-masked]
抄送: [email-masked]
主题: RE: 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