Re: [GROW] AD Review of draft-ietf-grow-bmp-local-rib

Warren Kumari <warren@kumari.net> Wed, 24 February 2021 23:18 UTC

Return-Path: <warren@kumari.net>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE603A1D3D for <grow@ietfa.amsl.com>; Wed, 24 Feb 2021 15:18:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.656
X-Spam-Level:
X-Spam-Status: No, score=-0.656 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, 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=kumari-net.20150623.gappssmtp.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 CKBSRYDpFgWp for <grow@ietfa.amsl.com>; Wed, 24 Feb 2021 15:18:13 -0800 (PST)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 2C8DD3A1D3C for <grow@ietf.org>; Wed, 24 Feb 2021 15:18:12 -0800 (PST)
Received: by mail-lf1-x12d.google.com with SMTP id z11so5661166lfb.9 for <grow@ietf.org>; Wed, 24 Feb 2021 15:18:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RbGlQdwDU7Vr6iKfxnukq5JewAoxmJxv4xgQlEDn7Yc=; b=W9CS5jbYNXJ+Nd++AA2BtnBspv0nu9KkBVOWFCSREWXTD0IGIklBOPEdASw8R6UjRH yRhOt1qkNdpo2RXdEKQC+nAyq467qHQfT6nwBQLJ2l3ZmPlsZRfmCmmzj+amHAKDdP5G kcl3ENqTb9I7XEMC+bPu/qHkGzGKjqeSS/4ZDQ/mBICU32MVMldp5pjxvLcsTxowco1m 71rPu/ufHrcIbSK8mRGgYc9PTZSoBzWibAMCJo6Z/B0Sg4Krk0jU23RHVrxxBPi5+bMb eGBQMxWUQvCtEiz+BcfHTATnBkOwxPR4eLwu94v56t51Ayly8oggoMs5E9s0fnIR+cn5 Gt0Q==
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=RbGlQdwDU7Vr6iKfxnukq5JewAoxmJxv4xgQlEDn7Yc=; b=mHUVW4yWJIMF1q9Fn9quMJONioYuD3qmS5BNtRhxp8tYoiQp517BKyNwjKZfFPLxad Q0lO2HA7b52OsHc/kbODOOs+1SeS0GCXO8TPaaCly3qtZdjI/bSNHd4agbMMyqzcVnse Rwl8SeCGzEDC7fNOyPIS6P4nzsSMrfzpCTGl7ajmVXE7iRr29IGliZmP9iUKHgpW2gYe /ymscg3/6umXS/lrNdfIXUUvHb4QhZpAEW2YjF3f6NgRTliX55cP20dz/Hjz3kxmBsBh 9Kui+OZLULuRirCXWwxIj2WArAG6CJa3T827xam/AcFD0FNUD/MO7BDT00nm+nLzhjLD wz5w==
X-Gm-Message-State: AOAM533ryTz+nR1iqDxGvo5VZYPQNr/3u9Dcw/SNPTYY1qA9/927UGp3 T40cVWLjgxOCSQ3Vvnb0siUehzRUOEqnz6Ak5vwlfA==
X-Google-Smtp-Source: ABdhPJzxMpp0KyTGcccN7a9mjm8VKlykHC3cdSIIKAlqc6MIxS5Z6IC+ZYI0O4s8w9TWsN9DNDBe6DLhuUt4i5pC53g=
X-Received: by 2002:a05:6512:752:: with SMTP id c18mr183544lfs.459.1614208690974; Wed, 24 Feb 2021 15:18:10 -0800 (PST)
MIME-Version: 1.0
References: <CAHw9_iJzhxO4xBBPXgZu6wHR6tkBRGwjsiRH+wSQy_zAz183yg@mail.gmail.com> <MW3PR11MB465134C130B37766AD8E3C2EB69F9@MW3PR11MB4651.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB465134C130B37766AD8E3C2EB69F9@MW3PR11MB4651.namprd11.prod.outlook.com>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 24 Feb 2021 18:17:35 -0500
Message-ID: <CAHw9_iJXWZdCwYeME1nOPz0NHsacfnJ7X+zn5GntCCPKLigd-g@mail.gmail.com>
To: "Tim Evens (tievens)" <tievens@cisco.com>
Cc: "draft-ietf-grow-bmp-local-rib@ietf.org" <draft-ietf-grow-bmp-local-rib@ietf.org>, "grow@ietf.org grow@ietf.org" <grow@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009e884805bc1d3f52"
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/qKL9s4oG6v0LRFAUVoQUHVr4bPQ>
Subject: Re: [GROW] AD Review of draft-ietf-grow-bmp-local-rib
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Feb 2021 23:18:16 -0000

On Wed, Feb 24, 2021 at 3:22 PM Tim Evens (tievens) <tievens@cisco.com>
wrote:

> Hi Warren,
>
>
>
> Thank you so much for the review.   We agree with those changes. We have
> made the requested changes, but we cannot submit them until after Mar-8th.
> Until then, I have attached a text diff output.  You can also see the
> changes at https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib.  You
> can compare tag revisions.
>

Awesome, thank you very much. Please let me know LOUDLY once
you've submitted, and I'll kick off IETF LC. It will probably have to wait
until just after IETF ends, so that people can pay attention...

Thank again for the quick turn around,
W



>
>
> Thanks,
>
> Tim
>
>
>
> On 2/22/21, 9:27 AM, "Warren Kumari" <warren@kumari.net> wrote:
>
>
>
> Hi authors and WG,
>
>
>
> Thank you for this document, I believe that allowing BMP to share Loc-RIB
> is clearly a good thing.
>
>
>
> I do have a few comments/nits that addressing now should help the IETF
> LC and IESG eval go more smoothly.
>
>
>
> Please SHOUT loudly once you've had a chance to address these.
>
>
>
> AD Review of draft-ietf-grow-bmp-local-rib
> --------------------------------------------
>
> 1: "As shown in Figure 2, Locally originated section 9.4 of [RFC4271]"
> I'm unable to parse this - changing "As shown in Figure 2, Locally
> originated" into "As shown in Figure 2, Locally Originated into Loc-RIB,
> ..." doesn't fix it, because the figure doesn't really "show what Sec 9.4
> of RFC4271" says.
>
> Perhaps something like: "Figure 2 (Locally Originated into Loc-RIB)
> illustrates how redistributed or otherwise originated routes get installed
> into the Loc-RIB based on the decision process selection in [RFC4271]"
>
>
> 2: In Section 1.1 the document says things like: "The current method
> introduces the need..."
> Once the document is published, the phrase "the current method" seems
> incorrect, but I don't have a better suggestion...
>
> 3: "Locally sourced routes MUST be conveyed using the Loc-RIB instance
> peer type."
> Should this be "locally sourced BGP routes"? It would be silly to think
> that this might carry e.g OSPF only routes, but you have a MUST, so
> important to be explicit.
> This also seems to conflict with "The F flag indicates that the Loc-RIB is
> filtered". Perhaps that above is better worded something like:
> "If locally sourced routes are communicated using BMP, they MUST be
> conveyed using the Loc-RIB instance peer type." ?
>
> 4: " The Loc-RIB contains all routes selected by the BGP protocol Decision
> Process section 9.1 of [RFC4271]."
> Similar to #1 - perhaps this is just missing a "in section of..."? Still
> needs rewording.
>
> 5: "These routes include those learned from BGP peers via its Adj-RIBs-In
> post-policy, as well as routes learned by other means section 9.4 of
> [RFC4271]."
> Similar -- I suspect that there was an errant search and replace which
> clobbered some text?
>
> 6: "Peer AS: Set to the BGP instance global or default ASN value."
> Erm, what's this default ASN value?
>
> 7: "5.1.  Per-Peer Header"
> I think that this section needs a pointer to RFC7854 Sec 4.2.
>
> 8: "Capabilities MUST include 4-octet ASN"
> s/include 4/include the 4/
>
> 9: "For example, prefix 10.0.0.0/8 is updated "
> Please use RFC5737 examples instead.
>
>
> Nit:
> 1: "This is overly complex for such a simple application that only needed
> to have access to the Loc-RIB."
> s/needed/needs/
>
> 2: It can greatly reduce time to troubleshoot and resolve issues if
> operators had the history of Loc-RIB changes.
> s/had/have/
>
> 3: "BGP Instance: it refers to an"
> s/it//
>
>
>
> --
>
> Perhaps they really do strive for incomprehensibility in their specs.
> After all, when the liturgy was in Latin, the laity knew their place.
> -- Michael Padlipsky
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra