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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Jeff,

Thanks for sharing the analysis about those options. I agree that depends on the network topology, “overwrite the cluster list” may not be safe in some cases.

I agree that the “disjoint alternate” option in concept is similar to “best-external”, while for RTC the path selection may be different from other address families, it does not have to be the “best”, just needs to be as diverse as possible from the best path. We may use some example topologies to check the validity of this option.

Best regards,
Jie

From: Jeffrey Haas [mailto:[e-mail]]
Sent: Thursday, March 7, 2024 3:23 AM
To: Dongjie (Jimmy) <[e-mail]>
Cc: Alexander Okonnikov <[e-mail]>; Robert Raszuk <[e-mail]>; IDR List <[e-mail]>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rtc-hierarchical-rr-04.txt

Jie,

When Juniper was looking at how we were going to address the hierarchal rtc issue, add-paths ended up being our easiest answer.

We did also evaluate the "overwrite the cluster list" internally prior to the presentation given at IETF 118, although much more conservatively than that proposal.  I wasn't able to fully convince myself it was safe in all circumstances.  The property I half convinced myself was safe was that if the cluster list distributed to the obstructing reflector had its cluster-id removed from the top entry of the list, replaced with the alternative path trying to bridge the gap, and that the cluster list was at least as long as the one learned from the obstructing router, it'd probably be okay.  However, this sort of surgery was quite messy.

The alternative solution in your draft for the "diverse" route is effectively a flavor of the best-external.  I'll have to review the text in the most recent version of that draft, but I suspect it'll have some of the same considerations as add-paths in "how many additional paths do you send?  It may take some time to work through an example, but a single best-external is likely not sufficient in the general solution.

-- Jeff



On Mar 5, 2024, at 8:39 AM, Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:jie.dong=[e-mail]>> wrote:

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]<mailto:[e-mail]>> On Behalf Of Alexander Okonnikov
Sent: Tuesday, March 5, 2024 6:36 PM
To: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Cc: IDR List <[e-mail]<mailto:[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 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<http://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


_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr