Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection

From: Reshmi Prem <[email-masked]>
Date: Fri, 10 Jun 2011 03:42:57 -0700 (PDT)

Robert and All,
 
I have been following this discussion and I would like add my opinions here
 
We have been having similar requirements to steer traffic through selective exit points in the network which are driven by customer requirements, example having premium customers use a set of ASBRS vs. a different set of other customers using another set of ASBRs within a given region/POP or whatever you may like to call it. In effect, IGP metric may not always be the the choice in our case. 
 
As an opertor I am interested in the best solution and the more options we see, the better for us to choose what is appropriate for us. However I do not see this being reflected in any of the discussions here unfortunately. 
 
Back to the point, using a NH SAFI if I need three ASBR paths on a PE (let me call this Premium PE), I do have to modify the admin costs on each of these sets of PEs to each of the ASBR manually to a metric that will influence the RR to announce the best path to the PE. You state multiple paths can be announced as well - let us say I need 3. Is this using ADD-PATH? If so how do you compute the best path on ADD-PATH?
 
On the draft using RT and RTC, I do clearly see the means of achieving a set of preferred paths being advertised and received on the PE. The RR in this case strictly announces paths that match a given RT list which can also be controlled in regard to how many paths a PE is interested in. I would imagine that in the event of a path being withdrawn, the RR would send an alternate path with the same RT if it is available, as it what ADD-PATH is expected to do in any case which is announce additional paths if announced paths are withdrawn - I specifically refer to the case where pure ADD-PATH implementations constrain the number of paths to a specific number of paths (min and max no. of paths).
 
RT configurations are not a overhead for us, and I do not expect everyone to feel the same. If we were to implement this solution for us, I would just configure ASBRs with Route Targets specific to our needs, and have the PEs choose between them. Its simple for me since even IP addressing needs planning, VPNv4 RT allocations needed planning when we implemented RT. I am not drawing parallels, but I am more focussed on the ease of adding new RTs whenever a new requirement comes up. On the topic of ensuring the best path on the PE which someone raised, I would use a local policy to influence that. Probably use "weights" or some equivalent or expect the authors of this draft to have a mechanism to probably specify a method of assigning a weight to each RT, rather than having the RR do something here.
 
I am personally not comfortable and a strong advocate against running an SPF instance - in whatever shape on my RR. I do want any IGP related issue, be it a software bug or any other problem in respect to the RR having the need to have an IGP view of sorts - to impact the BGP machine. Whatever the promises are I would want to see this perform in my lab under different contraints using production code before this can be looked at.
 
Summary - Nice to have two choices, a. SPF on RR for closest IGP announcement b. Use RTs and RTC to have preference or operator based path announcement, with the favour tilting towards the RT approach as both the drafts in its present form stand today.
 
Prem

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 11 Jun 2011 00:05:15 +0200

Hi Reshmi,

Coming back to our discussion in the morning I have one clarification 
question.

> We have been having similar requirements to steer traffic through
> selective exit points in the network which are driven by customer
> requirements, example having premium customers use a set of ASBRS vs. a
> different set of other customers using another set of ASBRs within a
> given region/POP or whatever you may like to call it. In effect, IGP
> metric may not always be the the choice in our case.

Do you see a case where on the same PE which both premium and not so 
premium customers are attached to your network policy would require them 
to exit via different ASBRs out of your network ?

Many thx,
R.