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" <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/grow
