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

[Robert Raszuk <[e-mail]>]

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