Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5)

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

--------------------------------------------------
From: "Shah, Chintan" <[email-masked]>
Sent: Tuesday, June 07, 2011 2:02 PM
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
"Thareja, Gaurav" <[email-masked]>
Subject: RE: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection 
(was:  Idr Digest, Vol 86, Issue 5)

> Hi ilya,
>
> To add to this, As a carrier we would not like to restrict the path 
> selection only based on IGP or an administrative cost. There are diverse 
> requirements and the RT approach eases our needs to define strict, and 
> flexible path selection criteria based on RT constrain.
>

please bring requirements forth and we'll see if they're not already 
addressed. I wonder why did you make secret of these requirements when 
before and after Prague we were discussing ORR.

> Another advantage with the RT approach is: Carriers with service POP 
> deployments using Anycast can load balance traffic from end user to 
> multiple service POP through the use of RTs than just rely on IGP. There 
> is quite an amount of flexibility is there.
>
advantage compare to what, sorry? using NH SAFI a PE could simply signal 
equal cost to those "service PoPs" that it want to load-balance with, and if 
those PoP's are gone, next-best could take their place. if there is an 
advantage, then it's not of "possible/not possible" sort.

> With respect to the discussion of configurations for new ASBR/PE, once 
> there is design in place for Operation with respect a carrier network, 
> there is always a need for standard operational practices needed for this, 
> and this is something carriers are used to - when it comes to the use of 
> RT (courtesy VPNv4 deployments) I see it as something simpler and more 
> flexible that considering it a burden.
>

let's be practical - what are conditions when desired exit point is not an 
IGP-closest? I can understand this as an expeption in few scenarios but why 
did all of a sudden world wants to route traffic elsewhere? Could it be that 
your IGP design is wrong?

Kind regards,
iLya

---

From: "Shah, Chintan" <[email-masked]>
Date: Tue, 7 Jun 2011 12:02:13 +0000

Hi ilya,

To add to this, As a carrier we would not like to restrict the path selection only based on IGP or an administrative cost. There are diverse requirements and the RT approach eases our needs to define strict, and flexible path selection criteria based on RT constrain. 

Another advantage with the RT approach is: Carriers with service POP deployments using Anycast can load balance traffic from end user to multiple service POP through the use of RTs than just rely on IGP. There is quite an amount of flexibility is there.

With respect to the discussion of configurations for new ASBR/PE, once there is design in place for Operation with respect a carrier network, there is always a need for standard operational practices needed for this, and this is something carriers are used to - when it comes to the use of RT (courtesy VPNv4 deployments) I see it as something simpler and more flexible that considering it a burden. 

Regards,
Chintan

-----Original Message-----
From: Amit Khopkar [mailto:[email-masked]]
Sent: 07 June 2011 11:35
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,

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)

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

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

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.

[Colt Disclaimer]
The message is intended for the named addressee only and may not be disclosed
to or used by anyone else, nor may it be copied in any way. The contents of
this message and its attachments are confidential and may also be subject to
legal privilege. If you are not the named addressee and/or have received this
message in error, please advise us by e-mailing [email-masked] and delete the
message and any attachments without retaining any copies. Internet
communications are not secure and Colt does not accept responsibility for this
message, its contents nor responsibility for any viruses. No contracts can be
created or varied on behalf of Colt Technology Services, its subsidiaries,
group companies or affiliates ("Colt") and any other party by email
communications unless expressly agreed in writing with such other party.
Please note that incoming emails will be automatically scanned to eliminate
potential viruses and unsolicited promotional emails. For more information
refer to www.colt.net or contact us on +44(0)20 7390 3900