Subject: Re: [Idr] Idr Digest, Vol 86, Issue 5

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

Robert,

Glad that you agree that SPF on RRs as per your draft is not the way and that alternates are the need of the hour.

Let me clarify this clearly. The proposed draft provides the PE to indicate a list of affinities for ASBRs. It may choose to use the (1) closest based on the IGP Metric (2) Optimal NH based on traffic flow requirements that mandate that exit for certain PEs/POPs use a given set of ASBRs only (3) offload any overhead from the RR (4) Support other AF in addition to IPv4 (5) Use existing BGP state machinery that has been in use for ages (6) Offer extreme flexibility in control max number of paths per RT (7) Use individual RTs per RR to choose paths from a given RR and so on...

Hope this makes clear for all that this proposal has distinct advantages when compared to the drafts you have mentioned.

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: 06 June 2011 15:11
To: [email-masked]
Subject: Idr Digest, Vol 86, Issue 5

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. Re: draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt
      (Robert Raszuk)
   2. Re: draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt
      (Vinod Joseph)

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

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

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.

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

Message: 2
Date: Mon, 6 Jun 2011 15:09:16 +0100
From: Vinod Joseph <[email-masked]>
To: <[email-masked]>
Subject: Re: [Idr]
	draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

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
Professional Services - Service Provider Europe
Juniper Networks???????????????????????????????????????????????????????????????????
M: +44 (0) 7500 835 876
E:?[email-masked]
?

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

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

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

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

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

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 06 Jun 2011 16:36:01 +0200

Vinod,

> Glad that you agree that SPF on RRs as per your draft is not the way

No. I do not agree with that. It is the way. RR is just a computer. 
Computers are build to compute not to push the work further.

> and that alternates are the need of the hour.

My point was to indicate that all alternatives you list below are 
already possible with IDR WG doc + draft-varlashkin-bgp-nh-cost and all 
without any need for overhead of managing RTs for IP unicast or 
multicast routes.

Thx,
R.

> Let me clarify this clearly. The proposed draft provides the PE to
> indicate a list of affinities for ASBRs. It may choose to use the (1)
> closest based on the IGP Metric (2) Optimal NH based on traffic flow
> requirements that mandate that exit for certain PEs/POPs use a given
> set of ASBRs only (3) offload any overhead from the RR (4) Support
> other AF in addition to IPv4 (5) Use existing BGP state machinery
> that has been in use for ages (6) Offer extreme flexibility in
> control max number of paths per RT (7) Use individual RTs per RR to
> choose paths from a given RR and so on...
>
> Hope this makes clear for all that this proposal has distinct
> advantages when compared to the drafts you have mentioned.
>
>
> Regards Vinod Joseph

---

From: "iLya" <[email-masked]>
Date: Mon, 6 Jun 2011 17:25:27 +0200

Vinod,

looking at yours and Robert's fast-paced conversation I didn't want to 
interfere in the middle, but your latest mail seems like appropriate point 
for me to respond. Please see inline.

--------------------------------------------------
> requirements that mandate that exit for certain PEs/POPs use a given set 
> of ASBRs only (3) offload any overhead from the RR (4) Support other AF in 
> addition to IPv4 (5) Use existing BGP state machinery that has been in use 
> for ages (6) Offer extreme flexibility in control max number of paths per 
> RT (7) Use individual RTs per RR to choose paths from a given RR and so 
> on...
>

NH SAFI would allow you to do all of the above without need for ADD-PATH 
unless hierarchical route-reflectors are involved. An operator could simply 
configure routers to send administrative cost to next-hops rather then the 
one based on IGP.

Reading further you draft, I do not agree that contemporary ASBR's are 
suitable for performing route-reflection - they do have enough space for 
storing multiple RIB views, but their computational power is only fraction 
of what's available on the route reflectors for fraction of the cost.

Now a quote from section 3 of your draft:

"since
   multiple paths are available on the PE and the decision process can
   now be re-run on the PE itself."

That seems to imply either modification of the BGP selection process on the 
PE routers (not good), or use of policies to alter locally-significant 
preference (performance penalty, and recipe for inconsistent routing), or 
depreving PE routers from guaranteed connectivity to certain prefixes if 
they happen to be learned not via ASBR's that mark routes with RT that those 
PE are interested in. Also, it's likely to be the case that overall number 
of AS exit points (==potential next-hops) is higher than number of exit 
points where certain prefixes are learned (e.g. some US-based network may or 
may not have direct presence at european exchange point), in this case your 
solution will provide suboptimum routing (let me know if you'd like me to 
elaborate on this).

If operators would like to change exit point preferences then two existing 
drafts already have two solutions - either using angular metric or by using 
NH SAFI, and without limitations described above.

Kind regards,
iLya

---

From: Vinod Joseph <[email-masked]>
Date: Mon, 6 Jun 2011 19:21:19 +0100

Ilya,

One of the aspects that this proposal will address is the use of hierarchical Route Reflectors.

On your points:

"Reading further you draft, I do not agree that contemporary ASBR's are 
suitable for performing route-reflection - they do have enough space for 
storing multiple RIB views, but their computational power is only fraction 
of what's available on the route reflectors for fraction of the cost."

Vinod# The intent of this has been misunderstood. There was only a representation of ASBRs performing route reflection as an approach that some carriers may use to address the hot potato routing issue. We are not proposing that this is a solution in the draft. So let us clearly remove this from the discussion

Your draft does propose the need for a new BGP capability, our proposal intends to re-use existing BGP machinery for IPv4/V6 (RT/RT Constrain) and avoid much re-invention to the BGP state machinery.

Depending on the scale and capability of the PE, only a given number of ASBR paths can be indicated as acceptable. For instance a PE may indicate a preference of only 3 paths per RT. Whenever a path is withdrawn, the RR would announce an additional path (if available within the context of the RT signalled) to the PE. 

The proposal also makes way for a mechanism where a PE can signal interest in 2 Route targets and announce a special RT which is allocated on a per RR. This will provide more flexibility, wherein the RR would announce "N" number of paths for the two RTs, and calculate the best path for all other prefixes (default scheme) since the PE has sent interest in the RT allocated to a given RR. This provides flexibility for path selection and also provides an alternate for resiliency. Therefore there cannot be a permanent outage.

RT constrain also provides an optimal way of automatically filtering prefixes between RRs which have clients that are not interested in certain RTs. 

Why do you see the PE performing a best path calculation a problem? The draft has enough methods to providing optimal routing from a PE's standpoint without too much burden on the control plane, and I have explained this above. There is an added advantage by doing this as well, if a PE has more than one path locally available, it would provide quicker convergence locally, rather than waiting for the RR to pick the second best and announce it back to PEs.

Coming back to your comment in the NH SAFI draft - Section A3.

   As addition to ADDPATH a mechanism could be devised that would allow
   RR2 to learn how many alternative routes does it need to send to RR1.
   For example, if NetA would also be connected to R9 (not shown) but
   all clients of RR1 prefer R7 as exit point and R9 as next-best, then
   there is no need for RR2 to send NetA routes with next-hop R8 to RR1.

   Vinod# This is addressed in our draft and provides a solution already.

One of the advantages: This draft proposes a scheme where each PE in a POP may use a separate ASBR for exit, by means of announcing interest in specific Route Targets. In other words an operator can use certain ASBRs for certain PEs that are within the same POP, as primary exit points. Even if you would cost an ASBR administratively, can you elaborate how would influence one PE within the same POP as the ASBR to choose the local ASBR and another PE to use an ASBR in a remote POP? Since the RR is doing the best path calculation in your case?

Regards

Vinod Joseph

-----Original Message-----
From: iLya [mailto:[email-masked]] 
Sent: 06 June 2011 16:25
To: Vinod Joseph; [email-masked]
Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5)

Vinod,

"since

Kind regards,
iLya

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 06 Jun 2011 20:41:20 +0200

Vinod,

> special RT which is allocated on a per RR.

Please provide a quote from RFC4684 which would describe the concept of 
special RT which is allocated on a per RR basis as well as expected 
handling of this special RT by RR.

What device allocates this special RT ? What is the meaning of this 
special RT ?

Your explanations are very vague and not on the topic of the questions 
asked. Please kindly re-explain how using your solution PE will still 
get some paths even in the event of said PEs preferring subset of all 
available paths as indicated by the set of RTs and this subset of paths 
is no longer available.

R.

---

From: Ilya Varlashkin <[email-masked]>
Date: Mon, 6 Jun 2011 20:49:13 +0200

> Depending on the scale and capability of the PE, only a given number of ASBR paths can be indicated as acceptable. For instance a PE may indicate a preference of only 3 paths per RT. Whenever a pat…

Let's get specific. Consider 10 ASBR's in Europe and 10 in USA, and a bunch of PE's in each of these regions. Closest (according to current active) topology exit to reach foreign network is required. How many RT's do we need to cover this case, how many PATHs should RR advertise to PE, and what happens when this RR goes away? next round: what will be behaviour when a prefix learned via an ASBR that does not advertise RT in which PE is interested?

Kind regards,
iLya

---

From: Vinod Joseph <[email-masked]>
Date: Mon, 6 Jun 2011 23:41:18 +0100

Ilya,

Lets get this into perspective in regard to the NH draft:

1. New Capability is needed on all BGP speakers and the RR. Our proposal uses existing BGP machinery and does not need new capabilities or SPF instances created on the RR.

2. The NH draft presents a single (best based on metric) path to each BGP speaker. There is currently no mechanism to present different paths to two set of BGP speakers within the same POP - since the metric presented to a given RR will influence that RR to always choose a single best ASBR and announce that to the PE. Even if two RRs are used, and if a BGP speakers manipulates the metric to prefer an ASBR closer to the second RR - There is no guarantee that the needed ASBR path would be presented ever. Our proposed solution facilities this easily, but just indicating needed RTs that pertain to a given ASBR(s).

3. The NH draft has a problem when hierarchical RRs are used as Robert pointed out. There are no issues with the presented approach.

4. RT constrain ensures that only routes that an RR is interested in is propagated between RRs. This is not possible with the NH draft.

5. Manipulation of metrics using administrative values result in multiple touch-points anyways. The proposed approach is a replica of the VPNv4 model which uses RTs and RT constrain. I am not sure why this is considered operationally complex to configure? As far as grouping of ASBRs and RT goes: There are multiple approaches (1) Group all ASBRs within a region/POP to use a single RT (2) Group ASBRs in terms of function (peering vs transit) wit similar RTs (3) If the dynamics change where a certain set of BGP speakers need additional information from an ASBR with a different RT - The ASBR needs to just announce its prefixes with an additional RT - Single change.

6. There is strong interest in having a flexible approach wherein a single network can have the flexibility that RT and RT constrain can offer, with a mix of restricting paths advertised per RT, Have resiliency by using a set of RTs signalled by BGP speakers in addition to an RT which is uniquely identified per RR - to have best paths only for all other prefixes. Note that carriers want to have the flexibility of pre-defined primary, backup, paths that may not necessarily be the shortest IGP path at all instances. This draft provides that. 

7. Providers needs to deploy services (for eg, DNS, RADIUS, etc) with geo-resiliecy with a view of offering high avalability, geo resiliency and load sharing to scale the solution horizontally. In such requirments anycast routing approach may seem to be favourable. A virtual address or set of addresses for each application may be advertised via BGP from every service PoP The advantage of using BGP is that PE routers could learn BGP paths to each service PoP and have a local policy based on affinity or other design to load-share and provide resilience.

However the downside of this approach is that all PE routers are required to have a mesh of BGP sessions to all service PoPs in addition to the exsiting iBGP sessions with RR's and other eBGP sessions. PEs at service PoP also need to support a large number of BGP sessions (linear to the number of PEs in the network under consideration).

Operationally it implies that any PoP commissiong or de-commissiong activty involves multiple touch points on the network and additional change control processes need to be invoked as business critical services are located beind PE in service POPs. This also increases the risk to other services by nature of change enforced at multiple points

In the case of this solution, Multiple paths can be presented and effectively used in these solutions as the RR completely decouples itself from the path selection process and PE routers are presented with all available paths to service POPs. No additional BGP sessions are needed other than the existing iBGP sessions with RRs. 

Providers also benefit from the fact this is a very light touch approach and service PoPs can be gracefully taken offline for maintenance by easily singalling a community or other attribute over a iBGP session to the RRs by a service PE, as an example (the same can be achieved today but the service PE needs to signal this to all the PEs in the network and also implies that coherent BGP polices have been implement for each iBGP neighbour) OR The entire PoP can be brought off-line by manupulating IGP metrics which may always not be possible if multiple services/applications are offered from this PoP. 

More importantly it allows service provides to operate services in a very low touch mode where chances of collateral damage are minimised, policy enforcement is made simpler and is also easy on operational processes & resources.

Regards

Vinod Joseph

-----Original Message-----
From: Ilya Varlashkin [mailto:[email-masked]] 
Sent: 06 June 2011 19:49
To: Vinod Joseph
Cc: [email-masked]
Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5)

Kind regards,
iLya

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 07 Jun 2011 01:26:49 +0200

Vinod,

Lets get this into perspective in regard to your draft too ...

> 1. New Capability is needed on all BGP speakers and the RR. Our
> proposal uses existing BGP machinery and does not need new
> capabilities or SPF instances created on the RR.

I would like to observe that I am not aware of any network wide 
deployment of RT-Constrain today in the world - even for L3VPNs where it 
fits nicely .. most PEs and RRs just do not support it. Yes you have it 
in your lab running junos, but this is one of N routing stacks deployed 
today.

> 2. The NH draft presents a single (best based on metric) path to each
> BGP speaker. There is currently no mechanism to present different
> paths to two set of BGP speakers within the same POP - since the
> metric presented to a given RR will influence that RR to always
> choose a single best ASBR and announce that to the PE. Even if two
> RRs are used, and if a BGP speakers manipulates the metric to prefer
> an ASBR closer to the second RR - There is no guarantee that the
> needed ASBR path would be presented ever. Our proposed solution
> facilities this easily, but just indicating needed RTs that pertain
> to a given ASBR(s).

I think this clearly demonstrates that you lack understanding of what NH 
draft defines and therefor I would encourage you to read it again .. and 
again .. till you manage to understand it's technical value. In the 
event this will be hard please do consult your company's colleagues 
which do understand NH-SAFI draft very well.

> 3. The NH draft has a problem when hierarchical RRs are used as
> Robert pointed out. There are no issues with the presented approach.

Excuse me ? Please first refrain if you could from putting such false 
statement in the WG emails. I do not recall I ever said NH draft has 
issues with hierarchical RRs.

If you would actually read my draft you would clearly see the below two 
paragraphs:

sec 3

    In the network architectures consisting of more then single pair of
    route reflectors it is required that all reflectors are fully meshed
    and have ability to learn and maintain all external BGP paths.  In
    the event of constructing a hierarchy of reflectors to relax the full
    RR mesh requirements ORR should not be run between such route
    reflectors.

+ sec 4.3

       Deploy add-paths between route reflectors in order to maximize
       path diversity within the cluster.

That explains very clearly that top level RR in the hierarchical setups 
does not provide any ORR and by using add-paths encoding distributes all 
paths to the lower level of RRs.

> 4. RT constrain ensures that only routes that an RR is interested in
> is propagated between RRs. This is not possible with the NH draft.

Great .. so now we are talking about even bigger outage then I 
originally assumed by PE-RR RT signaling. Those paths are not on RR as 
RR did not asked corresponding ASBR to send towards it the available 
unicast paths.

What a broken and completely no resiliency based design.

In the interest of IDR members and my own time I will refrain from even 
commenting any more on the below points.

I encourage you to pursue your ideas and your draft further as long as 
you rename the draft. It is just not ethical to call it the same name as 
existing WG document which actually works and addresses real large 
operator's needs.

Regards,
R.

PS. The further your draft goes the better .... ;-) if you know what I 
mean.

> 5. Manipulation of metrics using administrative values result in
> multiple touch-points anyways. The proposed approach is a replica of
> the VPNv4 model which uses RTs and RT constrain. I am not sure why
> this is considered operationally complex to configure? As far as
> grouping of ASBRs and RT goes: There are multiple approaches (1)
> Group all ASBRs within a region/POP to use a single RT (2) Group
> ASBRs in terms of function (peering vs transit) wit similar RTs (3)
> If the dynamics change where a certain set of BGP speakers need
> additional information from an ASBR with a different RT - The ASBR
> needs to just announce its prefixes with an additional RT - Single
> change.
>
> 6. There is strong interest in having a flexible approach wherein a
> single network can have the flexibility that RT and RT constrain can
> offer, with a mix of restricting paths advertised per RT, Have
> resiliency by using a set of RTs signalled by BGP speakers in
> addition to an RT which is uniquely identified per RR - to have best
> paths only for all other prefixes. Note that carriers want to have
> the flexibility of pre-defined primary, backup, paths that may not
> necessarily be the shortest IGP path at all instances. This draft
> provides that.
>
> 7. Providers needs to deploy services (for eg, DNS, RADIUS, etc) with
> geo-resiliecy with a view of offering high avalability, geo
> resiliency and load sharing to scale the solution horizontally. In
> such requirments anycast routing approach may seem to be favourable.
> A virtual address or set of addresses for each application may be
> advertised via BGP from every service PoP The advantage of using BGP
> is that PE routers could learn BGP paths to each service PoP and have
> a local policy based on affinity or other design to load-share and
> provide resilience.
>
> However the downside of this approach is that all PE routers are
> required to have a mesh of BGP sessions to all service PoPs in
> addition to the exsiting iBGP sessions with RR's and other eBGP
> sessions. PEs at service PoP also need to support a large number of
> BGP sessions (linear to the number of PEs in the network under
> consideration).
>
> Operationally it implies that any PoP commissiong or de-commissiong
> activty involves multiple touch points on the network and additional
> change control processes need to be invoked as business critical
> services are located beind PE in service POPs. This also increases
> the risk to other services by nature of change enforced at multiple
> points
>
> In the case of this solution, Multiple paths can be presented and
> effectively used in these solutions as the RR completely decouples
> itself from the path selection process and PE routers are presented
> with all available paths to service POPs. No additional BGP sessions
> are needed other than the existing iBGP sessions with RRs.
>
> Providers also benefit from the fact this is a very light touch
> approach and service PoPs can be gracefully taken offline for
> maintenance by easily singalling a community or other attribute over
> a iBGP session to the RRs by a service PE, as an example (the same
> can be achieved today but the service PE needs to signal this to all
> the PEs in the network and also implies that coherent BGP polices
> have been implement for each iBGP neighbour) OR The entire PoP can be
> brought off-line by manupulating IGP metrics which may always not be
> possible if multiple services/applications are offered from this
> PoP.
>
> More importantly it allows service provides to operate services in a
> very low touch mode where chances of collateral damage are minimised,
> policy enforcement is made simpler and is also easy on operational
> processes&  resources.
>
> Regards
>
> Vinod Joseph Professional Services - Service Provider Europe Juniper
> Networks
>  M: +44 (0) 7500 835 876 E: [email-masked]
>
>
>
>
> -----Original Message----- From: Ilya Varlashkin
> [mailto:[email-masked]] Sent: 06 June 2011 19:49 To: Vinod Joseph
> Cc: [email-masked] Subject: Re: [Idr] more on
> draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest,
> Vol 86, Issue 5)
>
>> Depending on the scale and capability of the PE, only a given
>> number of ASBR paths can be indicated as acceptable. For instance a
>> PE may indicate a preference of only 3 paths per RT. Whenever a
>> path is withdrawn, the RR would announce an additional path (if
>> available within the context of the RT signalled) to the PE.
>>
>
> Let's get specific. Consider 10 ASBR's in Europe and 10 in USA, and a
> bunch of PE's in each of these regions. Closest (according to current
> active) topology exit to reach foreign network is required. How many
> RT's do we need to cover this case, how many PATHs should RR
> advertise to PE, and what happens when this RR goes away? next round:
> what will be behaviour when a prefix learned via an ASBR that does
> not advertise RT in which PE is interested?
>
> Kind regards, iLya
>
> _______________________________________________ Idr mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/idr
>

---

From: "iLya" <[email-masked]>
Date: Tue, 7 Jun 2011 10:31:21 +0200

Hi Vinod,

> 1. New Capability is needed on all BGP speakers and the RR. Our proposal 
> uses existing BGP machinery and does not need new capabilities or SPF 
> instances created on the RR.
>

NH draft indeed requires new capability, but solves the problem, WG ORR 
draft does not require new capability and solves the problem. Your draft 
doesn't require new capability but doesn't solve problem either.

> 2. The NH draft presents a single (best based on metric) path to each BGP 
> speaker. There is currently no mechanism to

NH draft only provides source of information to RR, but does not specify 
whether single or multiple paths are sent by RR to PE, the routers are free 
to use any current or future techniques to exchange single or multiple 
PATH's.

> 3. The NH draft has a problem when hierarchical RRs are used as Robert 
> pointed out. There are no issues with the presented approach.
>

I have pointed out during my presentation in Prague that if inter-RR 
optimisation is required, then it can be addressed. If there is no practical 
interest, then there's no point in wasting effort solving academic problem 
outside of academic realm.

> 4. RT constrain ensures that only routes that an RR is interested in is 
> propagated between RRs. This is not possible with the NH draft.

RT constrain also ensures that if routes are not marked with certain 
community, then PE checking that community will never receive the routes and 
will either not be able to access the network in question or will reach it 
through sub-optimum path (e.g. via default).

>
> 5. Manipulation of metrics using administrative values result in multiple 
> touch-points anyways. The proposed approach is a replica of the VPNv4 
> model which uses RTs and RT constrain. I am not sure why this is 
> considered operationally complex to configure? As far as grouping of ASBRs 
> and RT goes: There are multiple approaches (1) Group all ASBRs within a 
> region/POP

I propose you book a month in NOC as your next holiday destination. Anything 
that needs to be configured by human is error prone. Anything that you 
propose to configure by a script is just a shift of responsibility - as 
network operator I'd like to see vendors delivering solutions and not saying 
"hey, but you could just solve it yourself". At VPNv4/v6 we know in advance 
all potential routers where a prefix can be learned so we can ensure that 
they're marked with appropriate RT. For global Internet routes we don't have 
this information and therefore cannot mark them appropriately.

> to use a single RT (2) Group ASBRs in terms of function (peering vs 
> transit) wit similar RTs

it's not unusual to have transit and peering on the same devices. And peer 
vs. transit can easily be addressed with long-existing tools as local-pref, 
MED and custom decision process metric, no need for any new mechanism.

> (3) If the dynamics change where a certain set of BGP speakers need 
> additional information from an ASBR with a different RT - The ASBR needs 
> to just announce its prefixes with an additional RT - Single change.

yes, single change every time a prefix is announced differently. And we will 
introduce new position at NOCs - real-time routing table observer; skills 
required - lightningfast analysis of 400K routes and outstanding typing 
speed.

> 6. There is strong interest in having a flexible approach wherein a single 
> network can have the flexibility that RT and RT constrain can offer, with 
> a mix of restricting paths advertised per RT, Have resiliency by using a 
> set of RTs signalled by BGP speakers in addition to an RT which is 
> uniquely identified per RR - to have best paths only for all other 
> prefixes. Note that carriers want to have the flexibility of pre-defined 
> primary, backup, paths that may not necessarily be the shortest IGP path 
> at all instances. This draft provides that.
>

sorry but your draft does not guarentee that a router will be able to obtain 
full routing table. We need full routing table to access the Internet.

> geo-resiliecy with a view of offering high
[...]
> effectively used in these solutions as the RR

which is nothing new - has been like this since ADD-PATH. And IDR WG ORR 
draft allows sending best and next-best on per-PE basis without requiring 
any changes in the PE (beyond supporting ADD-PATH).

To restate it once more - your draft has problem with guaranteeing delivery 
of all routes to a PE. Until you address that issue, it doesn't matter what 
else you're trying to solve.

Kind regards,
iLya

---

From: Vinod Joseph <[email-masked]>
Date: Tue, 7 Jun 2011 09:41:03 +0100

sorry but your draft does not guarentee that a router will be able to obtain full routing table. We need full routing table to access the Internet.

Vinod# I presume you have read the RT constrain draft. Full Internet routes can be received by using the Default RT which is equal to prefixes with all Route Targets.

The point here is not about whether this draft is superior to superior to the NH draft, its very clear that this proposal offers the flexibility that is not addressed by your draft.

Can you answer this:

This draft proposes a scheme where each PE in a POP may use a separate ASBR for exit, by means of announcing interest in specific Route Targets. In other words an operator can use certain ASBRs for certain PEs that are within the same POP, as primary exit points. Even if you would cost an ASBR administratively, can you elaborate how would influence one PE within the same POP as the ASBR to choose the local ASBR and another PE to use an ASBR in a remote POP? Since the RR is doing the best path calculation in your case?

Regards

Vinod Joseph

-----Original Message-----
From: iLya [mailto:[email-masked]] 
Sent: 07 June 2011 09:31
To: Vinod Joseph
Cc: [email-masked]; Amit Khopkar; Laurent Lavallee
Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5)

Hi Vinod,

[...]

Kind regards,
iLya

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 07 Jun 2011 11:13:14 +0200

Vinod,

The most interesting point within your serious of replies is that you do 
not even understand what you are missing.

 > Vinod# I presume you have read the RT constrain draft. Full Internet
 > routes can be received by using the Default RT which is equal to
 > prefixes with all Route Targets.

So you write a draft, recommend to use RT constrain in it to filter 
preferred paths then on top of all of that call for using the default 
route target to get all paths in order to make sure RR client can still 
reach destinations in the event of some paths being withdrawn.

What a total nonsense.

R.

> sorry but your draft does not guarentee that a router will be able to
> obtain full routing table. We need full routing table to access the
> Internet.
>
> Vinod# I presume you have read the RT constrain draft. Full Internet
> routes can be received by using the Default RT which is equal to
> prefixes with all Route Targets.
>
> The point here is not about whether this draft is superior to
> superior to the NH draft, its very clear that this proposal offers
> the flexibility that is not addressed by your draft.
>
> Can you answer this:
>
> This draft proposes a scheme where each PE in a POP may use a
> separate ASBR for exit, by means of announcing interest in specific
> Route Targets. In other words an operator can use certain ASBRs for
> certain PEs that are within the same POP, as primary exit points.
> Even if you would cost an ASBR administratively, can you elaborate
> how would influence one PE within the same POP as the ASBR to choose
> the local ASBR and another PE to use an ASBR in a remote POP? Since
> the RR is doing the best path calculation in your case?
>
> Regards
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 07 Jun 2011 11:20:48 +0200

Vinod,

> Can you answer this:

Of course.

> the RR is doing the best path calculation in your case?

Trivial case.

RR sends NH-SAFI request to PE1 and PE2 listing two next hops nh1 and 
nh2 corresponding to paths received via local ASBR1 in the POP and some 
remote ASBR2 in the other POP.

PE1 replies to RR: nh1 metric 100
                    nh2 metric 200

PE2 replies to RR: nh1 metric 200
                    nh2 metric 100

Done !

RR will consider optimal path for PE1 from ASBR1 (lowest metric) and for 
PE2 the optimal path will be the one advertised by ASBR2 (lowest metric).

No need to worry about any manual re-assignment of anything during any 
network failure or path withdraw. RR will always send another path and 
PEs would not need to keep more paths then they need to use at any point 
of time.

Case solved.

Thx,
R.

---

From: "iLya" <[email-masked]>
Date: Tue, 7 Jun 2011 11:27:54 +0200

> Can you answer this:
>
> This draft proposes a scheme where each PE in a POP may use a separate 
> ASBR for exit, by means of announcing interest in specific Route Targets. 
> In other words an operator can use certain ASBRs for certain PEs that are 
> within the same POP, as primary exit points. Even if you would cost an 
> ASBR administratively, can you elaborate how would influence one PE within 
> the same POP as the ASBR to choose the local ASBR and another PE to use an 
> ASBR in a remote POP? Since the RR is doing the best path calculation in 
> your case?
>

In case of NH SAFI each PE may just announces administrative cost to 
next-hops, e.g. (in their announces to RR) PE1 announces cost 10 to NH1 and 
15 to NH2, while PE2 announces cost 20 to NH2 and cost 40 to NH1, the rest 
is assured by section 3 of NH SAFI draft. RR then uses this cost instead of 
its own when performing per-client (or per-group) best path selection, so if 
a prefix A is reachable via both NH1 and NH2, then PE1 will receive 
"A-via-NH1" as best (and optionally "-via-NH2" as next-best) and PE2 will 
receive "A-via-NH2" as best (and optionally "-via-NH1" as next-best).

Cheers,
iLya

---

From: Vinod Joseph <[email-masked]>
Date: Tue, 7 Jun 2011 10:36:07 +0100

Interesting enough. I just needed this to be spelt out.

So there is enough overhead here is calculating and assigning administrative costs between each PE-ASBR pair, if traffic flows need to be addressed in this manner. I would imagine how easy it would be to do this on a larger scale if there are diverse requirements as such. 

Add IPv6 to this, and you have another set of administrative costs + calculations to be made. Makes it more interesting. 

Regards

Vinod Joseph

-----Original Message-----
From: iLya [mailto:[email-masked]] 
Sent: 07 June 2011 10:28
To: Vinod Joseph
Cc: [email-masked]; Amit Khopkar; Laurent Lavallee
Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5)

Cheers,
iLya

---

From: "iLya" <[email-masked]>
Date: Tue, 7 Jun 2011 11:45:54 +0200

> So there is enough overhead here is calculating and assigning 
> administrative costs between each PE-ASBR pair, if traffic flows need to 
> be addressed in this manner. I would imagine how easy it would be to do 
> this on a larger scale if there are diverse requirements as such.
>

we've been through this about a month ago - discussing overheads and costs 
and scaleability of ORR on IDR mailing list. If you have some new info to 
add, please bring it up, otherwise it appeared we have addressed the issue 
positively (see archives).

> Add IPv6 to this, and you have another set of administrative costs + 
> calculations to be made. Makes it more interesting.
>

if you prefer different exit for v6 than for v4, then yes - more costs, 
otherwise you just use option "admin cost N all-afi" and done. As for number 
of calculations - the amount of work is constant, whether it's cheaper/more 
efficient to perform this on RR or on PE is discussed earlier as mentioned 
above.

Cheers,
iLya

---

From: "iLya" <[email-masked]>
Date: Tue, 7 Jun 2011 12:38:16 +0200

> As a network operator we believe the approach using RTs is simpler than 
> adding more computation and software complexity on the RR which is not 
> free of scalability concerns.
>

Amit,

I am truely surprised that you as network operator don't see that RT-based 
proposal in its current form cannot provide full routing table.

Kind regards,
iLya

---

From: "iLya" <[email-masked]>
Date: Tue, 7 Jun 2011 13:11:11 +0200

> I think Vinod has covered some options to support this requirement in an 
> earlier email.
>
Must have been written in invisible ink. Unless you referring to "use 
default RT", which degrades behaviour to ordinary ADD-PATH and hence does 
not bring anything that wasn't already there. I'm all ears and eyes to learn 
how exactly your draft proposes to address full routing table issue.

Kind regards,
iLya

---

From: Vinod Joseph <[email-masked]>
Date: Tue, 7 Jun 2011 12:19:46 +0100

Ilya,

1. Use of an RR specific RT, which enables the RR to send only the best path (RR calculated using the default behaviour) for all prefixes in addition to RT specific prefixes that a BGP speaker would explicitedly indicate interest in.

2. Section 5.8 of the draft: Use of the Default RT and also the ability to indicate max no. of paths on a per RT basis. or even more max no. of paths for all prefixes with RTs or without RTs.

3. Section 5:5 of the draft: Define a range of RTs. Let us consider a scenario where, a BGP speaker is interested in multiple RTs.  The proposal suggests that any implementation should  have the ability for a given BGP speakers to use a range of RT values and Wildcards to signal affinities.  For example a range as follows indicates that the RT Membership NLRI includes RT values of [1-20,30-35, 50].  This avoids the need for configuring each RT value
individually.

RT constraint supports the notion of a RT-prefix. Hence all RTs can be advertised as a single prefix assuming they are assigned from a prefix (and that would be a reasonable deployment model).

Regards

Vinod Joseph

-----Original Message-----
From: iLya [mailto:[email-masked]] 
Sent: 07 June 2011 12:11
To: Amit Khopkar; Vinod Joseph
Cc: [email-masked]
Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5)

Kind regards,
iLya

---

From: "iLya" <[email-masked]>
Date: Tue, 7 Jun 2011 16:27:34 +0200

--------------------------------------------------
From: "Vinod Joseph" <[email-masked]>
Sent: Tuesday, June 07, 2011 1:19 PM
To: "iLya" <[email-masked]>; "Amit Khopkar" <[email-masked]>
Cc: <[email-masked]>; "Laurent Lavallee" <[email-masked]>
Subject: RE: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection 
(was:  Idr Digest, Vol 86, Issue 5)

[skip]

> 3. Section 5:5 of the draft: Define a range of RTs. Let us consider a 
> scenario where, a BGP speaker is interested in multiple RTs.  The proposal 
> suggests that any implementation should  have the ability for a given BGP 
> speakers to use a range of RT values and Wildcards to signal affinities. 
> For example a range as follows indicates that the RT Membership NLRI 
> includes RT values of [1-20,30-35, 50].  This avoids the need for 
> configuring each RT value
> individually.
>

consider a network with presence in Europe (10 exits) and USA (10 exits). 
two route reflectors are deployed - one in UK and one south-west USA. A PE 
in Germany wants to use German exit points (but only if prefixes pass beyond 
MED consideration) as first choice and shortest IGP cost from their 
perspective otherwise. If the PE signals to RR that it wants prefixes with 
RT-Germany as first priority and rest IGP-cost-based, then for prefix A 
available over LINX and AMSIX and a private peer in France but not over 
DECIX the PE will get LINX prefixes, which are more far. Worst, when 
London's RR disappears (maintenance, failure) German PE will get US 
prefixes. Something does not compute.

Kind regards,
iLya

---

From: Amit Khopkar <[email-masked]>
Date: Tue, 7 Jun 2011 11:35:26 +0100

Hi Ilya,

lets take a step back from the details and revisit the current situation

1. In networks with BGP-free cores the route reflector ends up making a decision on the best path from its point of view and filters other paths from being advertised to the PE.
2. BGP ADD-PATH overcomes this challenge but has some scalability concerns
3. there are two approaches to resolve this
        a. let the route reflector make a decision for every PE based on some criteria (IGP metric in your draft)
        b. take the RR out of the route selection process (one of the main reasons for existence of ADD-PATH) but in a scalable manner

Also the question to ask is what is optimal? is it lowest IGP metric to next hop or some other criteria that the operator wishes to exercise. there should be flexibility with the network operator to support this choice.

As a network operator we believe the approach using RTs is simpler than adding more computation and software complexity on the RR which is not free of scalability concerns.

There are pros and cons to each approach and maybe there is space for both approaches. let the market decide what it wants ;)

cheers
amit

-----Original Message-----
From: iLya [mailto:[email-masked]]
Sent: 07 June 2011 10:46
To: Vinod Joseph
Cc: [email-masked]; Amit Khopkar; Laurent Lavallee
Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5)

Cheers,
iLya

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trade marks of British Sky Broadcasting Group plc and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky Interactive Limited (Registration No. 3554332), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

---

From: Amit Khopkar <[email-masked]>
Date: Tue, 7 Jun 2011 11:54:58 +0100

Ilya,

I think Vinod has covered some options to support this requirement in an earlier email.

A.

-----Original Message-----
From: iLya [mailto:[email-masked]]
Sent: 07 June 2011 11:38
To: Amit Khopkar; Vinod Joseph
Cc: [email-masked]; Laurent Lavallee
Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5)

Amit,

Kind regards,
iLya

---

From: "UTTARO, JAMES (ATTSI)" <[email-masked]>
Date: Tue, 7 Jun 2011 11:01:42 -0400

Could you elaborate on your concerns in re add-paths scalability?? What
are the concerns? add-paths can be selectively applied, can be limited
to a certain number of paths, can inter-operate with best-external where
applicable, is deployable in a subset of the topology.. It would be
helpful to detail your concerns and the tradeoff between creating a new
paradigm that essentially duplicates what add-paths already does..

Why are RTs simpler?

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Amit Khopkar
Sent: Tuesday, June 07, 2011 6:35 AM
To: iLya; Vinod Joseph
Cc: [email-masked]; Laurent Lavallee
Subject: Re: [Idr] more on
draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol
86, Issue 5)

Hi Ilya,

1. In networks with BGP-free cores the route reflector ends up making a
decision on the best path from its point of view and filters other paths
from being advertised to the PE.
2. BGP ADD-PATH overcomes this challenge but has some scalability
concerns
3. there are two approaches to resolve this
        a. let the route reflector make a decision for every PE based on
some criteria (IGP metric in your draft)
        b. take the RR out of the route selection process (one of the
main reasons for existence of ADD-PATH) but in a scalable manner

Also the question to ask is what is optimal? is it lowest IGP metric to
next hop or some other criteria that the operator wishes to exercise.
there should be flexibility with the network operator to support this
choice.

There are pros and cons to each approach and maybe there is space for
both approaches. let the market decide what it wants ;)

cheers
amit

-----Original Message-----
From: iLya [mailto:[email-masked]]
Sent: 07 June 2011 10:46
To: Vinod Joseph
Cc: [email-masked]; Amit Khopkar; Laurent Lavallee
Subject: Re: [Idr] more on
draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol
86, Issue 5)

> this on a larger scale if there are diverse requirements as such.

we've been through this about a month ago - discussing overheads and
costs
and scaleability of ORR on IDR mailing list. If you have some new info
to
add, please bring it up, otherwise it appeared we have addressed the
issue
positively (see archives).

if you prefer different exit for v6 than for v4, then yes - more costs,
otherwise you just use option "admin cost N all-afi" and done. As for
number
of calculations - the amount of work is constant, whether it's
cheaper/more
efficient to perform this on RR or on PE is discussed earlier as
mentioned
above.

Cheers,
iLya

Information in this email including any attachments may be privileged,
confidential and is intended exclusively for the addressee. The views
expressed may not be official policy, but the personal views of the
originator. If you have received it in error, please notify the sender
by return e-mail and delete it from your system. You should not
reproduce, distribute, store, retransmit, use or disclose its contents
to anyone. Please note we reserve the right to monitor all e-mail
communication through our internal and external networks. SKY and the
SKY marks are trade marks of British Sky Broadcasting Group plc and are
used under licence. British Sky Broadcasting Limited (Registration No.
2906991), Sky Interactive Limited (Registration No. 3554332),
Sky-In-Home Service Limited (Registration No. 2067075) and Sky
Subscribers Services Limited (Registration No. 2340150) are direct or
indirect subsidiaries of British Sky Broadcasting Group plc
(Registration No. 2247735). All of the co
 mpanies mentioned in this paragraph are incorporated in England and
Wales and share the same registered office at Grant Way, Isleworth,
Middlesex TW7 5QD.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Vinod Joseph <[email-masked]>
Date: Tue, 7 Jun 2011 16:12:06 +0100

James,

You are right in stating that the advertisement of ADD-PATHS can be limited to a subset of paths. 

However we are trying to address a totally separate issue of a BGP speaker indicating preferences for certain paths over others. In other words, the optimal path for a BGP speaker - which may be the based on the IGP Metric or a path that needs to be preferred over others due to an operators policy.  

As part of this process, we are using RTs to indicate which paths are needed on a per BGP speaker basis. Since the proposal is based on ADD-PATH to have the RR advertise more than a single path, we are proposing a mechanism to have a BGP speaker indicate its preference to have a given number of paths on a per RT basis. 

If we are to rely only on ADD-PATH, then the ability of a BGP speaker to indicate affinities will not be possible - so the driver is to have a BGP speaker the means of indicating preferences for paths - lets say as primary, backup and so on. 

Happy to elaborate more on this, if needed.

Regards

Vinod Joseph

-----Original Message-----
From: UTTARO, JAMES (ATTSI) [mailto:[email-masked]] 
Sent: 07 June 2011 16:02
To: Amit Khopkar; iLya; Vinod Joseph
Cc: [email-masked]; Laurent Lavallee
Subject: RE: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5)

Why are RTs simpler?

Jim Uttaro

-----Original Message-----

Hi Ilya,

cheers
amit

-----Original Message-----
From: iLya [mailto:[email-masked]]
Sent: 07 June 2011 10:46
To: Vinod Joseph
Cc: [email-masked]; Amit Khopkar; Laurent Lavallee
Subject: Re: [Idr] more on

Cheers,
iLya

---

From: "UTTARO, JAMES (ATTSI)" <[email-masked]>
Date: Tue, 7 Jun 2011 11:19:32 -0400

I think it is important to be clear as to the drivers.  So there is clearly no issue with add-paths scalability. I guess I am still a bit lost as to the driver.. You seem to want to be able to prefer a path or set of paths on an intermediate speaker ( RR ) prior to advertising further downstream.. It would seem that add-paths and some CV scheme and routing policy would accomplish the same goal.. If you are using add-paths on the RRs you can send as many paths as you want and only apply policy on the ingress PE..

I will take a read on the draft before commenting further. 

Jim Uttaro

-----Original Message-----
From: Vinod Joseph [mailto:[email-masked]] 
Sent: Tuesday, June 07, 2011 11:12 AM
To: UTTARO, JAMES (ATTSI); Amit Khopkar; iLya
Cc: [email-masked]; Laurent Lavallee
Subject: RE: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5)

James,

Regards

Vinod Joseph

-----Original Message-----
From: UTTARO, JAMES (ATTSI) [mailto:[email-masked]] 
Sent: 07 June 2011 16:02
To: Amit Khopkar; iLya; Vinod Joseph
Cc: [email-masked]; Laurent Lavallee
Subject: RE: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5)

Why are RTs simpler?

Jim Uttaro

-----Original Message-----

Hi Ilya,

cheers
amit

-----Original Message-----
From: iLya [mailto:[email-masked]]
Sent: 07 June 2011 10:46
To: Vinod Joseph
Cc: [email-masked]; Amit Khopkar; Laurent Lavallee
Subject: Re: [Idr] more on

Cheers,
iLya

---

From: Vinod Joseph <[email-masked]>
Date: Tue, 7 Jun 2011 16:34:37 +0100

Please do.

The driver and discussion is surely not about Add-Path.

One thing is, we do not want to have the RR announce all paths to the PE and then use policies to choose lets say 2 out of 10 paths.

Also, if a BGP speaker (PE) does not use Add-Path - the solution provides a means of having it indicate preferences for selective exit points via RT constrain. In this case it is expected that the RR would announce those ASBR NHs to the PEs. However since Add-Path is not supported on the PE, the RR would choose a NH which it considers the best (that is only in the event of multiple ASBRs having the same RT).

Regards

Vinod Joseph

-----Original Message-----
From: UTTARO, JAMES (ATTSI) [mailto:[email-masked]] 
Sent: 07 June 2011 16:20
To: Vinod Joseph; Amit Khopkar; iLya
Cc: [email-masked]; Laurent Lavallee
Subject: RE: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5)

Jim Uttaro

-----Original Message-----
From: Vinod Joseph [mailto:[email-masked]] 
Sent: Tuesday, June 07, 2011 11:12 AM
To: UTTARO, JAMES (ATTSI); Amit Khopkar; iLya
Cc: [email-masked]; Laurent Lavallee
Subject: RE: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5)

James,

Regards

Vinod Joseph

-----Original Message-----
From: UTTARO, JAMES (ATTSI) [mailto:[email-masked]] 
Sent: 07 June 2011 16:02
To: Amit Khopkar; iLya; Vinod Joseph
Cc: [email-masked]; Laurent Lavallee
Subject: RE: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5)

Why are RTs simpler?

Jim Uttaro

-----Original Message-----

Hi Ilya,

cheers
amit

-----Original Message-----
From: iLya [mailto:[email-masked]]
Sent: 07 June 2011 10:46
To: Vinod Joseph
Cc: [email-masked]; Amit Khopkar; Laurent Lavallee
Subject: Re: [Idr] more on

Cheers,
iLya

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 07 Jun 2011 18:24:48 +0200

Hi Amit,

> 3. there are two approaches to resolve this a. let the route
> reflector make a decision for every PE based on some criteria (IGP
> metric in your draft) b. take the RR out of the route selection
> process (one of the main reasons for existence of ADD-PATH) but in a
> scalable manner

Since Chintan is also apparently in the same assumption let me reiterate 
that base ORR IDR WG draft can use IGP metric or angular distance 
approximation techniques to select optimal paths.

Now if optimal for an operator means to use his other criteria the 
NH-SAFI draft Ilya and I wrote comes handy as "metric" which PE replies 
to RR is just a number. Yes it could be related to IGP view of PE to 
such next hop, but equally well it can be related to operator's local 
policy.

Such local policy needs to be configured and expressed somehow. Your 
draft recommends configuring RT to match what said ASBRs would use in 
route marking what clearly is more complex then allocating local value 
as local value does not require a correlation with any other network 
entity. That seems to be a difference you are not seeing.

The bottom line IDR WG draft + draft-varlashkin-bgp-nh-cost already 
address all possible scenarios which you may need by using your draft.

If there is something in your draft which the above set is missing and 
which by using the above two drafts could not be accomplished please 
clearly explain.

Many thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 07 Jun 2011 18:37:41 +0200

Hi Jim,

 > If
> you are using add-paths on the RRs you can send as many paths as you
> want and only apply policy on the ingress PE..

While we are a bit diverging from the main topic (new subject) I would 
be very interested in understanding your opinion on why would you 
recommend to perform send all followed by inbound drop for Internet 
prefixes to avoid storing information which is not necessary on PEs 
while in the same time you do recommend to use RT-Constraint or similar 
approaches to enforce send only what is required and avoid inbound drop 
for VPNv4/VPNv6 prefixes ?

Best regards,
R.

---

From: "UTTARO, JAMES (ATTSI)" <[email-masked]>
Date: Tue, 7 Jun 2011 13:03:42 -0400

Robert

I think there is a bit of a disconnect on use cases for add-paths. In my
mind add-paths is a surgical instrument akin to a scalpel that allows
for high value paths to be propagated through a topology. There are
various service enhancements/features ( Load Balancing, Fast
Convergence, Primary/Backup etc.. )  that could be monetized or act as a
differentiator.  With that in mind a small subset of paths are allowed
to propagate through the topology and each ingress PE would receive
multiple paths. This is no different than the use of a unique RD in a
VPNV4 in terms of learning multiple paths at a PE although one could
argue there are different routing contexts and the nature of a VPN would
mean less paths less paths.. Regardless I would never allow add-paths to
operate on the entire IPV4 routing domain it would never scale on RRs or
PEs.

Your comment "... inbound drop for Internet prefixes to avoid storing
information which is not necessary on PEs" is not correct.. In a Load
Balancing arrangement multiple paths would be used also having multiple
paths on a PE Primary/Backup would speed convergence considerably as the
ingress PE would only need to have the primary withdrawn part of the
with-drawl/advertisement cycle as the backup path is already on the
ingress and does not need to be re-advertised from the backup egress PE.

My thoughts on RT Constrain is that the base assumption is incorrect. RT
Constrain was envisioned as creating VPN distribution graphs that would
reduce the state in parts of the topology that did not require certain
VPN routing state. The thinking here is that it provided a method to
scale routing state.  RT Constrains "strength" is that it hides path
information from speakers that are not "interested" in it by virtue of a
VRF not being defined on a given PE.. But it is actually a weakness in
that it precludes the ability to provide high value services such as
stitching content between two VPNs.. Cloud, Content Based etc...
services that require "seeing" all of the routing state are examples. I
do believe RT Constrain is useful but only if there is also a mechanism
to force the distribution of routes regardless of whether or not a given
speaker "requires' it. Of course there are other issues i.e New AF needs
to be deployed, have to accommodate speakers that are legacy, NM needs
to be built to "know" what RT Constrain is doing is correct etc...

I do not understand why RT Constrain is being brought up in the context
of this conversation with Vinod. 

Jim Uttaro

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: Tuesday, June 07, 2011 12:38 PM
To: UTTARO, JAMES (ATTSI)
Cc: [email-masked]
Subject: Send only what is needed or send all then drop inbound ...

Hi Jim,

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 07 Jun 2011 19:15:42 +0200

Jim,

 > Balancing arrangement multiple paths would be used also having

Allow me to clarify ... when I specifically said "to avoid storing 
information which is not necessary on PEs" I meant the case where those 
paths would never be used by PE for example you have 30 paths in the 
network for a given destination and you at most like to load-balance to 
4 of them. Or just like you recommended paths could be defined as not 
necessary if it would be inbound drop as you have recommended.

 > I do not understand why RT Constrain is being brought up in the
 > context of this conversation with Vinod.

His entire draft uses RT-Constrain for filtering IPv4/IPv6 
unicast/multicast paths on a per RR client basis :)

Many thx,
R.

---

From: "UTTARO, JAMES (ATTSI)" <[email-masked]>
Date: Tue, 7 Jun 2011 13:18:52 -0400

Robert,

Comments In-Line

Jim Uttaro..

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: Tuesday, June 07, 2011 1:16 PM
To: UTTARO, JAMES (ATTSI)
Cc: [email-masked]
Subject: Re: [Idr] Send only what is needed or send all then drop
inbound ...

Jim,

Allow me to clarify ... when I specifically said "to avoid storing 
information which is not necessary on PEs" I meant the case where those 
paths would never be used by PE for example you have 30 paths in the 
network for a given destination and you at most like to load-balance to 
4 of them. Or just like you recommended paths could be defined as not 
necessary if it would be inbound drop as you have recommended.
[Jim U>] I would never send all thirty of the paths.. If four is needed
for Load balancing then I would configure add-paths with n=4.. I would
not allow add-paths to be deployed without constraining the number of
paths as I stated in my previous e-mail..

His entire draft uses RT-Constrain for filtering IPv4/IPv6 
unicast/multicast paths on a per RR client basis :)
[Jim U>] Yup I took a quick read and got it.

Many thx,
R.

> I do not understand why RT Constrain is being brought up in the
context

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 07 Jun 2011 19:34:09 +0200

Hi Jim,

 > [Jim U>] I would never send all thirty of the paths.. If four is
 > needed for Load balancing then I would configure add-paths with n=4..
 > I would not allow add-paths to be deployed without constraining the
 > number of paths as I stated in my previous e-mail..

Excellent.

So to clarify further what ORR IDR WG doc and what Vinod draft was 
trying to find an alternative solution for is the problem of which 4 out 
of available 30 paths you send to a client or group of clients. Note 
that from each RR client or group of RR clients the set of "optimal" 4 
paths may consists of a different set.

That is the problem statement.

It is completely orthogonal how you encode the subset of paths and 
naturally if you need to send more paths add-paths is the "transport" 
solution. It is also orthogonal on what paths are send eligible .. ie 
which add-path selection mode is chosen. The additional step comes after 
that.

Many thx,
R.

---

From: Vinod Joseph <[email-masked]>
Date: Tue, 7 Jun 2011 22:32:03 +0100

Robert,

There has been some amount of confusion in regard to BGP speakers will handle traffic in the event of prefixes not being available on ASBRs that match the RT interest from a PEs perspective. Let me clarify this here:

-> Let us assume that there are 10 ASBRs in a network with two RRs (RR1 and RR2) and each ASBR has an RT for its prefixes, and PE1 has expressed interest in two RTs - lets say "A" and "B"(two ASBRs). The RR would announce prefixes for these two ASBRs only to the PE, therefore in the event of prefixes not being available at these two ASBRs - traffic may be blackholed even though there are 8 other ASBRs available. The draft clearly mentions that each RR can be allotted an RR specific RT. So lets say RR1 has an RT of X and RR2 has Y. The PE1 can announce interest in RT "X" and RT "Y" in addition to "A" and "B". This is a common deployment where, RR1 and RR2 will both announce prefixes that match "A" and "B" plus the best path for all prefixes that it is aware of (Prefixes with RT extended communities and prefixes that may be announced without RT extended community). This will ensure that PE1 receives 2 additional paths from RR1 and RR2 which can be used as backup in the event of prefixes not being available from RT "A" and "B". This will ensure that traffic will never be black-holed at all (until viable paths exist).

-> Whether a network entity or local is a matter of how much administrative overhead vs. flexibility can be achieved. In the case of the NH draft, each PE needs to be configured with an administrative distance to each ASBR - if we need to achieve something similar to what can be achieved by using RTs. This can be complex, since we would end up calculating each pair (PE-ASBR) in addition to traffic flows needed to put in values. On the contrary use of RTs is nothing new for operators. Using appropriate RTs would be the only step involved in receiving ASBR paths. Addition of new paths, means - just adding another RT interest or removing it etc and does not involve re-engineering metrics. 

-> RT uses existing BGP machinery, therefore an operator does not need to worry about the support of a new capability. 

-> This solution proposes a scheme of announcing affinities, even in the case of ADD-PATH not being supported on PEs - which is an advantage. So a PE can just indicate an RT that matches an ASBR that is closest or administratively preferred and still get that path announced by the RR. In addition RR specific RTs (as mentioned above) can provide backup in the event of the preferred ASBR losing prefixes or going offline.

-> De-coupling the RR from path selection through intelligent requests through affinities can certainly reduce the overhead on the RR + the churn caused on the RR due to SPF runs.

-> It is the ease of adoption - since RT has been deployed for a while now which makes it simpler.

A updated version (01) of the draft elaborating some of these scenarios in large detail will be released shortly.

Regards

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

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: 07 June 2011 17:25
To: Amit Khopkar
Cc: iLya; Vinod Joseph; [email-masked]; Laurent Lavallee
Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection

Hi Amit,

Many thx,
R.

---

From: <[email-masked]>
Date: Wed, 8 Jun 2011 14:25:13 +0200

Hi Vinod,

Some comments your the draft, I followed quickly all the discussions on the subject on this mailing list but I have some questions more oriented on how your system is explained in your document.
I understand globally your idea, and I agree with Robert on the fact that your draft is not proposing an optimal route-reflection but more an "ingress preference-based" route-reflection. I understand your explanation about what is behind the word "optimal" but generally optimal is always shortest IGP :) otherwise this is more preference based routing.

To go more deeper in your text, in the §5.2, you are talking about "The objective here is to ensure that the "best path" based on the shortest IGP metric from each PE to an ASBR is announced by the RR.". I don't really agree on that, because your ingress router is able to choose the paths that will be given  to him by the RR using the RT mechanism. So it could , or could not be the shortest IGP metric path (the operator is choosing by himself). So If my understanding of your system is good, imo a rephrasing could be necessary to explain the exact goal/possibilities of your system. I agree that you can achieve hot potatoe routing with your system, but it is just a subcase of a more global approach.

Then you propose to use RT Constraint for IPv4 AFI/SAFI, as mentionned by Robert, today RTC is not done per AFI/SAFI, so you will have to deal with this and not interfer with current VPNs deployed (especially if you are mixing IPv4/VPNv4 on RRs), it's not blocking but operator must be aware of this when deploying your solution.
Moreover you are not using basic RTC like we do for VPNv4, because you need to modify the RR behavior to be able to compute "best path" per peer or per peer-group : this is not done today with current RTC. RTC in VPNv4 is working fine because of unicity of prefixes ensured by RD, but this is not the case for IPv4. You need to modify the way best path is computed. RTC, it's just putting an ORF ;) but without modifying best path computation, we are just filtering the RIB-OUT. We can guess this in your document, but imho this is not clearly explained. So what is your approach here :
	- 1) using ADD-PATH "export all" in addition to RTC, so all routes are putted in RIB-OUT then filtered towards PE by the RR based on the RT-ORF ?
	- 2) modify the best path mechanism, create a per peer/peer-group path eligible group (based on RTC infos), then do ADDPATH to export all paths or some paths inside this group ?
	- 3) Something else ?

Another point, RTC is a complex BGP machinery, new AFI/SAFI, new way to propagate this AFI/SAFI ... But here in fact you just need a point to point mechanism, why not using RT based ORF, or simply a BGP standard community based ORF ? If your ASBRs are marking routes using a special CT (normal 32bits community), PE can choose this ASBR by just signalling a CT based ORF to the RR (in combination with ADD-PATH) ?. So there is nothing new to implement (except CT based ORF, but ORF idea is globally already existing).
Then you have to take into account that your ingress router need to receive routes other than ASBR routes, so your mechanism must not prevent that. If you are using RTC, you will receive only routes matching your RT, potentially "internal" routes will not be received anymore if you don't marked them with an RT imported by all your routers.

Let me know your thought,

Best Regards,

Stephane

********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************

---

From: Vinod Joseph <[email-masked]>
Date: Wed, 8 Jun 2011 14:01:19 +0100

Hi Stephane,

Comments inline as Vinod#

Regards

Vinod Joseph

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 08 June 2011 13:25
To: Vinod Joseph
Cc: [email-masked]
Subject: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Hi Vinod,

Vinod# I am open to suggestions as you mentioned to changed the word "optimal" to something else - if that helps. Carriers do define optimal as being the closest IGP next-hop and this scheme does permit that to be achieved using preferences indicated via RT Constrain. As you mention, it moves one step further in permitting preference based routing (if you like). Do keep in mind that this proposal does use the IGP metric as the tie breaker in any case. For instance if a BGP speaker indicates a preference for RT:X, and if RT:X has 4 paths, which get advertised by the RR to the PE - Then the PE under normal conditions will choose the NH with the closest IGP metric anyways. 

Vinod# Yes. But Like I mentioned the tie breaker when multiple paths are announced to a PE is the shortest IGP metric. Therefore if the operator decides that he only wants a set of ASBRs chosen for traffic exit - the choice within those set of paths will always be the closest ASBR.

Vinod# There is another version of the draft clearly mentioning these scenarios in detail and I did mention this in email to Robert yesterday. There is no best path calculation when using RT constrain. The RR just picks the number of paths that match a given RT and advertise this to the PE. So there would be no advantage in exporting all paths to the RIB-OUT and then filtering prefixes/paths based on RT-ORF. The ideal approach would instead be to create a per peer-group based model where appropriate RT paths are only announced. The best path calculation is only performed when an RR specific RT is announced. I had emailed this yesterday, wherein a PE can signal an RT that is allocated to a given set of RR(s), and the RR(s) just announce the best path for all prefixes ir-respective of whether an RT is attached or not. 

Vinod# Standard communities are already used for various purposes such as filtering which customer routes get installed where and so on.... and we did not want to dilute this by using standard communities for another whole new purpose. The intent of this proposal is to leverage existing machinery - RT and RT constrain exists in all code and deployments. We ensure that the PE router will receive all routes other than routes matching the RT, and this is done by allotting an RT per RR as I mentioned in my previous emails. Each PE just needs to signal these RR specific RTs or an RR specific RT to get the best path for all other prefixes other than the interested RT alone. Therefore there never be a situation where a PE will be starved of routing information if ASBRs that match the RTs signalled via RTC lose visibility to any prefixes.

Keep in mind that this proposal can work with existing machinery as well i.e. if ADD-PATH is yet to be supported on PEs. In the event of PEs not supporting ADD-PATH, the RR would only send a single path per RT that gets signalled. 

Best Regards,

Stephane

---

From: <[email-masked]>
Date: Wed, 8 Jun 2011 15:33:00 +0200

Thanks for the feedback.

Regarding RTC behavior, I don't agree of your interpretation of the way it works, you said : "There is no best path calculation when using RT constrain. The RR just picks the number of paths that match a given RT and advertise this to the PE."
Maybe I'm wrong, but I hope Robert will correct us as he is one of people who defined RTC :)
For me, RTC doesn't change anything to the way BGP is globally working. RTC was designed to work for VPNs (first IPv4 but now it can be used for all VPN types). RTC is just a way to signal an interrest for a BGP speaker for a specific set of VPN prefixes matching some RTs (with end to end possibility to propagate it). This signalling will lead for the peer who received the RT NLRI to install a per peer ORF. And imo that's all.
So if you take this case (VPN) :

PE1 imports RT1 in VRF1 and peers with RR1 (enabling RTC between them)
PE1 signals his interrest for RT1 using RT AFI/SAFI to RR1.

RR1 owns VPN routes and has the followings :
	RD1:X/Y label z
		Path 1	-> NH1 (IGP cost 10), LP100, ASPATH empty, RT1
		Path 2	-> NH2 (IGP cost 5), LP100, ASPATH empty, RT2

	RD2:A/B label C
		Path 1	-> NH1 (IGP cost 10), LP100, ASPATH empty, RT1
		
	RD3:A/B label D
		Path 2	-> NH2 (IGP cost 5), LP100, ASPATH empty, RT1

RR1 still compute best path per VPN prefix (in your case it will be IPv4 but it doesn't really matter).
	RD1:X/Y label z -> Path2 is best
	RD2:A/B label C -> Path1
	RD3:A/B label D -> Path2
Then RR1 will advertise these best path to the peers, especially PE1, but it has an ORF for PE1 which match only RT1, so only RD2:A/B and RD3:A/B will be sent, RD1:X/Y will not because it doesn't have the community.

What I mean by this, is that if you consider your case (IPv4), you will have this :

PE1 is interrested by ASBR1 and ASBR2 routes, ASBR1 routes marked with RT1 and ASBR2 marked with RT2.
PE1 will signal his interrested for RT1 and RT2.

RR1 owns all IPv4 path from ASBRs, if we consider only one prefix X/Y received from all the ASBRs, we have this :
	X/Y
		Path 1	-> NH=ASBR1 (IGP cost a), LP 100, ASPATH a, RT1
		Path 2	-> NH=ASBR2 (IGP cost b), LP 100, ASPATH b, RT2
		Path 3	-> NH=ASBR3 (IGP cost c), LP 100, ASPATH c, RT3
		...
		Path x	-> NH=ASBRx (IGP cost x), LP 100, ASPATH x, RTx

RR1 receives PE1 RT-NLRI and installs ORF for RT1/RT2 on the PE1 peer.
RR1 selects best path for all prefixes, and so for X/Y, it will choose one path, the best for him, based on his own criteria. So if it selects for example Path3 as best, no path will be exported to PE1 :(

All, pls correct me if I'm wrong.

Thanks,

-----Message d'origine-----
De : Vinod Joseph [mailto:[email-masked]] 
Envoyé : mercredi 8 juin 2011 15:01
À : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]; [email-masked]; Amit Khopkar; [email-masked]; Thareja, Gaurav
Objet : RE: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Hi Stephane,

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]]
Sent: 08 June 2011 13:25
To: Vinod Joseph
Cc: [email-masked]
Subject: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Hi Vinod,

Best Regards,

Stephane

********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above.

---

From: Vinod Joseph <[email-masked]>
Date: Wed, 8 Jun 2011 14:37:35 +0100

Inline - 

Regards

Vinod Joseph

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 08 June 2011 14:33
To: Vinod Joseph; [email-masked]
Cc: [email-masked]; [email-masked]; Amit Khopkar; [email-masked]; Thareja, Gaurav
Subject: RE: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Thanks for the feedback.

	RD2:A/B label C
		
	RD3:A/B label D

Vinod# So what are proposing is: Use ADD-PATH for announcing not just the best path but all paths that match a given RT. So in your example, RR1 will not do a best path calc, and instead advertise Path1 and Path2 which match RT1 and RT2. Otherwise we are not adding any value here :-)

Thanks,

-----Message d'origine-----
De : Vinod Joseph [mailto:[email-masked]] 
Envoyé : mercredi 8 juin 2011 15:01
À : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]; [email-masked]; Amit Khopkar; [email-masked]; Thareja, Gaurav
Objet : RE: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Hi Stephane,

Regards

Vinod Joseph

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 08 June 2011 13:25
To: Vinod Joseph
Cc: [email-masked]
Subject: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Hi Vinod,

Best Regards,

Stephane

---

From: <[email-masked]>
Date: Wed, 8 Jun 2011 16:05:21 +0200

Yes for me you have to use ADD path in addition to RTC to make it working or change the BGP best path computation.
But you are mentionning : "use ADD-PATH for announcing not just the best path but all paths that match a given RT"
It is imo possible to do it, ADD PATH is just a transport mechanism but doesn't presume on how path are selected.
But today, the way you need is not described in draft-uttaro-idr-add-paths-guidelines (export n paths matching some attributes), so an update might be needed ...

Best Regards,

Stephane

-----Message d'origine-----
De : Vinod Joseph [mailto:[email-masked]] 
Envoyé : mercredi 8 juin 2011 15:38
À : LITKOWSKI Stephane DTF/DERX; [email-masked]
Cc : [email-masked]; [email-masked]; Amit Khopkar; [email-masked]; Thareja, Gaurav
Objet : RE: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Inline - 

Regards

Vinod Joseph

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 08 June 2011 14:33
To: Vinod Joseph; [email-masked]
Cc: [email-masked]; [email-masked]; Amit Khopkar; [email-masked]; Thareja, Gaurav
Subject: RE: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Thanks for the feedback.

Regarding RTC behavior, I don't agree of your interpretation of the way it works, you said : "There is no best path calculation when using RT constrain. The RR just picks the number of paths that match a given RT and advertise this to the PE."
Maybe I'm wrong, but I hope Robert will correct us as he is one of people who defined RTC :) For me, RTC doesn't change anything to the way BGP is globally working. RTC was designed to work for VPNs (first IPv4 but now it can be used for all VPN types). RTC is just a way to signal an interrest for a BGP speaker for a specific set of VPN prefixes matching some RTs (with end to end possibility to propagate it). This signalling will lead for the peer who received the RT NLRI to install a per peer ORF. And imo that's all.
So if you take this case (VPN) :

	RD2:A/B label C
		
	RD3:A/B label D

Thanks,

-----Message d'origine-----
De : Vinod Joseph [mailto:[email-masked]] Envoyé : mercredi 8 juin 2011 15:01 À : LITKOWSKI Stephane DTF/DERX Cc : [email-masked]; [email-masked]; Amit Khopkar; [email-masked]; Thareja, Gaurav Objet : RE: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Hi Stephane,

Regards

Vinod Joseph

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 08 June 2011 13:25
To: Vinod Joseph
Cc: [email-masked]
Subject: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Hi Vinod,

Best Regards,

Stephane

---

From: Vinod Joseph <[email-masked]>
Date: Wed, 8 Jun 2011 15:06:58 +0100

Yes, version 0.1 of this draft will have more detail case studies taking in the feedback that has been received from all on the list.

Stay tuned for the next version shortly.

Regards

Vinod Joseph

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 08 June 2011 15:05
To: Vinod Joseph; [email-masked]
Cc: [email-masked]; [email-masked]; Amit Khopkar; [email-masked]; Thareja, Gaurav
Subject: RE: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Best Regards,

Stephane

-----Message d'origine-----
De : Vinod Joseph [mailto:[email-masked]] 
Envoyé : mercredi 8 juin 2011 15:38
À : LITKOWSKI Stephane DTF/DERX; [email-masked]
Cc : [email-masked]; [email-masked]; Amit Khopkar; [email-masked]; Thareja, Gaurav
Objet : RE: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Inline - 

Regards

Vinod Joseph

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 08 June 2011 14:33
To: Vinod Joseph; [email-masked]
Cc: [email-masked]; [email-masked]; Amit Khopkar; [email-masked]; Thareja, Gaurav
Subject: RE: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Thanks for the feedback.

	RD2:A/B label C
		
	RD3:A/B label D

Thanks,

-----Message d'origine-----

Hi Stephane,

Regards

Vinod Joseph

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 08 June 2011 13:25
To: Vinod Joseph
Cc: [email-masked]
Subject: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Hi Vinod,

Best Regards,

Stephane

---

From: Vinod Joseph <[email-masked]>
Date: Wed, 8 Jun 2011 15:13:25 +0100

Stephane,

Changing BGP path computation is something we do not propose or prefer, having the RR doing a whole lot of work on running SPF instances in a large scale deployment just does not scale. It simply defies logic, having an RR to stay tuned to each and every IGP change in a network with 100/1000's of PEs, and re-run best-path calculation and re-advertise a new exit for hot potato routing - seems very interesting indeed. From trying to solve a problem, this would only introduce a new set of problems for an operator to handle :-). 

Regards

Vinod Joseph

-----Original Message-----
From: Vinod Joseph 
Sent: 08 June 2011 15:07
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Amit Khopkar; [email-masked]; Thareja, Gaurav
Subject: RE: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Regards

Vinod Joseph

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 08 June 2011 15:05
To: Vinod Joseph; [email-masked]
Cc: [email-masked]; [email-masked]; Amit Khopkar; [email-masked]; Thareja, Gaurav
Subject: RE: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Best Regards,

Stephane

-----Message d'origine-----
De : Vinod Joseph [mailto:[email-masked]] 
Envoyé : mercredi 8 juin 2011 15:38
À : LITKOWSKI Stephane DTF/DERX; [email-masked]
Cc : [email-masked]; [email-masked]; Amit Khopkar; [email-masked]; Thareja, Gaurav
Objet : RE: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Inline - 

Regards

Vinod Joseph

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 08 June 2011 14:33
To: Vinod Joseph; [email-masked]
Cc: [email-masked]; [email-masked]; Amit Khopkar; [email-masked]; Thareja, Gaurav
Subject: RE: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Thanks for the feedback.

	RD2:A/B label C
		
	RD3:A/B label D

Thanks,

-----Message d'origine-----

Hi Stephane,

Regards

Vinod Joseph

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 08 June 2011 13:25
To: Vinod Joseph
Cc: [email-masked]
Subject: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Hi Vinod,

Best Regards,

Stephane

---

From: Jakob Heitz <[email-masked]>
Date: Sun, 12 Jun 2011 12:43:11 -0400

Has this been answered?

--
Jakob Heitz.

---

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

Yes it has been Jacob.

The proposal uses ADD-PATH in combination with RTC - Therefore if a PE signals interest in a given RT (ASBRs), the RR will use ADD-PATH in order to make sure that NO best path calculation is used to tie-break between multiple paths within the same RT and in effect announce all or "N" paths (that can be configured on a per Peer/Peer-Group) basis to the PE.

Let me also re-iterate that a BGP speaker does not need to have a "RT" configured, if it does not intend to add an extended community to any of its announced prefixes, but will have the ability to use RT constrain to indicate a list of RTs it is interested in. In other words, only ASBRs may have Route Targets configured, and all PE may just use RTC to indicate preferences in a list of given ASBRs. 

Regards

Vinod Joseph

-----Original Message-----
From: Jakob Heitz [mailto:[email-masked]] 
Sent: 12 June 2011 17:43
To: [email-masked]
Cc: Vinod Joseph; [email-masked]; [email-masked]; Thareja, Gaurav; Amit Khopkar; [email-masked]; [email-masked]
Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection

Has this been answered?

--
Jakob Heitz.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 12 Jun 2011 20:44:16 +0200

Hi Vinod,

Bruno interpretation is correct your is I am afraid wrong even to your 
own implementation of RTC.

RTC does not modify best path calculation. For VPN in the even there 
would be overlapping VPNv4 nets different RD per VRF solves the problem 
of different path with different RT being selected as overall best and 
dropped by RTC. Perhaps operators may speak if they are using different 
RDs in case there would be two different VPNv4 paths for the same net or 
not today with RTC.

When you explained how draft-vinod is to work I assumed and took as 
obvious that you are calling for modification to how RTC works today for 
AFI/SAFIs draft-vinod would be applicable for.

Someone asked if you are going to issue a new RTC spec to address this, 
but that AFAIK was never answered.

 > Let me also re-iterate that a BGP speaker does not need to have a
 > "RT" configured, if it does not intend to add an extended community
 > to any of its announced prefixes, but will have the ability to use RT
 > constrain to indicate a list of RTs it is interested in.

You contradicting yourself. In order to use RTC for signaling on the 
interested set of RTs those I am afraid need to be configured.

 > words, only ASBRs may have Route Targets configured, and all PE may
 > just use RTC to indicate preferences in a list of given ASBRs.

RTC is not a cristal ball. When we wrote it we were thinking about 
adding some magic to it, but since it would even further delay review 
and release of the spec we concluded that we will leave it for later 
time ;-). Perhaps the time is now !

Cheers,
R.

> Yes it has been Jacob.
>
> The proposal uses ADD-PATH in combination with RTC - Therefore if a
> PE signals interest in a given RT (ASBRs), the RR will use ADD-PATH
> in order to make sure that NO best path calculation is used to
> tie-break between multiple paths within the same RT and in effect
> announce all or "N" paths (that can be configured on a per
> Peer/Peer-Group) basis to the PE.
>
> Let me also re-iterate that a BGP speaker does not need to have a
> "RT" configured, if it does not intend to add an extended community
> to any of its announced prefixes, but will have the ability to use RT
> constrain to indicate a list of RTs it is interested in. In other
> words, only ASBRs may have Route Targets configured, and all PE may
> just use RTC to indicate preferences in a list of given ASBRs.
>
> Regards
>
> -----Original Message----- From: Jakob Heitz
> [mailto:[email-masked]] Sent: 12 June 2011 17:43 To:
> [email-masked] Cc: Vinod Joseph;
> [email-masked]; [email-masked]; Thareja, Gaurav; Amit Khopkar;
> [email-masked]; [email-masked] Subject: Re:
> [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection
>
> Has this been answered?
>
> -- Jakob Heitz.
>
>
> On Jun 8, 2011, at 6:33 AM,
> "[email-masked]"<[email-masked]>
> wrote:
>
>> Thanks for the feedback.
>>
>> Regarding RTC behavior, I don't agree of your interpretation of the
>> way it works, you said : "There is no best path calculation when
>> using RT constrain. The RR just picks the number of paths that
>> match a given RT and advertise this to the PE." Maybe I'm wrong,
>> but I hope Robert will correct us as he is one of people who
>> defined RTC :) For me, RTC doesn't change anything to the way BGP
>> is globally working. RTC was designed to work for VPNs (first IPv4
>> but now it can be used for all VPN types). RTC is just a way to
>> signal an interrest for a BGP speaker for a specific set of VPN
>> prefixes matching some RTs (with end to end possibility to
>> propagate it). This signalling will lead for the peer who received
>> the RT NLRI to install a per peer ORF. And imo that's all. So if
>> you take this case (VPN) :
>>
>> PE1 imports RT1 in VRF1 and peers with RR1 (enabling RTC between
>> them) PE1 signals his interrest for RT1 using RT AFI/SAFI to RR1.
>>
>> RR1 owns VPN routes and has the followings : RD1:X/Y label z Path 1
>> ->  NH1 (IGP cost 10), LP100, ASPATH empty, RT1 Path 2  ->  NH2
>> (IGP cost 5), LP100, ASPATH empty, RT2
>>
>> RD2:A/B label C Path 1  ->  NH1 (IGP cost 10), LP100, ASPATH empty,
>> RT1
>>
>> RD3:A/B label D Path 2  ->  NH2 (IGP cost 5), LP100, ASPATH empty,
>> RT1
>>
>> RR1 still compute best path per VPN prefix (in your case it will be
>> IPv4 but it doesn't really matter). RD1:X/Y label z ->  Path2 is
>> best RD2:A/B label C ->  Path1 RD3:A/B label D ->  Path2 Then RR1
>> will advertise these best path to the peers, especially PE1, but it
>> has an ORF for PE1 which match only RT1, so only RD2:A/B and
>> RD3:A/B will be sent, RD1:X/Y will not because it doesn't have the
>> community.
>>
>>
>> PE1 is interrested by ASBR1 and ASBR2 routes, ASBR1 routes marked
>> with RT1 and ASBR2 marked with RT2. PE1 will signal his interrested
>> for RT1 and RT2.
>>
>> RR1 owns all IPv4 path from ASBRs, if we consider only one prefix
>> X/Y received from all the ASBRs, we have this : X/Y Path 1  ->
>> NH=ASBR1 (IGP cost a), LP 100, ASPATH a, RT1 Path 2  ->  NH=ASBR2
>> (IGP cost b), LP 100, ASPATH b, RT2 Path 3  ->  NH=ASBR3 (IGP cost
>> c), LP 100, ASPATH c, RT3 ... Path x  ->  NH=ASBRx (IGP cost x), LP
>> 100, ASPATH x, RTx
>>
>> RR1 receives PE1 RT-NLRI and installs ORF for RT1/RT2 on the PE1
>> peer. RR1 selects best path for all prefixes, and so for X/Y, it
>> will choose one path, the best for him, based on his own criteria.
>> So if it selects for example Path3 as best, no path will be
>> exported to PE1 :(
>>

---

From: Vinod Joseph <[email-masked]>
Date: Sun, 12 Jun 2011 19:49:14 +0100

Yes that's correct, we are calling for modification to the present RTC implementation. This was answered since when we were speaking about the RR specific RT, which can be signalled via RTC - In this case, the RR is to only announce the best path for a given prefix and this different to the present behaviour of RTC and will need to be modified.

Yes that is correct. 

Regards

Vinod Joseph

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: 12 June 2011 19:44
To: Vinod Joseph
Cc: Jakob Heitz; [email-masked]; [email-masked]; Thareja, Gaurav; Amit Khopkar; [email-masked]; [email-masked]
Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection

Hi Vinod,

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 12 Jun 2011 20:56:58 +0200

Vinod,

That puts an interesting challenge to AF independent code which in most 
BGP implementations is BGP best path calculation. Moreover as each peer 
by design will signal different set of RTs you are essentially proposing 
a best path per peer. If I recall correctly even your add-path can not 
provide today different selection criteria on set of eligible paths for 
groups of peers.

For one AF this should work very differently then for the other. Also it 
should work differently on RR then on ASBR.

With this in mind I think we need to first wait to evaluate the new RTC 
draft then if that passes any further then IETF submission front end we 
could come back to discuss draft-vinod in it's -00 or -01 versions.

Rgs,
R.

---

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

> Let me also re-iterate that a BGP speaker does not need to have a  > "RT" configured, if it does not intend to add an extended community  > to any of its announced prefixes, but will have the ability to use RT  > constrain to indicate a list of RTs it is interested in.

You contradicting yourself. In order to use RTC for signaling on the interested set of RTs those I am afraid need to be configured.

Vinod# The proposed draft intends to permit the use of RT signalling via RTC without the need for those specific RTs to be configured in every BGP speaker. So yes RTC will be modified and can be used as a vehicle for only signalling affinities or preferences in terms of RTs, also keep in mind we are  specifying the need for the RR to have the ability to look at RTC prefixes announced by PEs and announce "ALL" or "N" number of paths using ADD-PATH.

Stay tuned for the next version.

Regards

Vinod Joseph

-----Original Message-----
From: Vinod Joseph 
Sent: 12 June 2011 19:49
To: [email-masked]'
Cc: Jakob Heitz; [email-masked]; [email-masked]; Thareja, Gaurav; Amit Khopkar; [email-masked]; [email-masked]
Subject: RE: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection

Yes that is correct. 

Regards

Vinod Joseph

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: 12 June 2011 19:44
To: Vinod Joseph
Cc: Jakob Heitz; [email-masked]; [email-masked]; Thareja, Gaurav; Amit Khopkar; [email-masked]; [email-masked]
Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection

Hi Vinod,

Cheers,
R.

---

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

Robert,

Let me make this clear. The draft clearly specifies the need for modification to RTC, since the RR is supposed to signal the best path - ONLY in the case when a PE signal an RT that is RR specific. In other words the PE wants a set of routes through RTs that it is interested in, and the RR DOES NOT do any best path computation here and announces paths via ADD-PATH as a vehicle. This has relevance only to IPV4 and IPV6.

The changes to the original RTC specification will be clearly addressed in version 0.1. I do not want to get into a debate with you on whether we should be having 2 drafts etc. 

Version 0.1 will be submitted based on the feedback and views of the many operators on this list.

Thanks for your valuable comments as always ;-)

Regards

Vinod Joseph

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: 12 June 2011 19:57
To: Vinod Joseph
Cc: Jakob Heitz; [email-masked]; [email-masked]; Thareja, Gaurav; Amit Khopkar; [email-masked]; [email-masked]
Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection

Vinod,

Rgs,
R.

---

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

Vinod,

> Vinod# The proposed draft intends to permit the use of RT signalling
> via RTC without the need for those specific RTs to be configured in
> every BGP speaker.

If RTC capability is exchanged and no RT is signaled default behaviour 
is not to send any routes towards such PE.

Keep that in mind in your next version.

> "ALL" or "N" number of paths using ADD-PATH.

Are you also going to extend add-path spec to carry how many prefixes is 
required for given policy based exit PE ? If not how would the RR know 
how many paths to send to a given PE ?

R.

---

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

> many operators on this list.

Could you summarize those inputs from many operators on this list ?

Many thx,
R.

---

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

Version 0.1 shortly!

Regards

Vinod Joseph

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: 12 June 2011 20:09
To: Vinod Joseph
Cc: Jakob Heitz; [email-masked]; [email-masked]; Thareja, Gaurav; Amit Khopkar; [email-masked]; [email-masked]
Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection

Many thx,
R.

---

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

Robert,

I think I understand that very well, but thanks for the tip :-). The proposal takes care of that.

Regards

Vinod Joseph

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: 12 June 2011 20:05
To: Vinod Joseph
Cc: Jakob Heitz; [email-masked]; [email-masked]; Thareja, Gaurav; Amit Khopkar; [email-masked]; [email-masked]
Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection

Vinod,

R.

---

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

Vinod,

> The changes to the original RTC specification will be clearly
> addressed in version 0.1. I do not want to get into a debate with you
> on whether we should be having 2 drafts etc.

Consider it please as a formal input that I do not agree to modify base 
behavior and design principles of RFC4684 by any other document then a 
separate spec dedicated to it.

Thx,
R.

---

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

Any input on the list from everyone is considered as formal input Robert, so there is no exception to that.

Be rest assured.

Regards

Vinod Joseph

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: 12 June 2011 20:35
To: Vinod Joseph
Cc: Jakob Heitz; [email-masked]; [email-masked]; Thareja, Gaurav; Amit Khopkar; [email-masked]; [email-masked]
Subject: Re: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Vinod,

Thx,
R.

---

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

That puts an interesting challenge to AF independent code which in most 
BGP implementations is BGP best path calculation. 

Vinod: Interesting. Is'nt your ORR draft modifying the BGP best path calculation? And for IPv4 and possibly IPv6 on the RR?? Keen to understand this, since we are now speaking from a vendors implementation perspective.

Vinod: On the RR yes, Best path only for if PE signals an RT that is allocated to the RR - Where we want to only have the best path announced and NOT in other cases.

Regards

Vinod Joseph

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: 12 June 2011 20:35
To: Vinod Joseph
Cc: Jakob Heitz; [email-masked]; [email-masked]; Thareja, Gaurav; Amit Khopkar; [email-masked]; [email-masked]
Subject: Re: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection

Vinod,

Thx,
R.

---

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

Vinod,

Let me clarify as you did not get it.

As co-author of RFC4684 I would like to clearly state that I do not
agree to modify base behavior and design principles of RFC4684 by any
other document then a separate spec dedicated to it.

Best regards,
R.

> Any input on the list from everyone is considered as formal input
> Robert, so there is no exception to that.
>
> Be rest assured.
 >
> Regards Vinod Joseph Professional Services - Service
> Provider Europe Juniper Networks

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 12 Jun 2011 22:07:52 +0200

Vinod,

> That puts an interesting challenge to AF independent code which in
> most BGP implementations is BGP best path calculation.
>
> Vinod: Interesting. Is'nt your ORR draft modifying the BGP best path
> calculation? And for IPv4 and possibly IPv6 on the RR?? Keen to
> understand this, since we are now speaking from a vendors
> implementation perspective.

It does not need to if you implement it right. Sorry for being dense but 
I hope you will understand that.

However IDR WG ORR spec does not impact or changes an existing behavior 
of any other BGP extension. That is a significant difference.

r.

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 13 Jun 2011 00:50:43 -0400

Before you do that, I'd like to hear from some of the
less vocal operators. What are your pain points?
What is difficult or impossible to do?

I have seen 2 requirements so far:
1. For a PE to prefer routes from a given set of ASBR's.
2. For premium customers to prefer routes from a given set of ASBR's.

For calrification: How is a premium customer identified?
Is it one that owns a particular IP address?
Is it one that connects to a particular interface on the PE?
Something else?

--
Jakob Heitz.

> Sent: Sunday, June 12, 2011 12:04 PM
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 13 Jun 2011 08:42:08 +0200

Hi Jakob,

In fact I have a better question ... how is the "premium" ASBR 
identified ? What determines that premium today will be premium tomorrow ?

How do you map Internet topology changes to the static selection
of "premium" exit point from any network.

And of course I will not take "operator's policy" as an answer ;).

Can anyone guarantee that even if I have painted gold ASBR with 10 GB 
pipe to best tier one of the world all Internet reachability there will 
be always better then what would 10 silver painted ASBRs give me from 
mix of paths received from various tier 1's or tier 2's ?

Different products exist today from multiple vendors to address such 
task on a destination prefix granularity, but non of them is based on a 
static mapping to any ASBR.

Rgs,
R.

---

From: Vinod Joseph <[email-masked]>
Date: Mon, 13 Jun 2011 21:20:28 +0100

Robert,

I just had a relook of your email and I think we are talking about two different things.

I meant to say that the BGP speaker need not have its prefixes tagged with a specific RT for those RTs to be signalled via RT Constrain. This does not mean, that the RTC will not carry any RT, neither does this mean any modification to RTC behaviour - in this context. 

Check Section 5.7 of the Draft. The draft makes it clear(for completeness) that tagging the prefixes with an RT, vs. indicating preferences via RT constrain are two separate things. So ASBR is configured with its prefixes tagged using specific RTs, and PEs would signal interest via RTC. If certain circumstances demand that, the PE needs to tag specific RTs to prefixes - to influence the traffic flows, then it can do it as well.

Regards

Vinod Joseph

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: 12 June 2011 20:05
To: Vinod Joseph
Cc: Jakob Heitz; [email-masked]; [email-masked]; Thareja, Gaurav; Amit Khopkar; [email-masked]; [email-masked]
Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection

Vinod,

R.