Subject: [bess] ARP ND draft

From: Antoni Przygienda <[email-masked]>
Date: Wed, 25 Mar 2015 15:23:08 +0000

Watching the presentation in the group and instead crowding the mike here are my comments:

a)      It is worth explaining what flavor of ARP proxy eVPN implements. 'proxy ARP' I found out has different flavors including e.g. the router responding with its own MAC to requests representing remote hosts. Customers & other folks are easily confused by the overloaded 'proxy ARP' term in eVPN context.

b)      It is worth explaining what is suggested behavior if eVPN advertises the same IP with multiple MACs and what happens when e.g. the served MAC vanishes

c)      It is worth explaining what the suggested behavior should be when 'local-bit' MACs are being advertised from remotes (and when those collide)

d)      eVPN draft does not explain anything about possibility to snoop @ DHCP

e)      the IP duplicate detection is an interesting thing given the anycast/multicast and other zoo

--- tony

There are basically two types of people. People who accomplish things, and people who claim to have accomplished things. The first group is less crowded.<http://www.brainyquote.com/quotes/quotes/m/marktwain393535.html>
~~~ Mark Twain<http://www.brainyquote.com/quotes/quotes/m/marktwain393535.html>

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Mar 2015 18:32:37 -0500

On 3/25/15 10:23 AM, Antoni Przygienda wrote:
> a)It is worth explaining what flavor of ARP proxy eVPN implements. 
> ‘proxy ARP’ I found out has different flavors including e.g. the 
> router responding with its own MAC to requests representing remote 
> hosts. Customers & other folks are easily confused by the overloaded 
> ‘proxy ARP’ term in eVPN context.
>
Yes, that is a part that is underspecified for EVPN. I assume that the 
response would include the MAC address of the CE instead of the router's 
own MAC address.

> b)It is worth explaining what is suggested behavior if eVPN advertises 
> the same IP with multiple MACs and what happens when e.g. the served 
> MAC vanishes
>
Doesn't the EVPN RFC already stating that the routes would be withdrawn 
in that case?
>
> c)It is worth explaining what the suggested behavior should be when 
> ‘local-bit’ MACs are being advertised from remotes (and when those 
> collide)
>
Does L2VPN handle that in any interesting way? I don't think EVPN 
introduces any new failure modes for duplicate MAC addresses.
>
> d)eVPN draft does not explain anything about possibility to snoop @ DHCP
>

> e)the IP duplicate detection is an interesting thing given the 
> anycast/multicast and other zoo
>
Presumably not only anycast, but also for some host that might have a 
single IP address and use it with different MAC addresses (I think 
certain configurations of NIC bonding has that effect.)

FWIW the SAVI RFC provides an approach to tell whether it was a change 
in the IP to MAC binding or the IP address being reachable at multiple 
MAC addresses at the same time (which is basically to unicast an NS to 
the old MAC address - I don't know if that would work will for ARP as well).

That still leaves out what to do in the case of anycast addresses etc.

Regards,
    Erik

> --- tony
>
> //
>
> /There are basically two types of people. People who accomplish 
> things, and people who claim to have accomplished things. The first 
> group is less crowded. 
> <http://www.brainyquote.com/quotes/quotes/m/marktwain393535.html>/
>
> /~~~ Mark Twain 
> <http://www.brainyquote.com/quotes/quotes/m/marktwain393535.html>/
>
>
>
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess

---

From: Antoni Przygienda <[email-masked]>
Date: Wed, 25 Mar 2015 23:56:17 +0000

> Doesn't the EVPN RFC already stating that the routes would be withdrawn in
> that case?

The scenario I had in mind was when eVPN PE receives 

>From PE2  IP1/M1  and  later
>From PE3  IP1/M2

while having answered with IP1/M1 per proxy alrady. Additionally, in such situation ends up seeing

>From PE2   IP1/<no MAC>

So the answer it gave is not valid anymore all of a sudden.

--- tony

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Thu, 26 Mar 2015 05:04:32 +0000

Tony, Erik,

Please see in-line.
Thank you for your comments.

-----Original Message-----
From: Erik Nordmark <[email-masked]>
Date: Wednesday, March 25, 2015 at 4:32 PM
To: Antoni Przygienda <[email-masked]>, Jorge Rabadan
<[email-masked]>, "Henderickx, Wim (Wim)"
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [bess] ARP ND draft

>response would include the MAC address of the CE instead of the router's

[JORGE] From draft-snr-bess-evpn-proxy-arp-nd-00:

4.2 Reply sub-function

...

   a) When replying to ARP Request or NS messages, the PE SHOULD use the
      Proxy-ARP/ND entry MAC address as MAC SA. This is recommended so
      that the resolved MAC can be learnt in the MAC FIB of potential
      Layer-2 switches seating between the PE and the CE requesting the
      Address Resolution.

>Doesn't the EVPN RFC already stating that the routes would be withdrawn

[JORGE] Based on our current version, the IP is unique in a PE’s proxy-ARP
table, so if a PE receives 2 RT-2s for the same IP different MAC, only one
IP->MAC binding will be picked up.

>introduces any new failure modes for duplicate MAC addresses.

[JORGE] indeed, this draft does not introduce any new way to handle MAC
addresses in the MAC-VRFs. EVPN has a MAC duplication mechanism, there is
nothing else afaik.

>> d)eVPN draft does not explain anything about possibility to snoop @ DHCP

[JORGE] do you mean in the proxy-arp/nd draft or in the base spec?
In the proxy-arp/nd only ARP/ND messages are used. DHCP is not always
there. Not there in the IXP use-case anyway.

>That still leaves out what to do in the case of anycast addresses etc.

[JORGE] As I mentioned during the session, the current draft does not
support anycast addresses. The use-case we are focusing at the moment
(IXPs) does not require it. We can think about it though.
As for the IP “moving" to a different MAC, we have introduced this
“CONFIRM” message in this implementation. We have implemented it not only
for ND (unicast NS, like in NUD) but also for ARP (unicast ARP request),
and seems to work well:

"o In order to detect the duplicate IP faster, the PE MAY send a
     CONFIRM message to the former owner of the IP. If the PE does not
     receive an answer within a given timer, the new entry will be
     confirmed and activated. For instance, if IP1->MAC1 moves to
     IP1->MAC2, the PE may send a unicast ARP-Request/NS message for IP1
     with MAC DA= MAC1 and MAC SA= PE's MAC."

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Thu, 26 Mar 2015 05:04:36 +0000

Hi Tony,

As I said earlier, the current proposal implies the IP is unique in the
proxy-arp/nd table.
If PE1 gets IP1->M1 from PE2 and later IP1->M2 from PE3, the latter will
override the former (see also the optional confirm message in my other
email).
Now, in order to make sure the arp/nd caches of the CEs/hosts are kept up
to date with the latest information we are suggesting the following:

"The following procedure associated to the Learning sub-function is
   recommended:

   o When a new Proxy-ARP/ND EVPN or static active entry is learnt (or
     provisioned) the PE SHOULD send an unsolicited GARP or NA message
     to the access CEs. This makes sure the CE ARP/ND caches are updated
     even if the ARP/NS/NA messages from remote CEs are not flooded in
     the EVPN network.”

Thanks.
Jorge

-----Original Message-----
From: Antoni Przygienda <[email-masked]>
Date: Wednesday, March 25, 2015 at 4:56 PM
To: Erik Nordmark <[email-masked]>, Jorge Rabadan
<[email-masked]>, "Henderickx, Wim (Wim)"
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [bess] ARP ND draft

>>in

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 26 Mar 2015 11:00:59 +0000

For this case you should sent a GARP with the new MAC/IP

---

From: Antoni Przygienda <[email-masked]>
Date: Mon, 30 Mar 2015 02:59:47 +0000

Yes, but of course I brought it up to show that 'the last one simply wins' as suggested by the draft is not enough IMO. A good architecture should probably keep track of what it served as answer and when the answer is invalid or a new, better one exists, provide a GARP. 

As well, when PE2 sends a newer MAC it may not be a good strategy to serve a GARP if PE1's MAC has already been offered. That could lead IMO to e.g. gateway chasing problems. 

--- tony 

There are basically two types of people. People who accomplish things, and people who claim to have accomplished things. The first group is less crowded.
~~~ Mark Twain

> From: Henderickx, Wim (Wim) [mailto:[email-masked]]
> Sent: Thursday, March 26, 2015 6:01 AM
> To: Antoni Przygienda; Erik Nordmark; Rabadan, Jorge (Jorge)
> Cc: [email-masked]
> >> > b)It is worth explaining what is suggested behavior if eVPN
> >> > advertises the same IP with multiple MACs and what happens when
> >> > e.g. the served MAC vanishes
> >> >
> >> Doesn't the EVPN RFC already stating that the routes would be
> >> withdrawn in that case?
> >

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 30 Mar 2015 04:18:21 +0000

We will update the draft to highlight the IPv6 anycast behaviour better as pointed out by RObert. In IPv4 there is no anycast behaviour and as such there should be one option possible.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 29 Mar 2015 23:45:03 -0500

Hi Wim,

What makes you say that in IPv4 there is no anycast ? All anycase I have
played so far is IPv4 :)

Cheers,
r.

On Sun, Mar 29, 2015 at 11:18 PM, Henderickx, Wim (Wim) <
[email-masked]> wrote:

> We will update the draft to highlight the IPv6 anycast behaviour better as
> pointed out by RObert. In IPv4 there is no anycast behaviour and as such
> there should be one option possible.
>
>
>
> >Yes, but of course I brought it up to show that 'the last one simply
> wins' as suggested by the draft is not enough IMO. A good architecture
> should probably keep track of what it served as answer and when the answer
> is invalid or a new, better one exists, provide a GARP.
> >
> >As well, when PE2 sends a newer MAC it may not be a good strategy to
> serve a GARP if PE1's MAC has already been offered. That could lead IMO to
> e.g. gateway chasing problems.
> >
> >--- tony
> >
> >
> >There are basically two types of people. People who accomplish things,
> and people who claim to have accomplished things. The first group is less
> crowded.
> >~~~ Mark Twain
> >
> >

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 30 Mar 2015 05:38:56 +0000

At interface level you get dad in most stacks I know.

Sent from my iPhone

On 30 Mar 2015, at 06:45, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi Wim,

What makes you say that in IPv4 there is no anycast ? All anycase I have played so far is IPv4 :)

Cheers,
r.

On Sun, Mar 29, 2015 at 11:18 PM, Henderickx, Wim (Wim) <[email-masked]<mailto:[email-masked]>> wrote:
We will update the draft to highlight the IPv6 anycast behaviour better as pointed out by RObert. In IPv4 there is no anycast behaviour and as such there should be one option possible.

On 30/03/15 04:59, "Antoni Przygienda" <[email-masked]<mailto:[email-masked]>> wrote:

>> From: Henderickx, Wim (Wim) [mailto:[email-masked]<mailto:[email-masked]>]
>> Cc: [email-masked]<mailto:[email-masked]>
>> On 25/03/15 18:56, "Antoni Przygienda" <[email-masked]<mailto:[email-masked]>>
>> wrote:
>>
_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 30 Mar 2015 06:10:58 +0000

To be clear: RFC4861 section 7.2.7 explains the anycast behaviour in IPv6.
I am not aware of such thing at IPv4/ARP level. Do you have a pointer?
There is anycast at IPv4 level for sure but I am not ware this is supported at arp level.

From: <Henderickx>, Wim Henderickx
Date: Monday 30 March 2015 07:38
To: Robert Raszuk
Cc: Erik Nordmark, Antoni Przygienda, "[email-masked]<mailto:[email-masked]>", Jorge Rabadan
Subject: Re: [bess] ARP ND draft

Sent from my iPhone

Hi Wim,

Cheers,
r.

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 30 Mar 2015 06:17:51 +0000

Found it https://www.ietf.org/rfc/rfc1546.txt seems to specify it.

From: <Henderickx>, Wim Henderickx
Date: Monday 30 March 2015 08:10
To: Robert Raszuk
Cc: Erik Nordmark, Antoni Przygienda, "[email-masked]<mailto:[email-masked]>", Jorge Rabadan
Subject: Re: [bess] ARP ND draft

Sent from my iPhone

Hi Wim,

Cheers,
r.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Mar 2015 01:19:10 -0500

Hi Wim,

> There is anycast at IPv4 level for sure but I am not ware this is
supported at arp level.

Precisely right. It needs to be documented and addressed if anyone is up to
proposing automated IP duplicate address detection and disabling.

RFC1546 is rather too old to consider here as solution :)

Cheers,
R.

On Mon, Mar 30, 2015 at 1:10 AM, Henderickx, Wim (Wim) <
[email-masked]> wrote:

> Cc: Erik Nordmark, Antoni Przygienda, "[email-masked]", Jorge Rabadan
>
> On 30 Mar 2015, at 06:45, Robert Raszuk <[email-masked]> wrote:
>
>    Hi Wim,
>
>> We will update the draft to highlight the IPv6 anycast behaviour better
>> as pointed out by RObert. In IPv4 there is no anycast behaviour and as such
>> >> On 25/03/15 18:56, "Antoni Przygienda" <[email-masked]
>> >
>> >> wrote:
>> >>

---

From: Antoni Przygienda <[email-masked]>
Date: Mon, 30 Mar 2015 07:12:12 +0000

I’m also skeptical whether IP duplicate detection would be a good default thing. Especially in case of what I call ‘aliased default gateway’ which section 10.1 specifically allows, i.e. default GW IP address is same but each PE may use a different MAC when advertising it and consequently responses for same IP with different ARPs may be seen in the network.  Yes, default GW ExtComm is there to differentiate so it can be called an exception but nevertheless.

I also thought a tad about VRRP but I think the IP duplicate detection will not apply there, it’s all same IPx->MACx from all routers so if anything, it’s more of a MAC move thing.

Generally I think someone who wants a secure, stable eVPN wants IP duplicate detection, someone who runs a very dynamic network with tons gateways, possibly anycast & floating IPs will probably not be too enamored with it.

Thanks

--- tony

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, March 30, 2015 1:19 AM
To: Henderickx, Wim (Wim)
Cc: Erik Nordmark; Antoni Przygienda; [email-masked]; Rabadan, Jorge (Jorge)
Subject: Re: [bess] ARP ND draft

Hi Wim,

> There is anycast at IPv4 level for sure but I am not ware this is supported at arp level.

Precisely right. It needs to be documented and addressed if anyone is up to proposing automated IP duplicate address detection and disabling.

Cheers,
R.

On Mon, Mar 30, 2015 at 1:10 AM, Henderickx, Wim (Wim) <[email-masked]<mailto:[email-masked]>> wrote:
To be clear: RFC4861 section 7.2.7 explains the anycast behaviour in IPv6.
I am not aware of such thing at IPv4/ARP level. Do you have a pointer?
There is anycast at IPv4 level for sure but I am not ware this is supported at arp level.

Sent from my iPhone

Cheers,
r.

---

From: Antoni Przygienda <[email-masked]>
Date: Mon, 30 Mar 2015 07:26:13 +0000

Hey Jorge, I read your draft again in a larger context than simple 'informational how IXP network runs eVPN ARP stuff'.  Generally I think it should be extended beyond 'some customer's use case' and provide BCP or 'implementation recommendations' or some such thing for the generic issue of snooping ARP/ND/DHCP/others to reduce the amount of BU_ traffic across the PEs.  ARP/DHCP/ND snooping is a delicate functionality that is vastly underspecified in eVPN base and is essential for a good eVPN implementation (i.e. robust, interoperable & scalable) IMO. 

Thanks for sharing all this experience BTW, insightful read that enlightened bunch of corner cases I didn't think through. 

Comments inline 

> >response would include the MAC address of the CE instead of the
> >router's own MAC address.
> 

 [Tony saiz:]  agreed. I cannot imagine why it's NOT a MUST (except default GW cases where it makes sense e.g. in case of aliased case to resolve GW IP request). 

Small observation for 4.2b)  If we want to be double-perfect we should actually  not even respond if we have 2 ACs on the same ESI on the same PE ;-)  

Small observation for 4.3:  enabling the send-refresh option is a dangerous thing. It's not only they may keep up active entries in the fast-path forever (since there is always some traffic generated by the 'probes'), it's also that the IP/MAC binding 'kept up' even if there is no traffic is sitting in all PEs as RT-2.  The section talks about advantages, maybe it deserves a sentence to point out the dangers of such behavior. 

> >> advertises the same IP with multiple MACs and what happens when e.g.
> >> the served MAC vanishes
> >>
> [JORGE] Based on our current version, the IP is unique in a PE’s proxy-ARP table,
> so if a PE receives 2 RT-2s for the same IP different MAC, only one

[Tony saiz:]   as I wrote in other email, the problem is if the first route goes, the second should be honored IMO. It seems to me we have this very case BTW with the aliased default gateways?

> addresses in the MAC-VRFs. EVPN has a MAC duplication mechanism, there is

 [Tony saiz:]  agreed. 

> In the proxy-arp/nd only ARP/ND messages are used. DHCP is not always there.
> Not there in the IXP use-case anyway.

 [Tony saiz:]  agreed,  I just read the draft in wider scope than just IXP and that's why I'm asking.  

One could even talk about initially snooping  IP frames directly in case eVPN "attaches" to an already running bridge and snoops already active IP traffic to learn IP/MAC bindings from bridge ports. Probably hypothetical only  ;-) 

-- tony

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Tue, 31 Mar 2015 20:10:52 +0000

Hey Tony,

-----Original Message-----
From: Antoni Przygienda <[email-masked]>
Date: Monday, March 30, 2015 at 12:26 AM
To: Jorge Rabadan <[email-masked]>, Erik Nordmark
<[email-masked]>, "Henderickx, Wim (Wim)"
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [bess] ARP ND draft

>Hey Jorge, I read your draft again in a larger context than simple
>'informational how IXP network runs eVPN ARP stuff'.  Generally I think
>it should be extended beyond 'some customer's use case' and provide BCP
>or 'implementation recommendations' or some such thing for the generic
>issue of snooping ARP/ND/DHCP/others to reduce the amount of BU_ traffic
>across the PEs.  ARP/DHCP/ND snooping is a delicate functionality that is
>vastly underspecified in eVPN base and is essential for a good eVPN
>implementation (i.e. robust, interoperable & scalable) IMO.

[JORGE] at the moment the draft is Informational and it only includes the
IXP use-case, but based on the feedback we will extend it to the DC
use-case. 

> 
>
>Thanks for sharing all this experience BTW, insightful read that
>enlightened bunch of corner cases I didn't think through.

[JORGE] Thank you for your feedback. This is based on an existing
implementation/shipping code and the result of the issues we found when
implementing proxy-arp/nd for EVPN.

> [Tony saiz:]  agreed. I cannot imagine why it's NOT a MUST (except
>default GW cases where it makes sense e.g. in case of aliased case to
>resolve GW IP request).

[JORGE] I am personally a bit reluctant to use “MUST” in this draft, since
the use-cases can be very different. You are highlighting one example.

> 
>
>Small observation for 4.2b)  If we want to be double-perfect we should
>actually  not even respond if we have 2 ACs on the same ESI on the same
>PE ;-)  

[JORGE] 2 ACs on the same ESI/EVI on the same PE? I suppose to are talking
about VLAN-aware bundle interfaces, where each VLAN goes to a different
BD? note that the proxy-arp/nd function is per broadcast domain, i.e. one
per EVI for VLAN-based and VLAN-bundle and one per BD for VLAN-aware
bundle interfaces. We can clarify that in the draft.

>
>Small observation for 4.3:  enabling the send-refresh option is a
>dangerous thing. It's not only they may keep up active entries in the
>fast-path forever (since there is always some traffic generated by the
>'probes'), it's also that the IP/MAC binding 'kept up' even if there is
>no traffic is sitting in all PEs as RT-2.  The section talks about
>advantages, maybe it deserves a sentence to point out the dangers of such
>behavior.

[JORGE] send-fresh is optional and should be enabled/disabled depending on
the use-case. The purpose is in fact keep local IP->MAC bindings active
and make sure they are still valid before withdrawing the RT2s. It can
also help keeping active not only the proxy entry but also the MAC-VRF
entry. If the user wants to rely purely on the age-time, that should be
allowed. Not sure why this is a danger?

>[Tony saiz:]   as I wrote in other email, the problem is if the first
>route goes, the second should be honored IMO. It seems to me we have this
>very case BTW with the aliased default gateways?

[JORGE] Yes, if the first route is withdrawn (IP1->M1), the second
(IP1->M2) will be now installed in the proxy-arp/nd table. As long as the
BGP route is kept we are good. A different thing is anycast, in which case
IP1->M1 and IP1->M2 are both valid at the same time. We will tackle this
in the next rev.

>IXP and that's why I'm asking.

[JORGE] IMHO focusing on learning arp/nd for the time being is simpler,
and it is really what we want to keep under control to reduce flooding.
But we can discuss.

>
>One could even talk about initially snooping  IP frames directly in case
>eVPN "attaches" to an already running bridge and snoops already active IP
>traffic to learn IP/MAC bindings from bridge ports. Probably hypothetical
>only  ;-) 
>
>-- tony 
>

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Tue, 31 Mar 2015 20:10:49 +0000

Hi Robert and Tony,

As Wim mentioned, ipv6 anycast is something that we will add to the draft in the next rev. There is an easy way to know if a given proxy-ND entry belongs to an anycast address or not and disable the duplicate IP detection for those.

The challenge for IPv4 is that I don’t see an easy way to learn dynamically from access attachment circuits that a given ipv4 is anycast. Even for default gateways, if they are integrated in the EVPN PE, we are good, but if they are external and connected to a MAC-VRF, it is not so clear how to learn that (unless you learn those entries from the management interface).

One of the reasons why we have lots of “SHOULDs” in the draft and not “MUST” is because the implementation has to be flexible enough to be configured in a different way depending on the use-case, which is one of the points that Tony mentions below. In the use-case described at the moment there is no anycast and duplicate IP detection is very important. We will add the DC use case in the next rev as suggested by Robert and others.
Thanks.
Jorge

From: Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 30, 2015 at 12:12 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>, "Henderickx, Wim (Wim)" <[email-masked]<mailto:[email-masked]>>
Cc: Erik Nordmark <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Jorge Rabadan <[email-masked]<mailto:[email-masked]>>
Subject: RE: [bess] ARP ND draft

Thanks

--- tony

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, March 30, 2015 1:19 AM
To: Henderickx, Wim (Wim)
Cc: Erik Nordmark; Antoni Przygienda; [email-masked]<mailto:[email-masked]>; Rabadan, Jorge (Jorge)
Subject: Re: [bess] ARP ND draft

Hi Wim,

Cheers,
R.

Sent from my iPhone

Cheers,
r.

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 31 Mar 2015 23:51:03 +0000

[Tony saiz:] agreed

[Tony saiz:] agreed.

--- tony

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 31 Mar 2015 23:53:25 +0000

> about VLAN-aware bundle interfaces, where each VLAN goes to a different BD?
> note that the proxy-arp/nd function is per broadcast domain, i.e. one per EVI for
> VLAN-based and VLAN-bundle and one per BD for VLAN-aware bundle
> interfaces. We can clarify that in the draft.

 [Tony saiz:]  same EVI/ESI/VLAN which for me indicates that the two ACs belong to the same customer and are same  ether. very small nitpick, probably not worth mentioning ;-) 

> >advantages, maybe it deserves a sentence to point out the dangers of
> >such behavior.
> 
> [JORGE] send-fresh is optional and should be enabled/disabled depending on the
> use-case. The purpose is in fact keep local IP->MAC bindings active and make
> sure they are still valid before withdrawing the RT2s. It can also help keeping
> active not only the proxy entry but also the MAC-VRF entry. If the user wants to
> rely purely on the age-time, that should be allowed. Not sure why this is a
> danger?

 [Tony saiz:]  because disabling aging will basically accumulate more and more state in fwd path even if the src/dst pairs don't talk to each other anymore. In your customer's scenario that's what's needed, in e.g. sparse, large scale EVPN deployments in backbone it's probably not what a carrier would be excited about given PE state is expensive.

> >route goes, the second should be honored IMO. It seems to me we have
> >this very case BTW with the aliased default gateways?
> 
> (IP1->M2) will be now installed in the proxy-arp/nd table. As long as the BGP
> route is kept we are good. A different thing is anycast, in which case

 [Tony saiz:]  I agree with that (i.e. the 2nd best BGP route is GARP'ed).  The anycast in ipv4 is a rare animal from the sightings I had so I'm only concered about the 'aliased default GW' case I guess. 

> [JORGE] IMHO focusing on learning arp/nd for the time being is simpler, and it is
> really what we want to keep under control to reduce flooding.
> But we can discuss.

 [Tony saiz:]  agreed. Maybe one sentence placeholder like "DHCP and other strange fruit can be snooped beside to learn the IP/MAC bindings" ;-)

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Wed, 1 Apr 2015 00:23:49 +0000

Thank you Tony.
Very helpful feedback.

Jorge

-----Original Message-----
From: Antoni Przygienda <[email-masked]>
Date: Tuesday, March 31, 2015 at 4:53 PM
To: Jorge Rabadan <[email-masked]>, Erik Nordmark

>>BD?
> [Tony saiz:]  same EVI/ESI/VLAN which for me indicates that the two ACs
>belong to the same customer and are same  ether. very small nitpick,
>probably not worth mentioning ;-)
>
>> 
>> 
>> >
> [Tony saiz:]  because disabling aging will basically accumulate more and
>more state in fwd path even if the src/dst pairs don't talk to each other
>anymore. In your customer's scenario that's what's needed, in e.g.
>sparse, large scale EVPN deployments in backbone it's probably not what a
>carrier would be excited about given PE state is expensive.
>
>> >
> [Tony saiz:]  I agree with that (i.e. the 2nd best BGP route is
>GARP'ed).  The anycast in ipv4 is a rare animal from the sightings I had
>so I'm only concered about the 'aliased default GW' case I guess.
>
>> >
>> >> >>
>>and it is
> [Tony saiz:]  agreed. Maybe one sentence placeholder like "DHCP and
>other strange fruit can be snooped beside to learn the IP/MAC bindings"
>;-) 
>
>