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

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

Robert,

The objective of the draft is to provide closest exit routing based on the operators preference. Let me answer each of the comments inline:

> It does it in pure static way putting all burden of what can be 
automated into the operator's NOC. Note that all information required 
for optimal path selection is already present on RR without any need for 
operational configuration burden today.

Vinod# You rightly said that RT constrain and Route Targets have been used for a while now. The idea of this draft is to ensure that existing BGP machinery successfully used in the context of other address families, is used for IPv4. Policy control on the list of paths needed is indicated by the PE through the use of RT constrain, and only prefixes/paths that match the list of RTs specified are announced by the RR, and the PEs do the best path calculation. It is arguable that policy control via RT constrain adds operational burden - since the use of RT and RT constrain have been used on other address families for ages as you mentioned. The advantage here is that the RR can be completely taken out of the picture as far as the closest or optimal path calculation goes.

The networks topologies change dynamically which will not be 
reflected in the static RT based preference.

Vinod# Let me put it this way, an operator may prefer a list of RTs and not just a single RT - if we assume a single RT maps to a single ASBR, to build resiliency. The objective is clear - provide the operator with an approach to selectively choose the best path, and also indicate a list of affinities (list of RTs) that a PE is interested in. It is also possible to extend the scheme where all ASBRs within a region = a single RT. Therefore there is flexibility. Primarily this draft does not (1) break the use of BGP Peer groups (2) cause network churn if there is an IGP change, since we are not using an SPF instance per PE. 

- Addition and deletion of new ASBR both planned and unplanned require 
full reconfiguration of each PE to get to the same level of BGP path 
redundancy reception.

Vinod# Like I mentioned, planning for resiliency and allocation of RTs are flexible. It is not mandatory to have a single ASBR be allotted a single RT, multiple ASBRs may share the same RT.

> POPs which do not have local exit ASBRs and which do not leak next 
hops from core to POP area in the IGP even if given opportunity to 
receive _all_ external paths still have no visibility into the closet 
exit ASBR in the domain as ABRs would typically depending on the IGP 
selection and area type shield them from domain wide flooding 
information. Therefor those PEs will still remain selecting random paths 
unless the proposal would also include static best path selection on 
such PEs based on RT.

    We make the assumption that complete Internet routing
    information is available at every ASBR. If the local ASBR does not
    have reachibility to the relevant prefixes (or the ASBR itself is not
    available), traffic should use the closest (in terms of IGP metric)
    egress.

It would be interesting to see under what network conditions one could 
assure that that every ASBR in the network contains complete Internet 
routing. Then I would like to see prove on how using static RT mapping 
to one's preference of some day assures reception and selection of paths 
which could be categorized as "closest (in terms of IGP metric) egress". 
Provided example of 3 ASBRs located on three continents of the world is 
rather unreal considering today's network topologies where number of 
ASBRs or IX interconnects very often reaches much larger numbers.

Vinod# The draft also talks about scenarios of POPs with ASBRs having only partial routes and not just complete routes. Once again this brings us back to the original point elaborated above. An operator does not need to build a model where each ASBR belongs to an individual RT. If my objective is to use the local ASBR (having only 1000 prefixes for instance) for known prefixes, and another ASBR(s) in a given region/POPs (having full routes) - I would need to add in appropriate RT(s) for signalling interest. Do take note, that the draft talks about the possibility of indicating max-no-of-paths per RT - in the event of a PE unable to take many a path advertised via ADD-PATH or even if the constraints on path selection is more lenient. Flexibility is the key here.

* The title of the draft should reflect that the proposal does not 
provide, a solution for "optimal" route reflection. The draft describes 
a solution for "operator's statically configured ASBR path preferences". 
Those two are quite dis-joined solutions. While perhaps under some 
scenarios the end result may be the same at a given point of time there 
is no guarantee that such result will stay as such during day to day 
network operation.

Vinod# Optimal route reflection is what the operator deems as optimal. This draft provides the ability to instruct the RR to announce only a set of paths that it considers optimal and choose between them. In other words optimal is more relevant to the end user (PE) and not the RR. So if the PE wants to use a path with the closest IGP metric, it indicates the RR to only send paths that match a given RT. 

* IDR WG draft does not require any manual static configuration of path 
preferences - all required information is already present today on the 
RR and can be readily used.

* IDR WG draft can use add-paths to send more then best optimal path 
from RR to the RR client - per clients preference

Vinod# Same applies here. Key in this proposal (1) do not break the use of BGP Peer groups (2) No churn on the RR re-calculating best path on behalf of each PE in case of IGP fluctuations (3) More flexibility in indicating the paths that are needed (4) max number of paths per RT can be signalled (5) Each RR can be allocated an RT, and if a PE signals only that RT in the RT constrain, then the RR calculated best path only (default behaviour) is announced (6) Existing BGP machinery is re-used for IPv4.

* IDR WG draft dynamically recalculates optimal/closest IGP metric exist 
point or points for each client and group of clients when ASBR 
add/withdraw BGP routes or when IGP topology changes

Vinod# IGP Churn impacting re-calculation??

* IDR WG draft provides ways to dynamically group clients based on their 
common POP location / IGP area without any operator's configuration 
burden on RR

Vinod# Not just the ASBR with the closest IGP metric, but any affinity to any combination of ASBR(s) can be chosen based on the policy of the POP/individual PE can be deployed. 

* IDR WG draft works equally well in normal IPv4/IPv6 networks as well 
as with some form of tunneled networks without putting any requirement 
on forwarding paradigm selection in the network

Vinod# Not sure whether I follow this. The proposed draft focuses on clearing the core or P routers (if you may) to steer clear of BGP routing - for hot potato routing. But nothing stops an implementation from using that.

* It works in the same way for any AFI/SAFI and independently guarantees 
calculation of optimal/closest exit points for IPv4, IPv4+label or IPv6 
paths as well as their distribution to the clients.

Vinod# Per AF based policies can be used. 

* IDR WG document provides ability for virtual RR placement in any IGP 
network node location without any physical reconnection required. Such 
provision is not addressed in the above document.

Regards

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 05 June 2011 20:00
To: [email-masked]
Subject: Idr Digest, Vol 86, Issue 3

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/idr

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send Idr mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/idr
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Idr digest..."

Today's Topics:

   1. draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt
      (Robert Raszuk)
   2. Re: draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt
      (Jeff Tantsura)

----------------------------------------------------------------------

Message: 1
Date: Sun, 05 Jun 2011 00:51:57 +0200
From: Robert Raszuk <[email-masked]>
To: "[email-masked] List" <[email-masked]>
Subject: [Idr]
	draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi,

Attracted by the title I could not resit to read this draft. Here are 
some of the comments and questions I have regarding the document.

* Up front to make it very clear for all readers can authors explicitly 
confirm that the applicability of this draft is only limited to networks 
which use some form of tunneling (for example: MPLS) between each PE and 
ASBRs ?

* The idea of community based route selection on RRs is nothing new. 
Using RT extended community as well as RT Constrain while does automates 
the preference push from PE to RR to limit number of paths to be 
received. However if also comes along with the following issues:

  - It does it in pure static way putting all burden of what can be 
automated into the operator's NOC. Note that all information required 
for optimal path selection is already present on RR without any need for 
operational configuration burden today.

  - The networks topologies change dynamically which will not be 
reflected in the static RT based preference.

  - Addition and deletion of new ASBR both planned and unplanned require 
full reconfiguration of each PE to get to the same level of BGP path 
redundancy reception.

  - Addition and deletion of new service POP both planned and unplanned 
require full reconfiguration of each PE to get to the same level of BGP 
path redundancy reception.

- POPs which do not have local exit ASBRs and which do not leak next 
hops from core to POP area in the IGP even if given opportunity to 
receive _all_ external paths still have no visibility into the closet 
exit ASBR in the domain as ABRs would typically depending on the IGP 
selection and area type shield them from domain wide flooding 
information. Therefor those PEs will still remain selecting random paths 
unless the proposal would also include static best path selection on 
such PEs based on RT.

* The draft says:

    We make the assumption that complete Internet routing
    information is available at every ASBR. If the local ASBR does not
    have reachibility to the relevant prefixes (or the ASBR itself is not
    available), traffic should use the closest (in terms of IGP metric)
    egress.

It would be interesting to see under what network conditions one could 
assure that that every ASBR in the network contains complete Internet 
routing. Then I would like to see prove on how using static RT mapping 
to one's preference of some day assures reception and selection of paths 
which could be categorized as "closest (in terms of IGP metric) egress". 
Provided example of 3 ASBRs located on three continents of the world is 
rather unreal considering today's network topologies where number of 
ASBRs or IX interconnects very often reaches much larger numbers.

* The title of the draft should reflect that the proposal does not 
provide, a solution for "optimal" route reflection. The draft describes 
a solution for "operator's statically configured ASBR path preferences". 
Those two are quite dis-joined solutions. While perhaps under some 
scenarios the end result may be the same at a given point of time there 
is no guarantee that such result will stay as such during day to day 
network operation.

* RT Constrain as proposed, implemented and deployed today has been 
designed to express a VPN membership rules as an base object. While 
there were some attempts to further divide this to be on per AFI/SAFI 
basis RT Constrain authors came to the conclusion that those attempts 
have no practical justification. In this proposal use of RT constrain 
filtering would however result in the same exit ASBR preference to be 
applied for IPv4 as to the IPv6 with or without labels AFI/SAFIs. It is 
already well known fact in operation today that optimal/closest exit 
preferences for IPv4 unicast do not match in many networks the 
optimal/closest exit preferences for IPv6 or for IPv4+label AFI/SAFIs. 
It would be interesting how authors of the proposed draft are going to 
address this point going forward.

***

Now let me take a moment to provide few points on number of advantages 
of the IDR WG document draft-ietf-idr-bgp-optimal-route-reflection-00 as 
compared with the above document:

* IDR WG draft does not require any manual static configuration of path 
preferences - all required information is already present today on the 
RR and can be readily used.

* IDR WG draft can use add-paths to send more then best optimal path 
from RR to the RR client - per clients preference

* IDR WG draft dynamically recalculates optimal/closest IGP metric exist 
point or points for each client and group of clients when ASBR 
add/withdraw BGP routes or when IGP topology changes

* IDR WG draft provides ways to dynamically group clients based on their 
common POP location / IGP area without any operator's configuration 
burden on RR

* IDR WG draft works equally well in normal IPv4/IPv6 networks as well 
as with some form of tunneled networks without putting any requirement 
on forwarding paradigm selection in the network

* It works in the same way for any AFI/SAFI and independently guarantees 
calculation of optimal/closest exit points for IPv4, IPv4+label or IPv6 
paths as well as their distribution to the clients.

* IDR WG document provides ability for virtual RR placement in any IGP 
network node location without any physical reconnection required. Such 
provision is not addressed in the above document.

Best regards,
R.

------------------------------

Message: 2
Date: Sat, 4 Jun 2011 22:05:08 -0400
From: Jeff Tantsura <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked] List" <[email-masked]>
Subject: Re: [Idr]
	draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

+1

Regards,
Jeff

On Jun 4, 2011, at 15:51, "Robert Raszuk" <[email-masked]> wrote:

> Hi,
> 
> Attracted by the title I could not resit to read this draft. Here are 
> some of the comments and questions I have regarding the document.
> 
> * Up front to make it very clear for all readers can authors explicitly 
> confirm that the applicability of this draft is only limited to networks 
> which use some form of tunneling (for example: MPLS) between each PE and 
> ASBRs ?
> 
> * The idea of community based route selection on RRs is nothing new. 
> Using RT extended community as well as RT Constrain while does automates 
> the preference push from PE to RR to limit number of paths to be 
> received. However if also comes along with the following issues:
> 
>  - It does it in pure static way putting all burden of what can be 
> automated into the operator's NOC. Note that all information required 
> for optimal path selection is already present on RR without any need for 
> operational configuration burden today.
> 
>  - The networks topologies change dynamically which will not be 
> reflected in the static RT based preference.
> 
>  - Addition and deletion of new ASBR both planned and unplanned require 
> full reconfiguration of each PE to get to the same level of BGP path 
> redundancy reception.
> 
>  - Addition and deletion of new service POP both planned and unplanned 
> require full reconfiguration of each PE to get to the same level of BGP 
> path redundancy reception.
> 
> - POPs which do not have local exit ASBRs and which do not leak next 
> hops from core to POP area in the IGP even if given opportunity to 
> receive _all_ external paths still have no visibility into the closet 
> exit ASBR in the domain as ABRs would typically depending on the IGP 
> selection and area type shield them from domain wide flooding 
> information. Therefor those PEs will still remain selecting random paths 
> unless the proposal would also include static best path selection on 
> such PEs based on RT.
> 
> * The draft says:
> 
>    We make the assumption that complete Internet routing
>    information is available at every ASBR. If the local ASBR does not
>    have reachibility to the relevant prefixes (or the ASBR itself is not
>    available), traffic should use the closest (in terms of IGP metric)
>    egress.
> 
> It would be interesting to see under what network conditions one could 
> assure that that every ASBR in the network contains complete Internet 
> routing. Then I would like to see prove on how using static RT mapping 
> to one's preference of some day assures reception and selection of paths 
> which could be categorized as "closest (in terms of IGP metric) egress". 
> Provided example of 3 ASBRs located on three continents of the world is 
> rather unreal considering today's network topologies where number of 
> ASBRs or IX interconnects very often reaches much larger numbers.
> 
> * The title of the draft should reflect that the proposal does not 
> provide, a solution for "optimal" route reflection. The draft describes 
> a solution for "operator's statically configured ASBR path preferences". 
> Those two are quite dis-joined solutions. While perhaps under some 
> scenarios the end result may be the same at a given point of time there 
> is no guarantee that such result will stay as such during day to day 
> network operation.
> 
> * RT Constrain as proposed, implemented and deployed today has been 
> designed to express a VPN membership rules as an base object. While 
> there were some attempts to further divide this to be on per AFI/SAFI 
> basis RT Constrain authors came to the conclusion that those attempts 
> have no practical justification. In this proposal use of RT constrain 
> filtering would however result in the same exit ASBR preference to be 
> applied for IPv4 as to the IPv6 with or without labels AFI/SAFIs. It is 
> already well known fact in operation today that optimal/closest exit 
> preferences for IPv4 unicast do not match in many networks the 
> optimal/closest exit preferences for IPv6 or for IPv4+label AFI/SAFIs. 
> It would be interesting how authors of the proposed draft are going to 
> address this point going forward.
> 
> ***
> 
> Now let me take a moment to provide few points on number of advantages 
> of the IDR WG document draft-ietf-idr-bgp-optimal-route-reflection-00 as 
> compared with the above document:
> 
> * IDR WG draft does not require any manual static configuration of path 
> preferences - all required information is already present today on the 
> RR and can be readily used.
> 
> * IDR WG draft can use add-paths to send more then best optimal path 
> from RR to the RR client - per clients preference
> 
> * IDR WG draft dynamically recalculates optimal/closest IGP metric exist 
> point or points for each client and group of clients when ASBR 
> add/withdraw BGP routes or when IGP topology changes
> 
> * IDR WG draft provides ways to dynamically group clients based on their 
> common POP location / IGP area without any operator's configuration 
> burden on RR
> 
> * IDR WG draft works equally well in normal IPv4/IPv6 networks as well 
> as with some form of tunneled networks without putting any requirement 
> on forwarding paradigm selection in the network
> 
> * It works in the same way for any AFI/SAFI and independently guarantees 
> calculation of optimal/closest exit points for IPv4, IPv4+label or IPv6 
> paths as well as their distribution to the clients.
> 
> * IDR WG document provides ability for virtual RR placement in any IGP 
> network node location without any physical reconnection required. Such 
> provision is not addressed in the above document.
> 
> Best regards,
> R.
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

------------------------------

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

End of Idr Digest, Vol 86, Issue 3
**********************************

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 05 Jun 2011 22:58:23 +0200

Hi Vinod,

Let me reply to your post as it does indicate couple of issues with the 
understanding of draft-ietf-idr-bgp-optimal-route-reflection-00 further 
for simplicity referred to as IDR WG doc.

 > Vinod# You rightly said that RT constrain and Route Targets have been
 > used for a while now. The idea of this draft is to ensure that
 > existing BGP machinery successfully used in the context of other
 > address families, is used for IPv4.

RT have been used for managing L3VPN imports and exports of routes since 
around 1999. While BGP can handle RT based filtering just fine there is 
significant management overhead to configure and maintain RT 
assignments. Only in lab, small networks or on ppt slides it looks neat. 
As someone who have been helping to deploy RFC2547 since day one I think 
I am entitled to say that use of RTs to manage VPNs is the biggest issue 
with that VPN technology. Personally if you would like to use extended 
communities for IPv4/IPv6 unicast/multicast filtering on RRs my 
recommendation would be to define a new type and to not mix it with VPN 
service RTs.

 > Policy control on the list of
 > paths needed is indicated by the PE through the use of RT constrain,
 > and only prefixes/paths that match the list of RTs specified are
 > announced by the RR, and the PEs do the best path calculation.

In your reply you have not answered most of my points so let me 
reiterate ...

* How PE is able to do best path calculation if it is in a POP or area 
without full visibility to the entire network of the provider ? Are you 
limiting applicability of your draft only to flat IGP networks running 
mpls ?

* Imagine PE specify preference of receiving two paths one from ASBR1 
and the other from ASBR2. Now for operational reasons ASBR1 goes down. 
Would you not have not to reconfigure such PE to ask for 2nd path from 
some other ASBR ? That is operationally real obstacle of your idea in 
any mid to large size of the network.

* How your idea will work with PEs which yet do not support add-paths 
and yet do not support rt-constrain ?

Let me here point out that all of those points just work fine in the IDR 
WG doc without any need to touch or load new software on the existing PEs.

 > The advantage here is
 > that the RR can be completely taken out of the picture as far as the
 > closest or optimal path calculation goes.

For me this is a drawback not an advantage. RRs are intelligent control 
plane devices which can deliver real value to the routing in any 
network. On RRs you have already all routing information, memory and cpu 
to compute information which is needed. If you run out of current 
resources of one RR you add another RR to scale further. I am clearly 
against treating RR as dumb BGP repeaters - they can do much better.

 > Primarily this draft does not (1) break the use of BGP Peer groups
 > (2) cause network churn if there is an IGP change, since we are not
 > using an SPF instance per PE.

IDR WG draft does not break use of peer groups either. Section 3.2 
clearly describes a method to logically place RR in strategic network 
locations and distribute BGP paths from such location to the PEs. All 
PEs may still be in the same peer-group.

If you have as described in your draft three exit strategic locations no 
matter where the actual RR physically sits you install 3 of them and 
tell each that one is in Japan, one in US and one in Europe and your PEs 
get 3 paths to choose from again without any need to burden yourself 
with management of new set of any RTs, reconfiguring PEs, requiring PEs 
to be upgraded to support new technologies and so on.

Now since you keep bringing the topic of breaking peer groups I need to 
point few things. IDR WG doc does not break the concept of peer groups 
at all. Contrary to your misunderstanding it provides mechanism for 
automated peer grouping via very simple BGP OPEN message extension. Such 
peer grouping is constant and does not change with any IGP changes.

So in any practical deployment of IDR WG doc described ORR you are at 
most talking about as many peer groups as you have POPs in your network. 
Excuse my optimism but if any RR can not deal today with 10s of peer 
groups I think it deserves an upgrade :)

Last and not least concept of static peer groups is a history gone about 
10 years ago in modern BGP implementations. Those use in shipping 
products dynamic update groups which adjust automatically to both peer's 
requirements, add-paths or policy advertisement rules without requiring 
and putting burden on operator to group the peers in a static and 
predefined way.

As to your point of network churn IDR WG doc is very clear on two 
points. First not each network IGP change needs to resolve in any BGP 
action including even local re-evaluation of optimal best paths. There 
is clear definition of basic next hop metric change choice of threshold 
where if the change is below the line BGP does not need to react on it.

Second please observe that IDR WG doc also enable to re advertise 
optimal path or paths only to those POPs where the IGP change would 
affect them. That alone contrary to today's case has clear benefit of 
BGP wave effect reduction ... something which I hope everyone would see 
as a positive outcome.

 > Vinod# Like I mentioned, planning for resiliency and allocation of
 > RTs are flexible. It is not mandatory to have a single ASBR be
 > allotted a single RT, multiple ASBRs may share the same RT.

It is not the point that you can not ask for list of N RTs. Sure you 
can. The point is that those RTs PE ask for are only as good as those 
RTs will be attached to a given route by the ASBRs in the first place. 
Let me illustrate more precisely the issue ...

Imagine you have 10 ASBRs and PEs have constructed the list of set of 
two RTs RT1 and RT2 to get two paths from RRs corresponding to their 
preference.

Now it so happens that while RR has still 8 paths to a given destination 
two of them are withdrawn due to a problem with some upstream transit 
ISP two ASes up the tree.

It also so happens that those two paths were those which set of PEs 
signaled to get.

Conclusion: Your network has still 8 valid paths to reach set of 
destinations however large number of PEs report OUTAGE !!! Their 
preferred paths are no longer available .. maybe for few seconds .. 
maybe for few minutes ... maybe for an hour.

Till NOC eng in the network which supports your draft logs to the PEs 
and reconfigure the list of RTs they were considering "optimal" perhaps 
hundreds of such operators customers are really upset as they lost their 
favorite show or cricket game view not to even mention other much more 
critical uses of networks today which go way beyond entertainment.

Your draft breaks by design a basic network architecture rule .. if you 
have reachability to a destination your policy whatever it is should not 
result in your customer's to loose reachability to said destination.
.
.
.

I could continue to address your other points, but I think we are done 
right here and no further discussion is needed, before you really prove 
that your idea does not fall into the above showstopper.

Best regards,
R.

PS. The use of the exact same name of totally different and quite broken 
idea as compared with already existing a WG document I think is a 
precedence in the IETF. By any measures of probability this is not an 
accident :)

I find it odd to say at least and while I hope the goal of the drafts is 
not cause distraction in the working group I would like to see WG chairs 
as well as AD's (Bcc-ed) official IETF opinion on it.

> Robert,
>
> The objective of the draft is to provide closest exit routing based
> on the operators preference. Let me answer each of the comments
> inline:
>
> automated into the operator's NOC. Note that all information
> required for optimal path selection is already present on RR without
> any need for operational configuration burden today.
>
> Vinod# You rightly said that RT constrain and Route Targets have been
> used for a while now. The idea of this draft is to ensure that
> existing BGP machinery successfully used in the context of other
> address families, is used for IPv4. Policy control on the list of
> paths needed is indicated by the PE through the use of RT constrain,
> and only prefixes/paths that match the list of RTs specified are
> announced by the RR, and the PEs do the best path calculation. It is
> arguable that policy control via RT constrain adds operational burden
> - since the use of RT and RT constrain have been used on other
> address families for ages as you mentioned. The advantage here is
> that the RR can be completely taken out of the picture as far as the
> closest or optimal path calculation goes.
>
> Vinod# Let me put it this way, an operator may prefer a list of RTs
> and not just a single RT - if we assume a single RT maps to a single
> ASBR, to build resiliency. The objective is clear - provide the
> operator with an approach to selectively choose the best path, and
> also indicate a list of affinities (list of RTs) that a PE is
> interested in. It is also possible to extend the scheme where all
> ASBRs within a region = a single RT. Therefore there is flexibility.
> Primarily this draft does not (1) break the use of BGP Peer groups
> (2) cause network churn if there is an IGP change, since we are not
> using an SPF instance per PE.
>
> - Addition and deletion of new ASBR both planned and unplanned
> require full reconfiguration of each PE to get to the same level of
> BGP path redundancy reception.
>
> Vinod# Like I mentioned, planning for resiliency and allocation of
> RTs are flexible. It is not mandatory to have a single ASBR be
> allotted a single RT, multiple ASBRs may share the same RT.
>
> receive _all_ external paths still have no visibility into the
> closet exit ASBR in the domain as ABRs would typically depending on
> the IGP selection and area type shield them from domain wide
> flooding information. Therefor those PEs will still remain selecting
> random paths unless the proposal would also include static best path
> selection on such PEs based on RT.
>
>
> We make the assumption that complete Internet routing information is
> available at every ASBR. If the local ASBR does not have reachibility
> to the relevant prefixes (or the ASBR itself is not available),
> traffic should use the closest (in terms of IGP metric) egress.
>
> It would be interesting to see under what network conditions one
> could assure that that every ASBR in the network contains complete
> Internet routing. Then I would like to see prove on how using static
> RT mapping to one's preference of some day assures reception and
> selection of paths which could be categorized as "closest (in terms
> of IGP metric) egress". Provided example of 3 ASBRs located on three
> continents of the world is rather unreal considering today's network
> topologies where number of ASBRs or IX interconnects very often
> reaches much larger numbers.
>
> Vinod# The draft also talks about scenarios of POPs with ASBRs having
> only partial routes and not just complete routes. Once again this
> brings us back to the original point elaborated above. An operator
> does not need to build a model where each ASBR belongs to an
> individual RT. If my objective is to use the local ASBR (having only
> 1000 prefixes for instance) for known prefixes, and another ASBR(s)
> in a given region/POPs (having full routes) - I would need to add in
> appropriate RT(s) for signalling interest. Do take note, that the
> draft talks about the possibility of indicating max-no-of-paths per
> RT - in the event of a PE unable to take many a path advertised via
> ADD-PATH or even if the constraints on path selection is more
> lenient. Flexibility is the key here.
>
> provide, a solution for "optimal" route reflection. The draft
> describes a solution for "operator's statically configured ASBR path
> preferences". Those two are quite dis-joined solutions. While perhaps
> under some scenarios the end result may be the same at a given point
> of time there is no guarantee that such result will stay as such
> during day to day network operation.
>
>
> Vinod# Optimal route reflection is what the operator deems as
> optimal. This draft provides the ability to instruct the RR to
> announce only a set of paths that it considers optimal and choose
> between them. In other words optimal is more relevant to the end user
> (PE) and not the RR. So if the PE wants to use a path with the
> closest IGP metric, it indicates the RR to only send paths that match
> a given RT.
>
> * IDR WG draft does not require any manual static configuration of
> path preferences - all required information is already present today
> on the RR and can be readily used.
>
> Vinod# Same applies here. Key in this proposal (1) do not break the
> use of BGP Peer groups (2) No churn on the RR re-calculating best
> path on behalf of each PE in case of IGP fluctuations (3) More
> flexibility in indicating the paths that are needed (4) max number of
> paths per RT can be signalled (5) Each RR can be allocated an RT, and
> if a PE signals only that RT in the RT constrain, then the RR
> calculated best path only (default behaviour) is announced (6)
> Existing BGP machinery is re-used for IPv4.
>
> * IDR WG draft dynamically recalculates optimal/closest IGP metric
> exist point or points for each client and group of clients when ASBR
> * IDR WG draft provides ways to dynamically group clients based on
> their common POP location / IGP area without any operator's
> configuration burden on RR
>
> Vinod# Not just the ASBR with the closest IGP metric, but any
> affinity to any combination of ASBR(s) can be chosen based on the
> policy of the POP/individual PE can be deployed.
>
> * IDR WG draft works equally well in normal IPv4/IPv6 networks as
> well as with some form of tunneled networks without putting any
> requirement on forwarding paradigm selection in the network
>
> Vinod# Not sure whether I follow this. The proposed draft focuses on
> clearing the core or P routers (if you may) to steer clear of BGP
> routing - for hot potato routing. But nothing stops an implementation
> from using that.
>
> * It works in the same way for any AFI/SAFI and independently
> guarantees calculation of optimal/closest exit points for IPv4,
> IPv4+label or IPv6 paths as well as their distribution to the
> clients.
>
> * IDR WG document provides ability for virtual RR placement in any
> IGP network node location without any physical reconnection required.
> Such provision is not addressed in the above document.
>
>
> Regards
>
> Vinod Joseph Professional Services - Service Provider Europe Juniper
> Networks
>  M: +44 (0) 7500 835 876 E: [email-masked]
>
>
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of [email-masked] Sent:
> 05 June 2011 20:00 To: [email-masked] Subject: Idr Digest, Vol 86,
> Issue 3
>
> Send Idr mailing list submissions to [email-masked]
>
> https://www.ietf.org/mailman/listinfo/idr or, via email, send a
> message with subject or body 'help' to [email-masked]
>
> You can reach the person managing the list at [email-masked]
>
> 1. draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt (Robert
> Raszuk) 2. Re:
> draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt (Jeff
> Tantsura)
>
>
>  Message: 1 Date: Sun, 05 Jun 2011 00:51:57 +0200 From: Robert
> Raszuk<[email-masked]> To: "[email-masked] List"<[email-masked]>
> Subject: [Idr]
> Message-ID:<[email-masked]> Content-Type: text/plain;
> charset=ISO-8859-1; format=flowed
>
> Hi,
>
> Attracted by the title I could not resit to read this draft. Here
> are some of the comments and questions I have regarding the
> document.
>
> * Up front to make it very clear for all readers can authors
> explicitly confirm that the applicability of this draft is only
> limited to networks which use some form of tunneling (for example:
> MPLS) between each PE and ASBRs ?
>
> Using RT extended community as well as RT Constrain while does
> automates the preference push from PE to RR to limit number of paths
> to be received. However if also comes along with the following
> issues:
>
> automated into the operator's NOC. Note that all information
> required for optimal path selection is already present on RR without
> any need for operational configuration burden today.
>
> - Addition and deletion of new ASBR both planned and unplanned
> require full reconfiguration of each PE to get to the same level of
> BGP path redundancy reception.
>
> - Addition and deletion of new service POP both planned and
> unplanned require full reconfiguration of each PE to get to the same
> level of BGP path redundancy reception.
>
> receive _all_ external paths still have no visibility into the
> closet exit ASBR in the domain as ABRs would typically depending on
> the IGP selection and area type shield them from domain wide
> flooding information. Therefor those PEs will still remain selecting
> random paths unless the proposal would also include static best path
> selection on such PEs based on RT.
>
> * The draft says:
>
> We make the assumption that complete Internet routing information is
> available at every ASBR. If the local ASBR does not have reachibility
> to the relevant prefixes (or the ASBR itself is not available),
> traffic should use the closest (in terms of IGP metric) egress.
>
> It would be interesting to see under what network conditions one
> could assure that that every ASBR in the network contains complete
> Internet routing. Then I would like to see prove on how using static
> RT mapping to one's preference of some day assures reception and
> selection of paths which could be categorized as "closest (in terms
> of IGP metric) egress". Provided example of 3 ASBRs located on three
> continents of the world is rather unreal considering today's network
> topologies where number of ASBRs or IX interconnects very often
> reaches much larger numbers.
>
> provide, a solution for "optimal" route reflection. The draft
> describes a solution for "operator's statically configured ASBR path
> preferences". Those two are quite dis-joined solutions. While perhaps
> under some scenarios the end result may be the same at a given point
> of time there is no guarantee that such result will stay as such
> during day to day network operation.
>
> there were some attempts to further divide this to be on per
> AFI/SAFI basis RT Constrain authors came to the conclusion that those
> attempts have no practical justification. In this proposal use of RT
> constrain filtering would however result in the same exit ASBR
> preference to be applied for IPv4 as to the IPv6 with or without
> labels AFI/SAFIs. It is already well known fact in operation today
> that optimal/closest exit preferences for IPv4 unicast do not match
> in many networks the optimal/closest exit preferences for IPv6 or for
> IPv4+label AFI/SAFIs. It would be interesting how authors of the
> proposed draft are going to address this point going forward.
>
> ***
>
> Now let me take a moment to provide few points on number of
> advantages of the IDR WG document
> draft-ietf-idr-bgp-optimal-route-reflection-00 as compared with the
> above document:
>
> * IDR WG draft does not require any manual static configuration of
> path preferences - all required information is already present today
> on the RR and can be readily used.
>
> * IDR WG draft dynamically recalculates optimal/closest IGP metric
> exist point or points for each client and group of clients when ASBR
> * IDR WG draft provides ways to dynamically group clients based on
> their common POP location / IGP area without any operator's
> configuration burden on RR
>
> * IDR WG draft works equally well in normal IPv4/IPv6 networks as
> well as with some form of tunneled networks without putting any
> requirement on forwarding paradigm selection in the network
>
> * It works in the same way for any AFI/SAFI and independently
> guarantees calculation of optimal/closest exit points for IPv4,
> IPv4+label or IPv6 paths as well as their distribution to the
> clients.
>
> * IDR WG document provides ability for virtual RR placement in any
> IGP network node location without any physical reconnection required.
> Such provision is not addressed in the above document.
>
> Best regards, R.
>
>
> Message: 2 Date: Sat, 4 Jun 2011 22:05:08 -0400 From: Jeff
> Tantsura<[email-masked]> To:
> "[email-masked]"<[email-masked]> Cc: "[email-masked]
> List"<[email-masked]> Subject: Re: [Idr]
> Message-ID:<[email-masked]>
> Regards, Jeff
> On Jun 4, 2011, at 15:51, "Robert Raszuk"<[email-masked]>  wrote:
>
>> Hi,
>>
>> Attracted by the title I could not resit to read this draft. Here
>> are some of the comments and questions I have regarding the
>> document.
>>
>> * Up front to make it very clear for all readers can authors
>> explicitly confirm that the applicability of this draft is only
>> limited to networks which use some form of tunneling (for example:
>> MPLS) between each PE and ASBRs ?
>>
>> * The idea of community based route selection on RRs is nothing
>> new. Using RT extended community as well as RT Constrain while does
>> automates the preference push from PE to RR to limit number of
>> paths to be received. However if also comes along with the
>> following issues:
>>
>> automated into the operator's NOC. Note that all information
>> required for optimal path selection is already present on RR
>> without any need for operational configuration burden today.
>>
>> - Addition and deletion of new ASBR both planned and unplanned
>> require full reconfiguration of each PE to get to the same level of
>> BGP path redundancy reception.
>>
>> - Addition and deletion of new service POP both planned and
>> unplanned require full reconfiguration of each PE to get to the
>> same level of BGP path redundancy reception.
>>
>> - POPs which do not have local exit ASBRs and which do not leak
>> next hops from core to POP area in the IGP even if given
>> opportunity to receive _all_ external paths still have no
>> visibility into the closet exit ASBR in the domain as ABRs would
>> typically depending on the IGP selection and area type shield them
>> from domain wide flooding information. Therefor those PEs will
>> still remain selecting random paths unless the proposal would also
>> include static best path selection on such PEs based on RT.
>>
>> * The draft says:
>>
>> We make the assumption that complete Internet routing information
>> is available at every ASBR. If the local ASBR does not have
>> reachibility to the relevant prefixes (or the ASBR itself is not
>> available), traffic should use the closest (in terms of IGP
>> metric) egress.
>>
>> It would be interesting to see under what network conditions one
>> could assure that that every ASBR in the network contains complete
>> Internet routing. Then I would like to see prove on how using
>> static RT mapping to one's preference of some day assures reception
>> and selection of paths which could be categorized as "closest (in
>> terms of IGP metric) egress". Provided example of 3 ASBRs located
>> on three continents of the world is rather unreal considering
>> today's network topologies where number of ASBRs or IX
>> interconnects very often reaches much larger numbers.
>>
>> provide, a solution for "optimal" route reflection. The draft
>> describes a solution for "operator's statically configured ASBR
>> path preferences". Those two are quite dis-joined solutions. While
>> perhaps under some scenarios the end result may be the same at a
>> given point of time there is no guarantee that such result will
>> stay as such during day to day network operation.
>>
>> * RT Constrain as proposed, implemented and deployed today has
>> been designed to express a VPN membership rules as an base object.
>> While there were some attempts to further divide this to be on per
>> AFI/SAFI basis RT Constrain authors came to the conclusion that
>> those attempts have no practical justification. In this proposal
>> use of RT constrain filtering would however result in the same exit
>> ASBR preference to be applied for IPv4 as to the IPv6 with or
>> without labels AFI/SAFIs. It is already well known fact in
>> operation today that optimal/closest exit preferences for IPv4
>> unicast do not match in many networks the optimal/closest exit
>> preferences for IPv6 or for IPv4+label AFI/SAFIs. It would be
>> interesting how authors of the proposed draft are going to address
>> this point going forward.
>>
>> ***
>>
>> Now let me take a moment to provide few points on number of
>> advantages of the IDR WG document
>> draft-ietf-idr-bgp-optimal-route-reflection-00 as compared with the
>> above document:
>>
>> * IDR WG draft does not require any manual static configuration of
>> path preferences - all required information is already present
>> today on the RR and can be readily used.
>>
>> * IDR WG draft can use add-paths to send more then best optimal
>> path from RR to the RR client - per clients preference
>>
>> * IDR WG draft dynamically recalculates optimal/closest IGP metric
>> exist point or points for each client and group of clients when
>> ASBR add/withdraw BGP routes or when IGP topology changes
>>
>> * IDR WG draft provides ways to dynamically group clients based on
>> their common POP location / IGP area without any operator's
>> configuration burden on RR
>>
>> * IDR WG draft works equally well in normal IPv4/IPv6 networks as
>> well as with some form of tunneled networks without putting any
>> requirement on forwarding paradigm selection in the network
>>
>> * It works in the same way for any AFI/SAFI and independently
>> guarantees calculation of optimal/closest exit points for IPv4,
>> IPv4+label or IPv6 paths as well as their distribution to the
>> clients.
>>
>> * IDR WG document provides ability for virtual RR placement in any
>> IGP network node location without any physical reconnection
>> required. Such provision is not addressed in the above document.
>>
>> Best regards, R. _______________________________________________
>> Idr mailing list [email-masked]
> _______________________________________________ Idr mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/idr
>
>
> _______________________________________________ Idr mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/idr
>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 05 Jun 2011 23:24:38 +0200

Vinod,

Let me also describe how all goals of your draft are met by IDR WG doc 
as well as by associated with it Next-Hop SAFI draft 
(draft-varlashkin-bgp-nh-cost-01) without any need for using SPF on the 
RRs.

Imagine you have number of PEs which per operator's logic know their 
exit preference. Using new NH-SAFI they can idicate to RR their own 
local metric to each of available next hop. If one or N of those paths 
with previously advertised next hops goes away RR will immediately 
replace it with new set of available paths.

This is simplest form of local operator decision on what is the order of 
paths in the network yet number of paths received by PE is decoupled 
from the preference (unlike in your draft). It is also robust as at any 
point it will not result in the customer's outage.

Here I would like to thank you for highlighting within our discussion 
that PE driven provider's optimal path selection is requested by some 
operators. This will clearly help to progress 
draft-varlashkin-bgp-nh-cost-01 and it's implementations further and it 
offers a very good tool to accomplish such requirement.

Best regards,
R.

---

From: Vinod Joseph <[email-masked]>
Date: Mon, 6 Jun 2011 15:09:16 +0100

Robert,

More inline - 

Up front to make it very clear for all readers can authors explicitly 
confirm that the applicability of this draft is only limited to 
networks which use some form of tunneling (for example: MPLS) between 
each PE and ASBRs ?

Vinod# Yes

 POPs which do not have local exit ASBRs and which do not leak next 
 hops from core to POP area in the IGP even if given opportunity to 
 receive _all_ external paths still have no visibility into the closet 
 exit ASBR in the domain as ABRs would typically depending on the IGP 
 selection and area type shield them from domain wide flooding 
 information. Therefor those PEs will still remain selecting random 
 paths unless the proposal would also include static best path 
 selection on such PEs based on RT.

Vinod# Can you explain this, not sure whether I follow your question?

 RT Constrain as proposed, implemented and deployed today has been 
 designed to express a VPN membership rules as an base object. While 
 there were some attempts to further divide this to be on per AFI/SAFI 
 basis RT Constrain authors came to the conclusion that those attempts 
 have no practical justification. In this proposal use of RT constrain 
 filtering would however result in the same exit ASBR preference to be 
 applied for IPv4 as to the IPv6 with or without labels AFI/SAFIs.

Vinod# Why is that the case? RTs would control the set of paths that a PE would receive. However the choice of which of these to pick could be different for IPv4 and IPv6.

However if the desire is to have different sets for IPv4 and different sets for IPv6 then one way to solve this is to have different RTs for IPv4 and IPv6. With this model if a PE has both IPv4 and IPv6 routes, it would use different RTs for v4 and v6.

In the case of VPNs, some vendors said that they wanted to reuse the same RT for IPv4 and IPv6 VPNs and yet not send IPv4 routes to an IPv6 only PE, for example. Hence there was discussion on AFI/SAFI granularity for RT constrain. For the purposes of this draft the solution is probably much simpler.

Regards

Vinod Joseph

-----Original Message-----
From: Vinod Joseph 
Sent: 05 June 2011 20:58
To: [email-masked]
Subject: RE: draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt

Robert,

Regards

Vinod Joseph

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 05 June 2011 20:00
To: [email-masked]
Subject: Idr Digest, Vol 86, Issue 3

Today's Topics:

Message: 1

Hi,

* The draft says:

***

Best regards,
R.

Message: 2

+1

Regards,
Jeff