Kireeti, I'm not clear what difference it makes whether a packet is unicast forwarded using MAC address or IP address within a subnet as long as it gets to the intended destination along the most optimal path, particularly when the price to pay is non-standard behavior (intra-subnet ARP manglers ;}, etc). I understand the argument about the sub-optimal routing from a third site, but when the primary sites end up aggregating prefixes for scaling reasons that argument falls off the table. One way or other the piper gets paid.
In terms of the real world issue of getting there from here -- personally I haven't seen any vendor working towards a standards-based solution that will allow intra-subnet routing for subnets over HW/TOR-based PE, let alone intra-subnet routing for subnets that span across both hypervisor-based PE and TOR-based PE. This makes me leery of solutions that can only take us half way there, particularly during the transition phase. So if we're talking about network virtualization based purely on hypervisors, "route IP, bridge non-IP" may be realistic if you're willing to accept the caveats, but does not seem to be otherwise. Btw, I understand how multicast may be less than efficient when building both inter and intra subnet trees for the same IP mcast group that end up overlapping links (maybe even more than twice) -- but I'd like to hear your take on any other *insolvable* issues with regard to multicast. Best regards -- aldrin On Tue, Dec 18, 2012 at 6:06 PM, Kireeti Kompella <[email protected]> wrote: > Hi Thomas, > > On Dec 18, 2012, at 09:03 , Thomas Narten <[email protected]> wrote: > >> Kireeti Kompella <[email protected]> writes: >> >>> The solution is simple: route if IP, bridge if not. Yes, one could >>> do IRB, but why? IRB brings in complications, especially for >>> multicast. I'm sure someone suggested this already, so put me down >>> as supporting this view. >> >> I'm not sure I understand the difference. >> >> From an *NVE* perspective, when it receives a packet (which will have >> an L2 header), it can look at the Ethertype, and if its IP, it can >> route it. Otherwise, it can provide normal L2 service. So, in this >> sense, "route if IP, bridge if not" is straightforward. And more to >> the point, I assume that if the packet gets L2 service, the entire VN >> is treated as a *single* broadcast domain. All nodes can reach all >> other nodes. Right? > > Right. > >> Just so I understand, how is this different than IRB? What does IRB >> imply that the above does not? > > IRB follows the principle of "bridge when you can, route otherwise". So, an > IP packet with dest IP in the same subnet actually gets bridged; the > originator (e.g., the VM) is responsible for ARPing the IP address, slapping > the right dest MAC on the packet and sending that to the NVE which simply > forwards based on dest MAC address *without* decrementing the TTL. > > If the dest IP is in another subnet, the packet is sent to the gateway (which > for IRB would be the same NVE), which this time does an IP address lookup, > decrements TTL and routes the packet. > > For multicast, there are even more differences. > >> But this is different than what (I believe) Lucy is arguing for. In >> the case of a multi-subnet VN, you have one VN, but it contains >> different subnets. Each subnet is intended to be one broadcast domain >> (i.e., equivalent of a VLAN), so that when sending LL multicast and >> the like on a specific subnet, such packets are *not* delivered to all >> nodes in the VN, but only those that are part of subnet. > > If one were to configure multiple subnets on a VLAN, I wonder if LL traffic > goes to all members of the VLAN, or just those in the same subnet as the > sender. I suspect the former (but don't know). > >> This is a more complex type of service to provide. And I'm not sure we >> need this type of service to be provided by one VN. > > Agree. > >> A (seemingly >> simpler) alternative would be to put each subnet in its own VN and >> allow inter-subnet traffic to be handed as inter-VN traffic. So long >> as that case is optimized (i.e., the ingress NVE can tunnel directly >> to the egress NVE without adding triangular routing), this would seem >> to be a cleaner way to implement this. > > Can be done. However, we're on Lucy's topic; mine was "route if IP, bridge > otherwise"; the goal was to rationalize the need for Layer 2 forwarding for > non-IP traffic, and inter- and intra-subnet routing. > > Kireeti. > >> Thomas >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
