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

[Robert Raszuk <[e-mail]>]

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:
>
>> 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
> **********************************
> _______________________________________________ Idr mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/idr
>