Re: [bess] Roman Danyliw's No Objection on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)

Roman Danyliw <rdd@cert.org> Thu, 17 December 2020 14:10 UTC

Return-Path: <rdd@cert.org>
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 4FE2B3A0876; Thu, 17 Dec 2020 06:10:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 (1024-bit key) header.d=cert.org
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 Vs_7pAqzBu3Y; Thu, 17 Dec 2020 06:10:23 -0800 (PST)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 563B33A0880; Thu, 17 Dec 2020 06:10:23 -0800 (PST)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0BHEALvu005868; Thu, 17 Dec 2020 09:10:21 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 0BHEALvu005868
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1608214221; bh=TT+VYVtYb2CBWlxmHBFf+QVlMTMd1OpfmmkZPNX16Oo=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Xh6YOjl3yDaLoGJUZlVb/cM4hB1nacMXfQQ4ff36vQn7iz1rcaEbP7hdapUm5IWJ1 JN40l5AG4RyezISWwSuqFAq0SoiEE68YzmEOxUq9pIf2Rcu3iCAZXAcTYygL4d22uY if0s/VEK7QkpGS3pxHkEalDbWQ7Q8pd9TibLXT4E=
Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0BHEAGdo044184; Thu, 17 Dec 2020 09:10:16 -0500
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 17 Dec 2020 09:10:16 -0500
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Thu, 17 Dec 2020 09:10:16 -0500
From: Roman Danyliw <rdd@cert.org>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-bess-mvpn-fast-failover@ietf.org" <draft-ietf-bess-mvpn-fast-failover@ietf.org>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, BESS <bess@ietf.org>, Stephane Litkowski <slitkows.ietf@gmail.com>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)
Thread-Index: AQHW0/wz4wGjjhSIe0+A1ZnT2fODQKn68YSAgABjArA=
Date: Thu, 17 Dec 2020 14:10:14 +0000
Message-ID: <dc3e36bd1aab47f3b6a7e864e8215c1c@cert.org>
References: <160815830525.25925.2762690018830484963@ietfa.amsl.com> <CA+RyBmWBut-r-28FErFfsQu3TzgjWO1Us=x=JOh2YPAqXQ-mug@mail.gmail.com>
In-Reply-To: <CA+RyBmWBut-r-28FErFfsQu3TzgjWO1Us=x=JOh2YPAqXQ-mug@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.202.251]
Content-Type: multipart/alternative; boundary="_000_dc3e36bd1aab47f3b6a7e864e8215c1ccertorg_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/IbX3RG7bAI6jtdkI_M6z_1tnoqY>
Subject: Re: [bess] Roman Danyliw's No Objection on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)
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: Thu, 17 Dec 2020 14:10:25 -0000

Hi Greg!

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Wednesday, December 16, 2020 10:15 PM
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <iesg@ietf.org>; draft-ietf-bess-mvpn-fast-failover@ietf.org; bess-chairs@ietf.org; BESS <bess@ietf.org>; Stephane Litkowski <slitkows.ietf@gmail.com>
Subject: Re: Roman Danyliw's No Objection on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)

Hi Roman,
thank you for the review and the comment. Please find the proposed update below under the GIM>> tag.

Regards,
Greg

On Wed, Dec 16, 2020 at 2:38 PM Roman Danyliw via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-bess-mvpn-fast-failover-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Daniel Migault for the SECDIR review

I support Ben and Alvaro's DISCUSS positions.

One editorial nit from Section 3.1.6:

An implementation that does not recognize
   or is configured not to support this attribute MUST follow procedures
   defined for optional transitive path attributes in Section 5 of
   [RFC4271].

It seems odd to be specifying normative language for implementations that do
not/will not understand this specification.  I appreciate that this MUST is
coming from RFC4271.
GIM>> Indeed, sounds illogical. Would an updated text be acceptable:
   This document defines the format and ways of using a new BGP
   attribute called the "BFD Discriminator".  It is an optional
   transitive BGP attribute.  Thus it is expected that an implementation
   that does not recognize or is configured not to support this
   attribute follows procedures defined for optional transitive path
   attributes in Section 5 of [RFC4271].

[Roman] That looks good.  Thanks for this clarifying text.

Regards,
Roman