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

[Vinod Joseph <[e-mail]>]

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: [phone]
E: [e-mail]
 


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 05 June 2011 20:00
To: [e-mail]
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
	[e-mail]

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
	[e-mail]

You can reach the person managing the list at
	[e-mail]

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 <[e-mail]>
To: "[e-mail] List" <[e-mail]>
Subject: [Idr]
	draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt
Message-ID: <[e-mail]>
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 <[e-mail]>
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail] List" <[e-mail]>
Subject: Re: [Idr]
	draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"

+1

Regards,
Jeff

On Jun 4, 2011, at 15:51, "Robert Raszuk" <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr


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

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


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