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

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 <idr-bounces@ietf.org> On Behalf Of Alexander Okonnikov
Sent: Tuesday, March 5, 2024 6:36 PM
To: Robert Raszuk <robert@raszuk.net>
Cc: IDR List <idr@ietf.org>
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 <robert@raszuk.net<mailto:robert@raszuk.net>> написал(а):

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 <alexander.okonnikov@gmail.com<mailto:alexander.okonnikov@gmail.com>> 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 <robert@raszuk.net<mailto:robert@raszuk.net>> написал(а):

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 <alexander.okonnikov@gmail.com<mailto:alexander.okonnikov@gmail.com>> 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, internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> написал(а):

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
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr