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