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

[Robert Raszuk <[e-mail]>]

Hi John,

Do you think it would be helpful if we would modify this section as below ?

OLD

   BGP Route Reflector as per [RFC4456
<https://datatracker.ietf.org/doc/html/rfc4456>] runs a single BGP Decision

   Process.  Optimal route reflection may require multiple BGP Decision

   Processes or subsets of the Decision Process in order to consider

   different IGP locations or BGP policies for different sets of

   clients.





NEW

   OLD +

   This is very similar to what is defined in RFC 7947 section 2.3.2.1.



Thx,
R.

On Tue, Jun 15, 2021 at 9:41 PM John Scudder <[e-mail]> wrote:

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