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

[Rabadan, Jorge (Nokia - US/Mountain View)]

From: Muthu Arul Mozhi Perumal 
Date: Friday, May 3, 2019 at 11:47 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Cc: "bess@ietf.org" 
Subject: Re: [bess] Question on ARP probe in 
draft-ietf-bess-evpn-inter-subnet-forwarding

Please see inline..

On Fri, May 3, 2019 at 12:02 PM Rabadan, Jorge (Nokia - US/Mountain View) 
mailto: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?
[JORGE] you need it so that the ip can be imported in a remote IP-VRF that is 
not attached to the same MAC-VRF.

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.
[JORGE] the RT and ethernet tag ID always identify the BD for which the route 
is intended. I think that should be pretty straight forward based on RFC7432.

Regards,
Muthu


Thx
Jorge

From: Muthu Arul Mozhi Perumal 
mailto:muthu.a...@gmail.com>>
Date: Friday, May 3, 2019 at 7:39 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>
Cc: "bess@ietf.org" mailto: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) 
mailto: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 mailto:bess-boun...@ietf.org>> on behalf of 
Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail.com>>
Date: Tuesday, April 30, 2019 at 4:39 AM
To: "bess@ietf.org" mailto: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:


   - 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  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.


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

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

[Muthu Arul Mozhi Perumal]

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 
> *Date: *Friday, May 3, 2019 at 7:39 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)"  >
> *Cc: *"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  on behalf of Muthu Arul Mozhi
> Perumal 
> *Date: *Tuesday, April 30, 2019 at 4:39 AM
> *To: *"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:
>
>
>
> 
>
>- 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  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.
>
> 
>
>
>
> 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

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

[Rabadan, Jorge (Nokia - US/Mountain View)]

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.
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.

Thx
Jorge

From: Muthu Arul Mozhi Perumal 
Date: Friday, May 3, 2019 at 7:39 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Cc: "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) 
mailto: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 mailto:bess-boun...@ietf.org>> on behalf of 
Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail.com>>
Date: Tuesday, April 30, 2019 at 4:39 AM
To: "bess@ietf.org" mailto: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:


   - 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  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.


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