Subject: [GROW] Alvaro Retana's Discuss on draft-ietf-grow-bmp-local-rib-10: (with DISCUSS and COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Mon, 05 Apr 2021 12:43:02 -0700

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

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Tue, 6 Apr 2021 01:16:20 +0000

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-masked]> wrote:

(1) 4.2.  Peer Flags

(2) §4.2/8.2: Peer Flags

                              0 1 2 3 4 5 6 7
                             +-+-+-+-+-+-+-+-+
                             |F|  Reserved   |
                             +-+-+-+-+-+-+-+-+

[1]

(1) §3 (Definitions)

- s/add-paths/ADD-PATH/g

(7) [nits]

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 6 Apr 2021 07:56:25 -0700

On April 5, 2021 at 9:16:24 PM, Tim Evens wrote:

Tim:

Hi!  How are you?

> 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.

The DISCUSS position is mostly used to signal that a significant issue
has been identified -- something that we want to resolve before the
document is approved.  But it is not an invitation to an actual
live/f2f discussion -- we should be able to handle the points on
e-mail.

The IESG does have a Telechat scheduled for this Thursday, in which we
focus on going through all the documents currently in IESG Evaluation.
Authors are usually not present in the call and any live discussion is
normally handled by the AD.  In general, any observers (including
authors) don't participate in the discussion.  You are welcome to dial
in [1] if you want to -- but as I mentioned above, we should be able
to resolve the issues on e-mail.

Also, take a look at this:
https://www.ietf.org/blog/handling-iesg-ballot-positions/

[1] ⁨https://ietf.webex.com/ietf/j.php?MTID=m38beb3706c7e5a24dd749a50d7e87dfd ⁩

> 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.
>

Thanks!

Alvaro.

---

From: Job Snijders <[email-masked]>
Date: Wed, 21 Apr 2021 19:34:22 +0200

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

---

From: Warren Kumari <[email-masked]>
Date: Fri, 23 Apr 2021 14:21:14 -0400

> 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

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> _______________________________________________
> GROW mailing list
> [email-masked]
> 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

---

From: Job Snijders <[email-masked]>
Date: Wed, 28 Apr 2021 17:12:23 +0200

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.

Thanks!

Job

---

From: Warren Kumari <[email-masked]>
Date: Wed, 28 Apr 2021 13:14:57 -0400

> And some questions for the GROW group.
Awesome, thank you!
W