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

Mon, 24 Mar 2014 11:01:47 -0700 

On 3/17/14 7:40 PM, Larry Kreeger (kreeger) wrote:
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.


Larry,
I agree.

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.



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



- Larry


From: <Black>, David Black <[email protected] 
<mailto:[email protected]>>

Date: Wednesday, March 12, 2014 9:04 AM

To: "Jim Guichard (jguichar)" <[email protected] 
<mailto:[email protected]>>, 
"[email protected] 
<mailto:[email protected]>" 
<[email protected] 
<mailto:[email protected]>>
Cc: "[email protected] <mailto:[email protected]>" <[email protected] 
<mailto:[email protected]>>
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

> 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 protected]]
*Sent:* Wednesday, March 12, 2014 11:08 AM

*To:* Black, David; Xuxiaohu; 
[email protected] 
<mailto:[email protected]>

*Cc:* [email protected] <mailto:[email protected]>

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



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


*From: *<Black>, David <[email protected] <mailto:[email protected]>>
*Date: *Wednesday, March 12, 2014 at 9:59 AM

*To: *Xuxiaohu <[email protected] <mailto:[email protected]>>, 
"[email protected] 
<mailto:[email protected]>" 
<[email protected] 
<mailto:[email protected]>>
*Cc: *"[email protected] <mailto:[email protected]>" <[email protected] 
<mailto:[email protected]>>
*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 protected]]
*Sent:* Wednesday, March 12, 2014 3:45 AM

*To:* Black, David; Lucy yong; 
[email protected] 
<mailto:[email protected]>

*Cc:* [email protected] <mailto:[email protected]>

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


*发件人**:*nvo3 [mailto:[email protected]] *代表 *Black, David
*发送时间:* 2014年3月12日 3:14

*收件人:* Lucy yong; 
[email protected] 
<mailto:[email protected]>

*抄送:* [email protected] <mailto:[email protected]>

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


Lucy,


> [Lucy2] An overlay network may carry SFC traffic or non-SFC traffic. Without an indication in 
overlay header,


> how does egress NVE know what type of inner data a packet has, i.e. SFC, L2 
or L3?


IMHO, if SFC is a different type of traffic than L2 or L3, then 
something is seriously wrong - the SFC header ought to be a shim 
header that can be added into either L2 or L3 traffic. I believe that 
egress determination of L2 vs. L3 is already under control (e.g., 
can’t mix those types dynamically in same VN), and beyond that, I 
think it’s SFC’s responsibility to specify any needed indication of 
whether an SFC header is present.



  [Xiaohu] As said in draft-quinn-sfc-nsh, “…The presence of NSH is
  indicated via protocol type or other indicator in the outer
  encapsulation.” Hence, to indicate whether a SFC header (a.k.a. NSH)
  is present in a VXLAN packet, it would be better to add a protocol
  type field in the VXLAN header. The following two drafts (i.e.,
  draft-yong-l3vpn-nvgre-vxlan-encap-03 and draft-quinn-vxlan-gpe-02)
  have proposed very similar approaches for adding a protocol type
  field in the VXLAN header. IMHO, it’s the SFC’s responsibility to
  define a transport-independent SFC header (e.g., NSH in VXLAN, NSH
  in MPLS, NSH in UDP, etc.), just as what has been done by
  draft-quinn-sfc-nsh. However, the transport itself should has the
  potential capability of indicating the presence of the SFC header
  (e.g., having a protocol type field), which should be considered as
  early as possible. In this way, the IEEE EtherType, 0x894F, which
  has been allocated for NSH could be directly used by VXLAN to
  indicate the presence of the NSH.


  Best regards,


  Xiaohu


Thanks,
--David

*From:*Lucy yong [mailto:[email protected]]
*Sent:* Tuesday, March 11, 2014 3:08 PM

*To:* Black, David; 
[email protected] 
<mailto:[email protected]>

*Cc:* [email protected] <mailto:[email protected]>

*Subject:* RE: needed data plane encap requirement in 
draft-ietf-nvo3-dataplane-requirements


David,

Hope this make sense to you. See below.

*From:*Black, David [mailto:[email protected]]
*Sent:* Tuesday, March 11, 2014 1:48 PM

*To:* Lucy yong; [email protected] 
<mailto:[email protected]>

*Cc:* [email protected] <mailto:[email protected]>

*Subject:* RE: needed data plane encap requirement in 
draft-ietf-nvo3-dataplane-requirements


Lucy,


*/[Lucy1] My point is about that the overlay header has a way to 
indicate the SFC header presence in the set of inner headers so 
ingress may insert SFC header and sets the indication in overlay 
header; egress NVE can forward the packets whether the SFC header 
presents or not on the packets./*


*//*


[DLB] My point is that I don’t see the necessity for that in the 
overlay encap header (e.g., VXLAN). After decapsulation at the 
receiving NVE, the resulting (formerly inner) headers that contain the 
SFC header already have to have a way to indicate the presence of the 
SFC header - this is an SFC requirement that is independent of NVO3 
decapsulation. Why are you proposing to duplicate this in the overlay 
encap header in an NVO3-specific fashion? What problem is it solving 
that SFC doesn’t already have to solve?



*/[Lucy2] An overlay network may carry SFC traffic or non-SFC traffic. 
Without an indication in overlay header, how does egress NVE know what 
type of inner data a packet has, i.e. SFC, L2 or L3? The payload type 
field is the part of overlay header. Current data plane requirements 
have the assumption that processed inner data at egress NVE are either 
Ethernet frame or IP packets. Am I right on that?/*


*//*

*/Lucy/*


*/[Lucy1] IMO: current date plane requirements only cover the case 
without the SFC header presence. If SFC may apply to NVO3, should we 
document related data plane requirement in this document?/*


*//*


[DLB] IMO, only if something specific is needed for NVO3 to support 
SFC. See above, and Joel’s comment about why this topic belongs in SFC.


Thanks,
--David

*From:*Lucy yong [mailto:[email protected]]
*Sent:* Tuesday, March 11, 2014 11:41 AM

*To:* Black, David; 
[email protected] 
<mailto:[email protected]>

*Cc:* [email protected] <mailto:[email protected]>

*Subject:* RE: needed data plane encap requirement in 
draft-ietf-nvo3-dataplane-requirements


Snip.. [lucy1]


and more is possible with a full service function chaining approach, 
but I’d prefer to stay away from service function chaining in the nvo3 WG.



*/[Lucy] I totally agree that we should stay away from SFC from NVO3 
WG. But IMO: we properly should specify the key element required in 
the encapsulation in supporting these kinds of capability in NVO 
without specify the SFC header./*



[DLB] So, why would the SFC header need to go into the nvo3-specific 
encapsulation, as opposed to accompanying the inner (overlay) or outer 
(underlay) headers?



*/[Lucy] No, SFC header should not go into NVO3 specific 
encapsulation. It is the indication how egress NVE should forward a 
received encapsulated packet to be conveyed by ingress NVE. /*



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



*/[Lucy1] My point is about that the overlay header has a way to 
indicate the SFC header presence in the set of inner headers so 
ingress may insert SFC header and sets the indication in overlay 
header; egress NVE can forward the packets whether the SFC header 
presents or not on the packets. Do you see the data plane requirement 
capture this now? IMO: current date plane requirements only cover the 
case without the SFC header presence. If SFC may apply to NVO3, should 
we document related data plane requirement in this document? Again, 
specifying these requirements does not mean we need to work on SFC in 
NVO3./*


*//*

*/Lucy/*

*//*

*/Thanks,/*

*/Lucy /*

*//*

*/Regards,/*

*/Lucy/*

Thanks,
--David

*From:*nvo3 [mailto:[email protected]] *On Behalf Of *Lucy yong
*Sent:* Monday, March 10, 2014 11:46 AM

*To:* [email protected] 
<mailto:[email protected]>

*Cc:* [email protected] <mailto:[email protected]>

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


Hi Authors,


In NVO3 architecture doc, it specifies that a Tenant System can be a 
network appliance system such as firewall. If an NVE (say ingress) 
receives packets from an attached TS and need to send them to a 
Network appliance that is attached to another NVE (say egress), it is 
very important for ingress NVE to inform egress NVE that the receiving 
packets need to reach the network appliance (TS) so egress NVE will 
perform the proper forwarding. Note that, in this case, the inner 
address on the packets is not the network appliances address that 
egress NVE can use in forwarding.



People may quickly think that this is related to SFC. I do not deny it 
but view it more as applying service functions within a virtual 
network overlay or virtualized environment. Network Virtualization 
Overlay should support this case.



It is important for data plane requirement document to specify the 
requirements for nvo3 overlay header and identify the key elements in 
the header that are necessary in a Network Virtualization Overlay 
solution. It is clear that, in this case, it is the ingress NVE 
selecting the egress NVE and informing the egress NVE if it (egress) 
needs to forward to TS based on the inner address on the packet or 
based on other information. Therefore, it is important for the overlay 
header to convey this information and it is important for the doc. 
capture this.


Thanks,

Lucy



_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3


_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3























					Reply via email to