Re: [bess] I-D Action: draft-ietf-bess-evpn-inter-subnet-forwarding-05.txt

Krzysztof Szarkowicz <> Wed, 18 July 2018 22:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 305021311FB for <>; Wed, 18 Jul 2018 15:30:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hBPk0uw1pUky for <>; Wed, 18 Jul 2018 15:30:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A4C141311F5 for <>; Wed, 18 Jul 2018 15:30:32 -0700 (PDT)
Received: by with SMTP id r1-v6so2626494pgp.11 for <>; Wed, 18 Jul 2018 15:30:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=NODcXoYNJX1tUPaUWsK1dZaO/5gtczXy7u2BLnpiuKg=; b=gGUDm2Qi565r4SB1qo8YRgDW+HcW0mHST3ps+s2EX8re65tcTo/e+1I7XncbvWbgsF zO3v13E2DI1xnvqXcxiVqiUV0UQj9U4Cuu1puZRf51k3z5GOtPRKUlPzQob6uQCWroAy Pjb2rVDyjl1bztuSNWckvYX0SpQMDt8Ow2eIArb1WiO7HW7U/H22CdjuspZa3wOsapC2 nVyEl3MXqWTRihUIG3r9sQx4nGEHfR40CWORpGQvfS2Q2tnJpfsPA7dS6sPca+g+tbOZ jcro7jTcVZ8upSJr6myaGDSsonvBqQP/bwK2KGaUO+BwUV/R/BRegVehE1OqVXtS1SQU r9EA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=NODcXoYNJX1tUPaUWsK1dZaO/5gtczXy7u2BLnpiuKg=; b=a8cgHlvfCxWChPgNPloMBymbIN3vvGTAwTu1IhhvkIUNDPZHBzQpONvXhRHJEfEbXS Ib1PP87uycpHwCjBt/+ixpVvzAM4pJRGQQbn/w02BPex9feiqd5Pb89IjoCKMrEilg+o gwNGgK2MJlEhbGd7YUm4PQ4g0rxBwFgYlKlaIjn7UPoGTg2W/vNRfi3PQl3fUtL5vhOt cXaRZYhUSxXEcTaP5zCUZzC9ofs9yqb4AYcDD+1FSrPes/6IsQJNbaOV8h6sl3uyWdze 51aBUcu5yUV7FyIscPXhp+CvgU1tZ5Bd9N3x26eKQTzwIleML/8PUXsXdDX/zQF6Zyp5 MmPw==
X-Gm-Message-State: AOUpUlGS/ATEUsig8QaEShBjTtXMg7+Ra//21BxDofNFW//a4Iye92zF DImeBgqMUTbbgNq7yoYWeIq1Zfx2
X-Google-Smtp-Source: AAOMgpcmW4lqGuvp4XfFzLJXzR99t49llkC2giJVdfW1T8tZ2P0nv++HXCMywv+tBuSoB9km7O4/2A==
X-Received: by 2002:a65:6086:: with SMTP id t6-v6mr7602387pgu.424.1531953031499; Wed, 18 Jul 2018 15:30:31 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id r71-v6sm12630406pfg.43.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jul 2018 15:30:29 -0700 (PDT)
From: Krzysztof Szarkowicz <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_51EEBCF6-5EB3-4FA1-99FB-6F8AE904D006"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 19 Jul 2018 00:30:24 +0200
References: <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [bess] I-D Action: draft-ietf-bess-evpn-inter-subnet-forwarding-05.txt
X-Mailman-Version: 2.1.27
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: Wed, 18 Jul 2018 22:30:36 -0000


I have two comments regarding section 3.1.

* Section 3.1. refers only to “ARP” or “ARP reply”. Given the fact, it is applicable to IPv6 as well, it should refer to NDP NS/NA messages as well, I believe.

* In the last paragraph of Section 3.1:

>  Irrespective of using only the anycast address or both anycast and
   non-anycast addresses on the same IRB, when a TS sends an ARP request
   to the PE that is attached to, the ARP request is sent for the
   anycast IP address of the IRB interface associated with the TS's
If both anycast and non-anycast addresses are on the IRB, it is legitimate that TS sends NS/ARP request to resolve either anycast (e.g. to resolve IP address of default gateway configured on TS), or to resolve non-anycast (e.g. ping towards non-anycast address was initiated on TS). Therefore, wording of this paragraph should cover these cases (NS/ARP request to resolve both anycast/non-anycast IP).

>> the PE1 sends an ARP reply with the MACx which is the anycast
   MAC address of that IRB interface.
NA/ARP reply has multiple MAC related fields:

* Destination MAC (in Ethernet header)
* Source MAC (in Ethernet header)
* Sender hardware address (in ARP payload)
* Target hardware address (in ARP payload)

It is not ultimately clear from the text, if 'Source MAC (in Ethernet header)’ or 'Sender hardware address (in the payload)’ should be populated with MACx. As I see it, in case of both anycast and non-anycast address is used on IRB, the behavior should be:

* TS sends and NS/ARP request for the anycast address:
   -> PE sends and NA/ARP reply with anycast MAC in both 'Source MAC (in Ethernet header)’ and 'Sender hardware address (in the payload)’ fields

* TS sends and NS/ARP request for the non-anycast address:
   -> PE sends and NA/ARP reply with non-anycast MAC in both 'Source MAC (in Ethernet header)’ and 'Sender hardware address (in the payload)’ fields

Otherwise, if only 'Sender hardware address (in the payload)’ is populated with anycast/non-anycast MAC, and 'Source MAC (in Ethernet header)’  is always populated with no-anycast MAC (in implementations mimicking RFC 5798, Section 8.1.2/8.2.2/8.2.3 behavior), the L2 domain (L2 switches) between PE and CE will not learn anycast MAC, thus resulting in unknown unicast flooding being used on these switches to reach anycast MAC. This is undesirable behavior and should be avoided. 


> On 2018-Jul-18, at 20:57, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
>        Title           : Integrated Routing and Bridging in EVPN
>        Authors         : Ali Sajassi
>                          Samer Salam
>                          Samir Thoria
>                          John E. Drake
>                          Jorge Rabadan
> 	Filename        : draft-ietf-bess-evpn-inter-subnet-forwarding-05.txt
> 	Pages           : 33
> 	Date            : 2018-07-18
> Abstract:
>   EVPN provides an extensible and flexible multi-homing VPN solution
>   over an MPLS/IP network for intra-subnet connectivity among Tenant
>   Systems and End Devices that can be physical or virtual. However,
>   there are scenarios for which there is a need for a dynamic and
>   efficient inter-subnet connectivity among these Tenant Systems and
>   End Devices while maintaining the multi-homing capabilities of EVPN.
>   This document describes an Integrated Routing and Bridging (IRB)
>   solution based on EVPN to address such requirements.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> BESS mailing list