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

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 11 Nov 2010 07:21:29 +0100

Robert,

Due to time we could not discuss it in the meeting.
In your presentation today around option A. What is the behavior in the RR when the IGP distance change between the Border BGP routers?

Cheers,
Wim

---

From: "Robert Raszuk (raszuk)" <[email-masked]>
Date: Thu, 11 Nov 2010 14:24:59 +0800

Hi,

When the IGP metric changes the client to next hop metric would be evaluated.

If they cross the threshold of significant value of metric the next hops will be evaluated and send to the clients.

Manz thx,
R.

---

From: Pierre Francois <[email-masked]>
Date: Thu, 11 Nov 2010 07:27:34 +0100

Robert, all

Can you expand on the threshold used by the RR to decide not to trigger
an update, as described in section 3.1.1 ?

The draft says that "this solution can be deployed in traditional hop-by-hop 
forwarding networks as well as in end-to-end tunneled environments".

Aren't you afraid that the threshold could be crossed for one client
of an RR, and not be crossed for another router on path, so that you have
a forwarding deflection ?

Pierre.

On 11/11/10 07:24, Robert Raszuk (raszuk) wrote:
> On Nov 11, 2010, at 2:21 PM, "Henderickx, Wim (Wim)"<[email-masked]>  wrote:
>
>> Robert,
>>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 11 Nov 2010 07:28:10 +0100

Robert,

Ok Thx this clarifies. So with this proposal we will see potentially more RR BGP updates due to IGP changes.

Cheers,
Wim

-----Original Message-----
From: Robert Raszuk (raszuk) [mailto:[email-masked]] 
Sent: donderdag 11 november 2010 7:25
To: Henderickx, Wim (Wim)
Cc: [email-masked]
Subject: Re: draft-raszuk-bgp-optimal-route-reflection-00.txt

Hi,

Manz thx,
R.

---

From: "Robert Raszuk (raszuk)" <[email-masked]>
Date: Thu, 11 Nov 2010 14:33:51 +0800

Hi,

In the event where normally change of IGP would not result in different best path selection from the RR point of view but would result in different optimal best path for the client the answer is yes,

Many thx,
R,

---

From: Tony Li <[email-masked]>
Date: Thu, 11 Nov 2010 14:36:41 +0800

> Ok Thx this clarifies. So with this proposal we will see potentially more RR BGP updates due to IGP changes.

That doesn't follow.  If there was an IGP change between the RR and the exit previously, then you would have seen an RR BGP update before.  Under this proposal, that topology change may now become irrelevant.

All this proposal does is change the perspective of IGP metric computation.

Tony

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 11 Nov 2010 07:42:52 +0100

In-line

-----Original Message-----
From: Tony Li [mailto:[email-masked]] 
Sent: donderdag 11 november 2010 7:37
To: Henderickx, Wim (Wim)
Cc: Robert Raszuk (raszuk); [email-masked]
Subject: Re: [Idr] draft-raszuk-bgp-optimal-route-reflection-00.txt

WH> The extra updates come from the fact that the IGP distance between Border BGP changes. Since the RR does IGP computation now to pretend being the RR Client, you will get potential extra updates if this results in better metrics for certain BGP routes that were not previously selected.

Tony

---

From: "Robert Raszuk (raszuk)" <[email-masked]>
Date: Thu, 11 Nov 2010 14:48:40 +0800

Hi Pierre,

Yes I will make sure in the text of 01 ver that the threshold does apply in case of encapsulated networks.

Many thx for pointing it out.

Cheers,
R.

On Nov 11, 2010, at 2:28 PM, Pierre Francois <[email-masked]> wrote:

> The draft says that "this solution can be deployed in traditional hop-by-hop forwarding networks as well as in end-to-end tunneled environments".
>

---

From: "Robert Raszuk (raszuk)" <[email-masked]>
Date: Thu, 11 Nov 2010 14:52:52 +0800

Hi Wim,

But please keep in mind that number of core IGP network changes will now not result in new best path selection for far away clients which before this proposal would.

I think this is the point Tony mentioned which I did forgot to highlight enough during the presentation nor in the draft.

Will be fixed shortly.

Many thx,
R.

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 11 Nov 2010 01:57:04 -0500

Hi Robert,

In option A you've proposed to use Reverse SPF to calculate IGP metric from client point of view (makes sense).
How would you trigger SPF?
LSDB change?
Timer based?
Just reacting on any change in LSDB could be rather heavy.  
Thanks!  

Regards,
Jeff

---

From: Tony Li <[email-masked]>
Date: Thu, 11 Nov 2010 14:56:44 +0800

> WH> The extra updates come from the fact that the IGP distance between Border BGP changes. Since the RR does IGP computation now to pretend being the RR Client, you will get potential extra updates…

Correct.  However, this is offset by the fewer updates that you won't get for off-path topology changes.

Tony

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 10:05:38 +0100

Robert,

This is an interresting idea.
But from your point of view, what could be the impact on RR scaling of
this solution as now there is a huge change on best path computation ,
as it's computed per peer and no more globally. What could be the impact
on current BGP updates generation codes ?

Regards,

Stephane

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 11 Nov 2010 10:16:47 +0100

Hi Stephane,

This is excellent question and the answer really depends which option we 
would use to get the right "metric" value. The answer really depends how 
much granularity would you expect from the solution.

For example if you have a centralized RR serving 20 POPs today each pop 
with 50 routers in most cases you can get 100% optimality with running 
20 BGP best paths upon the trigger as opposed to running it 1000 times. 
That is a significant difference for the impact evaluation.

Another important point is the trigger. Clearly in the encapsulated 
networks it does not have to be done at each IGP metric change. Contrary 
as pointed out by Tony on the list only localized significant metric 
changes or perhaps I could say just next hop down events of current 
best/2nd best next hops may result in re-computation.

Last but not least the CPU power of route reflectors especially acting 
as control plane devices is growing these days. And I am sure you know 
better then anyone else that upgrade of RRs is much of an easier 
operation then upgrade of all of your edge boxes to keep up with number 
of bgp paths and churn which would be required to get the same optimal 
customized best path selection.

Many thx,
R.

---

From: <[email-masked]>
Date: Fri, 12 Nov 2010 12:10:51 +0100

Thanks Robert for the feedback.
Clearly it's easier to upgrade RR HW :) but if we can optimize RR software rather than upgrading their HW, it's even better ! 

-----Message d'origine-----
De : Robert Raszuk [mailto:[email-masked]] 
Envoyé : jeudi 11 novembre 2010 10:17
À : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]
Objet : Re: [Idr] draft-raszuk-bgp-optimal-route-reflection-00.txt

Hi Stephane,

This is excellent question and the answer really depends which option we would use to get the right "metric" value. The answer really depends how much granularity would you expect from the solution.

For example if you have a centralized RR serving 20 POPs today each pop with 50 routers in most cases you can get 100% optimality with running 20 BGP best paths upon the trigger as opposed to running it 1000 times. 
That is a significant difference for the impact evaluation.

Another important point is the trigger. Clearly in the encapsulated networks it does not have to be done at each IGP metric change. Contrary as pointed out by Tony on the list only localized significant metric changes or perhaps I could say just next hop down events of current best/2nd best next hops may result in re-computation.

Last but not least the CPU power of route reflectors especially acting as control plane devices is growing these days. And I am sure you know better then anyone else that upgrade of RRs is much of an easier operation then upgrade of all of your edge boxes to keep up with number of bgp paths and churn which would be required to get the same optimal customized best path selection.

Many thx,
R.

> as it's computed per peer and no more globally. What could be the 
> impact on current BGP updates generation codes ?
>
> Regards,
>
>
> Stephane
>