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

From: Gyan Mishra <[email-masked]>
Date: Wed, 23 Mar 2022 16:15:08 -0400

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

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

14. Prefer the path with the shortest cluster list length. The length is 0
for no list.
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Mar 2022 16:20:20 -0400

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.

In practice, enough features are "core" enough that if we ever revised BGP we might want to pull them into the core document.  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://datatracker.ietf.org/doc/html/rfc4456>, §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.

Hope this helps.

-- Jeff

> On Mar 23, 2022, at 4:15 PM, Gyan Mishra <[email-masked]> 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.
> 
> Most all vendors support it correctly and so I don’t think it should be a big deal.
> 
> https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html <https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html>
> 12. If the originator or router ID is the same for multiple paths, prefer the path with the minimum cluster list length.
> 
> 
> https://www.juniper.net/documentation/en_US/junos/topics/reference/general/routing-protocols-address-representation.html <https://www.juniper.net/documentation/en_US/junos/topics/reference/general/routing-protocols-address-representation.html>
> 
> 
> 14. Prefer the path with the shortest cluster list length. The length is 0 for no list.
> -- 
> Gyan Mishra
> Network Solutions Architect 
> Email [email-masked] <mailto:[email-masked]>
> M 301 502-1347
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 23 Mar 2022 17:02:07 -0400

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 <[email-masked]> 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.
>
> https://datatracker.ietf.org/doc/html/rfc4456, §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 ??

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 23 Mar 2022 22:46:46 +0100

Gyan,

So what you are suggesting would be really for IBGP as in EBGP all bets are
off and anyone can choose best path as it seems fit by local policy.

Now for IBGP historically consistent path selection was also very
important. However now if you look practically most networks use some form
of encapsulation and you really map prefix to next hop only once. Ingress
to Egress.

While you can grep lot's of RFCs and drafts to find references to various
attributes they introduced and effects on best path selection (for example
you did not mention cost community for some reason yet - as described
in draft-ietf-idr-custom-decision) you really can not that easily grep
commercial implementations what is happening under the hood.

We used to have a joke that maybe it would be worth adding a new knob in
BGP cli "bgp rfc-compliant" but then we realized that it would really not
work that well :)

Best,
Robert.

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 23 Mar 2022 18:31:38 -0400

Robert

I see what you are saying however you don’t always have local policy and
thus end up resolve via tie breaker.

I believe there was a thread related to add paths and path id which I think
you were on the thread where that tie breaker for add path path id was not
defined in any RFC.

Responses in-line

Thanks

Gyan

On Wed, Mar 23, 2022 at 5:46 PM Robert Raszuk <[email-masked]> wrote:

> Gyan,
>
> So what you are suggesting would be really for IBGP as in EBGP all bets
> are off and anyone can choose best path as it seems fit by local policy.
>

   Gyan> Local policy is not always the case as you may have policy that
applies to some but not all routes conditionally or may not have any
policy.  On eBGP peers you tend to have local policy but on iBGP peers not
necessarily and if anything would be conditional for special cases.

> of encapsulation and you really map prefix to next hop only once. Ingress

    Gyan> Ack for next hop being set once for encapsulations.  However
there could be local policies setting optional non transitive attribute
like local pref or MED and that can alter best path selection or even core
link failures that alter the lowest IGP metric tie breaker which kicks in.

> commercial implementations what is happening under the hood.

   Gyan> Agreed but based on implementation documentation at least you know
the functionality independent of IETF standards.

> BGP cli "bgp rfc-compliant" but then we realized that it would really not

   😀

>> Understood on base features, however I would have thought all of best
>> path selection would be part of the base BGP RFC.
>>

*Gyan Mishra*

*M 301 502-1347*

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 24 Mar 2022 04:22:01 -0400

Gyan: 

New drafts continually propose additions to RFC4271 route selection .   One such draft is:   <https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking/> draft-ietf-bess-evpn-ipvpn-interworking-06

One of the key places to look for RFC4271 for a new BGP is the updates list.  You will note it says: 

Updated by  <https://datatracker.ietf.org/doc/rfc6286/> RFC 6286,  <https://datatracker.ietf.org/doc/rfc6608/> RFC 6608,  <https://datatracker.ietf.org/doc/rfc6793/> RFC 6793,  <https://datatracker.ietf.org/doc/rfc7606/> RFC 7606,  <https://datatracker.ietf.org/doc/rfc7607/> RFC 7607,  <https://datatracker.ietf.org/doc/rfc7705/> RFC 7705,  <https://datatracker.ietf.org/doc/rfc8212/> RFC 8212,  <https://datatracker.ietf.org/doc/rfc8654/> RFC 8654,  <https://datatracker.ietf.org/doc/rfc9072/> RFC 9072

You will note that RFC 4456 is not on that list.  

9 <https://datatracker.ietf.org/doc/html/rfc4456#section-9> .  Impact on Route Selection

   The BGP Decision Process Tie Breaking rules (Sect.  9.1.2.2, [1 <https://datatracker.ietf.org/doc/html/rfc4456#ref-1> ]) 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:[email-masked]] 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 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

Gyan,

   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.

    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

 

Hi Jeffrey 

 

 

-- 

 <http://www.verizon.com/> Image removed by sender.

Gyan Mishra

Email [email-masked]

M 301 502-1347

-- 

 <http://www.verizon.com/> Image removed by sender.

Gyan Mishra

Email [email-masked]

M 301 502-1347

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 24 Mar 2022 06:39:32 -0400

Gyan,

> On Mar 23, 2022, at 5:02 PM, Gyan Mishra <[email-masked]> wrote:

Since the features are "optional" in many cases, a "grand unified specification of how Things Must Work" is probably not an effort that will be rewarded.

However, there is reasonable room for either an informational draft or even a page on the IDR wiki that is a pointer to the specifications used for route selection in various implementations... and perhaps even a manifest of what RFCs a given implementor will claim it is following for its route selection.

I'm certainly willing to contribute Juniper's claimed support for a current release.  (And need to probably supply this info to our documentation group.)

-- Jeff

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 24 Mar 2022 11:44:38 -0400

Excellent !

I will start with an informational draft.

Also a pointer to IDR wiki with implementation specific details is a
great idea.

As far as unified core base BGP specification I will defer based on your
comments.

Kind Regards

Gyan

On Thu, Mar 24, 2022 at 6:39 AM Jeffrey Haas <[email-masked]> wrote:

>> In practice, enough features are "core" enough that if we ever revised
>> BGP we might want to pull them into the core document.
>>
>
> Since the features are "optional" in many cases, a "grand unified
> specification of how Things Must Work" is probably not an effort that will
> be rewarded.
>
> However, there is reasonable room for either an informational draft or
> even a page on the IDR wiki that is a pointer to the specifications used
> for route selection in various implementations... and perhaps even a
> manifest of what RFCs a given implementor will claim it is following for
> its route selection.
>
> I'm certainly willing to contribute Juniper's claimed support for a
> current release.  (And need to probably supply this info to our
> documentation group.)
>
> -- Jeff
>
> --

*Gyan Mishra*

*M 301 502-1347*

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Thu, 24 Mar 2022 18:03:50 +0000

Jeff, Gyan, Sue,

Let me explain the problem with cluster-list step in path-selection specification.

rfc4456#section-9

  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

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
  2.  ASBR21->RR27->ABR24 [nhs] ->RR26->ABR23
     *   Originator-ID ASBR21.
     *   Nexthop is received as ABR24
     *   Longer cluster-list
  3.  ASBR22->RR27->ABR23.
     *   Originator-ID ASBR22
     *   Nexthop is received as ASBR22
  4.  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 <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Thursday, March 24, 2022 at 1:23 AM
To: 'Gyan Mishra' <[email-masked]>, 'Jeffrey Haas' <[email-masked]>
Cc: 'IDR List' <[email-masked]>
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$>

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

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:

Cheers, Sue

Hi Jeffrey

Responses in-line

Thank you

Gyan

On Wed, Mar 23, 2022 at 4:20 PM Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
Gyan,

   Gyan> Ack

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

Thoughts ??

Hope this helps.

-- Jeff

On Mar 23, 2022, at 4:15 PM, Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jeffrey

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

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw0vMnJDb$>
Gyan Mishra
Network Solutions Architect
Email [email-masked]<mailto:[email-masked]>
M 301 502-1347

--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw0vMnJDb$>

Gyan Mishra

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

Juniper Business Use Only

---

From: Alexander Okonnikov <[email-masked]>
Date: Fri, 25 Mar 2022 00:28:09 +0300

Hi Kaliraj,

RFC 4456, section 10, says that NEXT_HOP SHOULD NOT be changed. In section 11 we see follow:

"To prevent routing loops and maintain consistent routing view, it is essential that the network topology be carefully considered in designing a route reflection topology."

I guess that RFC 4456 says 'SHOULD NOT' rather than 'MUST NOT' due to reason, that even NHS RRs could be deployed in such way that there will no be forwarding loops. Otherwise it is to be treated as 'MUST NOT'.

If you don't change NEXT_HOP, the 'intended' path would be chosen as the best one. Once you perform NHS, you reset NH Cost, and this is (step 'e' of the tie breaking procedure) reason why ABR23 chooses path via ABR24 (and vice versa) rather than via ASBR21/ASBR22. And even if NH Cost is the same, it is not the problem of cluster list that 'suboptimal' NH was chosen. In order to mitigate the problem with resetting NH Cost we have AIGP (RFC 7311) (compared before step 'a' of the procedure) or we may play with (increase) MED (step 'c' of the procedure) when we use NHS.

Regarding forwarding loop - if you decide to use topologies like you provided, and you won't to play with AIGP or MED, you have to use 'per-NH' label-allocation on NHS RRs, rather than 'per-prefix' one. In your example ABR23 readvertises to RR26 the path, where previous NH was ASBR21 or ASBR22. Hence, ABR23 should then install corresponding swap entry such that incoming traffic will be switched towards ASBR21/ASBR22 (according to readvertised path) and not to ABR24. The same for ABR24. If NHS RR follow this rule, there will not be forwarding loop.

What about provided example - it seems that there is problem with the design itself rather than with BGP or BGP RR specs.

Thank you.

> 24 марта 2022 г., в 21:03, Kaliraj Vairavakkalai <kaliraj=[email-masked]> написал(а):
> 
> Jeff, Gyan, Sue,
>  
> https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes-13#section-15.1 <https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes-13#section-15.1>
>  
> ASBR21->RR27->ABR23.
> Originator-ID ASBR21
> Nexthop is received as ASBR21
> ASBR21->RR27->ABR24 [nhs] ->RR26->ABR23
> Originator-ID ASBR21.
> Nexthop is received as ABR24
> Longer cluster-list
> ASBR22->RR27->ABR23.
> Originator-ID ASBR22
> Nexthop is received as ASBR22
> ASBR22->RR27->ABR24 [nhs] ->RR26->ABR23
> Originator-ID ASBR22.
> Nexthop is received as ABR24
> Longer cluster-list
>  
>  
> From: Idr <[email-masked] <mailto:[email-masked]>> on behalf of Susan Hares <[email-masked] <mailto:[email-masked]>>
> To: 'Gyan Mishra' <[email-masked] <mailto:[email-masked]>>, 'Jeffrey Haas' <[email-masked] <mailto:[email-masked]>>
> Cc: 'IDR List' <[email-masked] <mailto:[email-masked]>>
> 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$>
>  
> 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$>
>  
> 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:
>  
> From: Idr [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Gyan Mishra
> On Wed, Mar 23, 2022 at 4:20 PM Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
> Gyan,
>  
> https://datatracker.ietf.org/doc/html/rfc4456 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4456__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw6yl0nc3$>, §9
>  
> On Mar 23, 2022, at 4:15 PM, Gyan Mishra <[email-masked] <mailto:[email-masked]>> wrote:
>  
>  
> Hi Jeffrey 
>  
> 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$>
>  
>  <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw0vMnJDb$>
> Gyan Mishra
>  <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw0vMnJDb$>
> Gyan Mishra
> _______________________________________________
> Idr mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 24 Mar 2022 20:13:01 -0400

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

Juniper BGP Best Path Selection - rule 13, 14, 15

Kind Regards

Gyan
On Thu, Mar 24, 2022 at 2:03 PM Kaliraj Vairavakkalai <[email-masked]>
wrote:

> This will happen when a BGP-LU route for PE11 loopback is advertised in
> neighboring AS 2 domain, in below e.g. topology:
>
>
>
>
> When the EBGP-LU route PE11/32 is readvertised by ASBR21, ASBR22, they
> will add their respective Originator-IDs.
>
>
>
>       - Originator-ID ASBR21
>       - Nexthop is received as ASBR21
>       - Originator-ID ASBR21.
>       - Nexthop is received as ABR24
>       - Longer cluster-list
>    3. ASBR22->RR27->ABR23.
>       - Originator-ID ASBR22
>       - Nexthop is received as ASBR22
>       - Originator-ID ASBR22.
>       - Nexthop is received as ABR24
>       - Longer cluster-list
>
>
>
>
>
> In above condition ABR23 may chose route 2 above (ABR24 nexthop) as
> best-path. Instead of the intended ASBR21.
>
>
>
> The problem is that it doesn’t work appropriately as specified currently,
> for these “RR doing nexthop-self” scenarios.
>
>
>
> Thanks
>
> Kaliraj
>
>
>
> *From: *Idr <[email-masked]> on behalf of Susan Hares <
> [email-masked]>
> *Date: *Thursday, March 24, 2022 at 1:23 AM
> *To: *'Gyan Mishra' <[email-masked]>, 'Jeffrey Haas' <
> [email-masked]>
> *Cc: *'IDR List' <[email-masked]>
> *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$>
>
>
>
> 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$>
>
>
>
> *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:
>
>
>
> *From:* Idr [mailto:[email-masked]] *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
>
>
>
> https://datatracker.ietf.org/doc/html/rfc4456
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4456__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw6yl0nc3$>,
> §9
>
>
>
> <https://urldefense.com/v3/__https:/www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw20cFMwj$>
>
>
>
> *Network Solutions Architect *
>
> *Email [email-masked]* <[email-masked]>
>
> *M 301 502-1347*
>
>
>
>
>
> --
>
> *Network Solutions Architect *
>
> *Email [email-masked]* <[email-masked]>
>
> *M 301 502-1347*
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Fri, 25 Mar 2022 00:54:02 +0000

Agree, playing with IGP-cost is one of the ways to work around this problem. But I am noting that performing Cluster-List step before Originator-ID will avoid the problem.

IOW, what is the downside of performing Cluster-List step before Originator-ID? I can’t think of any. IMHO, Like AS-path length in EBGP-routes,
Cluster-List length provides same functionality for IBGP-routes. So these should be compared before arbitrary tiebreakers like RouterID or Peer-address.

Per-nexthop or per-prefix label allocation mode is orthogonal matter. In either mode, the forwarding information for the transit-route is derived from the best-path for PE11 prefix.
Which is why the pathselection of routes for PE11 prefix makes a difference, and not honoring cluster-list causes this problem.

About the example topology, it is a pair of Border-Nodes (RRs with NHS), for two regions in an AS. Each region having its own Transport layer RR.

Which part of this network design is impractical? Pair of Border-Nodes? or having Transport-RR in each region?

My point was: It may be relatively hard to play with IGP-costs and make things work. And this small tweak to path-selection may help such “RR with NHS” deployment scenarios.

Thanks
Kaliraj
From: Alexander Okonnikov <[email-masked]>
Date: Thursday, March 24, 2022 at 2:28 PM
To: Kaliraj Vairavakkalai <[email-masked]>
Cc: Susan Hares <[email-masked]>, Gyan Mishra <[email-masked]>, Jeffrey Haas <[email-masked]>, IDR List <[email-masked]>
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,

Thank you.

24 марта 2022 г., в 21:03, Kaliraj Vairavakkalai <kaliraj=[email-masked]<mailto:kaliraj=[email-masked]>> написал(а):

Jeff, Gyan, Sue,

rfc4456#section-9

rfc4271:

e.g.

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!WDjwgcgDH16XpIHuLTTSXItAqMb1X4Amspli_-xBS9bWSXU0EVy2PibfnKkKVvSL$>

1.      ASBR21->RR27->ABR23.

o    Originator-ID ASBR21

o    Nexthop is received as ASBR21

o    Originator-ID ASBR21.

o    Nexthop is received as ABR24

o    Longer cluster-list

3.      ASBR22->RR27->ABR23.

o    Originator-ID ASBR22

o    Nexthop is received as ASBR22

o    Originator-ID ASBR22.

o    Nexthop is received as ABR24

o    Longer cluster-list

Thanks
Kaliraj

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 24, 2022 at 1:23 AM
To: 'Gyan Mishra' <[email-masked]<mailto:[email-masked]>>, 'Jeffrey Haas' <[email-masked]<mailto:[email-masked]>>
Cc: 'IDR List' <[email-masked]<mailto:[email-masked]>>
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:

Cheers, Sue

Hi Jeffrey

Responses in-line

Thank you

Gyan

   Gyan> Ack

Thoughts ??

Hope this helps.

-- Jeff

Hi Jeffrey

Juniper Business Use Only
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!WDjwgcgDH16XpIHuLTTSXItAqMb1X4Amspli_-xBS9bWSXU0EVy2PibfnJDnWWTH$>

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Fri, 25 Mar 2022 01:06:31 +0000

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 <[email-masked]>
Date: Thursday, March 24, 2022 at 5:13 PM
To: Kaliraj Vairavakkalai <[email-masked]>
Cc: IDR List <[email-masked]>, Jeffrey Haas <[email-masked]>, Susan Hares <[email-masked]>
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.

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

Kind Regards

Gyan
On Thu, Mar 24, 2022 at 2:03 PM Kaliraj Vairavakkalai <[email-masked]<mailto:[email-masked]>> wrote:
Jeff, Gyan, Sue,

rfc4456#section-9

rfc4271:

e.g.

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

  1.  ASBR21->RR27->ABR23.

     *   Originator-ID ASBR21

  1.  ASBR21->RR27->ABR24 [nhs] ->RR26->ABR23

     *   Originator-ID ASBR21.

  1.  ASBR22->RR27->ABR23.

     *   Originator-ID ASBR22

  1.  ASBR22->RR27->ABR24 [nhs] ->RR26->ABR23

     *   Originator-ID ASBR22.

Thanks
Kaliraj

Gyan:

Cheers, Sue

From: Idr [mailto:[email-masked]<mailto:[email-masked]>] 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

Responses in-line

Thank you

Gyan

   Gyan> Ack

Thoughts ??

Hope this helps.

-- Jeff

Hi Jeffrey

--

Gyan Mishra

M 301 502-1347

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Rlx_-1v9e6EoWJdl2zftxsF6AD5K6uIdjed52Yt6ouHg3TizoN7wzgveeXOa1YRh$>

Gyan Mishra

M 301 502-1347

---

From: Alexander Okonnikov <[email-masked]>
Date: Fri, 25 Mar 2022 04:52:03 +0300

Hi Kaliraj,

Inline

> 25 марта 2022 г., в 03:54, Kaliraj Vairavakkalai <[email-masked]> написал(а):
> 

No, it will not. In your case OriginatorID is the same (e.g. ASBR21) for the two paths. Hence, tie breaking procedure will proceed to Cluster List length comparison.
> Cluster-List length provides same functionality for IBGP-routes. So these should be compared before arbitrary tiebreakers like RouterID or Peer-address.

There is one significant difference between AS Path and Cluster List: in regular eBGP an NH is changed while route is crossing AS boundary (unless we use 'next-hop-unchanged'); in regular iBGP with RRs an NH is not changed (unless we use 'next-hop-self'). Hence, usually AS Path has impact on data path, while Cluster List usually don't.
> Per-nexthop or per-prefix label allocation mode is orthogonal matter. In either mode, the forwarding information for the transit-route is derived from the best-path for PE11 prefix.

No, in your case you are talking about BGP-LU. In this case NHS RRs are LSRs on BGP LSP. Depending on label allocation mode, LSR will behave differently. If we use 'per-NH' mode, NHS RR has 1:1 mapping of incoming label to outgoing label/interface. In your case, if ABR23 has chosen the best path via ABR24, and ABR24 via ABR23, then when ABR23 will act as iLER, it will send traffic towards PE11 via ABR24. But, when it receives labeled packet from ABR24 towards PE11, and it applies 'per-NH' mode, it will label switch packet to ASBR21. In case of 'per-prefix' it will forward it back to ABR24.

> Which is why the pathselection of routes for PE11 prefix makes a difference, and not honoring cluster-list causes this problem.

In your case cluster list would solve the problem, if it would be compared before comparing NH cost, or in specific case when NH cost to ABR24 (ABR23) from ABR23 (ABR24) is equal to NH cost to ASBR21 from ABR23/ABR24. But comparing cluster list before NH cost will bring the problem in other topologies. Comparing it before Originator ID will not solve the problem.
> Which part of this network design is impractical? Pair of Border-Nodes? or having Transport-RR in each region?

For 'per-prefix' mode RR should be downstream for RRC (like LFA), otherwise there will be forwarding loop. With 'per-NH' it is not a matter. In your case, two ABRs in respect to PE11 route point to each other.
> My point was: It may be relatively hard to play with IGP-costs and make things work. And this small tweak to path-selection may help such “RR with NHS” deployment scenarios.

AIGP works automatically. Also, path with shorter cluster list may be more distant than one with longer cluster list. 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.

Thank you.

> Kaliraj 
> From: Alexander Okonnikov <[email-masked] <mailto:[email-masked]>>
> To: Kaliraj Vairavakkalai <[email-masked] <mailto:[email-masked]>>
> Cc: Susan Hares <[email-masked] <mailto:[email-masked]>>, Gyan Mishra <[email-masked] <mailto:[email-masked]>>, Jeffrey Haas <[email-masked] <mailto:[email-masked]>>, IDR List <[email-masked] <mailto:[email-masked]>>
> 24 марта 2022 г., в 21:03, Kaliraj Vairavakkalai <kaliraj=[email-masked] <mailto:kaliraj=[email-masked]>> написал(а):
>  
> Jeff, Gyan, Sue,
>  
> 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!WDjwgcgDH16XpIHuLTTSXItAqMb1X4Amspli_-xBS9bWSXU0EVy2PibfnKkKVvSL$>
>  
> https://www.ietf.org/mailman/listinfo/idr <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!WDjwgcgDH16XpIHuLTTSXItAqMb1X4Amspli_-xBS9bWSXU0EVy2PibfnJDnWWTH$>
>  
>

---

From: Enke Chen <[email-masked]>
Date: Thu, 24 Mar 2022 20:06:26 -0700

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=
[email-masked]> wrote:

> 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).
>
>
>
> 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 <[email-masked]>
> *Date: *Thursday, March 24, 2022 at 5:13 PM
> *To: *Kaliraj Vairavakkalai <[email-masked]>
> *Cc: *IDR List <[email-masked]>, Jeffrey Haas <[email-masked]>, Susan Hares
> <[email-masked]>
> 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.
>
>
>
> 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.
>
>
>
> <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$>
>
>
>
> <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$>
>
>
>
>
>
>
>
> <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$>
>
>
>
> <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$>
>
>
>
>
>
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Rlx_-1v9e6EoWJdl2zftxsF6AD5K6uIdjed52Yt6ouHg3TizoN7wzgveeXOa1YRh$>
>
> *Gyan Mishra*
>
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!Mt_FR42WkD9csi9Y!KQZtJfuBo-ukS37YAMzM4u7mcpYo50FFSJeAvT4cvgHKpFM0Fz_M561WCs-TdHOUqCG7yg$
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 25 Mar 2022 00:49:49 -0400

Hi Kaliraj

What you are saying makes complete sense and I agree flipping the
cluster-id to be before the router-is better optimization for RR in the
forwarding plane makes complete sense and is much better optimization for
the PE-RR BGP updates PE picking the path with the shortest cluster-list.

This problem has not caused any  issues in the industry for the more common
pure RR but I can see how it could definitely impact any situation with RR
in forwarding plane and adversely impact routing due to the path selection.

For pure RR here is an example where even though the very long cluster list
is chosen it does not cause any issues.

 PE-RR1-RR-RR ( RR’s many layers deep) RID=.1
   \
   RR2-PE RID=.2

In this case RR1 is picked with the current best path selection.

The cluster-list just shows how many RRs the path was reflected through
before it got to RR1 in this case, so the control plan is still optimal and
the PE is still getting the same consistent information even if he picked
RR2 based on the current best path selection.

In general in the pure RR scenario each PE has multiple peers to RRs that
are in a tiered mesh and so as long as you get the routing updates
regardless of the best path selection picking the most optimal RR which
would be the shortest cluster-id there is no issue.  Even if the the path
with the longer cluster list is chosen as this is control plane update, it
does not make a difference and there really is no impact to the forwarding
plane.   For that reason the standard has more then likely stayed as it is
addressing the most widespread pure RR scenario.

As the RR in the forwarding plane can be problematic just as in this case
local policy or as you mentioned link costing could be used as well to help
alter path selection to get the same desired result of picking the shorter
cluster list  path.

For the border nodes inter-as BGP-LU ASBRs for the EPE if you made them RR
Client instead of RR, then the cluster-id then would not come into the path
selection at all but would that help the scenario since now the BN is not
meshed with the RRs.  It would use router-id as tie breaker still and I
guess you may still have the issue.  In this case it maybe handy to have
the BN be an RR and now you can leverage the cluster-id to help with the
best path selection.   I believe typically for inter-as options the BN
PE/ASBR is a RR-C and not an RR.

With true EPE a controller is doing the path steering not BGP so you would
not see this issue with EPE correct?

Responses in-line

Current standard with both Juniper and Cisco best path selection follows:

Juniper has a knob to flip flop the cluster-id and router-id as you stated
which can help in situations where NHS is used and now due to the router-id
as the tie breaker over shortest cluster length can cause problems as you
noticed.

RFC 4271 step f & g

route.

RFC 4456

9 <https://datatracker.ietf.org/doc/html/rfc4456#section-9>.  Impact
on Route Selection

   The BGP Decision Process Tie Breaking rules (Sect.  9.1.2.2, [1
<https://datatracker.ietf.org/doc/html/rfc4456#ref-1>]) are
   modified as follows:

Update to RFC 4456 to flip flop cluster-id and router-id.

      In addition, the following rule SHOULD be inserted “BEFORE” 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.

Kind Regards

Gyan

On Thu, Mar 24, 2022 at 9:06 PM Kaliraj Vairavakkalai <[email-masked]>
wrote:

>  Gyan> Thank you for the important clarification
>
> doing NHS.

    Gyan> Agreed

> 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).
>
>  Gyan> Understood
>
>  Gyan> Agreed
>  Gyan> In my reply above I tried as best to answer that question.
> Basically technically there is no impact to pure RR and it’s only RR in
> forwarding plane where you run into this issue.
>
> Thanks
>
> Kaliraj
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 25 Mar 2022 08:45:00 +0000

Kaliraj,

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

              Apologies if the rationale has been given in this thread or others but could you describe more fully the issue. In looking at the RR RFC the comparison of Cluster-List is a SHOULD not a MUST so I am not even sure as to the consistency across vendor implementations although I  assume consistency and the order of evaluation seems slightly different as one gets deeper into the Best Path Selection across vendors.

Thanks,
              Jim Uttaro

From: Idr <[email-masked]> On Behalf Of Kaliraj Vairavakkalai
Sent: Thursday, March 24, 2022 9:07 PM
To: Gyan Mishra <[email-masked]>
Cc: IDR List <[email-masked]>; Susan Hares <[email-masked]>
Subject: Re: [Idr] BGP RFC 4271 missing 9.1.2.2 section missing shortest cluster length tie breaker

Gyan,

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

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

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 <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 24, 2022 at 5:13 PM
To: Kaliraj Vairavakkalai <[email-masked]<mailto:[email-masked]>>
Cc: IDR List <[email-masked]<mailto:[email-masked]>>, Jeffrey Haas <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>
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.

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.

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__;!!BhdT!kvk_tFkB6JMNtBDXr5Ct3Jvd5r5bLiFv_-KOV-7mzShepoS5H7ZWQ7hzbxYWbG2iLTS9CnwMc4xK_a3rbd6X2wbFqRw$>

Kind Regards

Gyan

rfc4456#section-9

rfc4271:

e.g.

  1.  ASBR21->RR27->ABR23.

     *   Originator-ID ASBR21

     *   Originator-ID ASBR21.

  1.  ASBR22->RR27->ABR23.

     *   Originator-ID ASBR22

     *   Originator-ID ASBR22.

This can be avoided only if "cluster-list comparison" is performed before Originator-ID/Router-ID step.

The problem is that it doesn't work appropriately as specified currently, for these "RR doing nexthop-self" scenarios.

Thanks
Kaliraj

Gyan:

Cheers, Sue

Hi Jeffrey

Responses in-line

Thank you

Gyan

   Gyan> Ack

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.

Thoughts ??

Hope this helps.

-- Jeff

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.

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.

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__;!!BhdT!kvk_tFkB6JMNtBDXr5Ct3Jvd5r5bLiFv_-KOV-7mzShepoS5H7ZWQ7hzbxYWbG2iLTS9CnwMc4xK_a3rbd6X2wbFqRw$>

--

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 25 Mar 2022 04:52:52 -0400

Jim: 

Gyan wanted to get an updated list on every draft that updates RFC4271 route
selection.  Jeff and I said – we would help him create one.    

The discussion went from this point to discussions on what should be changed
in route- selection.  AFAIK - No active daft proposals is on hand, just
discussions on possible changes.   

Your feedback on SHOULD is important.  

Sue 

From: UTTARO, JAMES [mailto:[email-masked]] 
Sent: Friday, March 25, 2022 4:45 AM
To: Kaliraj Vairavakkalai; Gyan Mishra
Cc: IDR List; Susan Hares
Subject: RE: [Idr] BGP RFC 4271 missing 9.1.2.2 section missing shortest
cluster length tie breaker

Kaliraj,

“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”

              Apologies if the rationale has been given in this thread or
others but could you describe more fully the issue. In looking at the RR RFC
the comparison of Cluster-List is a SHOULD not a MUST so I am not even sure
as to the consistency across vendor implementations although I  assume
consistency and the order of evaluation seems slightly different as one gets
deeper into the Best Path Selection across vendors. 

Thanks,

              Jim Uttaro

From: Idr <[email-masked]> On Behalf Of Kaliraj Vairavakkalai
Sent: Thursday, March 24, 2022 9:07 PM
To: Gyan Mishra <[email-masked]>
Cc: IDR List <[email-masked]>; Susan Hares <[email-masked]>
Subject: Re: [Idr] BGP RFC 4271 missing 9.1.2.2 section missing shortest
cluster length tie breaker

Gyan,

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

But amending the path-selection steps as noted looks like an easier fix, to
me. 

Thanks

Kaliraj 

From: Gyan Mishra <[email-masked]>
Date: Thursday, March 24, 2022 at 5:13 PM
To: Kaliraj Vairavakkalai <[email-masked]>
Cc: IDR List <[email-masked]>, Jeffrey Haas <[email-masked]>, Susan Hares
<[email-masked]>
Subject: Re: [Idr] BGP RFC 4271 missing 9.1.2.2 section missing shortest
cluster length tie breaker

 

Hi Kaliraj

 

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13
753-25.html
<https://urldefense.com/v3/__https:/www.cisco.com/c/en/us/support/docs/ip/bo
rder-gateway-protocol-bgp/13753-25.html__;!!NEt6yMaO-gk!Rlx_-1v9e6EoWJdl2zft
xsF6AD5K6uIdjed52Yt6ouHg3TizoN7wzgveeVZ4v2J5$> 

 

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/r
outing-protocols-address-representation.html
<https://urldefense.com/v3/__https:/www.juniper.net/documentation/en_US/juno
s/topics/reference/general/routing-protocols-address-representation.html__;!
!BhdT!kvk_tFkB6JMNtBDXr5Ct3Jvd5r5bLiFv_-KOV-7mzShepoS5H7ZWQ7hzbxYWbG2iLTS9Cn
wMc4xK_a3rbd6X2wbFqRw$> 

 

Kind Regards 

Gyan

Jeff, Gyan, Sue, 

Let me explain the problem with cluster-list step in path-selection
specification.

rfc4456#section-9

  f) and g)

rfc4271:

         Identifier value.

If step f already breaks ties because of Originator-ID, we will not reach
the new cluster-list comparison step. 

e.g. 

https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transpo
rt-planes-13#section-15.1
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-kali
raj-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. 

1.       ASBR21->RR27->ABR23. 

o Originator-ID ASBR21

o Originator-ID ASBR21. 

o Longer cluster-list 

3.       ASBR22->RR27->ABR23.

o Originator-ID ASBR22

o Originator-ID ASBR22. 

o Longer cluster-list

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. 

Thanks

Kaliraj 

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Thursday, March 24, 2022 at 1:23 AM
To: 'Gyan Mishra' <[email-masked]>, 'Jeffrey Haas' <[email-masked]>
Cc: 'IDR List' <[email-masked]>
Subject: Re: [Idr] BGP RFC 4271 missing 9.1.2.2 section missing shortest
cluster length tie breaker

Gyan: 

New drafts continually propose additions to RFC4271 route selection .   One
such draft is:
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess
-evpn-ipvpn-interworking/__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwc
JkqObmCZFYWRLl54y70L0Jwxo3NfnX$> draft-ietf-bess-evpn-ipvpn-interworking-06

One of the key places to look for RFC4271 for a new BGP is the updates list.
You will note it says: 

Updated by
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc6286/__;!!NE
t6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw1jTUEYR$>
RFC 6286,
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc6608/__;!!NE
t6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw1VR00ih$>
RFC 6608,
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc6793/__;!!NE
t6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw-iX1CuA$>
RFC 6793,
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc7606/__;!!NE
t6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw1cqRPWw$>
RFC 7606,
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc7607/__;!!NE
t6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw-Swxl9-$>
RFC 7607,
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc7705/__;!!NE
t6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw7p_Ekpo$>
RFC 7705,
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc8212/__;!!NE
t6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw7BbH_Dl$>
RFC 8212,
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc8654/__;!!NE
t6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw3blnz9s$>
RFC 8654,
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc9072/__;!!NE
t6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw4mR5Ukn$>
RFC 9072

 
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4456*se
ction-9__;Iw!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54
y70L0Jw-ZqQutS$> 9.  Impact on Route Selection

   The BGP Decision Process Tie Breaking rules (Sect.  9.1.2.2, [
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4456*re
f-1__;Iw!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L
0Jw-LFOgze$> 1]) are

   modified as follows:

 

Cheers, Sue 

From: Idr [mailto:[email-masked]] 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 

Responses in-line 

Thank you

Gyan

Gyan,

   Gyan> Ack

https://datatracker.ietf.org/doc/html/rfc4456
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4456__;
!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw6yl0n
c3$> , §9

Thoughts ??

Hope this helps.

-- Jeff

 

Hi Jeffrey 

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13
753-25.html
<https://urldefense.com/v3/__https:/www.cisco.com/c/en/us/support/docs/ip/bo
rder-gateway-protocol-bgp/13753-25.html__;!!NEt6yMaO-gk!WeYRUxpV1fveh31eDfiI
hyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw20cFMwj$> 

 

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/r
outing-protocols-address-representation.html
<https://urldefense.com/v3/__https:/www.juniper.net/documentation/en_US/juno
s/topics/reference/general/routing-protocols-address-representation.html__;!
!BhdT!kvk_tFkB6JMNtBDXr5Ct3Jvd5r5bLiFv_-KOV-7mzShepoS5H7ZWQ7hzbxYWbG2iLTS9Cn
wMc4xK_a3rbd6X2wbFqRw$> 

-- 

<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!WeYRUxpV
1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw0vMnJDb$> Image removed by
sender.

Gyan Mishra

Email  <mailto:[email-masked]> [email-masked]

M 301 502-1347

-- 

<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!WeYRUxpV
1fveh31eDfiIhyk3Op6FtgwKwcJkqObmCZFYWRLl54y70L0Jw0vMnJDb$> Image removed by
sender.

Gyan Mishra

Email  <mailto:[email-masked]> [email-masked]

M 301 502-1347

-- 

<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Rlx_-1v9
e6EoWJdl2zftxsF6AD5K6uIdjed52Yt6ouHg3TizoN7wzgveeXOa1YRh$> Image removed by
sender.

Gyan Mishra

M 301 502-1347

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 25 Mar 2022 10:58:26 +0100

All,

The discussion went from this point to discussions on what should be
> changed in route- selection.  AFAIK - No active daft proposals is on hand,
> just discussions on possible changes.
>

As Enke kindly pointed out let's be very careful here. We can not
update the spec and assume it will be safely deployed when it refers to
best path selection in non tunneled networks. Even in tunneled networks and
say ieBGP load balancing things can go south.

IMO the only safe way to introduce change to the best path selection is by
defining a new AFI/SAFI with different rules from start.

Regards,
Robert.

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Fri, 25 Mar 2022 17:49:37 +0000

Jim, the problem is described in the following email from me in below thread:

https://mailarchive.ietf.org/arch/msg/idr/xzGMJMhaT-XDvGwrnD0f5KDRPcc/

Thanks
Kaliraj
From: UTTARO, JAMES <[email-masked]>
Date: Friday, March 25, 2022 at 1:45 AM
To: Kaliraj Vairavakkalai <[email-masked]>, Gyan Mishra <[email-masked]>
Cc: IDR List <[email-masked]>, Susan Hares <[email-masked]>
Subject: RE: [Idr] BGP RFC 4271 missing 9.1.2.2 section missing shortest cluster length tie breaker
[External Email. Be cautious of content]

Kaliraj,

“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”

Thanks,
              Jim Uttaro

Gyan,

Thanks
Kaliraj

Hi Kaliraj

Kind Regards

Gyan

rfc4456#section-9

rfc4271:

e.g.

  1.  ASBR21->RR27->ABR23.

     *   Originator-ID ASBR21

     *   Originator-ID ASBR21.

  1.  ASBR22->RR27->ABR23.

     *   Originator-ID ASBR22

     *   Originator-ID ASBR22.

Thanks
Kaliraj

Gyan:

Cheers, Sue

Hi Jeffrey

Responses in-line

Thank you

Gyan

   Gyan> Ack

Thoughts ??

Hope this helps.

-- Jeff

Hi Jeffrey

--

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Fri, 25 Mar 2022 17:56:48 +0000

Enke, Robert,

Agree with that. It will be tricky to change the RR-spec rules for already deployed families.

> IMO the only safe way to introduce change to the best path selection is by defining a new AFI/SAFI with different rules from start.

Agree. That is precisely what draft -ct is suggesting for the new family: BGP CT, which is used in tunneled-networks.

Ref: the section “Avoiding loop between Route Reflectors in forwarding path” in:

https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes-13#section-10

Thanks
Kaliraj
From: Robert Raszuk <[email-masked]>
Date: Friday, March 25, 2022 at 2:58 AM
To: Susan Hares <[email-masked]>
Cc: UTTARO, JAMES <[email-masked]>, Kaliraj Vairavakkalai <[email-masked]>, Gyan Mishra <[email-masked]>, IDR List <[email-masked]>
Subject: Re: [Idr] BGP RFC 4271 missing 9.1.2.2 section missing shortest cluster length tie breaker
[External Email. Be cautious of content]

All,

The discussion went from this point to discussions on what should be changed in route- selection.  AFAIK - No active daft proposals is on hand, just discussions on possible changes.

As Enke kindly pointed out let's be very careful here. We can not update the spec and assume it will be safely deployed when it refers to best path selection in non tunneled networks. Even in tunneled networks and say ieBGP load balancing things can go south.

IMO the only safe way to introduce change to the best path selection is by defining a new AFI/SAFI with different rules from start.

Regards,
Robert.

---

From: Greg Skinner <[email-masked]>
Date: Fri, 25 Mar 2022 13:37:39 -0700

If there is a movement to update the core BGP specification, I hope some of the issues I brought up in a message from about a month ago <https://mailarchive.ietf.org/arch/msg/idr/7pzU5Z6rKmYmuk-_HgACSj-zCvk/> can be incorporated (except for the RFC911 issue, which is now in the hands of the RFC Editor).  At the very least, my understanding is making the BGP specification a Full Standard is still an idr wg milestone.

Regards, Greg

> On Mar 24, 2022, at 8:44 AM, Gyan Mishra <[email-masked]> wrote:
> 
> Excellent !
> 
> Also a pointer to IDR wiki with implementation specific details is a great idea.
> 
> As far as unified core base BGP specification I will defer based on your comments.
> 
> Kind Regards 
> 
> Gyan
> 
> On Thu, Mar 24, 2022 at 6:39 AM Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
> Gyan,
> 
> 
>> On Mar 23, 2022, at 5:02 PM, Gyan Mishra <[email-masked] <mailto:[email-masked]>> wrote:

---

From: tom petch <[email-masked]>
Date: Mon, 28 Mar 2022 09:21:48 +0000

From: Idr <[email-masked]> on behalf of Kaliraj Vairavakkalai <kaliraj=[email-masked]>
Sent: 25 March 2022 17:56
Subject: Re: [Idr] BGP RFC 4271 missing 9.1.2.2 section missing shortest cluster length tie breaker

Proposing a new address family caught my eye.  There are a number of I-D in a number of WG that refer to Address Family and they do not mean the same thing AFAICT.   bgp-model contains a list in YANG  of address family, which is imported by another I-D, but any change thereto will require an update an reissue of the bgp YANG module.

Should address family be more easy to maintain, such as by making it an IANA-maintained module, with suitable controls in the hands of the IDR WG?

Tom Petch

Enke, Robert,

Thanks
Kaliraj

All,

Regards,
Robert.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 28 Mar 2022 12:00:12 +0200

Hi Tom,

What we (at least here in IDR) are referring to as AFI/SAFI are the
following two registries as maintained by IANA:

https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml

https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml

I hope that is non-controversial :)

Cheers,
R.

On Mon, Mar 28, 2022 at 11:22 AM tom petch <[email-masked]> wrote:

> Proposing a new address family caught my eye.  There are a number of I-D
> in a number of WG that refer to Address Family and they do not mean the
> same thing AFAICT.   bgp-model contains a list in YANG  of address family,
> which is imported by another I-D, but any change thereto will require an
> update an reissue of the bgp YANG module.
>
> Should address family be more easy to maintain, such as by making it an
> IANA-maintained module, with suitable controls in the hands of the IDR WG?
>
> Tom Petch
>
> Enke, Robert,
>
> > IMO the only safe way to introduce change to the best path selection is
> by defining a new AFI/SAFI with different rules from start.
>
> Agree. That is precisely what draft -ct is suggesting for the new family:
> BGP CT, which is used in tunneled-networks.
>
>
> Cc: UTTARO, JAMES <[email-masked]>, Kaliraj Vairavakkalai <
> [email-masked]>, Gyan Mishra <[email-masked]>, IDR List <
> [email-masked]>
> As Enke kindly pointed out let's be very careful here. We can not update
> the spec and assume it will be safely deployed when it refers to best path
> selection in non tunneled networks. Even in tunneled networks and say ieBGP
> load balancing things can go south.
>
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: tom petch <[email-masked]>
Date: Mon, 28 Mar 2022 10:30:58 +0000

From: Robert Raszuk <[email-masked]>
Sent: 28 March 2022 11:00

Hi Tom,

What we (at least here in IDR) are referring to as AFI/SAFI are the following two registries as maintained by IANA:

<tp>
Robert 

Indeed I would hope so too:-)

What I had forgotten is that we already have a routing-types IANA-maintained with the address families in it so my issue is really why are bgp-model et al re-inventing the wheel?

Can we find an integrated solution?

Tom Petch

Cheers,
R.

On Mon, Mar 28, 2022 at 11:22 AM tom petch <[email-masked]<mailto:[email-masked]>> wrote:
From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Kaliraj Vairavakkalai <kaliraj=[email-masked]<mailto:[email-masked]>>
Sent: 25 March 2022 17:56
Subject: Re: [Idr] BGP RFC 4271 missing 9.1.2.2 section missing shortest cluster length tie breaker

Tom Petch

Enke, Robert,

Thanks
Kaliraj
From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 25, 2022 at 2:58 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: UTTARO, JAMES <[email-masked]<mailto:[email-masked]>>, Kaliraj Vairavakkalai <[email-masked]<mailto:[email-masked]>>, Gyan Mishra <[email-masked]<mailto:[email-masked]>>, IDR List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] BGP RFC 4271 missing 9.1.2.2 section missing shortest cluster length tie breaker
[External Email. Be cautious of content]

All,

Regards,
Robert.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 28 Mar 2022 12:41:49 +0200

Hi Tom,

BGP is not reinventing the wheel.

We use AFI/SAFI tuple in signalling.

In most cases we just use AFI 1 and 2 as a number of SAFIs are applicable
to those address families.

In some cases where protocol does not fall under existing AFI a new value
is defined. AFI 25 or 31 etc ...

Many thx,
R.

On Mon, Mar 28, 2022 at 12:30 PM tom petch <[email-masked]> wrote:

> What I had forgotten is that we already have a routing-types
> IANA-maintained with the address families in it so my issue is really why
> are bgp-model et al re-inventing the wheel?
>
> From: Idr <[email-masked]<mailto:[email-masked]>> on behalf
> of Kaliraj Vairavakkalai <kaliraj=[email-masked]<mailto:
> [email-masked]>>
> Cc: UTTARO, JAMES <[email-masked]<mailto:[email-masked]>>, Kaliraj
> Vairavakkalai <[email-masked]<mailto:[email-masked]>>, Gyan
> Mishra <[email-masked]<mailto:[email-masked]>>, IDR List <
> [email-masked]<mailto:[email-masked]>>

---

From: tom petch <[email-masked]>
Date: Mon, 28 Mar 2022 11:20:08 +0000

trimming the distribution list
________________________________________
From: Robert Raszuk <[email-masked]>
Sent: 28 March 2022 11:41

Hi Tom,

In most cases we just use AFI 1 and 2 as a number of SAFIs are applicable to those address families.

In some cases where protocol does not fall under existing AFI a new value is defined. AFI 25 or 31 etc ...

<tp>

Robert,

Yes, I am familiar with that.  'Re-inventing the wheel' was a reference to IDR's bgp-model creating a YANG model of address families that overlaps rtgwg's address families in the YANG module routing-types.  How many YANG modules of address families do we need?

NETMOD defined just IPv4 and IPv6 in RFC8349 which, with just the two, seemed ok.

Tom Petch

Many thx,
R.

On Mon, Mar 28, 2022 at 12:30 PM tom petch <[email-masked]<mailto:[email-masked]>> wrote:
From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: 28 March 2022 11:00

Hi Tom,

<tp>
Robert

Tom Petch

Cheers,
R.

On Mon, Mar 28, 2022 at 11:22 AM tom petch <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
From: Idr <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> on behalf of Kaliraj Vairavakkalai <kaliraj=[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
Sent: 25 March 2022 17:56
Subject: Re: [Idr] BGP RFC 4271 missing 9.1.2.2 section missing shortest cluster length tie breaker

Tom Petch

Enke, Robert,

Thanks
Kaliraj
From: Robert Raszuk <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
Date: Friday, March 25, 2022 at 2:58 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
Cc: UTTARO, JAMES <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, Kaliraj Vairavakkalai <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, Gyan Mishra <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, IDR List <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
Subject: Re: [Idr] BGP RFC 4271 missing 9.1.2.2 section missing shortest cluster length tie breaker
[External Email. Be cautious of content]

All,

Regards,
Robert.

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

---

From: tom petch <[email-masked]>
Date: Mon, 28 Mar 2022 16:05:07 +0000

From: Idr <[email-masked]> on behalf of Greg Skinner <gregskinner0=[email-masked]>
Sent: 25 March 2022 20:37

If there is a movement to update the core BGP specification, I hope some of the issues I brought up in a message from about a month ago<https://mailarchive.ietf.org/arch/msg/idr/7pzU5Z6rKmYmuk-_HgACSj-zCvk/> can be incorporated (except for the RFC911 issue, which is now in the hands of the RFC Editor).  At the very least, my understanding is making the BGP specification a Full Standard is still an idr wg milestone.

<tp>

Indeed it is with a target date of April 2016.  However, that is not the same as a revision of the core specification.   'Internet  Standard' requires a careful examination of every aspect of the specification and a demonstration of multiple implementations from different code bases which can inter-operate.  This cannot result in any significant new features being added, because they have not been implemented for long enough for there to be the experience,, but can result in features being removed (which is my experience) so revision and advancement are likely to be either/or (or perhaps neither!),

Tom Petch 

Regards, Greg

On Mar 24, 2022, at 8:44 AM, Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

Excellent !

Kind Regards

Gyan

On Thu, Mar 24, 2022 at 6:39 AM Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
Gyan,

On Mar 23, 2022, at 5:02 PM, Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:
In practice, enough features are "core" enough that if we ever revised BGP we might want to pull them into the core document.

Thoughts ??

-- Jeff

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

---

From: Greg Skinner <[email-masked]>
Date: Mon, 28 Mar 2022 14:25:13 -0700

Tom,

Understood.  I wasn’t suggesting anything more than applying some errata corrections and cleaning up some inconsistent text, for now.

Greg

> On Mar 28, 2022, at 9:05 AM, tom petch <[email-masked]> wrote:
>