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