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