Subject: [GROW] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection

From: Jakob Heitz <[email-masked]>
Date: Sun, 27 Mar 2011 17:27:57 -0400

Route selection tie breakers in RFC 4271 state:

      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.

Suppose RR Planes use different BGP Identifier values.
If they use the same BGP Identifier, a similar argument
can be made for peer address.

To prevent clients in different clusters from choosing
different bestpaths based on tie breaker (f):

The RR Plane that advertises the best path MUST be configured
with a BGP Identifier higher than that of the RR Plane that
advertises the 2nd best. This must be higher than that of
the Plane that advertises the 3rd best and so on.

I'm not sure if this rule completely solves the problem.
If not, then the "Edge_Discriminator attribute" proposed
by draft-pmohapat-idr-fast-conn-restore may be required.
Also, this would need to be applied before rule (f).

--
Jakob Heitz.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 28 Mar 2011 00:17:20 +0200

Jakob,

 > different bestpaths based on tie breaker (f):

Can you restate what is the problem with the above ?

Today clients would chose different best paths when IGP metric to one 
next hop is closest on one to NH1 and closest on the other to NH2. And 
this check happens well above step (f).

How is this at all related to the diverse path draft like the subject 
could indicate ?

Thx,
R.

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: Jakob Heitz <[email-masked]>
Date: Sun, 27 Mar 2011 18:21:33 -0400

This is standard BGP if the IGP metrics are equal.

--
Jakob Heitz.

> -----Original Message-----
> From: Robert Raszuk [mailto:[email-masked]] 
> Sent: Sunday, March 27, 2011 3:17 PM
> To: Jakob Heitz
> Cc: [email-masked]; IETF IDR
> Subject: Re: [GROW] draft-ietf-grow-diverse-bgp-path-dist: 
> risk of inconsistent path selection
> 
> Jakob,
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 28 Mar 2011 00:25:57 +0200

Exactly. So what is the problem within this thread which you claim that 
clients may "risk of inconsistent path selection" ?

R.

---

From: Jakob Heitz <[email-masked]>
Date: Sun, 27 Mar 2011 18:45:23 -0400

Suppose 2 clusters.
Cluster 1 has 2 diverse path speakers, RR11 and RR12
and client C1.
Cluster 2 has 2 diverse path speakers, RR21 and RR22.
and client C2.

Suppose BGP Identifiers:
RR11 = 11  advertises best
RR12 = 12  advertises second best
RR21 = 21  advertises second best
RR22 = 22  advertises best

If the tie breaker reaches step (f),
C1 will choose second best and C2 will choose best.

The rule I state will prevent the inconsistency.

I assume that the IGP metric problem at the RRs
has been fixed such that each RR plane
sees the same IGP metric as its mates.

--
Jakob Heitz.

> Sent: Sunday, March 27, 2011 3:26 PM
> To: Jakob Heitz

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 28 Mar 2011 01:01:52 +0200

Hi,

 > C1 will choose second best and C2 will choose best.

I am sorry but each client will choose the best and backup path among 
the paths it receives. And this selection are normal IBGP best path 
selection. We are not really defining an AS wide path ordering in this 
work. All we are doing is distributing more paths to clients so they 
could use it for backup or load-balancing purposes.

Are you saying that what RR considers as backup may be chosen as best by 
the client ?

That seems to me perfectly fine. Client has no need to choose the same 
path as the RR. Because the second path would be a backup path on the 
client. With hop by hop IP lookup this is the reality today. With 
tunnels of some sort this becomes completely transparent, but this is 
different story and diverse-path does not require tunneling.

Even today RRs may choose different best path when they are full meshed 
and advertise different to each client. Then client is at his own 
freedom to choose order of paths as he likes.

Moreover the same behaviour would be in add-paths. Among advertised 
paths there is no ordering and clients can choose whichever order it 
consider's correct.

Cheers,
R.

---

From: Jakob Heitz <[email-masked]>
Date: Sun, 27 Mar 2011 19:16:49 -0400

Again, if the tie breaker reaches step (f),
the client will use the BGP Identifier of
the RR it receives the path from to choose
its best.

In BGP, we like all speakers to choose the same
path unless IGP metrics are different.

With diverse-path, there is a possibility that
different speakers choose different paths even
if IGP metrics are the same.

If the clients were to receive their paths
from the source speaker, they would choose the
same path at tie breaker (f).

draft-pmohapat-idr-fast-conn-restore proposes
the Edge_Discriminator attribute to fix it.

It may not be a problem. However, the path selection is
different than without diverse-path, therefore
the behaviour needs to be stated in the draft.

The rule I stated will remove the inconsistency.

--
Jakob Heitz.

> Sent: Sunday, March 27, 2011 4:02 PM
> To: Jakob Heitz

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 28 Mar 2011 23:30:51 +0200

Jakob,

Diverse-path works between RR and the client and client does not 
advertise back the best path to other IBGP peers so there is no issue 
with churn or oscillation.

Advertising different paths to possible EBGP peers is a feature not a bug.

By definition of diverse path such path will have different next hop 
hence the metric to next hop would be in most cases a tie breaker.

If metric to next hop is the same across both paths I see no reason to 
mandate any rules which would force different PEs to choose the same 
path. If operator wishes to prefer one path then the other he will do so 
by applying local preference.

The fact that you like to see all paths in BGP to be selected as the 
same is not sufficient reason to mandate it on the clients. I see more 
value and no issue keeping them diverse especially since you are 
pointing out last step in best path selection.

Cheers,
R.

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 28 Mar 2011 18:37:38 -0400

The inventors of BGP added tie breaker rules
after IGP metric.

It helps to void churn in upstream AS's that would
be caused by advertising different paths needlessly.
There may be other reasons for these rules too.

Apparently, Pradosh found them important enough to
invent the Edge_Discriminator attribute to keep
these rules working.

--
Jakob Heitz.

> Sent: Monday, March 28, 2011 2:31 PM
> To: Jakob Heitz
> Cc: IETF IDR; [email-masked]
> Subject: Re: [Idr] [GROW] 
> draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent 
> path selection
> 
> Jakob,
>

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 28 Mar 2011 18:48:11 -0400

I don't want to argue the importance of the tie breaker
rules (f) and (g). They may or may not be important.

My point is that diverse-path breaks them and
my rule fixes it. Here it is again:

--
Jakob Heitz.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jakob Heitz
> Sent: Monday, March 28, 2011 3:38 PM
> To: [email-masked]
> Subject: Re: [GROW] [Idr]

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 29 Mar 2011 09:43:02 +0200

Jakob,

> rules (f) and (g). They may or may not be important.

Just because the above steps are in place there is no guarantee even 
today that all bgp speakers within the domain will declare the same very 
path as best. Especially RR clusters as not all RR clients clearly need 
to be connected to all clusters. That is also why RRs were recommended 
to be in the data plane topologically in the path between the rest of 
the network and it's clients.

> my rule fixes it. Here it is again:

Diverse-path does not break them. It only allows for more paths to be 
distributed to clients.

> the Plane that advertises the 3rd best and so on.

Sorry but this rule is not applicable to your problem in the first 
place. Your problem was described to be seen across RR clusters.

Moreover .. the same RR running single BGP process may serve both set of 
clients: .. those interested in best path, those interested in 2nd best, 
those interested in Nth best and so on. And all implementations I am 
familiar with have single BGP Identifier for any given BGP speaker.

R.