Re: [Idr] I-D Action: draft-ietf-idr-rtc-hierarchical-rr-04.txt

[Robert Raszuk <[e-mail]>]

Great.

But this does not change the fact that we still do not have any RFC
specifying this change to best path selection rules.

I guess this would be a good time for WG input on which draft should be
progressed assuming original authors of best-external still want to work on
their document.

Regards,
R.


On Tue, Mar 5, 2024 at 11:35 AM Alexander Okonnikov <
[e-mail]> wrote:

> Hi Robert,
>
> Actually, I successfully performed PoC few years ago using this solution
> ('best external') for exact problem your draft describes. Implementation
> was JunOS.
>
> BR
> Alexander Okonnikov
>
> 5 марта 2024 г., в 13:32, Robert Raszuk <[e-mail]> написал(а):
>
> Hi Alex,
>
> I am not actually aware of implementations supporting best external on
> IBGP per this paragraph:
>
> *Quote
> from https://datatracker.ietf.org/doc/html/draft-ietf-idr-best-external
> <https://datatracker.ietf.org/doc/html/draft-ietf-idr-best-external>*
>
>
> *When selecting the path to add to the Adj-RIB-OUT, this document
> specifies that the path that originate from the same mesh MAY be excluded
> from consideration.  This results in an Adj-RIB-OUT selection per mesh (the
> set of non-client peers or a specific cluster).*
>
> But you are right that this will/would address the issue. In fact our
> draft is pretty much proposing the very same as the second option:
>
> *Quote
> from https://datatracker.ietf.org/doc/html/draft-ietf-idr-rtc-hierarchical-rr
> <https://datatracker.ietf.org/doc/html/draft-ietf-idr-rtc-hierarchical-rr>*
>
> *When advertising an RT membership NLRI to a route-reflector peer (either
> client or non-client), if the best path as selected by the path selection
> procedure described in Section 9.1 of [RFC4271] is the path received from
> this peer, and there are alternative paths received from other peers, then
> the most disjoint alternative route SHOULD be advertised to this peer. The
> most disjoint alternative path is the path whose CLUSTER_LIST and
> ORIGINATOR_ID attributes are diverse from the attributes of the best path.*
>
> Except we specify this further and include not only different mesh
> criteria but also ORIGINATOR_ID difference when selecting a different path.
>
> Many thx,
> Robert
>
>
> On Tue, Mar 5, 2024 at 11:09 AM Alexander Okonnikov <
> [e-mail]> wrote:
>
>> Hi Robert,
>>
>> Yes, initially 'best external' addressed eBGP, but later it was
>> generalized for RR clusters as well.
>>
>> BR
>> Alexander Okonnikov
>>
>> 5 марта 2024 г., в 12:53, Robert Raszuk <[e-mail]> написал(а):
>>
>> Alex,
>>
>> The draft applies to reflected IBGP routes.
>>
>> Best external draft you are quoting - which is extremely useful and
>> deployed proposal - is applicable to ASBRs/PEs learning BGP routes over
>> EBGP.
>>
>> Thx,
>> R.
>>
>>
>>
>> On Tue, Mar 5, 2024 at 10:45 AM Alexander Okonnikov <
>> [e-mail]> wrote:
>>
>>> Hi authors,
>>>
>>> We have already more generic alternative for the second solution - 'Best
>>> external route' described in
>>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-best-external-05.
>>> What about choosing one of two solutions - I lean towards 'best external'
>>> based solution. It seems lightweight and doesn't require Add-paths support.
>>>
>>> Thanks.
>>>
>>> BR
>>> Alexander Okonnikov
>>>
>>> 4 марта 2024 г., в 13:27, [e-mail] написал(а):
>>>
>>> Internet-Draft draft-ietf-idr-rtc-hierarchical-rr-04.txt is now
>>> available. It
>>> is a work item of the Inter-Domain Routing (IDR) WG of the IETF.
>>>
>>>   Title:   Extensions to RT-Constrain in Hierarchical Route Reflection
>>> Scenarios
>>>   Authors: Jie Dong
>>>            Mach(Guoyi) Chen
>>>            Robert Raszuk
>>>   Name:    draft-ietf-idr-rtc-hierarchical-rr-04.txt
>>>   Pages:   6
>>>   Dates:   2024-03-04
>>>
>>> Abstract:
>>>
>>>   The Route Target (RT) Constrain mechanism specified in RFC 4684 is
>>>   used to build a route distribution graph in order to restrict the
>>>   propagation of Virtual Private Network (VPN) routes.  In network
>>>   scenarios where hierarchical route reflection (RR) is used, the
>>>   existing RT-Constrain mechanism cannot guarantee a correct route
>>>   distribution graph.  This document describes the problem scenario and
>>>   proposes a solution to address the RT-Constrain issue in hierarchical
>>>   RR scenarios.
>>>
>>> The IETF datatracker status page for this Internet-Draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-idr-rtc-hierarchical-rr/
>>>
>>> There is also an HTMLized version available at:
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-rtc-hierarchical-rr-04
>>>
>>> A diff from the previous version is available at:
>>>
>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-idr-rtc-hierarchical-rr-04
>>>
>>> Internet-Drafts are also available by rsync at:
>>> rsync.ietf.org::internet-drafts
>>>
>>>
>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>>>
>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>>
>>
>