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

[Igor Malyushkin <[e-mail]>]

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. 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.

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. As Alexander mentioned in his
message, it is possible to manipulate a label allocation mode to prevent
the loop. 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.

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
>
>   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
>
>   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$>
>
>