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

[Alexander Okonnikov <[e-mail]>]

Hi Jimmy,

To be precise, I don't think the 'best external' feature in Junos OS was implemented specifically to address issue with hierarchical RRs for RT. The implementation works for multiple families. Fortunately, it works for RT family too.

Thank you.

BR
Alexander Okonnikov

> 5 марта 2024 г., в 16:39, Dongjie (Jimmy) <[e-mail]> написал(а):
> 
> Hi Alex,
>  
> Thanks for sharing the POC information with IDR. This is great.
>  
> In the hierarchical RR draft, two candidate solutions are documented, on last IETF we heard of implementations of solution 1 (add-path based), and now both solutions have been implemented.
>  
> As for the best-external draft, I just noticed that it has been generalized for route-reflectors. This is something good. I will take a look at it in detail.
>  
> Then the WG may need to consider how to coordinate these efforts and move forward. Perhaps hierarchical RR could refer to best external by applying some of the rules there to the RTC address family with possible changes. 
>  
> Thoughts?
>  
> Best regards,
> Jie
>  
> From: Idr <[e-mail]> On Behalf Of Alexander Okonnikov
> Sent: Tuesday, March 5, 2024 6:36 PM
> To: Robert Raszuk <[e-mail]>
> Cc: IDR List <[e-mail]>
> Subject: Re: [Idr] I-D Action: draft-ietf-idr-rtc-hierarchical-rr-04.txt
>  
> 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 inhttps://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