Re: [bess] ARP ND draft
...@alcatel-lucent.com Subject: RE: [bess] ARP ND draft 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 // /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:*rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com [mailto:rras...@gmail.com mailto:rras...@gmail.com] *On Behalf Of *Robert Raszuk *Sent:* Monday, March 30, 2015 1:19 AM *To:* Henderickx, Wim (Wim) *Cc:* Erik Nordmark; Antoni Przygienda; bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org; 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. RFC1546 is rather too old to consider here as solution :) Cheers, R. On Mon, Mar 30, 2015 at 1:10 AM, Henderickx, Wim (Wim) wim.henderi...@alcatel-lucent.com mailto:wim.henderi...@alcatel-lucent.com mailto:wim.henderi...@alcatel-lucent.com mailto:wim.henderi...@alcatel-lucent.com 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. *From: *Henderickx, Wim Henderickx *Date: *Monday 30 March 2015 07:38 *To: *Robert Raszuk *Cc: *Erik Nordmark, Antoni Przygienda, bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org, Jorge Rabadan *Subject: *Re: [bess] ARP ND draft At interface level you get dad in most stacks I know. Sent from my iPhone On 30 Mar 2015, at 06:45, Robert Raszuk rob...@raszuk.net mailto:rob...@raszuk.net mailto:rob...@raszuk.net mailto:rob...@raszuk.net 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) wim.henderi...@alcatel-lucent.com mailto:wim.henderi...@alcatel-lucent.com mailto:wim.henderi...@alcatel-lucent.com mailto:wim.henderi...@alcatel-lucent.com 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 antoni.przygie...@ericsson.com mailto:antoni.przygie...@ericsson.com mailto:antoni.przygie...@ericsson.com mailto:antoni.przygie...@ericsson.com wrote: Yes, but of course I brought it up to show
Re: [bess] ARP ND draft
mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org, Jorge Rabadan jorge.raba...@alcatel-lucent.com mailto:jorge.raba...@alcatel-lucent.com mailto:jorge.raba...@alcatel-lucent.com mailto:jorge.raba...@alcatel-lucent.com mailto:jorge.raba...@alcatel-lucent.com mailto:jorge.raba...@alcatel-lucent.com mailto:jorge.raba...@alcatel-lucent.com mailto:jorge.raba...@alcatel-lucent.com mailto:jorge.raba...@alcatel-lucent.com mailto:jorge.raba...@alcatel-lucent.com mailto:jorge.raba...@alcatel-lucent.com mailto:jorge.raba...@alcatel-lucent.com mailto:jorge.raba...@alcatel-lucent.com mailto:jorge.raba...@alcatel-lucent.com mailto:jorge.raba...@alcatel-lucent.com mailto:jorge.raba...@alcatel-lucent.com Subject: RE: [bess] ARP ND draft 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 // /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:*rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com [mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com mailto:rras...@gmail.com] *On Behalf Of *Robert Raszuk *Sent:* Monday, March 30, 2015 1:19 AM *To:* Henderickx, Wim (Wim) *Cc:* Erik Nordmark; Antoni Przygienda; bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org
Re: [bess] ARP ND draft
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). [Tony saiz:] agreed 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. [Tony saiz:] agreed. --- tony ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] ARP ND draft
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 antoni.przygie...@ericsson.commailto:antoni.przygie...@ericsson.com Date: Monday, March 30, 2015 at 12:12 AM To: Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net, Henderickx, Wim (Wim) wim.henderi...@alcatel-lucent.commailto:wim.henderi...@alcatel-lucent.com Cc: Erik Nordmark nordm...@acm.orgmailto:nordm...@acm.org, bess@ietf.orgmailto:bess@ietf.org bess@ietf.orgmailto:bess@ietf.org, Jorge Rabadan jorge.raba...@alcatel-lucent.commailto:jorge.raba...@alcatel-lucent.com Subject: RE: [bess] ARP ND draft 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 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 Twainhttp://www.brainyquote.com/quotes/quotes/m/marktwain393535.html From: rras...@gmail.commailto:rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk Sent: Monday, March 30, 2015 1:19 AM To: Henderickx, Wim (Wim) Cc: Erik Nordmark; Antoni Przygienda; bess@ietf.orgmailto:bess@ietf.org; 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. RFC1546 is rather too old to consider here as solution :) Cheers, R. On Mon, Mar 30, 2015 at 1:10 AM, Henderickx, Wim (Wim) wim.henderi...@alcatel-lucent.commailto:wim.henderi...@alcatel-lucent.com 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. From: Henderickx, Wim Henderickx Date: Monday 30 March 2015 07:38 To: Robert Raszuk Cc: Erik Nordmark, Antoni Przygienda, bess@ietf.orgmailto:bess@ietf.org, Jorge Rabadan Subject: Re: [bess] ARP ND draft At interface level you get dad in most stacks I know. Sent from my iPhone On 30 Mar 2015, at 06:45, Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net 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) wim.henderi...@alcatel-lucent.commailto:wim.henderi...@alcatel-lucent.com 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 antoni.przygie...@ericsson.commailto:antoni.przygie...@ericsson.com wrote: 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
Re: [bess] ARP ND draft
Hey Tony, Thank you for your comments. Please see in-line. -Original Message- From: Antoni Przygienda antoni.przygie...@ericsson.com Date: Monday, March 30, 2015 at 12:26 AM To: Jorge Rabadan jorge.raba...@alcatel-lucent.com, Erik Nordmark nordm...@acm.org, Henderickx, Wim (Wim) wim.henderi...@alcatel-lucent.com Cc: bess@ietf.org bess@ietf.org 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. Comments inline 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. [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. [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? 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? [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. [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. c)It is worth explaining what the suggested behavior should be when ‘local-bit’ MACs are being
Re: [bess] ARP ND draft
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, bess@ietf.orgmailto:bess@ietf.org, Jorge Rabadan Subject: Re: [bess] ARP ND draft At interface level you get dad in most stacks I know. Sent from my iPhone On 30 Mar 2015, at 06:45, Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net 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) wim.henderi...@alcatel-lucent.commailto:wim.henderi...@alcatel-lucent.com 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 antoni.przygie...@ericsson.commailto:antoni.przygie...@ericsson.com wrote: 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 -Original Message- From: Henderickx, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.commailto:wim.henderi...@alcatel-lucent.com] Sent: Thursday, March 26, 2015 6:01 AM To: Antoni Przygienda; Erik Nordmark; Rabadan, Jorge (Jorge) Cc: bess@ietf.orgmailto:bess@ietf.org Subject: Re: [bess] ARP ND draft For this case you should sent a GARP with the new MAC/IP On 25/03/15 18:56, Antoni Przygienda antoni.przygie...@ericsson.commailto:antoni.przygie...@ericsson.com wrote: 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? 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 ___ BESS mailing list BESS@ietf.orgmailto:BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
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. RFC1546 is rather too old to consider here as solution :) Cheers, R. On Mon, Mar 30, 2015 at 1:10 AM, Henderickx, Wim (Wim) wim.henderi...@alcatel-lucent.com 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. From: Henderickx, Wim Henderickx Date: Monday 30 March 2015 07:38 To: Robert Raszuk Cc: Erik Nordmark, Antoni Przygienda, bess@ietf.org, Jorge Rabadan Subject: Re: [bess] ARP ND draft At interface level you get dad in most stacks I know. Sent from my iPhone On 30 Mar 2015, at 06:45, Robert Raszuk rob...@raszuk.net 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) wim.henderi...@alcatel-lucent.com 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 antoni.przygie...@ericsson.com wrote: 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 -Original Message- From: Henderickx, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.com] Sent: Thursday, March 26, 2015 6:01 AM To: Antoni Przygienda; Erik Nordmark; Rabadan, Jorge (Jorge) Cc: bess@ietf.org Subject: Re: [bess] ARP ND draft For this case you should sent a GARP with the new MAC/IP On 25/03/15 18:56, Antoni Przygienda antoni.przygie...@ericsson.com wrote: 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? 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 ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] ARP ND draft
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, bess@ietf.orgmailto:bess@ietf.org, Jorge Rabadan Subject: Re: [bess] ARP ND draft 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, bess@ietf.orgmailto:bess@ietf.org, Jorge Rabadan Subject: Re: [bess] ARP ND draft At interface level you get dad in most stacks I know. Sent from my iPhone On 30 Mar 2015, at 06:45, Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net 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) wim.henderi...@alcatel-lucent.commailto:wim.henderi...@alcatel-lucent.com 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 antoni.przygie...@ericsson.commailto:antoni.przygie...@ericsson.com wrote: 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 -Original Message- From: Henderickx, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.commailto:wim.henderi...@alcatel-lucent.com] Sent: Thursday, March 26, 2015 6:01 AM To: Antoni Przygienda; Erik Nordmark; Rabadan, Jorge (Jorge) Cc: bess@ietf.orgmailto:bess@ietf.org Subject: Re: [bess] ARP ND draft For this case you should sent a GARP with the new MAC/IP On 25/03/15 18:56, Antoni Przygienda antoni.przygie...@ericsson.commailto:antoni.przygie...@ericsson.com wrote: 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? 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 ___ BESS mailing list BESS@ietf.orgmailto:BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] ARP ND draft
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 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 Twainhttp://www.brainyquote.com/quotes/quotes/m/marktwain393535.html From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk Sent: Monday, March 30, 2015 1:19 AM To: Henderickx, Wim (Wim) Cc: Erik Nordmark; Antoni Przygienda; bess@ietf.org; 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. RFC1546 is rather too old to consider here as solution :) Cheers, R. On Mon, Mar 30, 2015 at 1:10 AM, Henderickx, Wim (Wim) wim.henderi...@alcatel-lucent.commailto:wim.henderi...@alcatel-lucent.com 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. From: Henderickx, Wim Henderickx Date: Monday 30 March 2015 07:38 To: Robert Raszuk Cc: Erik Nordmark, Antoni Przygienda, bess@ietf.orgmailto:bess@ietf.org, Jorge Rabadan Subject: Re: [bess] ARP ND draft At interface level you get dad in most stacks I know. Sent from my iPhone On 30 Mar 2015, at 06:45, Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net 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) wim.henderi...@alcatel-lucent.commailto:wim.henderi...@alcatel-lucent.com 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 antoni.przygie...@ericsson.commailto:antoni.przygie...@ericsson.com wrote: 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 -Original Message- From: Henderickx, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.commailto:wim.henderi...@alcatel-lucent.com] Sent: Thursday, March 26, 2015 6:01 AM To: Antoni Przygienda; Erik Nordmark; Rabadan, Jorge (Jorge) Cc: bess@ietf.orgmailto:bess@ietf.org Subject: Re: [bess] ARP ND draft For this case you should sent a GARP with the new MAC/IP On 25/03/15 18:56, Antoni Przygienda antoni.przygie...@ericsson.commailto:antoni.przygie...@ericsson.com wrote: 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? 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 ___ BESS mailing list BESS@ietf.orgmailto:BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess ___ BESS mailing list BESS@ietf.org
[bess] ARP ND draft
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 Twainhttp://www.brainyquote.com/quotes/quotes/m/marktwain393535.html ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
