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:
Hi David,
Please see in-line below.
*From:*Black, David [mailto:[email protected]]
*Sent:* Monday, March 10, 2014 2:22 PM
*To:* Lucy yong; [email protected]
*Cc:* [email protected]; 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 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
