Re: [bess] handling DAD in draft-ietf-bess-evpn-inter-subnet-forwarding-05
On 1/31/19, 1:39 AM, "Sowmini Varadhan" wrote: On Wed, Jan 30, 2019 at 9:20 PM Ali Sajassi (sajassi) saja...@cisco.com wrote: sajassi> AS> RFC 7431 has procedures for duplicate MAC address detection. rfc 7431 is the Informational RFC titled "Multicast-Only Fast Reroute". Perhaps you mean rfc 7432. And I suspect you mean Section 15.1 draft*evpn-inter-subnet-forwarding should call out this cross-reference explicitly, so that the reader does not have to speculate (as I just did) AS>> I will call out the reference explicitly. sajassi> AS> If ARP probing is done before the target NVE gets to declare that the TS has moved, then the MAC move is delayed unnecessarily for ALL the legitimate MAC move cases which in turn can cause some loss of traffic and degradation in service. It should be noted that the MAC move procedures in here is consistent with RFC 7432. sajassi> AS> same reply as above. it's a bit odd that lot of chaos can happen for approx 3 mins when there is actually a duplicate address (created accidentally or maliciously) but I suppose you could say that this is already based on 7431, so not something introduced by draft*evpn-inter-subnet-forwarding AS>> That's correct. The important thing is the detection of such duplication and avoid re-advertisements of MAC addresses as specified in RFC 7432. Cheers, Ali Thanks --Sowmini ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] handling DAD in draft-ietf-bess-evpn-inter-subnet-forwarding-05
On Wed, Jan 30, 2019 at 9:20 PM Ali Sajassi (sajassi) saja...@cisco.com wrote: sajassi> AS> RFC 7431 has procedures for duplicate MAC address detection. rfc 7431 is the Informational RFC titled "Multicast-Only Fast Reroute". Perhaps you mean rfc 7432. And I suspect you mean Section 15.1 draft*evpn-inter-subnet-forwarding should call out this cross-reference explicitly, so that the reader does not have to speculate (as I just did) sajassi> AS> If ARP probing is done before the target NVE gets to declare that the TS has moved, then the MAC move is delayed unnecessarily for ALL the legitimate MAC move cases which in turn can cause some loss of traffic and degradation in service. It should be noted that the MAC move procedures in here is consistent with RFC 7432. sajassi> AS> same reply as above. it's a bit odd that lot of chaos can happen for approx 3 mins when there is actually a duplicate address (created accidentally or maliciously) but I suppose you could say that this is already based on 7431, so not something introduced by draft*evpn-inter-subnet-forwarding Thanks --Sowmini ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] handling DAD in draft-ietf-bess-evpn-inter-subnet-forwarding-05
Please refer to my reply inline marked with "AS>"
On 9/17/18, 3:47 PM, "BESS on behalf of Sowmini Varadhan"
wrote:
hi,
I have a question about Section 4.1.1 ("Initiating an APR Request upon a
Move")
in draft-ietf-bess-evpn-inter-subnet-forwarding-05 which has the paragraph:
"Since this NVE has previously learned the same MAC and IP addresses
from the source NVE, it recognizes that there has been a MAC move and
it initiates MAC mobility procedures per [RFC7432] by advertising an
EVPN MAC/IP route with both the MAC and IP addresses filled in along
with MAC Mobility Extended Community with the sequence number
incremented by one."
but the Grat ARP may be an indication of a duplicate address, or it
may have been manufactured by a malicious node, in which case this is not
a mac-move.
Should the target NVE first check with the src NVE that the
original (ip, mac) binding does not exist at the source NVE
before advertising the MAC route?
AS> RFC 7431 has procedures for duplicate MAC address detection.
The next paragraph in Section 4.1.1 says
"The source NVE upon receiving this MAC/IP advertisement, realizes
that the MAC has moved to the target NVE. It updates its MAC-VRF and
IP-VRF table accordingly with the adjacency information of the target
NVE and withdraws its EVPN MAC/IP route. Furthermore, it sends an ARP
probe locally to ensure that the MAC is gone and it deletes its ARP
entry corresponding to that when there is no ARP response."
One minor nit here is that the ARP probe should really check that
the IP address is gone (i.e. the IP address is not duplicate),
and this check should be done *before* the target NVE gets to declare
that the TS has moved?
AS> If ARP probing is done before the target NVE gets to declare that the TS
has moved, then the MAC move is delayed unnecessarily for ALL the legitimate
MAC move cases which in turn can cause some loss of traffic and degradation in
service. It should be noted that the MAC move procedures in here is consistent
with RFC 7432.
(same thing for section 4.1.2, where the target NVE learns the
at the new location from the data packet without an
intervening GARP)
AS> same reply as above.
Thanks
--Sowmini
___
BESS mailing list
BESS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=7BzJkC9LubpFLLA9w_G3DK1kNzgduhVEcOWaw7e3qaw&s=afaJR-F-EDZgb60cwn8DLxnZNeRUtBoT4GbCGfk5B8I&e=
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
