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

[John Scudder <[e-mail]>]

Hi Robert,

Although I don’t agree with all of your analysis (e.g., “per-client RIB” is really an abstraction used to describe what’s happening, it’s not an implementation choice as such), if you and your coauthors don’t find the citation would be helpful, I don’t insist. I do hope other reviewers will find the paragraph in S. 3.2 to be clear enough standing on its own.

—John

On Jun 15, 2021, at 4:43 AM, Robert Raszuk <[e-mail]> wrote:

Hello John,

Many thx for your review. I have incorporated all of your suggestions except one. After discussing with co-authors we are a bit hesitant to add reference to  RFC 7947 especially Section 2.3.2.1 to ORR draft.

There are couple of reasons for it. Yes you are correct that both route server and route reflectors perform similar functions if we look at bgp information distribution. But how they do it is/can be different.

Reasons:

1. First while per client route distribution can be done with per client RIB this is not the only option and in fact not the best option implementation wise.

2. eBGP RS policies can be quite different then iBGP RR policies set or communicated on behalf of the clients.

3. The current mechanism of the ORR draft is focused on change to the route computation/decision process not necessarily reusing the same decision with different inputs N times.

So in our view we are entering the implementation optimizations area which usually is much better not to become part of the spec.

With that we would like to hear your take on this.

Many thx,
Robert



On Mon, Jun 14, 2021 at 11:50 PM John Scudder via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
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<https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!VwbkUuFAboGR7xDeip4otAOn9cD3SEdoNzeccXr5U1lL8tPS0KrCd5x7wToI1w$>
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/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection/__;!!NEt6yMaO-gk!VwbkUuFAboGR7xDeip4otAOn9cD3SEdoNzeccXr5U1lL8tPS0KrCd5wpuuRd8A$>



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