Re: [bess] handling DAD in draft-ietf-bess-evpn-inter-subnet-forwarding-05

"Ali Sajassi (sajassi)" <> Thu, 31 January 2019 02:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C120A131001 for <>; Wed, 30 Jan 2019 18:20:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -19.054
X-Spam-Status: No, score=-19.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OXsx4bzyHgpk for <>; Wed, 30 Jan 2019 18:20:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 48DA3130EE5 for <>; Wed, 30 Jan 2019 18:20:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3954; q=dns/txt; s=iport; t=1548901253; x=1550110853; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ytlJqSJe9JdQES2qKOQb//OEW9dtSJS0lfnoCl1S+1s=; b=MudeyXJLS7aQs49OAc6g6ktfGMNw0XgFgURCcYCPf8X4wrUotKfJjXrT XwwBZc62bE/EdwomR392mIUFVkWeOPZxPjpoKWZ22OHb0TbK7H+u9mPHj yhaCc79M5Whiw3Vu9sKtDrLJW32SsTIwZLBEDhqPnbMx+EEiLvwyj4nmG 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.56,542,1539648000"; d="scan'208";a="233082411"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2019 02:20:52 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id x0V2Kpb5025142 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Jan 2019 02:20:52 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 30 Jan 2019 21:20:51 -0500
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Wed, 30 Jan 2019 21:20:51 -0500
From: "Ali Sajassi (sajassi)" <>
To: Sowmini Varadhan <>, "" <>
CC: John E Drake <>, "Samir Thoria (sthoria)" <>, Sowmini Varadhan <>, "" <>, "sslam(mailer list)" <>
Thread-Topic: [bess] handling DAD in draft-ietf-bess-evpn-inter-subnet-forwarding-05
Thread-Index: AQHUTth9DYwQe3Tt8kuuiLpnlPC+DaXJRy4A
Date: Thu, 31 Jan 2019 02:20:51 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-Auto-Response-Suppress: DR, OOF, AutoReply
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [bess] handling DAD in draft-ietf-bess-evpn-inter-subnet-forwarding-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Jan 2019 02:21:00 -0000

Please refer to my reply inline marked with "AS>"

On 9/17/18, 3:47 PM, "BESS on behalf of Sowmini Varadhan" < on behalf of> wrote:

    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 <IP, MAC> 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
    <IP, MAC> at the new location from the data packet without an
    intervening GARP)

AS> same reply as  above.
    BESS mailing list