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

From: Vinod Joseph <[email-masked]>
Date: Thu, 9 Jun 2011 09:44:48 +0100

This is proposed specifically to address the need of an operator to indicate a list of preferred NHs and in addition to have the option of an RR selected path as well.

Regards

Vinod Joseph
Sent from my Blackberry 
Professional Services - Service Provider Europe, UK & Ireland
Juniper Networks, Inc. 
+44 7500 835 876
E: [email-masked]

----- Original Message -----
From: Robert Raszuk <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: Vinod Joseph; [email-masked] <[email-masked]>
Sent: Thu Jun 09 09:38:53 2011
Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection	(shortest IGP vs policy based routing)

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 10:56:46 +0200

If you would not use RR selected paths as well how are you going to 
provide service to those PEs which preferred 2 paths out of 10 and those 
2 paths are withdrawn.

If you would use RR selected overall path always to be send to the 
client how are you going to enforce the client not to select such path 
locally as overall best ? In other words are you going to modify bgp 
best path selection on the client based on the attached RT extended 
community ?

Please do answer both questions.

Many thx,
R.

> This is proposed specifically to address the need of an operator to
> indicate a list of preferred NHs and in addition to have the option
> of an RR selected path as well.
>
> Regards
>
> Vinod Joseph Sent from my Blackberry Professional Services - Service
> Provider Europe, UK&  Ireland Juniper Networks, Inc. +44 7500 835
> 876 E: [email-masked]
>
>
>
>
> ----- Original Message ----- From: Robert Raszuk<[email-masked]>
> To:
> [email-masked]<[email-masked]>
> Cc: Vinod Joseph; [email-masked]<[email-masked]> Sent: Thu Jun 09
> 09:38:53 2011 Subject: Re: [Idr]
> draft-vinod-lavallee-bgp-optimal-route-reflection	(shortest IGP vs
> policy based routing)
>
> Hello,
>
> 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
> 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 20:34:51 +0200

Hello Gaurav,

I agree with almost entire email. "Almost" as I am not clear just on 
your last sentence and would really like if you could elaborate on it 
further ..

> RTC based
> approach in our draft is just optimizing via offering the provider to
> not only receive the best two three or more paths to select from but
> also offering the flexibilty to prefer the exit ASBR it wish to exit
> including the closest one.

Practical questions:

- How many paths you will want to receive from RR which will be 
prioritized by RTC ? Assume you have 10 ASBRs peering to your upstreams.

- I assume you are still going to request RR to send you the overall 
best to make sure when all of your preferred paths are going away such 
PE can still reach the given networks - pls confirm or deny.

- If you receive more then one path from RR how are you going to 
influence best path selection on the PE to make sure that:
  - the one containing RT X wins the best path selection as the most
    preferred
  - the one containing RT Y will be a backup of X.
  - the one containing community RR will be the one last resort.

I am not saying this is easy or difficult .. I am just interested to 
learn your preference there on how you are going to achieve this on each 
PE.

Best regards,
R.

> Hi Rob,
>
> I see it this way. Initially when RR concept was introduced then
> even the access devices (PEs) were not of a scale to handle a big
> rib-in data base plus also every device in network had to ip switch
> the packet across the network and best path to the exit gateway was
> not possible in true sense always (from PE prospective). This is
> because core routers forwarding decision was independent of access
> PEs. However once MPLS is there on the network the switching is based
> on the next hop PE selects. There is no significance left anymore for
> RR to select the best path first and then forward it further. It
> should simply reflect what all routes it receives. And we are talking
> about RR not just deciding best path for itself but also for PEs
> too. The add path approach is simply serving the concept of true
> route reflection. There has been a debate on the increase of rib-in
> at PE due to multiple copies of prefixes from different ASBR. RTC
> based approach in our draft is just optimizing via offering the
> provider to not only receive the best two three or more paths to
> select from but also offering the flexibilty to prefer the exit ASBR
> it wish to exit including the closest one.
>
> Regards, G
>
> On 6/9/11, Vinod Joseph<[email-masked]>  wrote:
>> Vinod Joseph Sent from my Blackberry Professional Services -
>> Service Provider Europe, UK&  Ireland Juniper Networks, Inc. +44
>> 7500 835 876 E: [email-masked]
>>
>>
>>
>>
Cc: Vinod Joseph; [email-masked]<[email-masked]>
>> Sent: Thu Jun 09 09:38:53 2011 Subject: Re: [Idr]
>> That is more like conditional advertisement feature and I don't
>> think we have ever intended to combine it with RTC.
>>
>> Thx, R.
>>
>> RT will be considered as candidates for announcements." According
>> to my own reading of RFC 4684, the default RTC route matches all 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: Jie Dong <[email-masked]>
Date: Fri, 10 Jun 2011 07:36:54 +0000

Hi all,

If the requirement is to indicate a list of preferred NHs to RR, maybe there can be one straightforward solution: just tell RR an ordered list of preferred NHs. 

This may be achieved by extending the NH Cost SAFI or defining one new SAFI. If RR knows any valid path with preferred NHs, it would advertise such route to the PE, otherwise RR would advertise the IGP optimal path from either the PE's or the RR's perspective. When add-path is used, RR may advertise both paths with preferred NHs and IGP optimal paths to the PE.

The potential benefit is overhead of managing and configuring RTs on ASBRs and PEs for IPv4/IPv6 unicast could be removed. Besides, the IGP optimal path could be sent to PE when there is no path with preferred NHs or when add-path is used, i.e. solve the problem without configuring "unique RT" for each RR.

Of course, if this policy based routing is a real requirement from operators, we could have more discussions on the solution space.

Regards,
Jie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Vinod
> Joseph
> Sent: Thursday, June 09, 2011 4:45 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> This is proposed specifically to address the need of an operator to indicate a
> list of preferred NHs and in addition to have the option of an RR selected
> path as well.
> 
> Regards
> 
> Vinod Joseph
> Sent from my Blackberry

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Jun 2011 10:51:44 +0200

Hello Jie,

Many thx for your comment. This is exactly what NH-SAFI is already 
capable of doing and this is what we have explained to Vinod at all 
number of times in this thread already.

IDR WG doc if combined with NH-SAFI draft does both IGP SPF based path 
selection on a per PE or per POP basis as well as operator's static 
preference on the choice of paths for set of particular PEs.

As you also are correctly observing such policy could be configured on 
RRs directly for each client without any need for extra NH-SAFI signaling.

Many thx,
R.

> Hi all,
>
> If the requirement is to indicate a list of preferred NHs to RR,
> maybe there can be one straightforward solution: just tell RR an
> ordered list of preferred NHs.
>
> This may be achieved by extending the NH Cost SAFI or defining one
> new SAFI. If RR knows any valid path with preferred NHs, it would
> advertise such route to the PE, otherwise RR would advertise the IGP
> optimal path from either the PE's or the RR's perspective. When
> add-path is used, RR may advertise both paths with preferred NHs and
> IGP optimal paths to the PE.
>
> The potential benefit is overhead of managing and configuring RTs on
> ASBRs and PEs for IPv4/IPv6 unicast could be removed. Besides, the
> IGP optimal path could be sent to PE when there is no path with
> preferred NHs or when add-path is used, i.e. solve the problem
> without configuring "unique RT" for each RR.
>
> Of course, if this policy based routing is a real requirement from
> operators, we could have more discussions on the solution space.
>
> Regards, Jie
>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Vinod Joseph Sent:
>> Thursday, June 09, 2011 4:45 PM To: [email-masked];
>> [email-masked] Cc: [email-masked];
>> [email-masked]; [email-masked] Subject: Re: [Idr]
>> To: [email-masked]
>> <[email-masked]> Cc: Vinod Joseph;
>> [email-masked]<[email-masked]> Sent: Thu Jun 09 09:38:53 2011 Subject:
>> Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection
>> (shortest IGP vs policy based routing)
>>
>> Hello,
>>