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

From: Reshmi Prem <[email-masked]>
Date: Fri, 10 Jun 2011 04:15:05 -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: Fri, 10 Jun 2011 14:23:36 +0200

Hi Reshmi and All,

Many thx for your input. I think I have a very good news for you and for 
other operators which require policy based preferred exit management.

All of your stated requirements can be acoomplished _today_ in your 
current network without any need to:

- wait for new ietf consensus,
- extend and modify RTC behaviour on RRs
- add or delete any RT in the network
- introduce notion of "special RT" on the RR
- change the semantics of "default RT" as noticed by Bruno
- correlate RT values between PEs and ASBRs
- use add-paths or wait for your PE/RR/ASBR to support it
- add any single line of new code to existing network operating systems

The solution I am suggesting is very simple and straight forward. Let's 
call it:

"Hybrid IBGP Sessions"

Description:
------------

To address your requirements all what is needed is to add 1 or 2 
additional IBGP session from PE to set of exit ASBRs of choice. On PE's 
inbound side you configure on a per session basis weight or local pref 
accordingly to your preference and you are done.

You keep your existing session to RR just to make sure you always learn 
some best path when your preferred best paths are gone.

Your second session to your back-up RR is not optional. As a matter of 
fact you can remove it or you can transition it from such backup RR to 
receive diverse-path as described in 
draft-ietf-grow-diverse-bgp-path-dist. That will even further enhance 
your network robustness and fault tolerance - but this is totally optional.

Discussion:
-----------

Since PEs today support 1000s of BGP sessions adding one or two there 
should not be a problem to anyone.

Now one may argue that you would need to do a lot of configuration on 
the ASBRs to add/delete IBGP sessions there. Nothing more mistaken. \

Note that decent BGP implementations already for a long time support 
single sided BGP session provisioning. So all ASBRs can be configured 
today to automatically accept IBGP session requests from pre-configured 
range of peer's session addresses. If that security measure is not 
sufficient there is also an option do add MD5 signature match.

Also note that this does not put any additional burden on ASBRs as all 
of those PEs will be in the same peer group there. And as we all know 
replication is a very CPU cheap process.

RRs remain as is. No single change needed. They continue to have peers 
in the single peer group and no single additional SPF is executed there.

In other words RRs are tools to help operator instead of pushing more 
burden on them. While they can help in network operation and I am still 
very much convinced that running few more spf there is in the noise of 
their powers. They can also be completely bypassed when there is 
operational or commercial need to prefer set of exit points on a per PE 
basis just like demonstrated above in "Hybrid IBGP Sessions" case.

I hope your customers will be happy to exit via preferred ASBRs very 
soon. If you or anyone on the IDR WG list think that more formal 
description of this basic behaviour is required I will be more then 
happy to turn this into 1-2 page informational draft as well.

Best regards,
R.

> 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: Fri, 10 Jun 2011 14:27:07 +0200

Small typo ..

Is:

Your second session to your back-up RR is not optional.

Should be:

Your second session to your back-up RR is _now_ optional.

Apologies,
RR.

---

From: Reshmi Prem <[email-masked]>
Date: Fri, 10 Jun 2011 05:28:49 -0700 (PDT)

Sorry about that - The idea of iBGP sessions between PE and ASBR etc does not fit our needs, but thanks for the very innovative advise. I expected a more mature response to the feedback I had offered, but it seems you are totally not in a mood to look at my views and answer my questions but just seem to say "what i offer is the best - take it or leave it". and you want to make a statement. I feel there is no point in having a discussion with a person with ideas like you.
 
Prem

--- On Fri, 6/10/11, Robert Raszuk <[email-masked]> wrote:

From: Robert Raszuk <[email-masked]>
Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection
To: "Reshmi Prem" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Friday, June 10, 2011, 7:23 AM

Hi Reshmi and All,

Many thx for your input. I think I have a very good news for you and for other operators which require policy based preferred exit management.

All of your stated requirements can be acoomplished _today_ in your current network without any need to:

The solution I am suggesting is very simple and straight forward. Let's call it:

"Hybrid IBGP Sessions"

Description:
------------

To address your requirements all what is needed is to add 1 or 2 additional IBGP session from PE to set of exit ASBRs of choice. On PE's inbound side you configure on a per session basis weight or local pref accordingly to your preference and you are done.

You keep your existing session to RR just to make sure you always learn some best path when your preferred best paths are gone.

Your second session to your back-up RR is not optional. As a matter of fact you can remove it or you can transition it from such backup RR to receive diverse-path as described in draft-ietf-grow-diverse-bgp-path-dist. That will even further enhance your network robustness and fault tolerance - but this is totally optional.

Discussion:
-----------

Since PEs today support 1000s of BGP sessions adding one or two there should not be a problem to anyone.

Now one may argue that you would need to do a lot of configuration on the ASBRs to add/delete IBGP sessions there. Nothing more mistaken. \

Note that decent BGP implementations already for a long time support single sided BGP session provisioning. So all ASBRs can be configured today to automatically accept IBGP session requests from pre-configured range of peer's session addresses. If that security measure is not sufficient there is also an option do add MD5 signature match.

Also note that this does not put any additional burden on ASBRs as all of those PEs will be in the same peer group there. And as we all know replication is a very CPU cheap process.

RRs remain as is. No single change needed. They continue to have peers in the single peer group and no single additional SPF is executed there.

In other words RRs are tools to help operator instead of pushing more burden on them. While they can help in network operation and I am still very much convinced that running few more spf there is in the noise of their powers. They can also be completely bypassed when there is operational or commercial need to prefer set of exit points on a per PE basis just like demonstrated above in "Hybrid IBGP Sessions" case.

I hope your customers will be happy to exit via preferred ASBRs very soon. If you or anyone on the IDR WG list think that more formal description of this basic behaviour is required I will be more then happy to turn this into 1-2 page informational draft as well.

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Jun 2011 14:33:06 +0200

> Sorry about that - The idea of iBGP sessions between PE and ASBR etc
> does not fit our needs, but thanks for the very innovative advise.

Can you please elaborate why the idea of adding iBGP sessions between PE 
and ASBR etc does not fit your needs ?

Thx,
R.

---

From: Reshmi Prem <[email-masked]>
Date: Fri, 10 Jun 2011 05:36:09 -0700 (PDT)

Its policy that we would not like to have that kind of meshiness. I am sure you would not argue about the policy of an operator.
 
Prem

Date: Friday, June 10, 2011, 7:33 AM

> does not fit our needs, but thanks for the very innovative advise.

Can you please elaborate why the idea of adding iBGP sessions between PE and ASBR etc does not fit your needs ?

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Jun 2011 14:51:52 +0200

Indeed I will not argue with policy of an operator regardless what type 
of network he is operating.

However let me point out that "this kind of meshiness" is much easier to 
configure and manage when compared with new overlay of route targets 
semantics the alternative proposal is all about.

With that in mind I would like to hear other operator's opinions about 
their network policies which would prohibit PE to ASBR iBGP sessions yet 
in the same time request for per PE manual preference specification of 
exit points.

I think it would also be very helpful to hear experience of those 
operators which do not use route reflectors at all for their IPv4/IPv6 
Internet route distribution.

Many thx,
R.

> Its policy that we would not like to have that kind of meshiness. I am
> sure you would not argue about the policy of an operator.
> Prem
>
> --- On *Fri, 6/10/11, Robert Raszuk /<[email-masked]>/* wrote:
>
>
>     Cc: [email-masked], [email-masked],
>     [email-masked], [email-masked], [email-masked]
>     Can you please elaborate why the idea of adding iBGP sessions
>     between PE and ASBR etc does not fit your needs ?
>
>     Thx,
>     R.
>

---

From: Reshmi Prem <[email-masked]>
Date: Fri, 10 Jun 2011 05:59:46 -0700 (PDT)

Good that are not arguing on that. 
 
Policies are always not about operations and management. There are other reasons as well. I am sure you will hear about our specific needs or have already heard from your account teams.
 
One may argue as to why not place a RR in every POP with an ASBR, and handle the iBGP sessions so that the closest IGP path is always provided to the PE. So why did you write an ORR draft?? I presume to cater to certain set of requirements which come with some given contraints.
 
Robert, understand that operators are unique in some sense or the other. What you deem as less important may be important to us. Our business needs technology to support revenues and thats the bottomline, not the vice versa. 
 
So dont start becoming the advocate on how an operator should define needs or which needs are reasonable.
 
Prem

Date: Friday, June 10, 2011, 7:51 AM

Good.

Policies are always not about operations and management. There are other reasons as well. 

Many thx,
R.

>      > Sorry about that - The idea of iBGP sessions between PE and ASBR etc
>      > does not fit our needs, but thanks for the very innovative advise.
>

---

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

I would like to understand this:

Many thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Jun 2011 15:11:57 +0200

> One may argue as to why not place a RR in every POP with an ASBR, and
> handle the iBGP sessions so that the closest IGP path is always provided
> to the PE. So why did you write an ORR draft??

So I guess you have not been at Nanogs nor RIPEs nor APRICOT meetings 
where I clearly demonstrated that the best place of RR remains to be in 
data path on the POP to core boundary (just like it was traditionally 
recommended). And that design is still deployed and works great in many 
networks today.

Only due to some networks .. where PE-PE or PE-ASBR is all tunneled .. 
RRs no longer are in the data path. Those networks try to move them to 
core locations and that's the base of ORR proposal. IDR WG ORR draft is 
not to recommend new way of route reflection. Very much contrary .. it 
is designed to assure hot potato routing only for those operators which 
need it and which use pure control plane RRs.

With addition of NH-SAFI it also addresses needs of those operators 
which need to overwrite what IGP SPF product would be.

> I presume to cater to
> certain set of requirements which come with some given contraints.
> Robert, understand that operators are unique in some sense or the other.
> What you deem as less important may be important to us. Our business
> needs technology to support revenues and thats the bottomline, not the
> vice versa.

And I am here to judge an importance of your choice. But in order to 
help to meet your goals I am here to better understand your needs.

R.

---

From: Reshmi Prem <[email-masked]>
Date: Fri, 10 Jun 2011 06:18:36 -0700 (PDT)

I am not arguing about whether you are the messiah of a revolution in BGP Route Reflection or not.
 
If I use an RR (not in the forwarding plane imagine) at every POP which has an ASBR (imagine there are 10 ASBR POPs). If I have each PE in every POP peer with their closest RR - which is the RR in a POP which has the closest IGP metric in regard to that PE. Would'nt I be ensured that this PE will definitely receieve the ASBR path that has the closest IGP metric??
 
Prem

Date: Friday, June 10, 2011, 8:11 AM

> to the PE. So why did you write an ORR draft??

So I guess you have not been at Nanogs nor RIPEs nor APRICOT meetings where I clearly demonstrated that the best place of RR remains to be in data path on the POP to core boundary (just like it was traditionally recommended). And that design is still deployed and works great in many networks today.

Only due to some networks .. where PE-PE or PE-ASBR is all tunneled .. RRs no longer are in the data path. Those networks try to move them to core locations and that's the base of ORR proposal. IDR WG ORR draft is not to recommend new way of route reflection. Very much contrary .. it is designed to assure hot potato routing only for those operators which need it and which use pure control plane RRs.

With addition of NH-SAFI it also addresses needs of those operators which need to overwrite what IGP SPF product would be.

> needs technology to support revenues and thats the bottomline, not the

And I am here to judge an importance of your choice. But in order to help to meet your goals I am here to better understand your needs.

R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Jun 2011 15:21:14 +0200

Hi Reshmi,

> I would like to understand this:

Let me try to help ..

> will influence the RR to announce the best path to the PE.

That is correct. However please notice that this is no more 
configuration overhead then allocating three RTs on such premium PE in 
order to advertise them to the RR.

In fact metric could be expressed by numerical RT value.

That is how you express the local Premium PE policy. And just for 
completeness such PE policy can be expressed on the PE then signalled by 
using NH-SAFI to RR or directly on the RR when you are establishing a 
session between PE-RR.

> You state

Add-path spec deliberately avoids discussion on best path selection 
rules. Add-path spec is design to represent encoding on how BGP can send 
you more then single path on the same session.

Any application which would like utilize add-path requires separate 
specification.

In this particular case using ORR draft RR when advertising closest exit 
path, 2nd closest and 3rd closest towards PE can set local pref 
accordingly to the computed order of paths so PE will select using 
normal best path selection rules correctly.

Best regards,
R.

---

From: Reshmi Prem <[email-masked]>
Date: Fri, 10 Jun 2011 06:27:08 -0700 (PDT)

Robert,
 
Let me make sure that we are in sync.
 
That is correct. However please notice that this is no more configuration overhead then allocating three RTs on such premium PE in order to advertise them to the RR.

That is how you express the local Premium PE policy. And just for completeness such PE policy can be expressed on the PE then signalled by using NH-SAFI to RR or directly on the RR when you are establishing a session between PE-RR.

>>>>>>>>>So the configuration is no more complex than the RTC Draft in terms of number of lines or whatever that is.
 
In this particular case using ORR draft RR when advertising closest exit path, 2nd closest and 3rd closest towards PE can set local pref accordingly to the computed order of paths so PE will select using normal best path selection rules correctly.

>>>>>>>>>>>what scheme or what do you use to send three paths? is there a draft? i am keen to know if a PE sets a metric to 3 ASBRs as 5,10 and 15. Using NH SAFI how do i tell the RR to send me 3 paths?
 
Prem

Date: Friday, June 10, 2011, 8:21 AM

Hi Reshmi,

Let me try to help ..

> will influence the RR to announce the best path to the PE.

That is correct. However please notice that this is no more configuration overhead then allocating three RTs on such premium PE in order to advertise them to the RR.

That is how you express the local Premium PE policy. And just for completeness such PE policy can be expressed on the PE then signalled by using NH-SAFI to RR or directly on the RR when you are establishing a session between PE-RR.

> using ADD-PATH? If so how do you compute the best path on ADD-PATH?

Add-path spec deliberately avoids discussion on best path selection rules. Add-path spec is design to represent encoding on how BGP can send you more then single path on the same session.

Any application which would like utilize add-path requires separate specification.

In this particular case using ORR draft RR when advertising closest exit path, 2nd closest and 3rd closest towards PE can set local pref accordingly to the computed order of paths so PE will select using normal best path selection rules correctly.

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Jun 2011 15:28:45 +0200

> BGP Route Reflection or not.

Nope I am not a messiah of any sort, but now you know what my initials 
stand for.... ;-)

> If I use an RR (not in the forwarding plane imagine) at every POP which
> has an ASBR (imagine there are 10 ASBR POPs). If I have each PE in every
> POP peer with their closest RR - which is the RR in a POP which has the
> closest IGP metric in regard to that PE. Would'nt I be ensured that this
> PE will definitely receieve the ASBR path that has the closest IGP metric??
> Prem

Yes you will be ensured under two conditions:

- assuming that such RRs reside in the POP which will always have local
   exit ASBR

- that your RR even in the control plane has visibility to the area 0
   in the case of hierarchical IGP (practically is an ABR).

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Jun 2011 15:36:42 +0200

Reshmi,

> Let me make sure that we are in sync.

Very good idea !

>  >>>>>>>>>So the configuration is no more complex than the RTC Draft in
> terms of number of lines or whatever that is.

Yes but _only_ from PE point of view. Essentially if you are asking for 
manual policy you need to express it somewhere in the network - no way 
around that.

But with NH-SAFI there is _no change_ to any BGP operation on the RR, no 
RTC, no applying any new communities on the ASBR. So if we are to be in 
sync let's consider full picture.

>  >>>>>>>>>>>what scheme or what do you use to send three paths? is there
> a draft? i am keen to know if a PE sets a metric to 3 ASBRs as 5,10 and
> 15. Using NH SAFI how do i tell the RR to send me 3 paths?
> Prem

In today's implementations of add-path it is local configuration on the 
RR when you specify number of add-path eligible paths.

When we implement NH-SAFI draft RR will ask PE for metrics to all next 
hops let's say 10 it has in the BGP table. Then PE will reply with 
metric to 3 of them say 5, 10, 15 and metric 0 to the rest of them which 
means I am not interested to hear about them.

Hence RR will only send 3 paths to such PE without any need to manual 
configure the number on the RR side per POP or per client.

Best regards,
R.

---

From: Reshmi Prem <[email-masked]>
Date: Fri, 10 Jun 2011 06:58:25 -0700 (PDT)

Absolutely. So I dont need an ORR at all.

Date: Friday, June 10, 2011, 8:28 AM

> BGP Route Reflection or not.

Nope I am not a messiah of any sort, but now you know what my initials stand for.... ;-)

Thx,
R.

---

From: Reshmi Prem <[email-masked]>
Date: Fri, 10 Jun 2011 07:02:34 -0700 (PDT)

>>>>>>>>>>>How does this tie in to the whole story now? Are you saying that in your ORR proposal I have configure manual policies on the RR for each PE that has these needs , by statically defining each NH modifying local-pref on the RR towards each PE?
 
>>>>>>>> What happens if all the three NHs disappear or fail?
 
Prem

Date: Friday, June 10, 2011, 8:36 AM

Reshmi,

Very good idea !

>  >>>>>>>>>So the configuration is no more complex than the RTC Draft in

Yes but _only_ from PE point of view. Essentially if you are asking for manual policy you need to express it somewhere in the network - no way around that.

But with NH-SAFI there is _no change_ to any BGP operation on the RR, no RTC, no applying any new communities on the ASBR. So if we are to be in sync let's consider full picture.

>  >>>>>>>>>>>what scheme or what do you use to send three paths? is there

In today's implementations of add-path it is local configuration on the RR when you specify number of add-path eligible paths.

When we implement NH-SAFI draft RR will ask PE for metrics to all next hops let's say 10 it has in the BGP table. Then PE will reply with metric to 3 of them say 5, 10, 15 and metric 0 to the rest of them which means I am not interested to hear about them.

Hence RR will only send 3 paths to such PE without any need to manual configure the number on the RR side per POP or per client.

Best regards,
R.

---

From: <[email-masked]>
Date: Fri, 10 Jun 2011 15:46:44 +0200

Prem,

I agree with you that there are two needs:

-a- (IGP based) shortest path routing;

-b- (SP's) policy based routing.

And I understood your need is "b".

That being said, I'm not sure I understood why you state that the combined (additional) use of RT communities & RTC is the best solutions to fit this need.

e.g. why expressing routing preference using NH SAFI is harder compared the use of both RT communities and RTC routes. In both cases, given that the SP wants to specify its specific need, there is a need to configure it somewhere. (as opposed to IGP based shortest path routing where the information is already in the IGP).

e.g. why not using regular BGP communities -which I assume are already configured on the ASBR advertising BGP routes (vs RT communities which need to be configured additionally)- with BGP policies configured on the RR (e.g. to refer to the example in §5.2 of the Vinod-Lavalle draft, only advertise route from Tokyo to PE in Tokyo).

Could you elaborate on this?

Thanks,

Regards,

Bruno

From: Reshmi Prem [mailto:[email-masked]] 
Sent: Friday, June 10, 2011 1:15 PM
To: [email-masked]
Cc: [email-masked]; DECRAENE Bruno RD-CORE-ISS; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection

Robert and All,

Prem

---

From: "iLya" <[email-masked]>
Date: Fri, 10 Jun 2011 16:11:41 +0200

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

I can only guess to what such question leads, so let me show best way to 
implement what you desire using NH SAFI draft. PE can be configured with 
static sequence number of first N (3 in your case) most preferred next-hop, 
whatever next-hops remains after such pre-selection are ordered by ever 
increasing IGP cost taken _at the time of calculation_ (and and this order 
may change and be re-announced in the future should network topology 
change). This information is announced to RR via NH SAFI. The RR uses 
information instead of its own IGP cost to next-hop when it performs 
best-path selection. If ADD-PATH is not configured, RR sends only best 
(based on client perspective) path, if ADD-PATH is configured RR sends N (3 
in your case) best (again from client perspective) path's. The beauty of 
this approach is that if a prefix is not available via first N (3 in your 
case) prefered next-hops RR will still send N (3 in your case) best (from 
client perspective) possible paths. Without NH SAFI and WG ORR the clients 
will receive best path from RR perspective (that can be on the other side of 
the continent) and not from their own.

/iLya

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Jun 2011 16:13:26 +0200

>  >>>>>>>>>>>How does this tie in to the whole story now? Are you saying
> that in your ORR proposal I have configure manual policies on the RR for
> each PE that has these needs , by statically defining each NH modifying
> local-pref on the RR towards each PE?

Nope .. this is automatic from the order of BGP paths selected to be 
advertised. No manual local pref setting on RR needed at all.

 >  >>>>>>>> What happens if all the three NHs disappear or fail?

It's normal BGP again .. you get next three available paths. Remember 
that metric check is just one of 14 steps of BGP best path selection.

If you do not break tie at IGP metric step you move to bgp best path 
selection next step.

And let's point out that with RT filtering in place (without this 
special RR RT to semantically mean always send over all best path) this 
is one of the problems in draft-vinod.

Thx,
R.

---

From: Reshmi Prem <[email-masked]>
Date: Fri, 10 Jun 2011 07:30:26 -0700 (PDT)

All,
 
With Robert's ORR Draft = Manual configurations needed on the RR to list an order of BGP paths to be advertised per PE (I use the term per PE to make it granular). If they disappear, then next 3 paths as per RRs business as usual (RRs independent decission). Each time a new ASBR is added and has to be used by this PE, Policy on the RR needs to be modified. Concern: Our network tries to minimize or have no manual configurations on RRs.

With Vinod's ORR Draft: No policies on the RR. New ASBR added, needs a Route Target assignment. Multiple paths can be announced as per RTC. Would be keen to understand how the local PE would handle best path selection - Local weights per RT, Local policy on PE??. 
 
NH Draft: No policy on RR, only PEs need to be manually configured with admin costs and RR does reflect best paths based on these values. Concern: With vinod's draft, an RT can mean more than a single ASBR, but with NH draft, each ASBR path needed in the PE needs to be configured with an Admin cost, so more work. Add-path used for announcing multiple paths (illiya mentioned it). 
 
Both NH and Vinod's ORR draft still specify that in the event of an ASBR path being withdrawn, an additional path will be advertised since this is the default behavior of ADD-PATH - So Vinod's draft and NH draft are not doing something novel from what Add-Path specifies.
 
Prem

Date: Friday, June 10, 2011, 9:13 AM

>  >>>>>>>>>>>How does this tie in to the whole story now? Are you saying

Nope .. this is automatic from the order of BGP paths selected to be advertised. No manual local pref setting on RR needed at all.

>  >>>>>>>> What happens if all the three NHs disappear or fail?

It's normal BGP again .. you get next three available paths. Remember that metric check is just one of 14 steps of BGP best path selection.

If you do not break tie at IGP metric step you move to bgp best path selection next step.

And let's point out that with RT filtering in place (without this special RR RT to semantically mean always send over all best path) this is one of the problems in draft-vinod.

Thx,
R.

---

From: "iLya" <[email-masked]>
Date: Fri, 10 Jun 2011 18:17:44 +0200

> With Vinod's ORR Draft: No policies on the RR. New ASBR added, needs a 
> Route Target assignment. Multiple paths can be announced as per RTC. Would 
> be keen to understand how the local PE would handle best path selection - 
> Local weights per RT, Local policy on PE??.
>

if there are multiple non-preferred next-hops (which are not available via 
preferred), then Vinod's draft would return routes based on RR's view of the 
world

> NH Draft: No policy on RR, only PEs need to be manually configured with 
> admin costs and RR does reflect best paths based on these values. Concern: 
> With vinod's draft, an RT can mean more than a single ASBR, but with NH 
> draft, each ASBR path needed in the PE needs to be configured with an 
> Admin cost, so more work. Add-path used for announcing multiple paths 
> (illiya mentioned it).
>
Note that with NH draft you indeed configure N preferences on each of K PE, 
but nothing on ASBRs, so in total O(N*K)complexity. With RT you configure 1 
RT (assuming that RT-default is always wanted by default) on each of K PE 
and M RT on each L ASBR, so in total O(K+M*L) complexity. If you want two 
preferred exits for 100 PE (PE's don't have to have same preferences) then 
200 steps in case of NH draft regardless of number of ASBR's. If you have 
100 PE's and 50 ASBR's then you have 150 steps in case of Vinod's draft. I 
think 200 (NH) vs 150 (Vinod) steps is price worth paying for getting best 
route (in case of NH draft) from client's perspective in case destination 
prefix is not available over preferred path. Should you think the numbers in 
my example are low, I'd be interested to see realistic scenario where 
numbers will be significantly higher.

> Both NH and Vinod's ORR draft still specify that in the event of an ASBR 
> path being withdrawn, an additional path will be advertised since this is 
> the default behavior of ADD-PATH - So Vinod's draft and NH draft are not 
> doing something novel from what Add-Path specifies.
>

the difference is in this case NH SAFI draft will provide best route from 
client's perspective, Vinod's draft will provide best route from RR 
perspective.

Kind regards,
iLya

---

From: Vinod Joseph <[email-masked]>
Date: Fri, 10 Jun 2011 18:12:56 +0100

Ilya and Prem,

Vinod - As with the NH draft where you need to define admin metrics on a per ASBR, with the proposed draft you would need to identify potential ASBRs in the network which you want to signal interest in. 

Vinod - That's not correct, If a path belonging to an RT is withdrawn  then the RR would announce another path ASBR path that matches the same RT. 

Regards

Vinod Joseph
Professional Services - Service Provider Europe
Juniper Networks                                                                   
M: +44 (0) 7500 835 876
E: [email-masked]

-----Original Message-----
From: iLya [mailto:[email-masked]] 
Sent: 10 June 2011 17:18
To: Reshmi Prem; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Vinod Joseph; [email-masked]
Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection

Kind regards,
iLya

---

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

Ilya,
 
I did not see your draft specifying that you would be using ADD-PATH, Can you confirm this?
 
Vinod's draft specifies a means of using an RR specific RT to permit a RR calculated best path in addition to RTC specified paths. How does your draft handle this? What happens if the list of ASBRS that i indicate a metric for disappear??
 
Prem

--- On Fri, 6/10/11, Vinod Joseph <[email-masked]> wrote:

From: Vinod Joseph <[email-masked]>
Subject: RE: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection
To: "iLya" <[email-masked]>, "Reshmi Prem" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Friday, June 10, 2011, 12:12 PM

Ilya and Prem,

Regards

Vinod Joseph

-----Original Message-----
From: iLya [mailto:[email-masked]] 
Sent: 10 June 2011 17:18
To: Reshmi Prem; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Vinod Joseph; [email-masked]
Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection

Kind regards,
iLya

---

From: Ilya Varlashkin <[email-masked]>
Date: Fri, 10 Jun 2011 21:04:03 +0200

> I did not see your draft specifying that you would be using ADD-PATH, Can you confirm this?

ehrm...use of ADD-PATH is not feature of NH SAFI, but of...ADD-PATH. As long as you don't do anything what other specification forbids, do you need to describe every possible combination of features that could be used together? Today you can use ADD-PATH to send multiple PATHs, tomorrow there will be another solution to do it. NH SAFI neither forbids nor requires you to use any other BGP feature beyond what's specified in the drafts, so by all means if you want multiple best PATHs from RR-client perspective you can combine NH SAFI with ADD-PATH. If you don't need multiple paths, you just don't use multiple paths. Do you feel this combination should be explicitly spelled in the NH SAFI specs?

> Vinod's draft specifies a means of using an RR specific RT to permit a RR calculated best path in addition to RTC specified paths. How does your draft handle this? What happens if the list of ASBRS…

ok, implicit assumption is that RR will use a) cost provided by RR-c; b) if RR-c cost is unavailable for whatever reason RR will use its own cost. Note that original idea is that RR-c informs RR about all costs. If network policies call for non-IGP preference, then RR-c can use ever-increasing numbers calculated in a way operator prefers. First N (number of preferred exits) can be explicitly configured on RR-c, the rest RR-c will calculate itself by ordering IGP costs of remaining exits. To give an example: a PE prefers NH5 and NH9, which operator configures on the PE manually. Let's say at some moment _all_ prefixes are reachable via set of next-hops NH1,NH2,...,NH50. PE sends following info to RR: first it tells that NH5:cost1, NH9:cost2 (because it configured by operator), then PE takes remaining next-hops and arranges them in order of increasing IGP cost behind first two next-hops, the cost reported for NH-i to RR is the position of that NH-i in the just created list. When IGP cost to non-preferred next-hops changes (due to topology change), PE just re-evaluates NH order and sends updated cost to RR. When preferred ASBR's are not available as feasible path to certain prefix, RR just uses whatever is next NH in the list received from RR-c but only for prefixes where preferred ASBR is not feasible exit. When preferred ASBR's fail (i.e. no path can be reached via them), RR uses for whatever is next NH in the list received from RR-c for all prefixes. So in general, when certain prefix cannot be reached via preferred ASBR's (regardless of the reason) then RR uses next NH in the list received from RR-c. If for some reason connectivity from RR-c to ASBR fails, RR-c will inform RR that particular NH is no longer feasible (as described in NH SAFI draft) and RR will stop considering that ASBR when calculating routes for given RR-c (even if from RR perspective or from any other router perspective that very same ASBR is still reachable). Same question as above - do you feel such behaviour should be explicitly spelled out even though it's natural?

Kind regards,
iLya

---

From: Reshmi Prem <[email-masked]>
Date: Fri, 10 Jun 2011 12:39:06 -0700 (PDT)

Illya:

>>>>>>>>>>>>>>> You are talking about using ADD-PATH to choose a select no. of paths based only on admin costs that are statically specified on the PE. This needs some work or integration or extension or whatever you call it, to ADD-PATH. You need to mention this in your draft.
 
ok, implicit assumption is that RR will use a) cost provided by RR-c; b) if RR-c cost is unavailable for whatever reason RR will use its own cost. Note that original idea is that RR-c informs RR about all costs. If network policies call for non-IGP preference, then RR-c can use ever-increasing numbers calculated in a way operator prefers. First N (number of preferred exits) can be explicitly configured on RR-c, the rest RR-c will calculate itself by ordering IGP costs of remaining exits. To give an example: a PE prefers NH5 and NH9, which operator configures on the PE manually. Let's say at some moment _all_ prefixes are reachable via set of next-hops NH1,NH2,...,NH50. PE sends following info to RR: first it tells that NH5:cost1, NH9:cost2 (because it configured by operator), then PE takes remaining next-hops and arranges them in order of increasing IGP cost behind first two next-hops, the cost reported for NH-i to RR is the position of that NH-i in the
 just created list. When IGP cost to non-preferred next-hops changes (due to topology change), PE just re-evaluates NH order and sends updated cost to RR. When preferred ASBR's are not available as feasible path to certain prefix, RR just uses whatever is next NH in the list received from RR-c but only for prefixes where preferred ASBR is not feasible exit. When preferred ASBR's fail (i.e. no path can be reached via them), RR uses for whatever is next NH in the list received from RR-c for all prefixes. So in general, when certain prefix cannot be reached via preferred ASBR's (regardless of the reason) then RR uses next NH in the list received from RR-c. If for some reason connectivity from RR-c to ASBR fails, RR-c will inform RR that particular NH is no longer feasible (as described in NH SAFI draft) and RR will stop considering that ASBR when calculating routes for given RR-c (even if from RR perspective or from any other router perspective that very
 same ASBR is still reachable). Same question as above - do you feel such behaviour should be explicitly spelled out even though it's natural?
 
>>>>>>>>>>>>>>>>I am lost sorry. Simple example: network has 10 ASBRs. PE1 says ASBR1=METRIC15 and ASBR2=METRIC20 and sends this info to the RR. Now RR reflects both these ASBR paths to PE1 with the same metrics?
 
>>>>>>>>>>>>>>>>>>>>PE1 automatically calculates IGP Cost to ASBR 3--10?
>>>>>>>>>>>>>>>>>>>>>>> Assume ASBR 3-10 have metrics as follows ASBR3=3, ASBR4=4 .....ASBR10=10, This can happen right? 
 
>>>>>>>>>>>>>>>>>>>>>>>>>> RR advertises ASBR 3 TO ASBR 10 paths to PE1? 
 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How does RR ensure that non candidate (preferred paths) are not announced to the PE upfront?
 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How do you ensure that non candidate paths always have a higher metric than candidate paths?
 
- Prem

--- On Fri, 6/10/11, Ilya Varlashkin <[email-masked]> wrote:

From: Ilya Varlashkin <[email-masked]>
Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection
To: "Reshmi Prem" <[email-masked]>
Cc: "[email-masked] Raszuk" <[email-masked]>, "Vinod Joseph" <[email-masked]>, [email-masked], [email-masked], [email-masked], "IETF IDR" <[email-masked]>
Date: Friday, June 10, 2011, 2:04 PM

> Vinod's draft specifies a means of using an RR specific RT to permit a RR calculated best path in addition to RTC specified paths. How does your draft handle this? What happens if the list of ASBRS…

ok, implicit assumption is that RR will use a) cost provided by RR-c; b) if RR-c cost is unavailable for whatever reason RR will use its own cost. Note that original idea is that RR-c informs RR about all costs. If network policies call for non-IGP preference, then RR-c can use ever-increasing numbers calculated in a way operator prefers. First N (number of preferred exits) can be explicitly configured on RR-c, the rest RR-c will calculate itself by ordering IGP costs of remaining exits. To give an example: a PE prefers NH5 and NH9, which operator configures on the PE manually. Let's say at some moment _all_ prefixes are reachable via set of next-hops NH1,NH2,...,NH50. PE sends following info to RR: first it tells that NH5:cost1, NH9:cost2 (because it configured by operator), then PE takes remaining next-hops and arranges them in order of increasing IGP cost behind first two next-hops, the cost reported for NH-i to RR is the position of that NH-i in the
 just created list. When IGP cost to non-preferred next-hops changes (due to topology change), PE just re-evaluates NH order and sends updated cost to RR. When preferred ASBR's are not available as feasible path to certain prefix, RR just uses whatever is next NH in the list received from RR-c but only for prefixes where preferred ASBR is not feasible exit. When preferred ASBR's fail (i.e. no path can be reached via them), RR uses for whatever is next NH in the list received from RR-c for all prefixes. So in general, when certain prefix cannot be reached via preferred ASBR's (regardless of the reason) then RR uses next NH in the list received from RR-c. If for some reason connectivity from RR-c to ASBR fails, RR-c will inform RR that particular NH is no longer feasible (as described in NH SAFI draft) and RR will stop considering that ASBR when calculating routes for given RR-c (even if from RR perspective or from any other router perspective that very
 same ASBR is still reachable). Same question as above - do you feel such behaviour should be explicitly spelled out even though it's natural?

Kind regards,
iLya

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Jun 2011 22:12:58 +0200

Hi Reshmi,

Since you have been referring many times today that you are an operator 
may I ask what is the AS number of the network you manage or engineer ?

Many thx,
R.

---

From: Vinod Joseph <[email-masked]>
Date: Fri, 10 Jun 2011 21:28:38 +0100

Hi Prem,

Your question on path selection on the local PE will be elaborated in the following version of the draft to be released shortly.

Regards

Vinod Joseph

-----Original Message-----
From: Vinod Joseph 
Sent: 10 June 2011 18:13
To: iLya; Reshmi Prem; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection

Ilya and Prem,

Regards

Vinod Joseph

-----Original Message-----
From: iLya [mailto:[email-masked]] 
Sent: 10 June 2011 17:18
To: Reshmi Prem; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Vinod Joseph; [email-masked]
Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection

Kind regards,
iLya

---

From: Vinod Joseph <[email-masked]>
Date: Sun, 12 Jun 2011 20:05:36 +0100

Still waiting for inputs on this, Robert can you clarify this please?

Regards

Vinod Joseph

Juniper Networks

M: +44 (0) 7500 835 876

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

From: Reshmi Prem [mailto:[email-masked]] 
Sent: 10 June 2011 20:39
To: Ilya Varlashkin
Cc: [email-masked] Raszuk; Vinod Joseph; [email-masked];
[email-masked]; [email-masked]; IETF IDR
Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection

Illya:

ehrm...use of ADD-PATH is not feature of NH SAFI, but of...ADD-PATH. As
long as you don't do anything what other specification forbids, do you
need to describe every possible combination of features that could be
used together? Today you can use ADD-PATH to send multiple PATHs,
tomorrow there will be another solution to do it. NH SAFI neither
forbids nor requires you to use any other BGP feature beyond what's
specified in the drafts, so by all means if you want multiple best PATHs
from RR-client perspective you can combine NH SAFI with ADD-PATH. If you
don't need multiple paths, you just don't use multiple paths. Do you
feel this combination should be explicitly spelled in the NH SAFI specs?

>>>>>>>>>>>>>>> You are talking about using ADD-PATH to choose a select
no. of paths based only on admin costs that are statically specified on
the PE. This needs some work or integration or extension or whatever you
call it, to ADD-PATH. You need to mention this in your draft.

ok, implicit assumption is that RR will use a) cost provided by RR-c; b)
if RR-c cost is unavailable for whatever reason RR will use its own
cost. Note that original idea is that RR-c informs RR about all costs.
If network policies call for non-IGP preference, then RR-c can use
ever-increasing numbers calculated in a way operator prefers. First N
(number of preferred exits) can be explicitly configured on RR-c, the
rest RR-c will calculate itself by ordering IGP costs of remaining
exits. To give an example: a PE prefers NH5 and NH9, which operator
configures on the PE manually. Let's say at some moment _all_ prefixes
are reachable via set of next-hops NH1,NH2,...,NH50. PE sends following
info to RR: first it tells that NH5:cost1, NH9:cost2 (because it
configured by operator), then PE takes remaining next-hops and arranges
them in order of increasing IGP cost behind first two next-hops, the
cost reported for NH-i to RR is the position of that NH-i in the just
created list. When IGP cost to non-preferred next-hops changes (due to
topology change), PE just re-evaluates NH order and sends updated cost
to RR. When preferred ASBR's are not available as feasible path to
certain prefix, RR just uses whatever is next NH in the list received
from RR-c but only for prefixes where preferred ASBR is not feasible
exit. When preferred ASBR's fail (i.e. no path can be reached via them),
RR uses for whatever is next NH in the list received from RR-c for all
prefixes. So in general, when certain prefix cannot be reached via
preferred ASBR's (regardless of the reason) then RR uses next NH in the
list received from RR-c. If for some reason connectivity from RR-c to
ASBR fails, RR-c will inform RR that particular NH is no longer feasible
(as described in NH SAFI draft) and RR will stop considering that ASBR
when calculating routes for given RR-c (even if from RR perspective or
from any other router perspective that very same ASBR is still
reachable). Same question as above - do you feel such behaviour should
be explicitly spelled out even though it's natural?

>>>>>>>>>>>>>>>>I am lost sorry. Simple example: network has 10 ASBRs.
PE1 says ASBR1=METRIC15 and ASBR2=METRIC20 and sends this info to the
RR. Now RR reflects both these ASBR paths to PE1 with the same metrics?

>>>>>>>>>>>>>>>>>>>>>>> Assume ASBR 3-10 have metrics as follows
ASBR3=3, ASBR4=4 .....ASBR10=10, This can happen right? 

 

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How does RR ensure that non candidate
(preferred paths) are not announced to the PE upfront?

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How do you ensure that non candidate
paths always have a higher metric than candidate paths?

- Prem

	From: Ilya Varlashkin <[email-masked]>
	Subject: Re: [Idr]
draft-vinod-lavallee-bgp-optimal-route-reflection
	To: "Reshmi Prem" <[email-masked]>
	Cc: "[email-masked] Raszuk" <[email-masked]>, "Vinod Joseph"
<[email-masked]>, [email-masked],
[email-masked], [email-masked], "IETF IDR"
<[email-masked]>
	Date: Friday, June 10, 2011, 2:04 PM

	> I did not see your draft specifying that you would be using
ADD-PATH, Can you confirm this?
	
	ehrm...use of ADD-PATH is not feature of NH SAFI, but
of...ADD-PATH. As long as you don't do anything what other specification
forbids, do you need to describe every possible combination of features
that could be used together? Today you can use ADD-PATH to send multiple
PATHs, tomorrow there will be another solution to do it. NH SAFI neither
forbids nor requires you to use any other BGP feature beyond what's
specified in the drafts, so by all means if you want multiple best PATHs
from RR-client perspective you can combine NH SAFI with ADD-PATH. If you
don't need multiple paths, you just don't use multiple paths. Do you
feel this combination should be explicitly spelled in the NH SAFI specs?
	
	> Vinod's draft specifies a means of using an RR specific RT to
permit a RR calculated best path in addition to RTC specified paths. How
does your draft handle this? What happens if the list of ASBRS that i
indicate a metric for disappear??
	
	ok, implicit assumption is that RR will use a) cost provided by
RR-c; b) if RR-c cost is unavailable for whatever reason RR will use its
own cost. Note that original idea is that RR-c informs RR about all
costs. If network policies call for non-IGP preference, then RR-c can
use ever-increasing numbers calculated in a way operator prefers. First
N (number of preferred exits) can be explicitly configured on RR-c, the
rest RR-c will calculate itself by ordering IGP costs of remaining
exits. To give an example: a PE prefers NH5 and NH9, which operator
configures on the PE manually. Let's say at some moment _all_ prefixes
are reachable via set of next-hops NH1,NH2,...,NH50. PE sends following
info to RR: first it tells that NH5:cost1, NH9:cost2 (because it
configured by operator), then PE takes remaining next-hops and arranges
them in order of increasing IGP cost behind first two next-hops, the
cost reported for NH-i to RR is the position of that NH-i in the just
created list. When IGP cost to non-preferred next-hops changes (due to
topology change), PE just re-evaluates NH order and sends updated cost
to RR. When preferred ASBR's are not available as feasible path to
certain prefix, RR just uses whatever is next NH in the list received
from RR-c but only for prefixes where preferred ASBR is not feasible
exit. When preferred ASBR's fail (i.e. no path can be reached via them),
RR uses for whatever is next NH in the list received from RR-c for all
prefixes. So in general, when certain prefix cannot be reached via
preferred ASBR's (regardless of the reason) then RR uses next NH in the
list received from RR-c. If for some reason connectivity from RR-c to
ASBR fails, RR-c will inform RR that particular NH is no longer feasible
(as described in NH SAFI draft) and RR will stop considering that ASBR
when calculating routes for given RR-c (even if from RR perspective or
from any other router perspective that very same ASBR is still
reachable). Same question as above - do you feel such behaviour should
be explicitly spelled out even though it's natural?
	
	Kind regards,
	iLya

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 12 Jun 2011 21:10:49 +0200

Vinod,

I would like to clarify however the questions are so embedded that they 
are hard to understand. Perhaps author of them could restate them more 
clearly.

Thx,
R.

> *Vinod Joseph***
> Professional Services – Service Provider Europe
>
> Juniper Networks
>
> M: +44 (0) 7500 835 876
>
> E:[email-masked] <mailto:[email-masked]>
>
>
>
> *From:*Reshmi Prem [mailto:[email-masked]]
> *Sent:* 10 June 2011 20:39
> *To:* Ilya Varlashkin
> *Cc:* [email-masked] Raszuk; Vinod Joseph; [email-masked];
> *Subject:* Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection
>
> Illya:
>
> --- On *Fri, 6/10/11, Ilya Varlashkin /<[email-masked]>/* wrote:
>
>
>     ehrm...use of ADD-PATH is not feature of NH SAFI, but of...ADD-PATH.
>     As long as you don't do anything what other specification forbids,
>     do you need to describe every possible combination of features that
>     could be used together? Today you can use ADD-PATH to send multiple
>     PATHs, tomorrow there will be another solution to do it. NH SAFI
>     neither forbids nor requires you to use any other BGP feature beyond
>     what's specified in the drafts, so by all means if you want multiple
>     best PATHs from RR-client perspective you can combine NH SAFI with
>     ADD-PATH. If you don't need multiple paths, you just don't use
>     multiple paths. Do you feel this combination should be explicitly
>     spelled in the NH SAFI specs?
>
>     permit a RR calculated best path in addition to RTC specified paths.
>     How does your draft handle this? What happens if the list of ASBRS
>     that i indicate a metric for disappear??
>
>     RR-c; b) if RR-c cost is unavailable for whatever reason RR will use
>     its own cost. Note that original idea is that RR-c informs RR about
>     all costs. If network policies call for non-IGP preference, then
>     RR-c can use ever-increasing numbers calculated in a way operator
>     prefers. First N (number of preferred exits) can be explicitly
>     configured on RR-c, the rest RR-c will calculate itself by ordering
>     IGP costs of remaining exits. To give an example: a PE prefers NH5
>     and NH9, which operator configures on the PE manually. Let's say at
>     some moment _all_ prefixes are reachable via set of next-hops
>     NH1,NH2,...,NH50. PE sends following info to RR: first it tells that
>     NH5:cost1, NH9:cost2 (because it configured by operator), then PE
>     takes remaining next-hops and arranges them in order of increasing
>     IGP cost behind first two next-hops, the cost reported for NH-i to
>     RR is the position of that NH-i in the just created list. When IGP
>     cost to non-preferred next-hops changes (due to topology change), PE
>     just re-evaluates NH order and sends updated cost to RR. When
>     preferred ASBR's are not available as feasible path to certain
>     prefix, RR just uses whatever is next NH in the list received from
>     RR-c but only for prefixes where preferred ASBR is not feasible
>     exit. When preferred ASBR's fail (i.e. no path can be reached via
>     them), RR uses for whatever is next NH in the list received from
>     RR-c for all prefixes. So in general, when certain prefix cannot be
>     reached via preferred ASBR's (regardless of the reason) then RR uses
>     next NH in the list received from RR-c. If for some reason
>     connectivity from RR-c to ASBR fails, RR-c will inform RR that
>     particular NH is no longer feasible (as described in NH SAFI draft)
>     and RR will stop considering that ASBR when calculating routes for
>     given RR-c (even if from RR perspective or from any other router
>     perspective that very same ASBR is still reachable). Same question
>     as above - do you feel such behaviour should be explicitly spelled
>     out even though it's natural?
>
>     Kind regards,
>     iLya
>

---

From: Vinod Joseph <[email-masked]>
Date: Sun, 12 Jun 2011 20:13:03 +0100

Personally I do not find them embedded, but if you feel so, then we should wait!

Regards

Vinod Joseph

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: 12 June 2011 20:11
To: Vinod Joseph
Cc: Reshmi Prem; Ilya Varlashkin; [email-masked]; [email-masked]; [email-masked]; IETF IDR
Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection

Vinod,

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 13 Jun 2011 16:38:10 +0200

Dear Reshmi,

Thanks for your feedback. It seems you have recently joined this WG 
discussion and because you are using your private email address it would 
be great if you could introduce yourself and your company/role
association to allow us to better put your contributions into 
perspective. Once you respond I will be happy to address your points
in the below email.

Emily Postnews would recommend a signature, eg:

Reshmi Prem
Shrub Tree Networks
"The true voice of the operator"

---

From: "t.petch" <[email-masked]>
Date: Wed, 15 Jun 2011 09:49:15 +0200

----- Original Message -----
From: "Robert Raszuk" <[email-masked]>
To: "Reshmi Prem" <[email-masked]>
Cc: "IETF IDR" <[email-masked]>; <[email-masked]>; "Vinod
Joseph" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, June 13, 2011 4:38 PM

> perspective. Once you respond I will be happy to address your points

Robert

An interesting request but not one that I think Reshmi need respond to for me -
and others - to consider what he has to say.  I have always liked that aspect of
the IETF that we are here as individuals, not as representatives of an
organisation (although not all individuals are equal when it comes to such
matters as consensus calls:-).  So what I witness here is a lively discussion of
the merits of two different approaches to a problem, interesting but not one
that impacts me directly.  Were the IETF run on different lines, perhaps I would
be witnessing two silverbacks toughing it out; but it isn't, so I am not, just a
lively discussion involving, inter alia, the authors of two individual I-Ds.
Perhaps there will be a call for the adoption of one or both I-Ds in which case
I will consider the question some more, but in the meantime, I shall track the
discussion with interest.

Tom Petch

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

---

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

Hi Tom,

> matters as consensus calls:-).

I do too. But to the extend of _real_ individuals. Here I suspect we are 
dealing with ghost or virtual one - hence my kind request for a bit more 
clarification.

So since now you are putting me on the spot let me clarify what 
triggered my request for a bit of more insight from Mr Prem.

First and above all as you perhaps know me I always try to understand 
everyone's points of view. Clearly I do not agree with all of them no 
matter who the src is and in those cases I really want to understand it 
better. For example the resistance from adding few new IBGP sessions in 
the network where policy routing is top priority was something I wanted 
to better understand. I was ready to visit this operator to listen about 
concerns to add few more sessions.

However Mr Prem presented himself as:

Date: Fri, 10 Jun 2011 03:42:57 -0700 (PDT)
* "As an opertor I am interested in the best solution"

Date: Fri, 10 Jun 2011 05:36:09 -0700 (PDT)
* "Its policy that we would not like to have that kind of meshiness. I 
am sure you would not argue about the policy of an operator."

Date: Fri, 10 Jun 2011 05:59:46 -0700 (PDT)
* "Policies are always not about operations and management. There are
    other reasons as well. I am sure you will hear about our specific
    needs or have already heard from your account teams.
    ...
    Robert, understand that operators are unique in some sense or the
    other. So dont start becoming the advocate on how an operator should 
define needs or which needs are reasonable."

Date: Fri, 10 Jun 2011 06:18:36 -0700 (PDT)
* "I am not arguing about whether you are the messiah of a revolution in
    BGP Route Reflection or not."

We also see a Vinod and Reshim dialog going on example:

---
Date: Fri, 10 Jun 2011 21:28:38 +0100
Hi Prem,

Your question on path selection on the local PE will be elaborated in 
the following version of the draft to be released shortly.

Regards
Vinod Joseph

M: +44 (0) 7500 835 876
E: vjoseph at juniper.net
---

SRC: http://www.ietf.org/mail-archive/web/idr/current/maillist.html

So one of my co-authors of the associated draft as well as myself poke
around to find out what kind of operator that is especially since
he was sending emails via yahoo. And here are a bit of shocking facts:

------
Received: from [66.129.224.36] by web37907.mail.mud.yahoo.com via HTTP;
Fri, 10 Jun 2011 10:21:09 PDT
...
Date: Fri, 10 Jun 2011 10:21:09 -0700 (PDT)
From: Reshmi Prem <[email-masked]>
------

Now let's see where the source of the email (66.129.224.36) originates:

$ host 66.129.224.36
36.224.129.66.in-addr.arpa domain name pointer natint3.juniper.net.
                                                ^^^^^^^^^^^^^^^^^^^^
More info ...
=============

Vinod Joseph as the author which tried to submit a parallel proposal to 
an already accepted as IDR WG doc 
draft-ietf-idr-bgp-optimal-route-reflection

"Reshmi Prem" email headers:

Received from [66.129.224.36] by web37907.mail.mud.yahoo.com via HTTP;
                ^^^^^^^^^^^^^  Fri, 10 2011 Jun 10:21:09 PDT

#nslookup 66.129.224.36
Name:     natint3.juniper.net
Address:  66.129.224.36

Vinod Joseph's email header comes from computer behind the same Juniper 
internal NAT:

from P-EMHUB01-HQ.jnpr.net ([66.129.224.36])
                              ^^^^^^^^^^^^^

While I do have more data at the moment IMHO this already provides 
sufficient basis to just ask for a bit of more clarification considering 
that the draft-vinod is a Juniper's draft with 4 (at the time of review) 
Juniper employees listed in it's ack section.

People are working very hard to deliver specifications and solutions to 
help the Internet community via various working groups in the IETF. IETF 
is the organization based on trust. How can we really continue to use 
the trust model if vendors like Juniper Networks are using such technics 
to fight against competing and technically superior while much more 
simple solutions on the table ? Isn't this a direct departure from 
industry ethics we are used to ?

Sincerely yours,
Robert Raszuk
Cisco Systems.

---

From: "t.petch" <[email-masked]>
Date: Wed, 15 Jun 2011 15:08:56 +0200

---- Original Message -----
From: "Robert Raszuk" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Reshmi Prem" <[email-masked]>; "IETF IDR" <[email-masked]>
Sent: Wednesday, June 15, 2011 11:56 AM
> 36.224.129.66.in-addr.arpa domain name pointer natint3.juniper.net.

Well, yes and no.

I too look at e-mail headers and had seen

Received: from [66.129.224.36] by web37906.mail.mud.yahoo.com via HTTP;
 Fri, 10 Jun 2011 07:30:26 PDT
X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.304355
Date: Fri, 10 Jun 2011 07:30:26 -0700 (PDT)
From: Reshmi Prem <[email-masked]>

whereas in another context I had seen

Received: from source ([66.129.224.36]) (using TLSv1) by
 exprod7ob123.postini.com ([64.18.6.12]) with SMTP
 ID DSNKTW1XlrXkI3ebz3G6wQl+AOhm/[email-masked];
 Tue, 01 Mar 2011 12:31:20 PST
Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net
 (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0;
 Tue, 1 Mar 2011 12:08:49 -0800
..
Date: Tue, 1 Mar 2011 14:45:38 -0500
From: Phil Shafer <[email-masked]>

ie both 66.129.224.36, both the same silverback.

And this is what some organisations do, or at least allow, multiple posts from
different e-mail addresses whereas with other organisations, there is one voice
speaking, or at least one e-mail address (perhaps with many bodies behind it:-)

It matters when it gets to rough consensus, that the chairs and AD can spot
ringers and stooges, make allowances for them when evaluating the opinions
expressed and, in my experience, they do.  And it helps to get to meetings and
see the body in question as you do, and of late, I have not; e-mail is such an
impoverished channel and so hard to form judgements over.

I think that the right technical solution depends on the requirements and the
latter are often undefined which makes the former not clear cut.  Prem hints at
a different set of requirements which may make the other solution preferable,
but that can only come about if his requirements are clearly stated and if those
requirements are widespread, neither of which is currently true.  So I see no
case for that I-D to be adopted; but, it is possible that that changes.

Tom Petch

---

From: Paul WALL <[email-masked]>
Date: Thu, 16 Jun 2011 22:40:56 -0700

On Wed, Jun 15, 2011 at 2:56 AM, Robert Raszuk <[email-masked]> wrote:
> People are working very hard to deliver specifications and solutions to help
> the Internet community via various working groups in the IETF. IETF is the
> organization based on trust. How can we really continue to use the trust
> model if vendors like Juniper Networks are using such technics to fight
> against competing and technically superior while much more simple solutions
> on the table ? Isn't this a direct departure from industry ethics we are
> used to ?

In the interest of transparency, Cisco is guilty of performing similar
shenanigans. Its a well known fact that Cisco encourages its customers
to chime in on IETF drafts, even when the some of the customers staff
has no comprehension of what is at hand.

For example look at the amount of posts from a certain large Cisco
customer in support of something. Note that all the emails came in
roughly within a few days of each other.

# RE: Advancing the Protocol and Morin Drafts, SZELA, MATEUSZ W (MATT), ATTLABS
# RE: Advancing the Protocol and Morin Drafts, RAMSAROOP, JEEWAN P, ATTLABS
# RE: Advancing the Protocol and Morin Drafts, ROSENBERG, ERIC, ATTLABS
# RE: Advancing the Protocol and Morin Drafts, SUNDT, MARK R, ATTLABS
# RE: Advancing the Protocol and Morin Drafts, RAMACHANDRAN, PRASANNA, ATTOPS
# RE: Advancing the Protocol and Morin Drafts, ASIF, SAUD, ATTLABS
# RE: Advancing the Protocol and Morin Drafts, DUBOSE, KENNETH S (KEN), ATTOPS

and again this time pushing the aigp draft all within a few days:

# Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document - Support,
ZATLOUKAL, JAMES W (JIM), ATTOPS
# Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document, SAAD,
SAMIR S, ATTLABS
# [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document, KARIM, REHAN, ATTLABS
# [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document, GIBBONS, JOHN, ATTLABS
# Re: [Idr] draft-rosen-idr-aigp-00.txt, PULIPATI, RAVI, ATTLABS
# Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document, TONG, HUI, ATTLABS

These aren't common names you see actively participating in the IETF
meetings or on the mailing lists. Its pretty obvious what is going on
here.

Drive Slow,

Paul WALL

---

From: Randy Bush <[email-masked]>
Date: Fri, 17 Jun 2011 06:33:31 -0700

> has no comprehension of what is at hand.

i think of it more as friends giving the one man dos attack a break.

randy

---

From: "NAPIERALA, MARIA H (ATTSI)" <[email-masked]>
Date: Fri, 17 Jun 2011 12:00:24 -0400

> # RE: Advancing the Protocol and Morin Drafts, SZELA, MATEUSZ W
(MATT),
> ATTLABS
> # RE: Advancing the Protocol and Morin Drafts, DUBOSE, KENNETH S
(KEN),
> ATTOPS

To set the record straight - Cisco had nothing to do with this voting. 
Please be careful what you state about the people who voted above as not
having a "comprehension of what is at hand". Not only that they clearly
identified themselves but they work directly on MVPNs either in the
design or operations. They possess more "comprehension" on the subject
at hand than you can imagine ;-).

Please check your facts before you made such disrespectful accusations..

Maria Napierala
AT&T Labs