Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

<> Thu, 03 October 2019 13:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A140120870; Thu, 3 Oct 2019 06:01:22 -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_HELO_NONE=0.001, 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 FiPSMn3iAx82; Thu, 3 Oct 2019 06:01:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A402A12001A; Thu, 3 Oct 2019 06:01:18 -0700 (PDT)
Received: by with SMTP id y72so1703981pfb.12; Thu, 03 Oct 2019 06:01:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=rTMtcBsxIPklnDm9qokHt0mn0J4bR8XRQQKozCL4sTg=; b=Iu71e92wCl9ERT99Wpo8CstDRbUyKjEkerT368vPjFpsFF0iYzTfmd6aeJFvIJmC0B pBbzSgPRLZzvK2QFhu+9FoLv1cPtI4o9fGdMgKpfBnCZjlqfOYf6UMv4tqOvaAhwkleX ZQonMQ6FH6+KPPFBwct21n35Rxz5hbjCt6FEaE3+dlFXndsjwiq+r/6lCM2TGgYLfRo+ nylWMiTOZkD6J70TmvyP5Tr5/eAA5Fmw3J6GXMdiL3uo+rWAyc+a9Bcumg1Yas2KC9d0 cLb9kiaPNosYuYpbBe7xC1eRE9XWNq7qUtQWTEWQGjsTR6onPrebnoKt/3zwqRiEegZm bKiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=rTMtcBsxIPklnDm9qokHt0mn0J4bR8XRQQKozCL4sTg=; b=CelpMBvpS/4HZJvOFbOs/yCD3/OKxgj9JO9vDrgPkWWTK8Er0id185AE534PkGFndd Aya+IWCSxF/NSv2n9IaZLhFAwZltZXB9iq+TLI4lHMB9SVc2CeEt1kkILRWwkPy6fI/Y wkW5uvQ59viFEYgNLjJcY8fgw9+GoP39c5bZnlZ2g6bBvB7TdzqeTcmk3TyGwZGOhf2i wIJIvYSTTqQIF7PTxKniPS1wLtQWpDktIiOB0wxPmkOxco8wA359vkQUoS2V/3+k9U9w /RFAD3hNg1Htd0AflumNnTteN1a8XLu433XsyFjgf4Z3UJ4JTaK0HvW15ILBr8GpZVX2 6L3Q==
X-Gm-Message-State: APjAAAV+zBGtqm3MGgB4AowEa27QTFaW3N7fdvhq7m59J7IjL5Ooa3lp j7whn5Pu+np1TWF7K5DtmhM8Hlg=
X-Google-Smtp-Source: APXvYqyYxuPKCo8dguXfB38jpd0ExOJqdPlt0rls8UQ2S8EPH08a0LYui9MffFFepOu2zHcmqJ3FkQ==
X-Received: by 2002:a63:6c89:: with SMTP id h131mr9668229pgc.322.1570107677576; Thu, 03 Oct 2019 06:01:17 -0700 (PDT)
Received: from SLITKOWS3YYU6 ([2001:420:c0c8:1008::39c]) by with ESMTPSA id h66sm12451874pjb.0.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Oct 2019 06:01:16 -0700 (PDT)
To: "'Rabadan, Jorge (Nokia - US/Mountain View)'" <>, "'Ali Sajassi (sajassi)'" <>,,,
References: <> <>
In-Reply-To: <>
Date: Thu, 03 Oct 2019 06:01:15 -0700
Message-ID: <005501d579ea$a49f9e50$eddedaf0$>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_0056_01D579AF.F8427400"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQH0xxMrL4CXoXyypD911TL/YynUIQHv2CDwpvrHwVA=
Content-Language: fr
Archived-At: <>
Subject: Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect
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, 03 Oct 2019 13:01:23 -0000

Hi all,


This adoption call is running for a long time. The WG adoption was a bit tough or at least unusual.


I hold on this call waiting for a sync-up with my co-chair to decide how we proceed.


We keep you posted asap.





From: Rabadan, Jorge (Nokia - US/Mountain View) <> 
Sent: jeudi 3 octobre 2019 00:51
To: Ali Sajassi (sajassi) <>;;;
Subject: Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect


Hi Ali,


Thank you for your feedback.


The draft is going through a WG adoption call, and although during the first part of the adoption call there was not much feedback, the draft has now fair good support from several Service Providers and vendors. We also got the feedback from a Service Provider that the topic is important enough to deserve a separate document where the WG can throw feedback and can be improved to make sure all cases are covered. So I believe it has to be adopted as an (Informational) WG document. 


When 7432bis is WG adopted (it’s not even published yet!), as a WG we can decide if loop-protection is part of it or not. My co-authors, other WG members and chairs can express their opinion as well.


About backhole mac vs ACL – backhole is more generic. You can implement it via ACL or flags in the bridge table or any other way. We don’t mandate how to do it, only the required behavior. If you do it via an “automatic” ACL, that’s your implementation choice. 


About the timer, it would be good if you can elaborate why it is questionable. We are very interested in your feedback and we would like to encourage the WG to also participate in the discussion, if the WG thinks loops are an important topic.






From: "Ali Sajassi (sajassi)" < <> >
Date: Thursday, October 3, 2019 at 8:17 AM
To: " <> " < <> >, " <> " < <> >, " <> " < <> >
Cc: " <> " < <> >
Subject: Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect
Resent-From: < <> >
Resent-To: < <> >, < <> >, < <> >, < <> >, < <> >
Resent-Date: Thursday, October 3, 2019 at 8:17 AM



We need to cover the loop protection for EVPN as we needed to cover MAC duplicate detection in EVPN. However, I am wondering why not simply cover it in couple of paragraphs in RFC7432bis. I made this comment when this draft was presented for the first time. My rational for it is as follow:


1)      The detection mechanism for loop protection is identical to MAC duplicate detection as described in section 15.1 of RFC 7432. As the matter of fact the procedure described in section 15.1 of RFC 7432 is repeated in this new draft.

2)      The only difference is action taken. For MAC duplicate detection, we stop advertising the learned MAC address; whereas, for loop prevention, we install an ACL for the duplicate MAC.

3)      We should also try to use commonly used terms as opposed to inventing new terms – i.e., instead of creating a new section in describing what blackhole MAC is, we should simply say we want to install ACL for MAC SA (to get discarded). 

4)      The new timer for flushing MAC SA and restarting the process IMO is questionable and should not be used.


Again, if we were not doing RFC7432bis, I would have been very supportive of this draft as we do need to cover loop protection; however, given that we can cover this loop protection by just adding one or two paragraphs to section 15.1, then I really don’t see the need to create unnecessary reading materials for our community.







From: BESS < <> > on behalf of " <> " < <> >
Date: Monday, September 2, 2019 at 7:29 AM
To: " <> " < <> >, " <> " < <> >
Cc: " <> " < <> >
Subject: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect




This email begins a two-weeks WG adoption poll for draft-snr-bess-evpn-loop-protect-04 [1]

Please review the draft and post any comments to the BESS working group list.


We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).


If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document won't progress without answers from all the authors and contributors.

Currently, there are no IPR disclosures against this document.


If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.


This poll for adoption closes on 16th September 2019.  



Stephane and Matthew









Stephane Litkowski 
Network Architect 

Orange Expert Future Networks

phone:  <> +33 2 23 06 49 83  NEW !
mobile:  <> +33 6 71 63 27 50  NEW !


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.