A host may get an arp request via the switched network and reply with its MAC address if IP address matches. This is current host be behavior. Lucy
From: Jakob Heitz [mailto:[email protected]] Sent: Thursday, December 27, 2012 5:18 PM To: Lucy yong; Black, David Cc: [email protected] Subject: RE: Multi-subnet VNs - should be a new service type? Multicast traffic is not at issue. You said: This will have an issue if VAP of EVPN are via a switched network What is the issue? -- Jakob Heitz. x25475. 510-566-2901 ________________________________ From: Lucy yong [mailto:[email protected]] Sent: Thursday, December 27, 2012 3:04 PM To: Jakob Heitz; Black, David Cc: [email protected] Subject: RE: Multi-subnet VNs - should be a new service type? From: Jakob Heitz [mailto:[email protected]] Sent: Thursday, December 27, 2012 3:25 PM To: Lucy yong; Black, David Cc: [email protected] Subject: RE: Multi-subnet VNs - should be a new service type? What is the issue? Are you referring to the case where a network is connected to multiple EVPN PEs in a multihoming arrangement? [Lucy] no, for multihoming case, there is designated forwarder to forward multicast traffic. If that is the case, then I think the EVPN draft is not clear. It should point out that an EVI acting as standby in an active-standby topology can not act as Default Gateway. -- Jakob Heitz. ________________________________ From: Lucy yong [mailto:[email protected]] Sent: Thursday, December 27, 2012 11:06 AM To: Jakob Heitz; Black, David Cc: [email protected] Subject: RE: Multi-subnet VNs - should be a new service type? This will have an issue if VAP of EVPN are via a switched network. Need to modify the ARP response schema. Lucy From: Jakob Heitz [mailto:[email protected]] Sent: Thursday, December 27, 2012 12:58 PM To: Lucy yong; Black, David Cc: [email protected] Subject: RE: Multi-subnet VNs - should be a new service type? The Default Gateway feature of EVPN helps to avoid tromboning. http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-02, Sec. 11.1. Every PE responds to the ARP request for the default router and every PE will route packets with the destination MAC of the default router. -- Jakob Heitz. x25475. 510-566-2901 ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Lucy yong Sent: Thursday, December 27, 2012 10:11 AM To: Black, David Cc: [email protected] Subject: Re: [nvo3] Multi-subnet VNs - should be a new service type? 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
