Re: [bess] Question on ARP probe in draft-ietf-bess-evpn-inter-subnet-forwarding

Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> Fri, 03 May 2019 05:39 UTC

MIME-Version: 1.0
References: <CAKz0y8z+3UoHg_2ssWcEh50qfuAZLbrN8LkLOd5wVJ9o+uq=kQ@mail.gmail.com> <D3B5CFF7-632F-4D03-A324-80E01C37252B@nokia.com>
In-Reply-To: <D3B5CFF7-632F-4D03-A324-80E01C37252B@nokia.com>
From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Date: Fri, 03 May 2019 11:08:57 +0530
Message-ID: <CAKz0y8zLbKDe0ad+2AfX8+a=GU9Cm8XcOwfyJD3UnAazJmcF7g@mail.gmail.com>
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
Cc: "bess@ietf.org" <bess@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006e3dd70587f52bce"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/TzWa4IEp7hZQysMic_bHgmrd6uQ>
Subject: Re: [bess] Question on ARP probe in draft-ietf-bess-evpn-inter-subnet-forwarding
Precedence: list

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.rabadan@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-bounces@ietf.org> on behalf of Muthu Arul Mozhi
> Perumal <muthu.arul@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] Question on ARP probe in draft-ietf-bess-e… Muthu Arul Mozhi Perumal
Re: [bess] Question on ARP probe in draft-ietf-be… Rabadan, Jorge (Nokia - US/Mountain View)
Re: [bess] Question on ARP probe in draft-ietf-be… Muthu Arul Mozhi Perumal
Re: [bess] Question on ARP probe in draft-ietf-be… Rabadan, Jorge (Nokia - US/Mountain View)
Re: [bess] Question on ARP probe in draft-ietf-be… Muthu Arul Mozhi Perumal
Re: [bess] Question on ARP probe in draft-ietf-be… Rabadan, Jorge (Nokia - US/Mountain View)