Subject: [Idr] alternatives to draft-raszuk-bgp-optimal-route-reflection-00.txt

From: Jakob Heitz <[email-masked]>
Date: Sun, 14 Nov 2010 22:28:58 -0500

Alternatives are possible with existing technology.

1. Add-Path AS-wide best paths   (mentioned before)
2. Full mesh the clients and disable client-to-client reflection.
3. Confederations instead of RR.

(2) works if the best exit is within the cluster.
If the best exit is otuside the cluster, the RR-best is probably quite good if not optimal.

(3) will pick a better path than (2) if the AS exit is not also the confed exit, assuming the confed AS is congruent to the RR cluster.

--
Jakob Heitz.

---

From: Jakob Heitz <[email-masked]>
Date: Sun, 14 Nov 2010 22:51:31 -0500

If exit points outside the cluster are sufficiently different, use
multiple route-reflectors in different locations, such that the
clients will receive paths of sufficient diversity from the reflectors.
RRs are often in multiples for redundancy anyway.

        --
        Jakob Heitz.

---

From: "iLya" <[email-masked]>
Date: Mon, 15 Nov 2010 08:34:33 +0100

Jakob,

--------------------------------------------------
From: "Jakob Heitz" <[email-masked]>
Sent: Monday, November 15, 2010 4:28 AM
To: <[email-masked]>
Subject: [Idr] alternatives 
todraft-raszuk-bgp-optimal-route-reflection-00.txt

> 1. Add-Path AS-wide best paths   (mentioned before)

there was also a scenario where AS-wide-best didn't work well.

> 2. Full mesh the clients and disable client-to-client reflection.

What if full mesh is undesirable? Additionally (taking your second mail into 
consideration) placing RR at each PoP is not always practical or desirable.

> 3. Confederations instead of RR.

There are case where confederation is already in use, and RRs (possible 
multiple clusters) are used within member-AS's.

The draft addresses scenarios which aren't found on every network, but there 
are number of networks where solutions proposed by the draft provide better 
alternative to what currently can be achieved.

Kind regards,
iLya

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Nov 2010 09:14:04 +0100

Hi Jakob,

The ISPs requirements for optimal best path reflection are:

Case A) Customer may have no network wide policies or AS_PATHs lengths 
can be equal which in this case the tie break is the IGP metric to the 
next hop on the RRs for vast majority of paths

Case B) their network wide *often outside of the local cluster* exit 
policy does not need to be uniform and identical for all RR clients - 
transit of course with some form of end to end encapsulation.

You are correct that add-path AS-wide best paths or global full IBGP 
mesh may satisfy those or even add path ALL may be a good solution if 
you have in total 2 or 3 paths per bgp net.

But if you have 6, 10 or more BGP paths per net I really do not think 
that this is a good idea to send them all to all RR clients. Moreover 
skipping scaling and churn worry you would have to choose per client now 
which paths are chosen as best. This may be a management headache.

Many thx,
R.

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

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 15 Nov 2010 04:32:26 -0500

I didn't say to full mesh the IGP. I said to mesh the cluster.

--
Jakob Heitz. 510-566-2901

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Nov 2010 13:35:00 +0100

Hi Jakob,

> I didn't say to full mesh the IGP. I said to mesh the cluster.

Correct. And I pointed out that there are customers who want to exit 
from some routers belonging to the clusters out via other clusters.

Keep in mind that out of 20-50 POPs in decent size networks not every 
POP has a tier-1 transit upstream EBGP peering.

So my comment was that ORR could be replaced by full IBGP mesh there 
indeed.

Cheers,
R.

> On Nov 15, 2010, at 12:14 AM, "Robert Raszuk"<[email-masked]>  wrote:
>
>> Hi Jakob,
>>

---

From: "UTTARO, JAMES (ATTLABS)" <[email-masked]>
Date: Mon, 15 Nov 2010 11:18:02 -0500

Comments In-Line..

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Raszuk
Sent: Monday, November 15, 2010 3:14 AM
To: Jakob Heitz
Cc: [email-masked]
Subject: Re: [Idr]alternatives to
draft-raszuk-bgp-optimal-route-reflection-00.txt

Hi Jakob,

which paths are chosen as best. This may be a management headache.
[Jim U>] In the VPN case with a unique RD multiple paths are sent all
the way to the client.. Is it the sheer volume of paths coming over
multiple peering points?? If so the RRs can reduce that from 6-10 to 2
or 3.. Can you clarify this use case..

Many thx,
R.

>          (3) will pick a better path than (2) if the AS exit is not
also the confed exit, assuming the confed AS is congruent to the RR
cluster.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Nov 2010 17:26:58 +0100

Hi Jim,

> the way to the client..

In the VPN case most customer sites are single-homed or multihomed to 
two PEs. I hardly see that a single site is connected to more then two 
PEs. Maybe there are some exceptions, but clearly this is not a majority 
of cases.

So in this case for each VPNv4/v6 net you have one or two paths. I think 
this is fine to receive them all .. each with different RD.

> Is it the sheer volume of paths coming over
> multiple peering points??

Yes exactly.

> If so the RRs can reduce that from 6-10 to 2 or 3..

Precisely so. And this is why I indicated that optimal RR path selection 
is very nicely applicable to add-paths.

The point is that if you are reducing number of paths to be advertised 
from 6-10 to 2 or 3 you would like to still send to each client of group 
of clients the _optimal_ path for given clients point of view.

If you just have control plane RR and if you select 2 or 3 paths from 
the network position of such RR it is very clear that paths clients will 
receive will not be optimal for all of them.

It is clear that today clients are ok if they get reachability. The 
proposal I suggested allows to make the reachability customized for the 
client's individual needs (or POP's needs).

It is therefor fully applicable to add-paths encoding and will allow to 
sent optimal 2-3 paths to each add-path client or set of clients.

Many thx,
R.