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

[Warren Kumari <[e-mail]>]

On Mon, Mar 8, 2021 at 7:16 PM Tim Evens (tievens) <[e-mail]>
wrote:

> Hi Warren,
>
>
>
> I have just submitted revision 10 with the updates.
>

Ta! IETF LC has just been requested.

Thanks again to the authors and WG.
W



>
>
> Thanks,
>
> Tim
>
>
>
>
>
> On 2/24/21, 3:18 PM, "Warren Kumari" <[e-mail]> wrote:
>
>
>
>
>
>
>
> On Wed, Feb 24, 2021 at 3:22 PM Tim Evens (tievens) <[e-mail]>
> 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" <[e-mail]> 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
>


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