David,
*From:*Black, David [mailto:[email protected]]
*Sent:* Thursday, December 27, 2012 11:42 AM
*To:* Lucy yong
*Cc:* [email protected]
*Subject:* RE: Multi-subnet VNs - should be a new service type?
Lucy,
The core of our disagreement is here:
*/[Lucy] We have either L2 overlay network or L3 overlay network. But
sometime a tenant network needs both L2 and L3 functions to accomplish
the needs, where neither L2 overlay nor L3 overlay fit it well. /*
I strongly disagree with the statement that an L2 overlay is a poor fit
for carrying tenant IP traffic that needs to cross L2 (virtual) network
boundaries. That sort of IP traffic that needs to cross L2 network
boundaries works fine on VLANs and it works fine on L2 overlays.
*/[Lucy] I did not say it is poor fit, and just express if you integrate
L2 function and L3 function on the same NVE, it is better to give a new
NVE service type. Obviously, we have disagreement here. /*
I would agree that there are ways to implement routing support for
traffic that exits an L2 virtual network that are poor fits to some
situations (e.g., lengthy discussions here and elsewhere on trombone and
triangle routing), but I do not see the need for a new hybrid L2-3
service definition to enable better implementations of routing
integration with L2 networking.
And my answer to this question:
*/[Lucy1] For this service capability, do you see it as a L2 service or
L3 service? IMO: neither of them fits./*
is that it’s still an L2 service, in part because it makes no sense to
me to restrict an L2 service (at least for nvo3) by forbidding the
attachment of IP routing functionality to L2 (virtual) networks.
*/[Lucy] No, such restriction is not good. L2 switches have been used to
bridge IP traffic between router and hosts for long time. We are on the
same page here./*
*//*
*/Thanks,/*
*/Lucy/*
Thanks,
--David
*From:*Lucy yong [mailto:[email protected]]
*Sent:* Thursday, December 27, 2012 11:55 AM
*To:* Black, David
*Cc:* [email protected]
*Subject:* RE: Multi-subnet VNs - should be a new service type?
David,
Please see in-line with [lucy1]
Hi Lucy,
I’m going back to the original question of whether we need a new service
type, and starting from a couple of comments from you on how the
proposed new L2-3 service works ...
But a frame from TS have both Ethernet and IP header. From TS perspective,
the frame to the TS on the same subnet will be bridged, the frame to the
TS on the different subnet goes to the router. We need to a service to
guarantee that.
TS send a frame to the destination directly if it is on the same subnet and
send a frame to the gateway if the destination of the frame is not on the same
subnet.
I observe that these describe exactly how the currently-defined L2
service works - bridge the frame to the L2 destination, and route it
beyond there if the L2 destination happens to be an L3 router.
*/[Lucy] Yes, you state correct. How does a tenant system to know the
MAC of a router? It uses arp protocol and L2 service is transparent to
arp protocol. What this lead to that even two TSes in the different
subnets attaches the same NVE, the traffic between two has to be routed
via an L3 router./**//*
[David] For clarity - it has to be routed via a **logical** L3 router,
which could be part of an NVE. That logical routing functionality has
to be provisioned and configured independent of whether the two subnets
are in different service instances or the same service instance in the
architecture.
*/[Lucy1]OK, I understand. For this service capability, do you see it as
a L2 service or L3 service? IMO: neither of them fits./*
*/If you choose to have a lot of routers and push the router function
close to NVE for a tenant network, this problem is not a problem.
However, this will make operator nightmare because you have to configure
many L2 and L3 services. /**//*
[David] I think you’ve missed the point. If there are multiple subnets
across which traffic has to be forwarded, the routing functionality to
forward that traffic has to be configured.
*/[Lucy1] If this is the case, you may want to choose few router
locations to avoid massive configuration. This is the case where routing
function is outside hypervisor and on some routers. /*
*/Second, this also require both L2 and L3 interworking mechanism on TS
mobility./*
[David] What do you mean by “L3 interworking”?
*/[Lucy1] If your case is that the L2/L3 are paired and co-exist on the
same NVE, this does not apply to your case. do you think it would be
more clear to express this case with a new NVE service type? /*
Beyond that, the discussion around where the router is located and
whether it’s distributed among multiple nodes, e.g., NVEs, is an
implementation discussion, not a service definition discussion. To be
specific, just spreading such a router (e.g., default gateway) across
the NVEs need change the service that is provided; please see VRRP for a
worked example of this sort of distribution, and VRRP does not change
the service definition in the sense that nvo3 is using the term “service”.
*/[Lucy] Do you say “need change” or “not need change” here? IMO: if
using distributed routing, it is very different from designated routers
design. Both are very useful for the operator, and it would be nice to
distinguish two in overlay./*
[David] “need not change” was intended, sorry for the typo. I agree
that solutions will have to spell out the router structure in detail,
but I’m at a loss for why the service definition has to care.
*/[Lucy1] IMO: we are working on overlay networking. We have either L2
overlay network or L3 overlay network. But sometime a tenant network
needs both L2 and L3 functions to accomplish the needs, where neither L2
overlay nor L3 overlay fit it well. We can let operators to combine two
overlay networks to accomplish the task. But this is not help in
positioning these functions in standard development and causing some
confusion here and there. Furthermore, IMO: it brings a complexity for
operators. /*
I also think that the provisioning topic is a red herring:
*/[Lucy] what do you think about SDN?/*
[David] I think it’s orthogonal to this thread of discussion about
whether provisioning provides a rationale for defining a new service
type in the framework.
*/[Lucy1] This is not what I mean. I agree that SDN is not the reason
for the new service. Let’s stop here./*
Without it [new service type], it means that, for creating a tenant virtual
network that
contains multiple subnets, operators have to create individual layer 2
overlays and layer 3 overlay and specify the interfaces to interconnect them,
etc.
That really does not require a new service type. Rather, a single
sentence ought to suffice to state that orchestration functionality
(e.g., software) may provision multiple virtual networks as part of a
single larger provisioning operation.
*/[Lucy] optimizing operation is attractive for operators. /*
[David] and that optimization can be done via provisioning software that
iterates over the virtual networks that need to be provisioned.
*/[Lucy1] you mean planning tool. I do not think this will work well for
the dynamics in DC, i.e. TS mobility in real time./*
In contrast, there may be a new service type in the discussion of “route
before bridge” because when traffic can be bridged at L2, routing that
traffic at L3 may remove L2 adjacency information, and the discussion of
use of EVPN for traffic that suffers from that removal then follows. I
would hope that this topic can be deferred in the same fashion that (I
hope) non-transitive L2 connectivity (e.g., L2 stations A and B are in
VN 1, stations B and C are in VN 2, A can talk to B, B can talk to C,
but A can’t talk directly to C at L2) has been deferred.
*/[Lucy] this is the hub-spoke. Why do we need to defer this? /*
[David] I’m concerned that it will lead to a long discussion about
redefining exactly what an L2 Ethernet service is and how it differs
from various IEEE 802 definitions.
*/[Lucy1] Thank you to bring this point. If we have a new service type,
that will be different from L2 Ethernet service. We can keep the L2
overlay service is exactly same as the L2 Ethernet service defined in
IEEE. If not, for the scenarios you picture here, it does not belong to
the L2 Ethernet service nor IETF defined L3VPN service. You either
change these services or distinguish it from these two./*
*/Thanks,/*
*/Lucy/*
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[email protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
