Re: [Idr] BGP RFC 4271 missing 9.1.2.2 section missing shortest cluster length tie breaker

[Enke Chen <[e-mail]>]

Hi, Folks:

As I recall, the reason for having the cluster-list comparison after
router-id was for backward compatibility and deployment. When BGP route
reflection was designed, some networks were already pretty large in terms
of the number of routers. Thus the deployment needed to be gradual and
incremental. Until the deployment was complete, there were routers with the
new code that understood the new attributes, and some did not.  As we know,
all routers inside a network need to be consistent with BGP route selection
in order to avoid forwarding loops. The cluster-list comparison was
introduced as the last step in BGP route selection to minimize risks in
deployment.

It's always difficult for a new BGP route selection algorithm to be
introduced in the middle of a large network.  It has to be designed and
planned very carefully. I would consider the idea of reversing the
"router-id" and "cluster-list" comparison as in the "difficult to deploy"
category.  It's a different story, though, with tunnels, where the
destination lookup is not performed on each hop.

Thanks.   -- Enke

On Thu, Mar 24, 2022 at 6:07 PM Kaliraj Vairavakkalai <kaliraj=
[e-mail]> wrote:

> Gyan,
>
>
>
> Originator-ID when exists on a route is considered as Router-ID.
>
>
>
> > use the cluster-id knob for shortest cluster-id to be picked before the
> neighbor address
>
>
>
> That is not what I said. I was talking about ‘Cluster-List before
> Router-ID’. Not neighbor address.
>
>
>
> Both Juniper and Cisco documentation you cite below show Router-ID step is
> done before Cluster-List, as also is prescribed by RR RFC 4456.
>
>
>
> My point is, doing ‘Router-ID before Cluster-List’ is OK for pure-RR
> scenarios. But it causes problems for “RRs in forwarding path” i.e. RRs
> doing NHS. The problem can be worked around using carefully choosing
> IGP-Cost in LU-networks. And in CT-networks, this can be worked-around by
> not provisioning Colored-tunnels between the pair of Border-nodes (RRs with
> NHS).
>
>
>
> But amending the path-selection steps as noted looks like an easier fix,
> to me.
>
>
>
> So, I wanted to humbly urge the WG to analyze if there are any other
> problems, for which RFC-4456 originally suggested ‘Router-ID before
> Cluster-List’ and not other way around.
>
>
>
> Thanks
>
> Kaliraj
>
>
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Thursday, March 24, 2022 at 5:13 PM
> *To: *Kaliraj Vairavakkalai <[e-mail]>
> *Cc: *IDR List <[e-mail]>, Jeffrey Haas <[e-mail]>, Susan Hares
> <[e-mail]>
> *Subject: *Re: [Idr] BGP RFC 4271 missing 9.1.2.2 section missing
> shortest cluster length tie breaker
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Kaliraj
>
>
>
> Most all implementations as well as here we are talking about Cisco and
> Juniper both follow the proper BGP best path selection to avoid routing
> loops or sub optimal routing even though the RFC’s maybe disjointed and not
> stated clearly.  I agree with what you stated that you have to  use the
> cluster-id knob for shortest cluster-id to be picked before the neighbor
> address.
>
>
>
> See the Juniper link below it does not say but must be assuming the
> cluster knob must be used since or shows the correct best path selection.
> I think that must be the best practice when configuring BGP or you can run
> into routing loops or sub optimal routing.
>
>
>
> Multiple cluster-id should only come into play with a hierarchical layered
> RR architecture where the RRs fully meshed  which occurs 1- PE-RR-RR-PE
> versus 2- PE-RR-PE you 1-would have 2 cluster-id in the cluster list and 2-
> 1 cluster-id in cluster list.
>
>
>
> I am planning to address the BGP best path selection in an informational
> draft with an IDR Wiki for vendor implementations of BGP best path
> selection.  BGP best path selection is a critical issue for
> interoperability.  I may also try to develop a base core BGP draft as well
> that covers PE and RR eBGP and iBGP holistically in one specification.
>
>
>
> So per below both Juniper and Cisco follow the proper best path selection
> with the lowest router-id, shortest cluster list followed by the lowest
> neighbor address tie breaker.
>
>
>
> So any lab test done on Juniper or Cisco in a CT or CAR EPE scenario would
> be fine as far as picking the RR shortest cluster length before the lowest
> neighbor address.
>
>
>
> Note that since we are talking iBGP the neighbor address is the same as
> the router-id which is the loopback of the egress PE.
>
>
>
> The originator-id is set by the RR-C PE route originator and then when the
> RR receives it appends it’s cluster-id to the cluster list so now when the
> PE receives two paths with same originator-id / router-id which the
> originator-id and router-id would be the same the PE should select the path
> with shorter cluster length which if it’s a tie same cluster length then it
> would still drop down to lowest neighbor IP.  The originator-id does not
> come into play so to speak in BGP best path selection is lowest router-id,
> shortest cluster length, lowest Neigjhbor IP.
>
>
>
>
>
> Cisco BGP Best path selection - rule 11, 12, 13
>
>
>
>
> https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
> <https://urldefense.com/v3/__https:/www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html__;!!NEt6yMaO-gk!Rlx_-1v9e6EoWJdl2zftxsF6AD5K6uIdjed52Yt6ouHg3TizoN7wzgveeVZ4v2J5$>
>
>
>
> 12. If the originator or router ID is the same for multiple paths, prefer
> the path with the minimum cluster list length.
>
>
>
>
>
> Juniper BGP Best Path Selection - rule 13, 14, 15
>
>
>
>
> https://www.juniper.net/documentation/en_US/junos/topics/reference/general/routing-protocols-address-representation.html
> <https://urldefense.com/v3/__https://www.juniper.net/documentation/en_US/junos/topics/reference/general/routing-protocols-address-representation.html__;!!Mt_FR42WkD9csi9Y!KQZtJfuBo-ukS37YAMzM4u7mcpYo50FFSJeAvT4cvgHKpFM0Fz_M561WCs-TdHN0wuKbyw$>
>
>
>
>
>
>
>
> 14. Prefer the path with the shortest cluster list length. The length
> is 0 for no list.
>
>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
> On Thu, Mar 24, 2022 at 2:03 PM Kaliraj Vairavakkalai <[e-mail]>
> wrote:
>
> Jeff, Gyan, Sue,
>
>
>
> Let me explain the problem with cluster-list step in path-selection
> specification.
>
>
>
> rfc4456#section-9
>
>
>
> In addition, the following rule SHOULD be inserted between Steps
>
>   f) and g)
>
>
>
>
>
> rfc4271:
>
>
>
>       f) Remove from consideration all routes other than the route that
>
>          was advertised by the BGP speaker with the lowest BGP
>
>          Identifier value.
>
>
>
>       g) Prefer the route received from the lowest peer address.
>
>
>
> The problem in rfc4456#section-9 is:
>
>
>
> If step f already breaks ties because of Originator-ID, we will not reach
> the new cluster-list comparison step.
>
>
>
> e.g.
>
>
>
> This will happen when a BGP-LU route for PE11 loopback is advertised in
> neighboring AS 2 domain, in below e.g. topology:
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes-13#section-15.1
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes-13*section-15.1__;Iw!!NEt6yMaO-gk!Rlx_-1v9e6EoWJdl2zftxsF6AD5K6uIdjed52Yt6ouHg3TizoN7wzgveeTQpH_K1$>
>
>
>
> When the EBGP-LU route PE11/32 is readvertised by ASBR21, ASBR22, they
> will add their respective Originator-IDs.
>
>
>
> ABR23 may receive routes via the following paths:
>
>
>
>    1. ASBR21->RR27->ABR23.
>
>
>    - Originator-ID ASBR21
>       - Nexthop is received as ASBR21
>
>
>    1. ASBR21->RR27->ABR24 [nhs] ->RR26->ABR23
>
>
>    - Originator-ID ASBR21.
>       - Nexthop is received as ABR24
>       - Longer cluster-list
>
>
>    1. ASBR22->RR27->ABR23.
>
>
>    - Originator-ID ASBR22
>       - Nexthop is received as ASBR22
>
>
>    1. ASBR22->RR27->ABR24 [nhs] ->RR26->ABR23
>
>
>    - Originator-ID ASBR22.
>       - Nexthop is received as ABR24
>       - Longer cluster-list
>
>
>
>
>
> Assume originator-ID ASBR21 wins over ASBR22 originator-ID.
>
>
>
> In above condition ABR23 may chose route 2 above (ABR24 nexthop) as
> best-path. Instead of the intended ASBR21.
>
>
>
> And similarly, ABR24 may chose ABR23 as the best-path. Thus making a
> forwarding loop.
>
>
>
> This can be avoided only if “cluster-list comparison” is performed before
> Originator-ID/Router-ID step.
>
>
>
> So, in conclusion the reported problem was not that rfc4456 does not talk
> about cluster-list step.
>
>
>
> The problem is that it doesn’t work appropriately as specified currently,
> for these “RR doing nexthop-self” scenarios.
>
>
>
> Thanks
>
> Kaliraj
>
>
>
> *From: *Idr <[e-mail]> on behalf of Susan Hares <
> [e-mail]>
> *Date: *Thursday, March 24, 2022 at 1:23 AM
> *To: *'Gyan Mishra' <[e-mail]>, 'Jeffrey Haas' <
> [e-mail]>
> *Cc: *'IDR List' <[e-mail]>
> *Subject: *Re: [Idr] BGP RFC 4271 missing 9.1.2.2 section missing
> shortest cluster length tie breaker
>
> *[External Email. Be cautious of content]*
>
>
>
> Gyan:
>
>
>
> New drafts continually propose additions to RFC4271 route selection .
>   One such draft is:  draft-ietf-bess-evpn-ipvpn-interworking-06
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking/__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jwxo3NfnX$>
>
>
>
> One of the key places to look for RFC4271 for a new BGP is the updates
> list.  You will note it says:
>
>
>
> Updated by RFC 6286
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc6286/__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw1jTUEYR$>
> , RFC 6608
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc6608/__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw1VR00ih$>
> , RFC 6793
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc6793/__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw-iX1CuA$>
> , RFC 7606
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc7606/__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw1cqRPWw$>
> , RFC 7607
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc7607/__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw-Swxl9-$>
> , RFC 7705
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc7705/__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw7p_Ekpo$>
> , RFC 8212
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc8212/__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw7BbH_Dl$>
> , RFC 8654
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc8654/__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw3blnz9s$>
> , RFC 9072
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc9072/__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw4mR5Ukn$>
>
>
>
> You will note that RFC 4456 is not on that list.
>
>
>
> *9*
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4456*section-9__;Iw!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw-ZqQutS$>*.
> Impact on Route Selection*
>
>
>
>    The BGP Decision Process Tie Breaking rules (Sect.  9.1.2.2, [1
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4456*ref-1__;Iw!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw-LFOgze$>])
> are
>
>    modified as follows:
>
>
>
>       If a route carries the ORIGINATOR_ID attribute, then in Step f)
>
>       the ORIGINATOR_ID SHOULD be treated as the BGP Identifier of the
>
>       BGP speaker that has advertised the route.
>
>
>
>       In addition, the following rule SHOULD be inserted between Steps
>
>       f) and g): a BGP Speaker SHOULD prefer a route with the shorter
>
>       CLUSTER_LIST length.  The CLUSTER_LIST length is zero if a route
>
>       does not carry the CLUSTER_LIST attribute.
>
>
>
> It is one of the RFCs, I think should indicate it updates RFC4271.
>
>
>
> A draft with all BGP updates would be useful for many reasons.
>
>
>
>
>
> Cheers, Sue
>
>
>
> *From:* Idr [mailto:[e-mail]] *On Behalf Of *Gyan Mishra
> *Sent:* Wednesday, March 23, 2022 5:02 PM
> *To:* Jeffrey Haas
> *Cc:* IDR List
> *Subject:* Re: [Idr] BGP RFC 4271 missing 9.1.2.2 section missing
> shortest cluster length tie breaker
>
>
>
> Hi Jeffrey
>
>
>
> Understood on base features, however I would have thought all of best path
> selection would be part of the base BGP RFC.
>
>
>
> I see that in section 9 for cluster length. Excellent!
>
>
>
> I think a core BGP draft that has the best path selection as well as all
> core features in one central document is a worthy effort as it would not be
> difficult to spin up and I can see would be valuable for implementations as
> well as operators.
>
>
>
> Responses in-line
>
>
>
> Thank you
>
>
>
>
>
> Gyan
>
>
>
> On Wed, Mar 23, 2022 at 4:20 PM Jeffrey Haas <[e-mail]> wrote:
>
> Gyan,
>
>
>
> RFC 4271 only specifies the base BGP feature.  IETF mostly does protocol
> specification "by patch".  Theoretically each of the additional RFCs with
> their dependencies are standalone optional features.
>
>
>
>    Gyan> Ack
>
>
>
> In practice, enough features are "core" enough that if we ever revised BGP
> we might want to pull them into the core document.
>
>
>
> Gyan> Agreed.  I think that would be honestly a worthwhile effort and I
> don’t think to difficult.  I would be happy to spin up a first cut at the
> core BGP draft.
>
>
>
>  This conversation was one of the difficult discussions about what's core
> enough to go into the IETF BGP YANG module.
>
>
>
> You'll have the cluster list portion in:
>
> https://datatracker.ietf.org/doc/html/rfc4456
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4456__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw6yl0nc3$>,
> §9
>
>
>
> There's no high level roadmap of all of the RFCs that impact route
> selection.  There's quite a few, and theoretically some may not be in an
> implementation.
>
>
>
>     Gyan> I have a database of RFC sorted by protocols and RFC analysis I
> have done over the years related that is ongoing personal effort, and I can
> easily glean from that to build the document.
>
>
>
> Thoughts ??
>
>
>
> Hope this helps.
>
>
>
> -- Jeff
>
>
>
>
>
>
>
> On Mar 23, 2022, at 4:15 PM, Gyan Mishra <[e-mail]> wrote:
>
>
>
>
>
> Hi Jeffrey
>
>
>
> While reviewing the CT draft I discussed with Kaliraj the verbiage related
> to RFC 4271 section 9.1.2.2 tiebreaker section that it’s missing the
> shortest cluster-id tiebreaker.
>
>
>
> After looking at the section again it does appear to be missing other tie
> breakers in the best path selection such as lowest IGP metric for iBGP tie
> breaker for example.
>
>
>
> Do you think it’s worth updating RFC 4271 as a BIS or new version.
>
>
>
> Most all vendors support it correctly and so I don’t think it should be a
> big deal.
>
>
>
> Cisco BGP Best path selection
>
>
>
>
> https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
> <https://urldefense.com/v3/__https:/www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw20cFMwj$>
>
>
>
> 12. If the originator or router ID is the same for multiple paths, prefer
> the path with the minimum cluster list length.
>
>
>
>
>
> Juniper BGP Best Path Selection
>
>
>
>
> https://www.juniper.net/documentation/en_US/junos/topics/reference/general/routing-protocols-address-representation.html
> <https://urldefense.com/v3/__https://www.juniper.net/documentation/en_US/junos/topics/reference/general/routing-protocols-address-representation.html__;!!Mt_FR42WkD9csi9Y!KQZtJfuBo-ukS37YAMzM4u7mcpYo50FFSJeAvT4cvgHKpFM0Fz_M561WCs-TdHN0wuKbyw$>
>
>
>
>
>
>
>
> 14. Prefer the path with the shortest cluster list length. The length
> is 0 for no list.
>
> --
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw0vMnJDb$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email **[e-mail]* <[e-mail]>
>
> *M 301 502-1347*
>
>
>
>
>
> --
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw0vMnJDb$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email **[e-mail]* <[e-mail]>
>
> *M 301 502-1347*
>
>
>
>
>
> Juniper Business Use Only
>
> --
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Rlx_-1v9e6EoWJdl2zftxsF6AD5K6uIdjed52Yt6ouHg3TizoN7wzgveeXOa1YRh$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> Juniper Business Use Only
> _______________________________________________
> Idr mailing list
> [e-mail]
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!Mt_FR42WkD9csi9Y!KQZtJfuBo-ukS37YAMzM4u7mcpYo50FFSJeAvT4cvgHKpFM0Fz_M561WCs-TdHOUqCG7yg$
>