Re: [GROW] Alvaro Retana's Discuss on draft-ietf-grow-bmp-local-rib-10: (with DISCUSS and COMMENT)

["Tim Evens (tievens)" <[e-mail]>]

I'm new to the process.  When is the discussion scheduled?  I believe there is a telechat on 4/8 at 7am PDT.  Is this when you want to discuss this?  I have not seen an invite with a link for the conference/meeting.

I have lc, rtgdir, and secdir updates in revision 11 that have not been submitted yet (https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib).   The below would require some minor updates.  I can add those to the pending updates to revision 11.  All the updates are minor/clarifications so far.  AFAIK, the issue with IANA peer flags and title update of "Initiation … TLVs" have been resolved.

I'll send a respond to the below nits and peer flag question tomorrow, PDT time.

Thanks,
Tim

On 4/5/21, 12:43 PM, "Alvaro Retana via Datatracker" <[e-mail]> wrote:


Alvaro Retana has entered the following ballot position for
draft-ietf-grow-bmp-local-rib-10: Discuss

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-grow-bmp-local-rib/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am balloting DISCUSS because there are significant clarity issues.

(1) 4.2.  Peer Flags

   In section 4.2 of [RFC7854], the "locally sourced routes" comment
   under the L flag description is removed.  If locally sourced routes
   are communicated using BMP, they MUST be conveyed using the Loc-RIB
   instance peer type.

This change is bigger than simply removing a comment: it is changing the
behavior.  Note that §8.2/rfc7854 also talks about the L flag.  Do the same
considerations apply?   I would like to see a clearer treatment of the change
related to locally sourced routes -- a separate section/sub-section seems
appropriate.

(2) §4.2/8.2: Peer Flags

§4.2 defines a new Flag as follows:

                              0 1 2 3 4 5 6 7
                             +-+-+-+-+-+-+-+-+
                             |F|  Reserved   |
                             +-+-+-+-+-+-+-+-+

But it doesn't mention that this field is intended to be specific to the
Loc-RIB peer-type.  OTOH, §8.2 (IANA Considerations) does:

   This document defines a new flag (Section 4.2) and proposes that peer
   flags are specific to the peer type:

The registry [1] shows that the early allocation was made in the "generic" (not
per-peer-type) Peer Flags field.  The flags defined in rfc7854 and rfc8671 both
assume the same set of Flags for all peer types.

[1]
https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#peer-flags

(3) §5.4 (Route Monitoring)  The implication in this section is that a BGP
UPDATE includes the route information -- but the information in the Loc-RIB may
not have come from BGP, so there is no BGP UPDATE to propagate.  This clearly
is a case where the UPDATE is fabricated.  Please provide specific instructions
on how this UPDATE is constructed, including any path attributes.


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

(1) §3 (Definitions)

   *  Post-Policy Adj-RIB-Out: The result of applying outbound policy to
      an Adj-RIB-Out. This MUST be what is actually sent to the peer.

s/This MUST be what is actually sent to the peer./This is what is sent to the
peer.

Note that this document should not use Normative language related to what a BGP
session does.  In this case, that is rfc4271's job.

(2) §5.2 (Peer UP Notification): "Capabilities MUST include the 4-octet ASN and
all necessary capabilities to represent the Loc-RIB route monitoring messages.
Only include capabilities if they will be used for Loc-RIB monitoring messages."

Which are the capabilities that "will be used for Loc-RIB monitoring messages"?
 The action above is required (MUST), but no specifics are given.

(3) §5.2.1: "The Information field contains a UTF-8 string whose value MUST be
equal to the value of the VRF or table name (e.g.  RD instance name) being
conveyed."

- Please take a look at the Shutdown Communication string definition in rfc9003
and use a similar definition.

- The "value of the VRF or table name" is a local matter, right?  How can the
requirement be normatively enforced?  How can the receiver enforce the "MUST"?
IOW, s/MUST.../The information field contains the value of the VRF or table
name...

- There's no need to redefine the TLV in §5.3.

(4) §5.4: "As defined in section 4.3 of [RFC7854]..."  The quote comes from
§4.6.

(5) §5.5 (Route Mirroring): "Route mirroring is not applicable to Loc-RIB and
Route Mirroring messages SHOULD be ignored."   If not applicable...when is it
ok not to ignore the Route Mirroring messages?  IOW, why is this behavior
recommended and not required?

(6) In general, the terminology used throughout the document is well-known to
BMP/BGP users but may not be to the average reader.  Please add references
(most can be informational).  These are some examples:

- Please add a reference to rfc471 when introducing Loc-RIB/Adj-RIB-In.
There's a mention in the Abstract about Loc-RIB, but that is not enough.

- s/Adj-RIB-In Post-Policy/Post-Policy Adj-RIB-In/g
That is how rfc7854 defines the term.  Also, please add a reference on first
mention.

- s/Adj-RIB-In Pre-Policy/pre-policy Adj-RIB-In/g
Same as above.

- Add a reference for BGP-LS (rfc7752).

- s/add-paths/ADD-PATH/g
That is how rfc7911 uses the term.  Also, please add a reference on first
mention.

- s/BGP-ID/BGP Identifier/g
>From rfc4271.  rfc7854 uses "BGP ID".

- Expand RD on first use.

- Add a reference for "4octet ASN" (rfc6793).

(7) [nits]

s/after best-path selection/after best route selection
That's the terminology used in rfc4271

s/build Adj-RIB-Out/build the Adj-RIB-Out