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

[Alexander Okonnikov <[e-mail]>]

Regarding taking into account ORIGINATOR_ID in addition to CLUSTER_LIST in draft-ietf-idr-rtc-hierarchical-rr - draft-ietf-idr-best-external takes it into account as well:

"2.  When advertising a route to a Route Reflection client peer, in
       case the overall best path has been received from the same
       cluster, a BGP speaker MUST be able to advertise the best overall
       path to all the members of the cluster other than the originator,
       unless "client-to-client" reflection is disabled.  The
       implementation MAY choose to advertise an alternate path to the
       specific peer that originates the best overall path by excluding
       from consideration all paths with the same originator-id."

What we need here is to use SHOULD vs MAY for routes of RT family. I.e. rule 2 of draft-ietf-idr-best-external replaces rule i) of RFC 4684. Rules 1 and 3 in draft-ietf-idr-best-external replace rule ii) of RFC 4684.

Only comment to the draft-ietf-idr-best-external is that I'm not sure we need separate rules for non-client mesh (1) and 'no client-to-client' client mesh (3). For me the former is just specific case of the latter.


My thoughts are that we need rfc4684-bis. The problem with propagating RT routes in presence of hierarchical RRs is not only problem with RFC 4684. Per my view we have other ones:

* no clear rules for propagating default route target - some implementations handle received default route target in ORF manner and don't propagate such route further; others treat it like regular BGP RT route and may propagate it (according to the Decision process).

- no ECMP considerations - some implementations don't provide multipath for RT routes at all; others allow it, though via special commands rather than applying regular 'multipath' logic like it is done for other families.

BR
Alexander Okonnikov

> 5 марта 2024 г., в 13:41, 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] <mailto:[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] <mailto:[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
>>> 
>>> 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
>>> 
>>> 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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
>>>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Idr mailing list
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>> 
>>