Please see inline.. On Fri, May 3, 2019 at 12:02 PM Rabadan, Jorge (Nokia - US/Mountain View) < jorge.raba...@nokia.com> wrote:
> You only need the IP-VRF RT in case of the IP is included in the MAC/IP > route _*and*_ you are in symmetric mode, since you need to install the IP > in the route-table. > If we follow the argument that there is only one IP-VRF per BD which you can identify based on the RT for the MAC-VRF and Ethernet tag, you don't need the RT for the IP-VRF even if the MAC/IP route includes the IP and you are in symmetric mode, right? > The mobility section is done for both symmetric and asymmetric modes, and > also, in particular, that case you allude to, there is only a MAC in the > route that the source NVE receives. So you cannot guarantee the source NVE > will receive an RT for the IP-VRF. > Agree. But, neither section 4.2 nor anywhere else in draft-ietf-bess-evpn-inter-subnet-forwarding we describe how the source NVE deduces the IP-VRF when the MAC/IP route has only the MAC address and MAC-VRF RT. Regards, Muthu > > > Thx > > Jorge > > > > *From: *Muthu Arul Mozhi Perumal <muthu.a...@gmail.com> > *Date: *Friday, May 3, 2019 at 7:39 AM > *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com > > > *Cc: *"bess@ietf.org" <bess@ietf.org> > *Subject: *Re: [bess] Question on ARP probe in > draft-ietf-bess-evpn-inter-subnet-forwarding > > > > Hi Jorge, > > > > Thanks for your response. Please see inline.. > > > > On Tue, Apr 30, 2019 at 8:43 PM Rabadan, Jorge (Nokia - US/Mountain View) < > jorge.raba...@nokia.com> wrote: > > Muthu, > > > > The source NVE identifies the MAC-VRF/BD out of the RT/eth-tag. The > assumption is that the BD is only attached to one IP-VRF, hence you know > what ARP table to look up. > > > > If this is the case, why include the RT for the IP-VRF at all in route > type-2 advertisements? > > > > Regards, > > Muthu > > > > My two cents. > > > > Jorge > > > > *From: *BESS <bess-boun...@ietf.org> on behalf of Muthu Arul Mozhi > Perumal <muthu.a...@gmail.com> > *Date: *Tuesday, April 30, 2019 at 4:39 AM > *To: *"bess@ietf.org" <bess@ietf.org> > *Subject: *[bess] Question on ARP probe in > draft-ietf-bess-evpn-inter-subnet-forwarding > > > > Hi Everyone, > > > > draft-ietf-bess-evpn-inter-subnet-forwarding describes the mobility > procedure to be followed when a TS moves from a source NVE to a target NVE > and starts sending data traffic without first initiating an ARP request. It > says the following in section 4.2: > > > > <snip> > > - The source NVE upon receiving this MAC/IP advertisement, realizes > > that the MAC has moved to the new NVE. It updates its MAC-VRF table > > accordingly by updating the adjacency information for that MAC > > address to point to the target NVE and withdraws its EVPN MAC/IP > > route that has only the MAC address (if it has advertised such route > > previously). Furthermore, *it searches its ARP table for this MAC and* > > *sends an ARP probe for this <MAC,IP> pair*. The ARP request message is > > sent both locally to all attached TSes in that subnet as well as it > > is sent to other NVEs participating in that subnet including the > > target NVE. > > </snip> > > > > The question I have is, the MAC/IP Advertisement route the source NVE > receives from the target NVE in the above case has only the MAC address of > the TS and the RT corresponding to the MAC-VRF. How can the source NVE > deduce the IP-VRF to search the corresponding ARP table and send an ARP > probe? > > > > Regards, > > Muthu > >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
