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

[Job Snijders <[e-mail]>]

Hi all,

We (GROW chairs + Alvaro + draft authors Tim & Paolo) had a productive
call, a number of suggestions for clarification came to light.

Tim will follow up by sending a summary of proposed changes to the list.
And some questions for the GROW group.

Thanks!

Job

On Wed, Apr 21, 2021 at 07:34:22PM +0200, Job Snijders wrote:
> Dear Alvaro, draft authors,
> 
> Perhaps it would be good to have a voice discussion? This might expedite
> figuring out a solution to how we describe things.
> 
> From what I understand the BMP Loc-RIB draft to propose is that all BMP
> messages of the Loc-RIB instance type are 'synthesized', as the
> Information Base contains the router's best paths (regardless of
> original protocol). It indeed would be good if the document is very
> clear on this aspect.
> 
> I'm happy to organize a call for early next week (early PST / afternoon
> CEST timeslot).
> 
> Kind regards,
> 
> Job & Chris
> GROW Chairs
> 
> On Mon, Apr 05, 2021 at 12:43:02PM -0700, Alvaro Retana via Datatracker 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
> > 
> > 
> >