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 21, 2021 at 1:34 PM Job Snijders <job=
[e-mail]> 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.
>

Yup, that sounds like a good idea to me.

Also, I'd like to apologize to the authors for not having made the meaning
of "DISCUSS" clearer; hopefully the blog post (
https://www.ietf.org/blog/handling-iesg-ballot-positions/) helps.

I don't think I need to be at the meetin' (scheduling difficulties scale
exponentially with the number of participants), but happy to show up if
useful...

W



>
> >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
> >
> >
> >
>
> _______________________________________________
> GROW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/grow
>


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