On Thu, Mar 20, 2014 at 7:20 PM, Pankaj Garg <garg.pan...@microsoft.com> 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.
> > > From: Tissa Senevirathne (tsenevir) [mailto:tsene...@cisco.com] > Sent: Friday, March 21, 2014 7:21 AM > To: Pankaj Garg; Larry Kreeger (kreeger); Black, David; Rajeev Manur > Cc: draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org; nvo3@ietf.org > > > Subject: RE: [nvo3] needed data plane encap requirement in > draft-ietf-nvo3-dataplane-requirements > > > > 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:nvo3-boun...@ietf.org] On Behalf Of Pankaj Garg > Sent: Thursday, March 20, 2014 6:38 PM > To: Larry Kreeger (kreeger); Black, David; Rajeev Manur > Cc: draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org; nvo3@ietf.org > Subject: Re: [nvo3] needed data plane encap requirement in > draft-ietf-nvo3-dataplane-requirements > > > > Inline. > > > > From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Larry Kreeger > (kreeger) > Sent: Friday, March 21, 2014 2:56 AM > To: Black, David; Rajeev Manur > Cc: draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org; nvo3@ietf.org > 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 > > > > From: <Black>, David Black <david.bl...@emc.com> > Date: Thursday, March 20, 2014 1:59 PM > To: Rajeev Manur <rma...@broadcom.com> > Cc: "draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org" > <draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org>, "nvo3@ietf.org" > <nvo3@ietf.org> > Subject: Re: [nvo3] needed data plane encap requirement in > draft-ietf-nvo3-dataplane-requirements > > > > 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:rma...@broadcom.com] > Sent: Thursday, March 20, 2014 2:16 PM > To: Pankaj Garg > Cc: Lucy yong; Jim Guichard (jguichar; Black, David; > draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org; Larry Kreeger > (kreeger; nvo3@ietf.org > 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. > > Thanks! > --Rajeev > > > > --------Original Message------------- > > From: Pankaj Garg <garg.pan...@microsoft.com> > 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 <rvma...@gmail.com>, Lucy yong <lucy.y...@huawei.com> > Cc: "Jim Guichard (jguichar)" <jguic...@cisco.com>, "Black, David" > <david.bl...@emc.com>, > "draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org" > <draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org>, "Larry Kreeger > (kreeger)" <kree...@cisco.com>, "nvo3@ietf.org" <nvo3@ietf.org> > > 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:nvo3-boun...@ietf.org] On Behalf Of Rajeev Manur > Sent: Thursday, March 20, 2014 4:14 AM > To: Lucy yong > Cc: Jim Guichard (jguichar); Black, David; > draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org; Larry Kreeger > (kreeger); nvo3@ietf.org > > > Subject: 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. > > > > Thanks! > > --Rajeev > > On Wed, Mar 19, 2014 at 1:41 PM, Lucy yong <lucy.y...@huawei.com> 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:kree...@cisco.com] > Sent: Tuesday, March 18, 2014 8:27 PM > To: Lucy yong; Black, David; Jim Guichard (jguichar); > draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org > Cc: nvo3@ietf.org > 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: > > > > 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 <lucy.y...@huawei.com> > Date: Tuesday, March 18, 2014 8:03 AM > To: Larry Kreeger <kree...@cisco.com>, David Black <david.bl...@emc.com>, > "Jim Guichard (jguichar)" <jguic...@cisco.com>, > "draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org" > <draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org> > Cc: "nvo3@ietf.org" <nvo3@ietf.org> > 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:nvo3-boun...@ietf.org] On Behalf Of Larry Kreeger > (kreeger) > Sent: Monday, March 17, 2014 9:40 PM > To: Black, David; Jim Guichard (jguichar); > draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org > Cc: nvo3@ietf.org > 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 <david.bl...@emc.com> > Date: Wednesday, March 12, 2014 9:04 AM > To: "Jim Guichard (jguichar)" <jguic...@cisco.com>, > "draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org" > <draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org> > Cc: "nvo3@ietf.org" <nvo3@ietf.org> > 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:jguic...@cisco.com] > Sent: Wednesday, March 12, 2014 11:08 AM > To: Black, David; Xuxiaohu; > draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org > Cc: nvo3@ietf.org > 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 <david.bl...@emc.com> > Date: Wednesday, March 12, 2014 at 9:59 AM > To: Xuxiaohu <xuxia...@huawei.com>, > "draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org" > <draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org> > Cc: "nvo3@ietf.org" <nvo3@ietf.org> > 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:xuxia...@huawei.com] > Sent: Wednesday, March 12, 2014 3:45 AM > To: Black, David; Lucy yong; > draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org > Cc: nvo3@ietf.org > Subject: 答复: needed data plane encap requirement in > draft-ietf-nvo3-dataplane-requirements > > > > > > > > 发件人: nvo3 [mailto:nvo3-boun...@ietf.org] 代表Black, David > 发送时间: 2014年3月12日 3:14 > 收件人: Lucy yong; draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org > 抄送:nvo3@ietf.org > 主题: 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:lucy.y...@huawei.com] > Sent: Tuesday, March 11, 2014 3:08 PM > To: Black, David; draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org > Cc: nvo3@ietf.org > 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:david.bl...@emc.com] > Sent: Tuesday, March 11, 2014 1:48 PM > To: Lucy yong; draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org > Cc: nvo3@ietf.org > 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:lucy.y...@huawei.com] > Sent: Tuesday, March 11, 2014 11:41 AM > To: Black, David; draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org > Cc: nvo3@ietf.org > 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:nvo3-boun...@ietf.org] On Behalf Of Lucy yong > Sent: Monday, March 10, 2014 11:46 AM > To: draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org > Cc: nvo3@ietf.org > 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 > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
