Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt

[Igor Malyushkin <[e-mail]>]

Hi Kaliraj,

See my inline as well (IM).

ср, 21 февр. 2024 г. в 11:28, Kaliraj Vairavakkalai <[e-mail]>:

> Hi Igor, pls see inline. KV>
>
>
>
> Thanks
>
> Kaliraj
>
> Juniper Business Use Only
>
> *From: *Igor Malyushkin <[e-mail]>
> *Date: *Tuesday, February 20, 2024 at 3:22 AM
> *To: *Kaliraj Vairavakkalai <[e-mail]>
> *Cc: *Robert Raszuk <[e-mail]>, Natrajan Venkataraman <
> [e-mail]>, idr@ietf. org <[e-mail]>, Susan Hares <
> [e-mail]>, Keyur Patel <[e-mail]>, Jeff Haas <
> [e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Kaliraj,
>
>
>
> Thank you for explaining. I would agree with you if you decided to express
> the problem in a separate informational document without altering the
> Decision Process. I think it would be useful.
>
>
>
> KV> OK. Agree it would be an informational document if we end up not
> suggesting the path-selection change.
>
>
>
> I don't think we have a problem that we can't solve with current
> mechanisms. There are many of them, including "robust and stable".
>
>
>
> The solution from this draft "helps" in only narrow scope of cases:
>
> * Metrics are equal.
>
> * Originators are different.
>
> * Cluster list length gives us a CORRECT winner.
>
>
>
> KV> In cases where clusterList does not give ‘correct’ winner, RouterID
> step would be even more arbitrary.
>
[IM] Yes. My point is that the flipping of the steps does not produce a
stable solution. In your previous example, suppose both ABR use a route
toward ASBR22 because of the shorter cluster list. We don't have a loop at
the moment which is good, but also suppose ASBR22 fails. After that we need
again to deal with metrics to stop the loop. If we imagine that the metrics
are equal (30 for ASBR1 instead of 40), a shorter cluster list will be
chosen naturally.

>
>
> For example, despite IGP cost may change during network churn, I think
> this is a task of a network designer to account all possible cases,
> especially in a transport network.There are many other pitfalls the
> designer can meet developing a proper solution. We do not have to have a
> magic knob for all of them.
>
>
>
> Even if we have a chaotic network, where events happen in an unpredictable
> manner and everything is possible, there are still several ways to prevent
> the loop. Every RR that applies NHS could increase a route's MED, creating
> something like a metric. For transport prefixes this is more than
> appropriate. Thus, when an ABR receives a route from an ASBR, its MED is 0,
> and MED of a route from another ABR is 10.
>
>
>
> KV> Agree. MED or AIGP-cost should help. Perhaps AIGP-cost is simpler.
> With MED possible oscillation scenarios if-any need to be considered.
>
>
>
> As Alexander mentioned in his message, it is possible to manipulate a
> label allocation mode to prevent the loop.
>
>
>
> KV> I looked at Alexander’s email again that you pointed out. Now I see
> what he meant. I agree - with “addpath and per-nexthop-label”,
>
> KV> the label advertised for inactive routes will not cause loop.
>
> KV> Also, I just noticed in that email Alexander was not opposed to the
> suggested path-selection change:
>
>     “I would agree that Cluster List comparison could be placed before f) (and not before e)), but, probably, authors of RFC 1966 had some reasons to do it this way.”
>
>  [IM] To be honest, I also can't imagine what this change may break. My
"resistance" is based on two things: we have other options, they can
elemenate loops at all, and the proposed option does not seem to have this
quality.

> And I'm sure we can find something else, not to mention that a proper
> design prevents the problem at all.
>
>
>
> In your example we lean on the fact that a longer cluster list is worst,
> but actually we can't say what it gives in all cases. Some of reflectors
> from your example apply a NHS others don't. We can't say that a longer
> cluster list prevents loops in all cases or it is better for forwarding.
>
>
>
> KV> I see what you mean. But it should be noted that Router-ID based
> comparison is even more arbitrary.
>
> KV> Especially because Originator-ID does not change on NHS. So
> Cluster-List provides a better tiebreaker when IGP-cost is equal.
>

>
> KV> Yes ClusterList is appended to, with or without NHS. Just like Aspath
> is appended to, with or without NHS.
>
> KV> So though ClusterList tiebreaker may not give the actual number of
> forwarding hops/metric (AIGP/IGP-cost is better for that),
>
> KV> but when AIGP/IGP-cost are equal, an option to tiebreak on ClusterList
> rather than RouterID seems like a good tool in the toolkit to me.
>

>
> KV> However since we are collectively not so comfortable about the
> side-effects of such an option (which makes me nervous aswell),
>
> KV> and other config based options are available, so I am OK to atleast
> document these available options and best practices
>
> KV> as an informational draft, without suggesting the path-selection
> change. Thanks.
>
[IM] As I already said, I would support such document.

>
>
>
>
>
>
> Thank you.
>
>
>
> пн, 19 февр. 2024 г. в 22:52, Kaliraj Vairavakkalai <[e-mail]>:
>
> Igor,
>
>
>
> As noted in the draft, one or more of the approaches (including IGP-cost)
> solves the problem. But IGP-cost may change during network churn, so I
> think it is better to have a more stable safety net.
>
>
>
> Even the ‘same CLUSTER_ID’ based configuration that Robert proposed looks
> better, as it is more stable, if it doesn’t have any other side effects.
>
>
>
> > in your example (if Rt1 & Rt2 have an equal cost to their next-hops),
> there is a common ORIGINATOR_ID (ASBR21) value for Rt1 & Rt2
>
>
>
> Yes, but there are routes from ASBR22 also in the picture. Here is the
> full route list in the problem condition:
>
>
>
> (Router-ID values comparison: ASBR21 < ASBR22)
>
>
>
> At ABR24:
>
>
>
> 1.1.1.1/32
> <https://urldefense.com/v3/__http:/1.1.1.1/32__;!!NEt6yMaO-gk!EfxgsODfk3-n2Er4z6x9V5yNgmgdgn1xm0qspEo4bL-5f4Nes99f0Iv6Pkju5yg_ENq3xQHonjsH1HikMZkM$>
>
>   Rt1 NH:ABR23, (Active)
>
> IGP-cost: 30
>
> AS-path: 1
>
> Cluster list:  RR26 ABR23 RR27
>
> Originator ID: ASBR21
>
>   Rt2 NH: ASBR22,
>
> IGP-cost: 30
>
> AS-path: 1
>
> Cluster list:  RR27
>
> Originator ID: ASBR22
>
> Tie-breaker: Router-ID/Originator-ID
>
>   Rt3 NH: ASBR21,
>
> IGP-cost: 40
>
> AS-path: 1
>
> Cluster list:  RR27
>
> Originator ID: ASBR21
>
> Tie-breaker: IGP-cost
>
>
>
>
>
> At ABR23:
>
>
>
> 1.1.1.1/32
> <https://urldefense.com/v3/__http:/1.1.1.1/32__;!!NEt6yMaO-gk!EfxgsODfk3-n2Er4z6x9V5yNgmgdgn1xm0qspEo4bL-5f4Nes99f0Iv6Pkju5yg_ENq3xQHonjsH1HikMZkM$>
>
>   Rt1 NH:ABR24, (Active)
>
> IGP-cost: 30
>
> AS-path: 1
>
> Cluster list:  RR26 ABR24 RR27
>
> Originator ID: ASBR21
>
>   Rt2 NH: ASBR22,
>
> IGP-cost: 30
>
> AS-path: 1
>
> Cluster list:  RR27
>
> Originator ID: ASBR22
>
> Tie-breaker: Router-ID/Originator-ID
>
>   Rt3 NH: ASBR21,
>
> IGP-cost: 40
>
> AS-path: 1
>
> Cluster list:  RR27
>
> Originator ID: ASBR21
>
> Tie-breaker: IGP-cost
>
>
>
>
>
> About AIGP cost, yes I think that would also solve the problem. But still
> has the dynamism of igp-cost, which may change during churn. It is
> difficult for me to comprehend whether the problem remains solved in all
> cases.
>
>
>
> If there is a temporary forwarding loop formed during churn, due to
> specific igp-cost situations, that may be very hard to troubleshoot. That’s
> the idea behind attempting to provide a more stable tie-breaker by the
> proposed path-selection tweak. Ofcourse we need to ensure there are no
> side-effects to that as-well.
>
>
>
> Bottom-line is: I think this problem is real, and I could not find any
> draft explaining best-practices on guidelines on how to avoid it. Hence I
> put together some text capturing the recommendations I could come up with.
>
>
>
> And during this short WG discussion, we have more approaches being added.
>
>
>
> My main intent is that only. Record in some document all the tribal wisdom
> that exists. So that it can help new folks stumbling on this problem.
>
>
>
> If there is already some document that explains these gotchas, pls point
> me to it. Then we don’t need a new WG document.
>
>
>
> Thanks
>
> Kaliraj
>
>
>
>
>
> Juniper Business Use Only
>
> *From: *Igor Malyushkin <[e-mail]>
> *Date: *Saturday, February 17, 2024 at 5:32 AM
> *To: *Kaliraj Vairavakkalai <[e-mail]>
> *Cc: *Robert Raszuk <[e-mail]>, Natrajan Venkataraman <
> [e-mail]>, idr@ietf. org <[e-mail]>, Susan Hares <
> [e-mail]>, Keyur Patel <[e-mail]>, Jeff Haas <
> [e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Kaliraj,
>
> To me, we should agree that the discussion on the e). step of 9.1.2.2 is
> the crucial to this problem. And all the comparison of CLUSTER_LIST lengths
> will take place only when we have an equal cost. Correct me if I am wrong.
> The draft says: "IGP metric should be assigned such that "ABR to redundant
> ABR" cost is inferior to "ABR to upstream ASBR" cost", which confirms my
> point. So, don't you think that AIGP solves the problem in automatically
> fashion? Nothing need to change at all.
>
> Second, in your example (if Rt1 & Rt2 have an equal cost to their
> next-hops), there is a common ORIGINATOR_ID (ASBR21) value for Rt1 & Rt2,
> don't we already compare these routes based on the CLUSTER_LIST length in
> this case?
>
>
> I wan't you to point your attention to a message of Alexander (
> https://mailarchive.ietf.org/arch/msg/idr/_uudeKVEulLuF7eYc0rcAeomxdU/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/_uudeKVEulLuF7eYc0rcAeomxdU/__;!!NEt6yMaO-gk!GeFYrsquBfGL7vOU-xt5CSRFUMJmstYFsexSe75R6FhXMWoXhbZ69fO9GQuZJ8QH0P3ZQ54lMcnk8sPazKO2$>).
> He has already expressed all of that and more.
>
>
>
> Thank you.
>
>
>
> сб, 17 февр. 2024 г. в 02:52, Kaliraj Vairavakkalai <[e-mail]>:
>
> >. So in presented topology when ABRs are RRs CLUSTER_LIST will likely be
> of the very same length
>
>
>
> No Robert.
>
>
>
> Take the following propagation paths for PE11 route in the Reference
> Topology in Fig 1
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00*figure-1__;Iw!!NEt6yMaO-gk!GeFYrsquBfGL7vOU-xt5CSRFUMJmstYFsexSe75R6FhXMWoXhbZ69fO9GQuZJ8QH0P3ZQ54lMcnk8obYEJli$>
> :
>
>
>
> Rt1 :  ABR23 <- RR27 <- ASBR21
>
> Rt2 :  ABR23 <- RR26 <- ABR24 <- RR27 <- ASBR21
>
>
>
> Rt1 will have a smaller CLUSTER_LIST (RR27) than Rt2 (RR26, ABR24, RR27).
>
>
>
> Rt1 has next hop of ASBR21.
>
> Rt2 has next hop of ABR24.
>
>
>
> Desired outcome is: ABR23 should chose ASBR21 as next hop, and not ABR24
>
>
>
> The cluster-list based tie-breaking will choose Rt1, ASBR21 as next hop.
>
>
>
> Thanks
>
> Kaliraj
>
>
>
> Juniper Business Use Only
>
> *From: *Robert Raszuk <[e-mail]>
> *Date: *Friday, February 16, 2024 at 4:01 PM
> *To: *Kaliraj Vairavakkalai <[e-mail]>
> *Cc: *Igor Malyushkin <[e-mail]>, Natrajan Venkataraman <
> [e-mail]>, idr@ietf. org <[e-mail]>, Susan Hares <
> [e-mail]>, Keyur Patel <[e-mail]>, Jeff Haas <
> [e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> But I am saying that I do not see how your change will yield any
> additional consistency here.
>
>
>
> Today's best path and even your draft only compares CLUSTER_LIST *length*
> not the actual values. So in presented topology when ABRs are RRs
> CLUSTER_LIST will likely be of the very same length. If so we move down to
> the next step in best path selection - so we gain null.
>
>
>
> Do you agree ?
>
>
>
> Thx,
>
> R.
>
>
>
> On Sat, Feb 17, 2024 at 12:51 AM Kaliraj Vairavakkalai <
> [e-mail]> wrote:
>
> I did not say same CLUSTER_ID will cause inconsistency.
>
>
>
> I said, without depending on specific CLUSTER_ID values (and
> Router-id/Originator-id values),
>
> path-selection should yeild consistent results. That’s a desired feature.
>
>
>
> That’s achieved by the path selection change proposed in this draft. viz.
> tie-break on
>
> cluster-list step before router-id/originator-id step.
>
>
>
> Thanks
>
> Kaliraj
>
>
>
> Juniper Business Use Only
>
> *From: *Robert Raszuk <[e-mail]>
> *Date: *Friday, February 16, 2024 at 3:06 PM
> *To: *Kaliraj Vairavakkalai <[e-mail]>
> *Cc: *Igor Malyushkin <[e-mail]>, Natrajan Venkataraman <
> [e-mail]>, idr@ietf. org <[e-mail]>, Susan Hares <
> [e-mail]>, Keyur Patel <[e-mail]>, Jeff Haas <
> [e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> I do not see how with the same CLUSTER_ID set on both RRs in your scenario
> as described in the draft current best path selection would provide
> inconsistent results on the clients.
>
>
>
> Thx.
> R.
>
>
>
> On Fri, Feb 16, 2024 at 11:58 PM Kaliraj Vairavakkalai <
> [e-mail]> wrote:
>
> Some deployments may use unique CLUSTER_IDs by design.
>
>
>
> I’d just say providing consistent path-selection is a desirable feature,
> irrespective of choice/assumptions on CLUSTER_ID values.
>
>
>
> That’s what this proposed text on path-sel chagne attempts to do.
>
>
>
> Thanks
>
> Kaliraj
>
>
>
> Juniper Business Use Only
>
> *From: *Robert Raszuk <[e-mail]>
> *Date: *Friday, February 16, 2024 at 1:14 PM
> *To: *Kaliraj Vairavakkalai <[e-mail]>
> *Cc: *Igor Malyushkin <[e-mail]>, Natrajan Venkataraman <
> [e-mail]>, idr@ietf. org <[e-mail]>, Susan Hares <
> [e-mail]>, Keyur Patel <[e-mail]>, Jeff Haas <
> [e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi,
>
>
>
> > So do you agree that with distinct CLUSTER_ID on the
>
> > RRs/ABRs, there is an issue?
>
>
>
> I do. But I call it misconfiguration.
>
>
>
> Of course you can/will say that in most if not all BGP implementations
> configuring CLUSTER_ID is optional and by default BGP RTR_ID is taken which
> makes it different by default RR by RR - but oh well - there is few things
> in BGP one is expected to just know before getting to the keyboard.
>
>
>
> Setting next-hop-self on RRs in IBGP is yet another topic for discussion,
> but I don't think we need to really spend time on it now.
>
>
>
> > Configuring same CLUSTER_ID, if feasible, is another way to deal with
> it, agree.
>
>
>
> Glad we agree on that one.
>
>
>
> Thx,
>
> R.
>
>
>
>
>
> On Fri, Feb 16, 2024 at 10:01 PM Kaliraj Vairavakkalai <
> [e-mail]> wrote:
>
> OK, now onto the technical discussion,
>
>
>
> > On the technical side just configured same CLUSTER_ID on both RRs/ABRs
> and there is no issue.
>
>
>
> So do you agree that with distinct CLUSTER_ID on the RRs/ABRs, there is an
> issue?
>
>
>
> Configuring same CLUSTER_ID, if feasible, is another way to deal with it,
> agree.
>
>
>
> Thanks
>
> Kaliraj
>
>
>
> Juniper Business Use Only
>
> *From: *Robert Raszuk <[e-mail]>
> *Date: *Friday, February 16, 2024 at 12:27 PM
> *To: *Kaliraj Vairavakkalai <[e-mail]>
> *Cc: *Igor Malyushkin <[e-mail]>, Natrajan Venkataraman <
> [e-mail]>, idr@ietf. org <[e-mail]>, Susan Hares <
> [e-mail]>, Keyur Patel <[e-mail]>, Jeff Haas <
> [e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Kaliraj & Sue,
>
>
>
> > The text in this draft has been reviewed by WG, as part of draft-ct.
>
>
>
> I do not agree with this explanation/justification. If someone is not
> interested at all in CT draft lot's of smuggled features and extensions may
> not get sufficient attention.
>
>
>
> So I am very glad chairs recommended to remove it from the CT draft into a
> separate document. As such I am afraid it would have a hard time to even
> become an IDR WG document so I am not sure if the fact that some orthogonal
> text was pulled out of WG document makes is automatically a WG document.
>
>
>
> On the technical side just configured same CLUSTER_ID on both RRs/ABRs and
> there is no issue.
>
>
>
> Cheers,
>
> R.
>
>
>
>
>
> On Fri, Feb 16, 2024 at 8:28 PM Kaliraj Vairavakkalai <[e-mail]>
> wrote:
>
> Hi Robert, Igor,
>
>
>
> To provide some context –
>
>
>
> The text in this draft has been reviewed by WG, as part of draft-ct.
>
>
>
>
> https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-23.html#name-avoiding-loops-between-rout
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-23.html*name-avoiding-loops-between-rout__;Iw!!NEt6yMaO-gk!HK1hMYBmWLPwtF2YCSAargxA_wbJrNC8lBcRa2wgLKBTusa6Yay2o3Ttz1O02ODTI36LdYU1PN5-1jQ3$>
>
>
>
> During the WG Directorate and Chair reviews of draft-ct, it was suggested
> to pull out this section to a new draft, as the described problem is not
> specific to CT.
>
>
>
> This document history is described in:
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00#appendix-A.1
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00*appendix-A.1__;Iw!!NEt6yMaO-gk!HK1hMYBmWLPwtF2YCSAargxA_wbJrNC8lBcRa2wgLKBTusa6Yay2o3Ttz1O02ODTI36LdYU1PF2tKmx3$>
>
>
>
> I will cleanup the Author and Contributor list, to not inherit from
> draft-CT.
>
>
>
> About whether the problem being described is real or not, we can have
> further discussions, and clarify draft text as required. We hit these
> issues in our testing with LU and CT, and I think it is very likely to hit
> it in the field. That’s why it is important to document it.
>
>
>
> Just wanted to first clear the confusion on the origin/history of this
> draft. So that we can focus on technical discussion.
>
>
>
> IDR-chairs may want to add something.
>
>
>
> Thanks
>
> Kaliraj
>
>
>
> Juniper Business Use Only
>
> *From: *Robert Raszuk <[e-mail]>
> *Date: *Friday, February 16, 2024 at 9:49 AM
> *To: *Igor Malyushkin <[e-mail]>
> *Cc: *Kaliraj Vairavakkalai <[e-mail]>, Natrajan Venkataraman <
> [e-mail]>, idr@ietf. org <[e-mail]>
> *Subject: *Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt
>
> *[External Email. Be cautious of content]*
>
>
>
> Hey Igor,
>
>
>
> Well I think there is no problem to be solved here to start with.
>
>
>
> It looks to me like someone completely unfamiliar with IETF process or
> even BGP Route Reflection took a CT draft and deleted most text except
> Appendix A, Co-Authors, Contributors and part of References :)
>
>
>
> I am actually surprised that IETF Submit script allowed to post it with
> such document name. Looks like it is broken.
>
>
>
> Cheers,
>
> R.
>
>
>
>
>
> On Fri, Feb 16, 2024 at 6:37 PM Igor Malyushkin <[e-mail]>
> wrote:
>
> Hello all,
>
> Agreed with Robert. I thought too I missed the adoption call and was
> surprised to see the doc already adopted.
>
> About CT parts, to me they look like a some form of advertising, not sure
> they are necessary to express the problem statement at all. Not to mention
> that it looks like AIGP solves the problem in general.
>
>
>
> пт, 16 февр. 2024 г. в 19:27, Robert Raszuk <[e-mail]>:
>
> All,
>
>
>
> > draft-ietf-idr-bgp-fwd-rr-00.txt
>
>
>
> Also please kindly indicate why this text is posted as an IDR WG document
> as the format of the name suggests ...
>
>
>
> I do not recall any single discussion on this proposal on the IDR WG list.
>
>
>
> Are the authors, so many co-authors and a large list of contributors not
> aware about the draft naming convention not to mention BGP Route Reflection
> principles of operation ?
>
>
>
> The Ack section also seems copied from CT draft ... not too mention it
> says this:
>
> The decision to not reuse SAFI 128 and create a new address-family to
> carry these transport-routes was based on suggestion made by Richard
> Roberts and Krzysztof Szarkowicz.¶
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00*appendix-C-2__;Iw!!NEt6yMaO-gk!AZEUHyTPYNlG9OKb52muKBAGkNew-0Po8FKLaviWSEg-Oqp4Bqg_H6hwb1DZEuJaszphNMHxl8ErvDlz$>
>
> I think it would be simply best if you delete this doc from datatracker at
> this point.
>
>
>
> Cheers,
>
> Robert
>
>
>
>
>
>
>
> On Fri, Feb 16, 2024 at 5:24 PM Robert Raszuk <[e-mail]> wrote:
>
> Hi,
>
>
>
> I have two comments on your draft:
>
>
>
> #1 - RFC4456 does not assume RRs not to be in the data plane. Quite
> contrary when this RFC was originally written all RRs were in the
> forwarding path as most networks did not use any form of encapsulation. Yes
> I do recall running network which did not run MPLS nor SR :) In fact the
> mentioned above encapsulations moved the RRs out of data path as
> encapsulated packets did not need IP lookup.
>
>
>
> #2 - What you are saying in respect to CLUSTER_LIST is incorrect. The
> entire point of CLUSTER_LIST is not to allow paths with local CLUSTER_ID to
> enter Route Reflector in the first place. Quote from RFC4456:
>
>
>
> *If the local CLUSTER_ID is found in the CLUSTER_LIST, the advertisement
> received SHOULD be ignored**.*
>
>
>
> Best path has nothing to do with it. The augmentation to BGP best path
> selection only aims for consistent selection not to prevent the loops.
>
>
>
> Conclusion: What you are describing is a route reflector
> misconfiguration not a protocol bug.
>
>
>
> ** "ignored - really means dropped here.
>
>
>
> Cheers,
>
> Robert
>
>
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Fri, Feb 16, 2024 at 2:23 PM
> Subject: I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt
> To: <[e-mail]>
> Cc: <[e-mail]>
>
>
>
> Internet-Draft draft-ietf-idr-bgp-fwd-rr-00.txt is now available. It is a
> work
> item of the Inter-Domain Routing (IDR) WG of the IETF.
>
>    Title:   BGP Route Reflector in Forwarding Path
>    Authors: Kaliraj Vairavakkalai
>             Natrajan Venkataraman
>    Name:    draft-ietf-idr-bgp-fwd-rr-00.txt
>    Pages:   8
>    Dates:   2024-02-16
>
> Abstract:
>
>    The procedures in BGP Route Reflection (RR) spec [RFC4456] primarily
>    deal with scenarios where the RR is not in forwarding path, and is
>    reflecting BGP routes with next hop unchanged.
>
>    These procedures can sometimes result in traffic forwarding loops in
>    deployments where the RR is in forwarding path, and is reflecting BGP
>    routes with next hop set to self.
>
>    This document specifies approaches to minimize possiblity of such
>    traffic forwarding loops.  One of those approaches updates path
>    selection procedures specified in Section 9 of BGP RR.  [RFC4456]
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-fwd-rr/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-bgp-fwd-rr/__;!!NEt6yMaO-gk!AZEUHyTPYNlG9OKb52muKBAGkNew-0Po8FKLaviWSEg-Oqp4Bqg_H6hwb1DZEuJaszphNMHxl6sQStEm$>
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00__;!!NEt6yMaO-gk!AZEUHyTPYNlG9OKb52muKBAGkNew-0Po8FKLaviWSEg-Oqp4Bqg_H6hwb1DZEuJaszphNMHxl5yt5xQa$>
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/i-d-announce__;!!NEt6yMaO-gk!AZEUHyTPYNlG9OKb52muKBAGkNew-0Po8FKLaviWSEg-Oqp4Bqg_H6hwb1DZEuJaszphNMHxl_q06C-f$>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!AZEUHyTPYNlG9OKb52muKBAGkNew-0Po8FKLaviWSEg-Oqp4Bqg_H6hwb1DZEuJaszphNMHxl9CJwiz8$>
>
>