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

[Robert Raszuk <[e-mail]>]

Excellent. Will add it to -26.

Many thx,
R.

On Wed, Jun 16, 2021 at 6:46 PM John Scudder <[e-mail]> wrote:

> Robert,
>
> Yes I do. Thanks.
>
> —John
>
> On Jun 16, 2021, at 12:37 PM, Robert Raszuk <[e-mail]> wrote:
>
> 
>
> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc4456__;!!NEt6yMaO-gk!WBSgzB-H7-ZtqL0NrN-5Pi0ae9gm5rI8ekxCYqpW5ToWMF-4FqrhvHONEeDLEg$>]
> 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.
>>>
>>>
>>>
>>>