IETF Logo Mail Archive

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

Greg Mirsky <gregimirsky@gmail.com> Thu, 17 December 2020 03:15 UTC

Return-Path: <gregimirsky@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 22F113A13C6; Wed, 16 Dec 2020 19:15:29 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 (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 JcLNVUG_TL-W; Wed, 16 Dec 2020 19:15:27 -0800 (PST)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 08BFB3A13C4; Wed, 16 Dec 2020 19:15:26 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id s26so19062266lfc.8; Wed, 16 Dec 2020 19:15:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vvShFrRvfFIJrgSpYrxzxQgLhSzvJ7CccmHISK9qDbM=; b=os4iO0HtMDglBs22G7IBm54JGif5rUEBKl5GcsHB0/K06xbPNYSsPwWveS5DR1yNfN IAR98Bs5GD7D7dVqC4WcDVhtTT8GCd9ZJHXKxmZyjVS33/JsmjY6A0fP9p0mys4tuaRQ Mz3tEWhZHRYwf8ACCfZ5WgFECbgrunHl1c3BVGVHWNbyslnbSgnRoT2ujGvytTmntrDl imNXLHSyIA5nTAccWuNO3yIj6O5nrY0ZqzySdzuB0M28K4yJ7TZVHd2Mgyf2bZVyUq4U t7USeSTEAf/eCjUbqu/TVLp7oCWO47vYdS8eZCwIXwvxmrT2iYIiqy/ndkT/JNbPMkrJ Bjuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vvShFrRvfFIJrgSpYrxzxQgLhSzvJ7CccmHISK9qDbM=; b=lV/Vevk4WZ4D5JTjvVflCalqXquhcXDdnsOero5Cb+z2C3hp8jRFIKRKGIj04tNDJQ fajg6MAheclM0+qyT3exFB+vSL2t5AiJIsPDI7Ku3NdVqPolKD7qpA+94GAJHr0CTHO9 DSaZEUqwMXDYDFkmOu0FUbKqcSRlSQfSd77w6kbhH1bzJzr0pjWp62ETfEHc4kn4idjA 91j93awz9j2WPPgTBRSuyEfN7Mpfo7kstZrTi1Cdf6iY/hMkZY/zpcTp3fi4IW7K8Doh lNdeLzphE/ICqJ+4ZK4urgCCOkSYYHHzOGUzVz4YcGeHgDgD5kaV6dkKEVr4QUV97aDa 3iSQ==
X-Gm-Message-State: AOAM532RJCivTQi/QIYjlFFE3u0Bg/kJJitH8DN4oePGhvvxvR2dDiJv 8xRTwICJ4uRbreMWoekVep7ca8UqMZBC6OVW10s=
X-Google-Smtp-Source: ABdhPJz0hB3jSFv8Tx1fe7PPKOZ6re63zH3HwxKgR/BLcfcDwqH+vHgOh2niggXvDZFw3Wzl5rxA+nKFItHWXx4sNrI=
X-Received: by 2002:a2e:a494:: with SMTP id h20mr16437534lji.145.1608174924690; Wed, 16 Dec 2020 19:15:24 -0800 (PST)
MIME-Version: 1.0
References: <160815830525.25925.2762690018830484963@ietfa.amsl.com>
In-Reply-To: <160815830525.25925.2762690018830484963@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 16 Dec 2020 19:15:13 -0800
Message-ID: <CA+RyBmWBut-r-28FErFfsQu3TzgjWO1Us=x=JOh2YPAqXQ-mug@mail.gmail.com>
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>
Content-Type: multipart/alternative; boundary="0000000000001f792e05b6a06704"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/B2zzrygtfs46YLlOutwNwb7_Ziw>
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 03:15:29 -0000

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> 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].

v2.23.0 | Report a Bug | By Email