On Wed, Apr 21, 2021 at 1:34 PM Job Snijders <job= 40fastly....@dmarc.ietf.org> 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 > GROW@ietf.org > 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
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
