IETF Logo Mail Archive

Re: [bess] Resolutions on draft-snr-bess-evpn-loop-protect &

<slitkows.ietf@gmail.com> Mon, 14 October 2019 09:47 UTC

Return-Path: <slitkows.ietf@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC8712018B; Mon, 14 Oct 2019 02:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfTNlqINjlYX; Mon, 14 Oct 2019 02:47:39 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657D112016E; Mon, 14 Oct 2019 02:47:39 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id v8so14250452eds.2; Mon, 14 Oct 2019 02:47:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=u4XK833lG2J/b36cXymbzkHNcttDECjnO8Gxa3NPVpU=; b=fBUjcHHYYiCAFYx14h86sLbHXEktqFLqEkUPmIlnori8QOmDLgeiRlzHnCgbkLnS+Z UQ7YLtd4siheIqUX7gVXzf9ZK0r6cWx8pYGYGuTlxA1lUECvfb5BK+W3v739Vr8cmPtP f0LmTW4r7+HgMBoM1YmwbDrCG+kQNVG/hGocVOLEH3OIm/e9AnaXB5Mf7FnlQe228+gh MLz7oW/87sKZBrYYgX6DqnQ7c9l84Z4FL3ZZhbX0/pSURFsASRHDNWjE5QkwOHqVfIZj M94/5fZG/0htM4lzJdL6NX8mWGXGmVCeHBwKvBu7TKjqF8nzN2tez3urjtvv3kuZ0Lfh RBkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=u4XK833lG2J/b36cXymbzkHNcttDECjnO8Gxa3NPVpU=; b=q7VTt148GfLbIWJubHjuqoZYDnHcR771MvjoXv65xtsqpHVOWpHynAwkWYVseALq+m 9Dpo31faJ6lENUebVpe9/ebmfR52EDme/OFEnuBQvkqJvJk0U8vQrY6rzZVEbISSo20z SujXqX5Dz6dKvu/h5fR+nrHvI0SVowEDKxNdDsIqmoXPs1DKblniyUQQb9X6KqHfRkRh 4f2KQDb2CUC+33cRe3uShXU5+07wnmkvhAjid2PLgMDSiFjrzlFOT4+fsY4Ny53eIpws NmLtpWItjXtjhbW28tPA4G4qNkOcRlvTGZZMRr2G0KVsvI7LnB5Q1ZlmPsuMXDqTEb65 mNbQ==
X-Gm-Message-State: APjAAAV48Q+p4LvMXwVplmuTfB6eBJ5wisvZwMEYzy3uib6ZtzRuU9UL OIcOIDmlDMjdfS7hXU7QH85/ngQ=
X-Google-Smtp-Source: APXvYqzGA1MWzJ+qYtl6nwG8E6Plav9sgfC2eulQV0W4eZxAYnbuwhoV9x+8dHRdWSBJHO3ivehOvg==
X-Received: by 2002:a17:906:360e:: with SMTP id q14mr27236965ejb.313.1571046457749; Mon, 14 Oct 2019 02:47:37 -0700 (PDT)
Received: from SLITKOWS3YYU6 ([2001:420:c0c0:1002::61]) by smtp.gmail.com with ESMTPSA id r16sm3060990eds.72.2019.10.14.02.47.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Oct 2019 02:47:37 -0700 (PDT)
From: slitkows.ietf@gmail.com
To: "'Ali Sajassi (sajassi)'" <sajassi@cisco.com>, bess-chairs@ietf.org, bess@ietf.org
Cc: "'Rabadan, Jorge (Nokia - US/Mountain View)'" <jorge.rabadan@nokia.com>
References: <93419492-F230-4744-82C7-8C1C2B5AA495@cisco.com>
In-Reply-To: <93419492-F230-4744-82C7-8C1C2B5AA495@cisco.com>
Date: Mon, 14 Oct 2019 11:47:35 +0200
Message-ID: <012201d58274$69209d60$3b61d820$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0123_01D58285.2CA9E290"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJCrFQBoMYlnoFJeoOKNwTgkHVeR6Z/j0dw
Content-Language: fr
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/te-pYLWXImr3MuZc7SHSgDz-rwg>
Subject: Re: [bess] Resolutions on draft-snr-bess-evpn-loop-protect &
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Oct 2019 09:47:42 -0000

Hi Folks,

 

Many thanks for these outcomes and resolution.

I’ll add a comment on the datatracker for the loop-protect draft and I’ll proceed with the adoption of the isid-cmacflush.

 

 

Stephane

 

From: Ali Sajassi (sajassi) <sajassi@cisco.com> 
Sent: samedi 12 octobre 2019 02:32
To: bess-chairs@ietf.org; bess@ietf.org
Cc: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>; Ali Sajassi (sajassi) <sajassi@cisco.com>
Subject: Resolutions on draft-snr-bess-evpn-loop-protect & 

 

 

Hi Stephane, 

 

 

Jorge and I had a meeting to discuss our comments on the following two drafts that are going through WG call: 

 

 <https://tools.ietf.org/html/draft-snr-bess-pbb-evpn-isid-cmacflush-06> https://tools.ietf.org/html/draft-snr-bess-pbb-evpn-isid-cmacflush-06

 <https://datatracker.ietf.org/doc/draft-snr-bess-evpn-loop-protect/> https://datatracker.ietf.org/doc/draft-snr-bess-evpn-loop-protect/

 

and reached the following resolutions:

 

On isid-cmacflush, we agreed to proceed with this draft and since we don’t want to have two separate solutions for I-SID flushing in PBB-EVPN, we decided to remove the section on I-SID flushing in virtual-eth-segment. The main factor for this decision was the fact that isid-cmacflush draft has been implemented by at least one vendor; whereas, the isid flusing section in virtual-eth-segment draft has not been implemented by any vendor to best of our knowledge even though the draft at large has been implemented by many vendors. If any of the co-authors or WG individual has any comment about this, please speak up, otherwise we’ll remove the appropriate section.

 

On loop-protect draft, we agreed on holding its WG adoption at this time and extend mac mobility in rfc7432bis to cover loops. The main factor for this decision was the fact that the detection mechanism for loop-protect draft is the same as mac-duplicate detection mechanism in section 15.1 of RFC 7432. So, we agreed we can build based on that and add some paragraphs to describe the action of loop protection. Once rfc7432bis is out, we would like to encourage people to read it and, unless there is feedback against it, the loop-protect draft will be abandoned. If there is feedback stating 7432bis is not enough for loop protection, at that time we can discuss if the loop-protect draft needs to be resumed and extended or if a new draft is needed.

 

Regards,

Ali & Jorge

v2.23.0 | Report a Bug | By Email