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

[Muthu Arul Mozhi Perumal]

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] 答复: [I2nsf] 答复: [IPsec] using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller facilitated IPsec configuration

[Susan Hares]

Alvaro: 

 

Can we set a date to discuss the IP sec tunnels?   Do you want to talk as 
routing chairs before we include the IPSEC and I2NSF chairs? 

 

Sue Hares

 

From: Alvaro Retana [mailto:aretana.i...@gmail.com] 
Sent: Tuesday, April 2, 2019 10:20 AM
To: Linda Dunbar
Cc: ip...@ietf.org WG; idr-cha...@ietf.org; bess-cha...@ietf.org; idr wg; 
i2...@ietf.org; 
Subject: Re: 答复: [I2nsf] 答复: [IPsec] using BGP signaling to achieve IPsec 
Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the 
I2NSF's Controller facilitated IPsec configuration

 

On April 2, 2019 at 5:21:09 AM, Xialiang (Frank, Network Standard & Patent 
Dept) (frank.xiali...@huawei.com) wrote:

 

[Trimmed individual addresses and consolidated (sec-ads, i2nsf-chairs) to avoid 
a bounce  + bess-chairs + rtg-ads.]

 

Hi!

 

Thank you all for the discussion.  I’m replying to this message to pick on what 
Frank said…but in reality is a general reply to the thread.  

the key point is...the function gaps each draft can fill in.

Because there are several drafts that may overlap in function and content, I 
have asked John/Sue (idr-chairs) to work with Stephane/Matthew (bess-chairs) in 
figuring out the overlaps and helping the authors (if needed) to rationalize 
what should go forward and what is not needed because it may be a duplicate…at 
least starting from the RTG area point of view.

Once the consolidation is done, we should have a clearer picture on the type of 
interaction we need to have with i2nsf/ipsecme.

Since we’re all just getting back from Prague, please give the Chairs a little 
bit of time.

Thanks!

Alvaro.

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess