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

[Warren Kumari <[e-mail]>]

On Wed, Apr 28, 2021 at 11:12 AM Job Snijders <job=
[e-mail]> wrote:

> 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.
>
>
Awesome, thank you!
W



> 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
> > >
> > >
> > >
>
>

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