Re: [GROW] Genart last call review of draft-ietf-grow-bmp-local-rib-10

[Thomas Fossati <[e-mail]>]

Hi Tim,

On 30/03/2021, 04:22, "Tim Evens (tievens)" <[e-mail]> wrote:
> Thank you for your review and catching these nits.  Please see my
> comments marked [tievens] inline.  You can see my pending PR
> (https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib/pull/22) for
> all these changes.  Once approved, I'll submit revision 11.

Thanks!

> On 3/20/21, 3:33 AM, "Thomas Fossati via Datatracker" <[e-mail]> wrote:
> * Section 8.2
>   * It is not clear to me if saying "and proposes that peer flags are
>     specific to the peer type" you are asking IANA to modify the
>     contents and/or structure of the BMP Peer Flags registry?  If so,
>     the request to IANA should be made more explicit.
>
>
> [tievens] I have updated it to: "This document defines that peer flags
> are specific to the Loc-RIB instance peer type.  As defined in
> (Section 4.2)".  We do have a problem as IANA did add this flag under
> the general table as flag/bit 4, which is incorrect.  The flag is F in
> position 0, which would be documented as flag 0.   The draft requests
> that the peer flags be unique by peer type.   IANA would need to
> create a new table based on the peer type of 3.

I understand that the flags space is *very* small and that in hindsight
making the flags dependent on the peer types would have been a better
choice.  However, retroactively changing the wire semantics looks like
something that should be treated with care.

If you really want to go that way I think the document should contain an
analysis of the impact on existing deployments and any dependent tooling
around those.  The requests to IANA should be made more precise too: for
example, what happens to the V, L, A, and O flags?  To which peer types
would they be associated with in the new table?

Or, you could make it someone else's problem, after the 8th flag has been
allocated.

> * Section 8.3
>   * Should "informational message TLV types" be "Initiation Message TLV
>     type" instead?
>
>
> [tievens]  No.  Considering the original draft RFC7854 defines some of
> the information TLV messages to be specific by type, it required IANA
> to create more than one table for informational TLVs as defined in
> section 4.4 of RFC7854.  RFC7854 defines that Peer UP does have
> information TLV String, but fails to identify the type number and does
> not request from IANA to define message TLVs for Peer Up.  Instead,
> RFC7854 does state in Section 4.4 that the defined info TLVs are used
> by both INIT and Peer Up messages, but it doesn't make that clear in
> the IANA request.  I'm thinking that IANA can update the title to
> indicate "Initiation and Peer Up" as they use the same registry/table.
> RFC8671 also added a new type, which is documented under that table.

This IANA situation looks quite intricate.  I suggest you clarify exactly
what the desired state of the BMP parameters registry is and make it
crystal clear in the IANA considerations section because as it stands
I don't think it is easily actionable.

cheers!

PS: Have you considered adding an "Implementation Status" section to the
doc (BCP 205) and talk a bit about OpenBMP?






IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.