Subject: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing)

From: <[email-masked]>
Date: Wed, 8 Jun 2011 19:09:54 +0200

Vinod,

"draft-vinod-lavallee-bgp-optimal-route-reflection-00

Abstract

   This document describes procedures on providing optimal routing for
   IPv4 Internet traffic based on the shortest IGP metric."

I would argue that currently the above draft does not provide optimal
routing based on the shortest IGP metric, but rather based on Service
Provider policy. I think the difference is important, especially when
there is another draft on that matter. Could you please reflect this in
the draft? And in the name of the draft?

If the requirement is to perform optimal route reflection based on IGP
metric, the data required for the computation comes from the IGP. I
don't see how asking the Service Provider to configure (an ersatz of)
this data again (through the configuration of RT communities & RTC
routes) could be any better (simpler/more accurate/less expensive...).

In the benefit of advancing on this subject, I believe we could agree on
the above 2 points and close that part of the discussion. Hopefully that
should clarify the relations between this draft and
draft-ietf-idr-bgp-optimal-route-reflection-00.

Now if your draft if about configuring policy based routing, IMO it
would be interesting to discuss the following points: what data need to
be configured, where does it need to be configured (e.g. PE vs RR), how
hard is it for the SP to "compute" that data; why and how to propagate
policy data between routers in the AS...

Thanks,
Regards,
Bruno

---

From: Vinod Joseph <[email-masked]>
Date: Wed, 8 Jun 2011 18:23:56 +0100

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 18:10
To: Vinod Joseph
Cc: [email-masked]
Subject: draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing)

Vinod,

Abstract

Vinod# Agreed, and this will reflect in the next version as mentioned yesterday- since the proposal is not merely about facilitating paths that have the shortest IGP metric only!!

Vinod# So, this is about providing preferential path selection in short. 

Vinod# Policy driven path selection is configured on the PEs/ASBRs (BGP speakers) using Route Targets (configured) and RT Constrain. The RR responds with a list of paths that match the RTs indicated - it could be a list, range or the default RT. The RR computes this information and advertises needed information to BGP speakers. There is no propagation needed between individual BGP speakers in the network, and is only needed between BGP Speakers to RR.

PS: In my earlier email I had indicated that we are open to suggestions - if the name needs to reflect something else.

Thanks,
Regards,
Bruno

---

From: Vinod Joseph <[email-masked]>
Date: Thu, 9 Jun 2011 00:22:21 +0100

Bruno, 

So addressing your question on the title of the draft, I hope we have clearly communicated that the proposed draft addresses a set of given requirements, and the next version will incorporate the proposed suggestions and reflect a title which is of consensus to all members.

Regards

Vinod Joseph

-----Original Message-----
From: Vinod Joseph 
Sent: 08 June 2011 18:24
To: [email-masked]
Cc: [email-masked]
Subject: RE: draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing)

Regards

Vinod Joseph

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 08 June 2011 18:10
To: Vinod Joseph
Cc: [email-masked]
Subject: draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing)

Vinod,

Abstract

Thanks,
Regards,
Bruno

---

From: <[email-masked]>
Date: Thu, 9 Jun 2011 10:00:45 +0200

Vinod,

>Vinod# Agreed, and this will reflect in the next version as mentioned yesterday

Ok, thanks.

> - since the proposal is not merely about facilitating paths that have the shortest IGP metric only!!

Hum...
My point was that the draft addresses a requirement for policy / TE routing. _Not_ for shortest IGP metric routing.  You're rephrasing by saying that the draft more or less addresses both points. So I'm not sure how much we are in sync.

>Vinod# So, this is about providing preferential path selection in short.

"Prefered" based on what criteria? SP policy IMO, not IGP cost.

>Vinod# Policy driven path selection is configured on the PEs/ASBRs (BGP speakers) using Route Targets
>(configured) and RT Constrain. The RR responds with a list of paths that match the RTs indicated - it
>could be a list, range or the default RT. The RR computes this information and advertises needed
>information to BGP speakers. There is no propagation needed between individual BGP speakers in the
>network, and is only needed between BGP Speakers to RR.

Thanks for summarizing you solution.
My intended question was more about the general problem that need to be solved and why you picked that specific (RTC based) solution rather than another one.
e.g.:
- why is the criteria for filtering configured on the PE received the routes, rather than the RR sending the routes? There are probably some advantages but the cost is to require an additional protocol to communicate those criteria to the RR (that protocol being RTC in you case). As already expressed on the list, you could define a BGP policy directly on the RR.
- on the PE sending the routes, why do you use RT extended communities rather than a regular communities. There may be little difference in a Greenfield scenario but in a existing network where SP use regular communities, this requires updating the configuration of all PE, all BGP peering policies to add an RT community in addition to the existing community. This may have a benefit but it would be usefull to elaborate on this benefit otherwise people will have more difficulties adopting your idea.
- why do you think RTC is the best fit for you application? RTC has been specifically designed for the VPN application. I see significant differences in applicability:
	- in VPN, PE receiving routes are already configured with import RT policies. This is required to import routes in the relevant VRF. So for filtering BGP routes on the RR, it makes sense to re-use that already configured information. Even if this requires adding a new "protocol" to it from the PE to the RR. This is not the case in your application.
	- in VPN, PE sending routes are already configured with a specific export policies setting RT on routes. This is not the case in your application as typically SP uses no RT communities.

	- So in short, in a VPN context, RTC make use of existing configuration data. In the IPv4 context, such RT information is not configured and you require the SP to configure it. IMO this is a significant difference for the SP point of view. 

>PS: In my earlier email I had indicated that we are open to suggestions - if the name needs to reflect

Yes IMO the name needs to reflect something else. E.g. Application of RTC to the distribution of BGP routing TE policies in IP networks. 

--
On a more detailed / technical level, could you also please clarify if your document propose to _use_ RFC 4684 (RTC) or _modify/extend_ it? 
§ 5.3 says "It is to be noted that the "Default RT" indicates that all prefixes/ paths even without a corresponding RT will be considered as candidates for announcements."
According to my own reading of RFC 4684, the default RTC route matches all RT communities. It would not allow requesting routes which have not RT community attached to them. Agreed RFC 4684 is not that specific on this as it says "receive all VPN route " but IMO this is because it assumes that all VPN routes have at least one RT attached on it.

Thanks,
Regards,
Bruno

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 09 Jun 2011 10:38:53 +0200

Hello,

While we are at the RTC topic ...

I see even bigger issue with them defining "special RT" applied at RRs 
to mean send me overall best if my requested RTs are not available.

That was used as the explanation on how their proposal will address the 
issue when non of preferred paths are available yet other non preferred 
paths could be used.

That is more like conditional advertisement feature and I don't think we 
have ever intended to combine it with RTC.

Thx,
R.

--
On a more detailed / technical level, could you also please clarify if 
your document propose to _use_ RFC 4684 (RTC) or _modify/extend_ it?
§ 5.3 says "It is to be noted that the "Default RT" indicates that all 
prefixes/ paths even without a corresponding RT will be considered as 
candidates for announcements."
According to my own reading of RFC 4684, the default RTC route matches 
all RT communities. It would not allow requesting routes which have not 
RT community attached to them. Agreed RFC 4684 is not that specific on 
this as it says "receive all VPN route " but IMO this is because it 
assumes that all VPN routes have at least one RT attached on it.

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 09 Jun 2011 12:59:41 +0200

Dear authors and co-authors of 
draft-vinod-lavallee-bgp-optimal-route-reflection,

1. I would like to ask you to clearly provide set of requirements from 
the point of view of PE in the point by point list your draft is 
attempting to solve and which must be met by any proposed solution.

2. I would like to ask to clearly state that the solution is applicable 
_only_ to full end to end MPLS LSP networks. In the event of network 
selecting to use TE-LSPs as it's forwarding plane I would like to see 
detailed reference to inter-area stitching solution deployed on the ABRs 
which avoids need for IP lookup. That description should clearly address 
IPv4 unicast, IPv4 multicast, IPv6 unicast and IPv6 multicast address 
families.

3. To put scale arguments in perspective please also indicate the scale 
ranges required to be possible for the solution. Number of PEs, number 
of required paths per PE for a given net and number of available ASBRs 
in the given autonomous system.

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 11 Jun 2011 21:28:55 +0200

Hi Vinod,

> Vinod# Policy driven path selection is configured on the PEs/ASBRs
> (BGP speakers) using Route Targets (configured) and RT Constrain. The
> RR responds with a list of paths that match the RTs indicated - it
> could be a list, range or the default RT. The RR computes this
> information and advertises needed information to BGP speakers. There
> is no propagation needed between individual BGP speakers in the

As Route Target Ext Community is a transitive BGP community can you 
clarify what mechanism are you going to use to prevent distribution of 
Route Targets outside of the autonomous system boundaries ?

Thx,
R.