This is the issue I refer to and agree that can be solved. The key is what standard rule to have, so that vendor device can interwork together.
Cheers, Lucy From: Lizhong Jin [mailto:[email protected]] Sent: Friday, December 28, 2012 12:22 AM To: Jakob Heitz Cc: [email protected]; Lucy yong; [email protected] Subject: RE: Multi-subnet VNs - should be a new service type? > Default Gateway responds to ARP request for the default gateway, > not to an ARP request for any host. > > An EVPN PE should respond to an ARP request if it knows > that the IP address being requested exists on a different > ethernet segment than the one on which the ARP request arrived. [Lizhong] Yes, and the precondition is the PE knows that the IP address being requested exists on a different ethernet segment. This is the different schema with current practice. And I agree this issue could be solved. Let's see if this is the case Lucy refers to. Lizhong > -- > Jakob Heitz. > > > From: [email protected] [mailto:[email protected]] > Sent: Thursday, December 27, 2012 5:39 PM > To: Jakob Heitz; [email protected] > Cc: [email protected]; [email protected] > Subject: Re: Multi-subnet VNs - should be a new service type? > > Does Lucy refer to the scenario that, if host_A requests MAC of > host_B which resides in the same switched network, the default > gateway should not reply such ARP request, otherwise host_A will > receive ARP reply both from host_B and default gateway. > > Lizhong > > > > > Re: [nvo3] Multi-subnet VNs - should be a new service type? > > > > Certainly. But how it that an issue? > > -- > > Jakob Heitz. > > > > > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Lucy yong > > Sent: Thursday, December 27, 2012 3:20 PM > > To: Jakob Heitz; Black, David > > Cc: [email protected] > > Subject: Re: [nvo3] Multi-subnet VNs - should be a new service type? > > > 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 > > > > > > > > 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 > > > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
