Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

Krzysztof Szarkowicz <> Wed, 08 August 2018 17:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C46A6130EAC for <>; Wed, 8 Aug 2018 10:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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] 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 UdltSGRHI-lE for <>; Wed, 8 Aug 2018 10:55:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2043012D7F8 for <>; Wed, 8 Aug 2018 10:55:48 -0700 (PDT)
Received: by with SMTP id z8-v6so1432978pgu.8 for <>; Wed, 08 Aug 2018 10:55:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Q+UplWMg6thS0MtZheNTiVcxBn5bYr4F3kPRDqWr3Lo=; b=TOsN8EzlEjUTJdrSnSkkTVhild7HcqaloEUeg9oE4lwlrZ7qH6NPeNt24nkoIVIf+7 jEcHTwUekfE4fv77pwg4mQ52SUITmkWocMCCXKfKRxWT3yEVXW6q/3Tg3USJKmOszYuZ p+YwCl4SyS9Mm203CH6prIxFLrCr4RC7RfIojBRrFU42jOFRzf2+3+Q0NsUZ+eyi70RQ zS6fBysbrR2WYk3zNB3V6IjY396nGivospNGfHZafjG8TX2fly5irf/Umb1pe2bUncJH 9UzMsRi0B1P9D8H7VNPF5anhwJB3iZxQ+ePxR1a/+2xb1r8+jkYe1NFLpKOnA6cTTYMq OMRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Q+UplWMg6thS0MtZheNTiVcxBn5bYr4F3kPRDqWr3Lo=; b=rQhWhTwSvD3edPFwIXh5ylgqXQWkG8xQcB2bA+IlEIBm4ep660h4YwHqreGKyrwQfW RRydFB8qenCpVj1bAbD6dJ/GqS1mqTLXqqLzrvXEs5hAkwq3/bVEIwtCmuG/WfgLvnH5 mI1KnVkLJJ84LPm4WKFjYorMNRD82EcY1ASZz2q7Vc3KLOuHY4YZgWKb/33lqnSo8nHL zWVpdRLr4xVQnpukLPphssX1x4DEFMnAtScQnywLbVpBCQEDATuFOs+Q3UGhybaVktIJ DIaa/qeLyvxS+Q2elNHZrjk/Es057/b+8eGWLuL/2Mu8ESyaxZuUqySTigbVqbkhaQ42 iFoQ==
X-Gm-Message-State: AOUpUlG1IXunPWZEfVjWnJ1/o5nHVm6SrnmmHXZ5HhAJuocw80DlFPJw /3l1TVp5kxHvB1t3Wo7N6ZLz9htD
X-Google-Smtp-Source: AA+uWPwsMOQFdJ1kXTUzgPxa3SO9Sg75OeCdKBj0AB8QFoJEeq/vNVaI8kvpgCzsfYjBcsfroHyvqg==
X-Received: by 2002:a63:e14a:: with SMTP id h10-v6mr3594338pgk.358.1533750946956; Wed, 08 Aug 2018 10:55:46 -0700 (PDT)
Received: from ([]) by with ESMTPSA id l10-v6sm80997pfj.179.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Aug 2018 10:55:45 -0700 (PDT)
From: Krzysztof Szarkowicz <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_96C457CA-E6EF-45CE-A22B-3C0D0A2B3D97"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 08 Aug 2018 19:55:41 +0200
In-Reply-To: <9216_1533737011_5B6AF833_9216_196_1_9E32478DFA9976438E7A22F69B08FF924B2291F9@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
To: "" <>
References: <9216_1533737011_5B6AF833_9216_196_1_9E32478DFA9976438E7A22F69B08FF924B2291F9@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05
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, 08 Aug 2018 17:55:51 -0000

Hello working group,

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 ND 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, presuming that TS sends ARP request to resolve only anycast IP is not fully correct, I believe. Thus, wording of this paragraph should cover two cases (NS/ARP request to resolve anycast, and NS/ARP request to resolve 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 the payload)
* Target hardware address (in the payload)

It is not ultimately clear from the text, if 'Source MAC (in Ethernet header)’ or 'Sender hardware address (in the payload)’, or both, 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 (depending, which IP address is being resolved), 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, which explicitly disables usage of V-MAC in the 'Source MAC (in Ethernet header)’), 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-Aug-08, at 16:03, wrote:
> Hello working group,
> This email starts a two-week Working Group Last Call on draft-ietf-bess-evpn-inter-subnet-forwarding-05 [1].
> A significant amount of update has been introduced since the previous WGLC. Please review the updates and provide your feedback.
> This poll runs until *the 22th of August*.
> Thank you
> Stéphane, Matthew
> bess chairs
> [1] <>
> _________________________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> _______________________________________________
> BESS mailing list
> <>
> <>