[Idr] John Scudder's No Objection on draft-ietf-idr-bgp-optimal-route-reflection-24: (with COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-idr-bgp-optimal-route-reflection-24: No Objection

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 DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm glad to see this draft moving forward!

I have some comments below, I hope they're helpful.

1. Introduction

   [RFC4456] asserts that, because the IGP cost to a given point in the
   network will vary across routers, "the route reflection approach may
   not yield the same route selection result as that of the full IBGP
   mesh approach."  One practical implication of this assertion is that

Strictly speaking, it’s not an implication of the assertion, it’s an
implication of the fact (that is being asserted). So, "... practical
implication of this fact is that..." (or just "... implication of this is...").

2. Section 3.1

   One or more backup IGP locations SHOULD be allowed to be specified
   for redundancy.

Doesn’t this depend entirely on what option is chosen, of the three you’ve
offered? They are, “per route reflector basis, per set of clients, or per
client basis”. In the per client case, what would you use for a backup IGP
location? When would you invoke the backup? (I’m imagining that the per-client
case would generally use the client’s position in the IGP topology, in fact I
imagine most implementations wouldn't force you to configure the IGP location
when doing per-client.)

This sentence would also benefit from a forward reference to the additional
discussion in Section 4, IMO.

3. Section 3.1.1

I don’t think “BGP prefix” is a term of art, especially not as you’re using it.
I think “BGP route” would be better.

4. Section 3.2

The third paragraph talks about applying different policies. While it’s
accurate, it’s a bit sparse. It’s very similar to what’s discussed in RFC 7947
Section 2.3, and especially Section 2.3.2.1. Might be worth informatively
referencing that?

5. Section 4

When you write “hop-by-hop switching“, I think you mean forwarding, not
switching, right?

   Modifying the IGP location of BGP ORR does not interfere with
   policies enforced before IGP tie-breaking (step e) in the BGP
   Decision Process Route.

That last word “Route” doesn’t need to be there.

   (both should be equal to the [RFC4456] ones)

Both *what* should be equal to the RFC4456 one *what*? Confused.