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

[Robert Raszuk <[e-mail]>]

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.