Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection

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

Further elaborating on the amount of configurations required in this draft vs the other proposals.

Only ASBRs need to be configured with Route targets when advertised to the RRs, and I am sure ASBRs are much fewer in number to PEs. The PEs only signal interest via RT constrain and do not need to attach RTs to their local prefixes. The reason: In most cases PE announced customer prefixes can be controlled using standard BGP methods, if these PE announced prefixes are not needed on an ASBR for some special reason.

On the contrary, the other solution needs every PE to ASBR pair mapped with an administrative cost in cases where the IGP is not preferred for use. If you have situations where each PE or groups of PEs have diverse outbound traffic flow requirements, you would end up having to manually setup potentially huge number of PE+ASBR pairs. In the event of a new ASBR introduced in the network, all PEs that need to use this ASBR as a primary exit point will need reconfiguration. Using RT, only the ASBR will need to be configured to advertise its paths with an additional Route target that matches a given PEs preference - HENCE SINGLE TOUCH POINT!

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: Vinod Joseph
To: [email-masked] <[email-masked]>; Amit Khopkar <[email-masked]>
Cc: iLya <[email-masked]>; [email-masked] <[email-masked]>; Laurent Lavallee <[email-masked]>
Sent: Tue Jun 07 22:32:03 2011
Subject: RE: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection

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,

> 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: Wed, 08 Jun 2011 09:09:27 +0200

Vinod,

 > PEs only signal interest via RT constrain and do not need to attach
 > RTs to their local prefixes.

If PEs are signaling their route preference interest via RT constrain I 
would assume they would have to be configured with those RTs ahead of 
time as well.

If not how would the PE know what to signal in RT constrain towards the 
RRs ?

Thx,
R.

> Only ASBRs need to be configured with Route targets when advertised
> to the RRs, and I am sure ASBRs are much fewer in number to PEs. The
> PEs only signal interest via RT constrain and do not need to attach
> RTs to their local prefixes. The reason: In most cases PE announced
> customer prefixes can be controlled using standard BGP methods, if
> these PE announced prefixes are not needed on an ASBR for some
> special reason.
>
> On the contrary, the other solution needs every PE to ASBR pair
> mapped with an administrative cost in cases where the IGP is not
> preferred for use. If you have situations where each PE or groups of
> PEs have diverse outbound traffic flow requirements, you would end up
> having to manually setup potentially huge number of PE+ASBR pairs. In
> the event of a new ASBR introduced in the network, all PEs that need
> to use this ASBR as a primary exit point will need reconfiguration.
> Using RT, only the ASBR will need to be configured to advertise its
> paths with an additional Route target that matches a given PEs
> preference - HENCE SINGLE TOUCH POINT!
>
> 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: Vinod Joseph To:
> [email-masked]<[email-masked]>; Amit
> Khopkar<[email-masked]> Cc: iLya<[email-masked]>;
> [email-masked]<[email-masked]>; Laurent
> Lavallee<[email-masked]> Sent: Tue Jun 07 22:32:03
> 2011 Subject: RE: [Idr] more on
> draft-vinod-lavallee-bgp-optimal-route-reflection
>
> 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.
>
> 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,
>
>> 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.
>
> 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.
>
> 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.
>
> 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: Vinod Joseph <[email-masked]>
Date: Wed, 8 Jun 2011 14:06:11 +0100

I would look at this way Robert. An operator may plan to allot a set of RT values lets say (1-10) for a given POP/Region. The proposal specifies the need for the implementation to support RT values as ranges as well. So each PE in a region can just include a range of RTs, and this may include all or near to complete RT values that may be allotted in a POP. So when a new ASBR is added, all you need is the ASBR to have the appropriate RT used. 

In contrast, you would need to re-engineer each PE to have a new metric (administrative) towards the new ASBR. So in effect every PE interested in that ASBR needs re-calculation (on what metric is to be used and whether this ASBR is going to be the primary path or backup and so on) and re-configuration. 

Regards

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

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: 08 June 2011 08:09
To: Vinod Joseph
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection

Vinod,

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 08 Jun 2011 15:28:59 +0200

Vinod,

In contrast using my proposal you do not to single touch any PE or any 
ASBR as what the default requirement for hot potato routing calls is the 
shortest IGP exit. And that is computed automatically without any RTs, 
any metrics or even without need for any BGP protocol extension.

Only in the event of operator wishing to overwrite the IGP shortest 
exist choice he may on a case by case basis use a manual policy.

In fact if you follow route server space (which can equally well be 
applicable to the current discussion) such policy preference of not 
sending some paths to some clients can be realized today already by 
dynamic community based instruction send from client to a route server 
in the shipping code. Completely no need to mess with any additional 
signaling is necessary. Especially if you are talking about 1-10 
preference levels. In RS such solution must scale at min on 1-1000 range 
:).

So to summarize I still see no practical case for your proposal to 
progress it any further.

Cheers,
R.

> I would look at this way Robert. An operator may plan to allot a set
> of RT values lets say (1-10) for a given POP/Region. The proposal
> specifies the need for the implementation to support RT values as
> ranges as well. So each PE in a region can just include a range of
> RTs, and this may include all or near to complete RT values that may
> be allotted in a POP. So when a new ASBR is added, all you need is
> the ASBR to have the appropriate RT used.
>
> In contrast, you would need to re-engineer each PE to have a new
> metric (administrative) towards the new ASBR. So in effect every PE
> interested in that ASBR needs re-calculation (on what metric is to be
> used and whether this ASBR is going to be the primary path or backup
> and so on) and re-configuration.
>
> Regards
>
> Vinod Joseph Professional Services – Service Provider Europe Juniper
> Networks
> [mailto:[email-masked]] Sent: 08 June 2011 08:09 To: Vinod Joseph
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked] Subject: Re: [Idr] more on
>> PEs only signal interest via RT constrain and do not need to
>> attach RTs to their local prefixes.
>
> If PEs are signaling their route preference interest via RT constrain
> I would assume they would have to be configured with those RTs ahead
> of time as well.
>
> If not how would the PE know what to signal in RT constrain towards
> the RRs ?
>
> Thx, R.
>
>
>
>> Only ASBRs need to be configured with Route targets when
>> advertised to the RRs, and I am sure ASBRs are much fewer in number
>> to PEs. The PEs only signal interest via RT constrain and do not
>> need to attach RTs to their local prefixes. The reason: In most
>> cases PE announced customer prefixes can be controlled using
>> standard BGP methods, if these PE announced prefixes are not needed
>> on an ASBR for some special reason.
>>
>> preferred for use. If you have situations where each PE or groups
>> of PEs have diverse outbound traffic flow requirements, you would
>> end up having to manually setup potentially huge number of PE+ASBR
>> pairs. In the event of a new ASBR introduced in the network, all
>> PEs that need to use this ASBR as a primary exit point will need
>> reconfiguration. Using RT, only the ASBR will need to be configured
>> to advertise its paths with an additional Route target that matches
>> a given PEs preference - HENCE SINGLE TOUCH POINT!
>>
>> Regards
>>
>> Vinod Joseph Sent from my Blackberry Professional Services -
>> Service Provider Europe, UK&   Ireland Juniper Networks, Inc. +44
>> 7500 835 876 E: [email-masked]
>>
>>
>>
>>
>> Lavallee<[email-masked]>  Sent: Tue Jun 07
>> 22:32:03 2011 Subject: RE: [Idr] more on
>> 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).
>>
>> administrative overhead vs. flexibility can be achieved. In the
>> case of the NH draft, each PE needs to be configured with an
>> 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.
>>
>> requests through affinities can certainly reduce the overhead on
>> the RR + the churn caused on the RR due to SPF runs.
>>
>> Networks M: +44 (0) 7500 835 876 E: [email-masked]
>>
>>
>>
>>
>> [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
>>> 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
>>
>> 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.
>>

---

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

Robert,

But the fact of running SPF on behalf of a PE does not scale in a large carrier environment, it translates to 'burning" the RR to keep up to every single change in the network and to calculate best path to ASBRs :-)
Regards

Vinod Joseph

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: 08 June 2011 14:29
To: Vinod Joseph
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection

Vinod,

Cheers,
R.

---

From: "iLya" <[email-masked]>
Date: Wed, 8 Jun 2011 16:13:47 +0200

--------------------------------------------------
> Robert,
>
> But the fact of running SPF on behalf of a PE does not scale in a large 
> carrier environment, it translates to 'burning" the RR to keep up to every 
> single change in the network and to calculate best path to ASBRs :-)

Vinod,

we've already shown multiple times that calculating SPF for N sources to K 
destinations can be done using single SPF run instead of N runs. Please 
check earlier discussion on ORR.

Kind regards,
iLya

---

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

Robert,

I agree with your approach. 

Vinod,

Today ORR/VRR fits well for hot potatoe routing. SPFs are not an issue (generally you will not run it per PE, but more per PoP) and RR are more and more powerful computers.

For preference based routing, like in your solution, I can ask you this question, why do you want to configure your preference on the PE ? It could be configured on the RR and in this case, there is no more signalling need :) It's a static "backbone" configuration (no need to change it every day). In the case, as Robert mentionned, RS solution already permits the preference based routing for a group a peers. The main question is what is the benefit to configure the preference on the PE rather than the RR ?
 
Regards,

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Robert Raszuk
Envoyé : mercredi 8 juin 2011 15:29
À : Vinod Joseph
Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection

Vinod,

In contrast using my proposal you do not to single touch any PE or any ASBR as what the default requirement for hot potato routing calls is the shortest IGP exit. And that is computed automatically without any RTs, any metrics or even without need for any BGP protocol extension.

Only in the event of operator wishing to overwrite the IGP shortest exist choice he may on a case by case basis use a manual policy.

In fact if you follow route server space (which can equally well be applicable to the current discussion) such policy preference of not sending some paths to some clients can be realized today already by dynamic community based instruction send from client to a route server in the shipping code. Completely no need to mess with any additional signaling is necessary. Especially if you are talking about 1-10 preference levels. In RS such solution must scale at min on 1-1000 range :).

So to summarize I still see no practical case for your proposal to progress it any further.

Cheers,
R.

> be allotted in a POP. So when a new ASBR is added, all you need is the 
> ASBR to have the appropriate RT used.
>
> Vinod Joseph Professional Services - Service Provider Europe Juniper 
> Networks
>> 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, 
>> RR specific RT. So lets say RR1 has an RT of X 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).
>>
>> be the only step involved in receiving ASBR paths.
>> announced by the RR. In addition RR specific RTs (as mentioned
>> Vinod Joseph Professional Services - Service Provider EMEA Juniper 
>>> process (one of the main reasons for existence of

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

********************************************************************************
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: Robert Raszuk <[email-masked]>
Date: Wed, 08 Jun 2011 16:22:19 +0200

Vinod,

What does not scale and results in 'burning' the RR in your 
implementation works very well in other implementations in large carrier 
environments. Moreover it is deployed today as part of LFA code.

I think it may be better if you consult your IGP developers before 
voicing such statements on the list. However I am happy that everyone 
already participating in this thread had a chance to hear directly from 
you that running few more instances of SPF (for example one per POP) is 
at all any measurable issue for you. Thank you for clarifying this for us.

Cheers,
R.

> But the fact of running SPF on behalf of a PE does not scale in a
> large carrier environment, it translates to 'burning" the RR to keep
> up to every single change in the network and to calculate best path
> to ASBRs :-) Regards
>
> Vinod Joseph

---

From: Rob Shakir <[email-masked]>
Date: Wed, 8 Jun 2011 15:44:38 +0100

> But the fact of running SPF on behalf of a PE does not scale in a large carrier environment, it translates to 'burning" the RR to keep up to every single change in the network and to calculate best…

Hi Vinod,

I have sent mails to the IDR list regarding to similar matters previously, and whilst I've reviewed your draft, I'd like to pick up on this comment in particular rather than the specifics of how it is intended operate.

At some point _somewhere_ in the network we have to expend additional resource to be able to achieve the result of (more) optimal route reflection - this either has to be on the RR by running some best path selection algorithm that takes into account the position of the PE within a topology, or it has to be giving the PE a number of paths that it can choose from to be able to make the best selection.

(In this case PE refers to some arbitrary edge device within the topology that receives prefixes via BGP).

The following should be noted:

1. The approach of limiting the number of paths that are advertised to the PE, however it is achieved, does not come for free - there is still resource expenditure on the RR to filter outgoing advertisements based on the Route Targets that the PE has advertised to it. There is also some resource consumption to measure this (albeit relatively static) RT-database on the PE itself. Now, AIUI from discussions regarding RTC with various IDR WG members, this practice is relatively lightweight for the RR - however, the key point here is it that such path filtering is not free in terms of CPU. (We do, however, save some CPU by not having to transmit the UPDATE).

2. Advertising multiple paths to the PE places additional load on the PE, which now has more paths over which it must iterate when making a best path selection. Of course, there is a limit to the size of this problem through limiting the number of additional paths to some arbitrary value of N. However, comparing this to an ORR solution where we have a single best path advertised between the 
RR and PE - there is still some load that is incurred in best path selection. We also have further RIB resource allocation on the PE to store these paths.

3. I find the assertion 'running SPF on behalf of a PE does not scale in a large carrier environment' to be very interesting. One of the points that I've made multiple times on the subject of ORR relates particularly to the scenario where the RR is _not_ in the forwarding path. At this point, we have no need to constrain the resources that are available on this device to anything that is available as a "router". All this device has to be is a computer that is able to run the BGP best path selection algorithm. In addition, we can scale this relatively easily (assuming the software scales to it), since in the case where we have the RR out of the forwarding path, and require some more optimal route selection, it is typically centralised within most architectures. Therefore, we have the problem that we just need to scale some processing power centrally. I think this scales quite nicely, and actually gives significant advantage that the CPU being used for this task is dedicated to it.

4. With both approaches, there is some penalty incurred in terms of one-off configuration. With the WG draft, we either need to specify our angular positions for PEs (somewhat complex IMHO), or we need to define some groups which we consider valid for the same ORR decision to be made. In your approach, we need to configure each PE that advertises routes into the network with an ingress RT, in addition, we need to configure each client with an ordered set of RTs that indicate which prefixes we then want to have advertised to us. From an operational overhead point of view, of course the latter is heavier. In terms of operational complexity, this will of course depend on your operational teams - but my concern with having an RT distributed to each PE is that this problem is no longer restricted to the RR where the "right" route is not being learnt by the PE in question - but rather now need verification that the RT membership information is being advertised correctly by the RR-C to the RR, and that the RR is performing the right best path selection and filtering.

The key point here is that we have to expend resource somewhere in the network "system" to achieve the more optimal path being received by a PE. I would be interested to see any figures comparing the resource utilisation between the cases, as it seems like you are asserting that the WG draft incurs more overhead (ignoring the operational complexity). I also encourage you to review the discussions about more efficient mechanisms to perform SPF that have been mentioned in discussions of route reflection previously.

Kind regards,
r.

---

From: "Shah, Chintan" <[email-masked]>
Date: Wed, 8 Jun 2011 15:05:15 +0000

Hi,

Having the RR do a best path calculation does not provide a means of selecting preferential paths based on operators policies and needs and as a Carrier. It would  cause scaling issues when we speak of the scale of a network and the amount of work the RR needs to do, which end of it only gives us the best IGP path.

The NH draft is once again seems to be overhead as Vinod pointed out – especially re-engineering and during introduction of new ASBRs etc, and needs new capabilities.
	
I still see the newly proposed draft does offer flexibility needed to deploy and manage.

Regards,
Chintan

-----Original Message-----
From: iLya [mailto:[email-masked]] 
Sent: 08 June 2011 19:44
To: Vinod Joseph; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Shah, Chintan; Thareja, Gaurav
Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection

> up to every single change in the network and to calculate best path to 
> ASBRs :-)

Vinod,

we've already shown multiple times that calculating SPF for N sources to K destinations can be done using single SPF run instead of N runs. Please check earlier discussion on ORR.

Kind regards,
iLya

[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

---

From: Vinod Joseph <[email-masked]>
Date: Wed, 8 Jun 2011 16:05:48 +0100

Very interesting comments indeed.

These are two diverse approaches Rob.

Firstly the ORR (Robert's) draft only offers best path based on the IGP. If a preferred list of paths (lets say PE1 needs ASBR1, ASBR2, ASBR3) is needed by a PE - Then a manual policy is needed to override this behaviour as Robert pointed out. Let us say the network largely needs a set of pre-defined paths as mentioned above, then you would end up manually configuring policies on the RR(s) to reflect each requirement of such. This is a lot of manual configurations.

When using RTs: An operator may plan to allot a set of RT values let's say (1-10) for a given POP/Region. The proposal specifies the need for the implementation to support RT values as ranges as well. So each PE in a region can just include a range of RTs, and this may include all or near to complete RT values that may be allotted in a POP. So when a new ASBR is added, all you need is the ASBR to have the appropriate RT used. This may be easier to pre-provision rather than reflect/respond to a change whenever it happens. 

Having multiple paths on the PE, depending on many or how few (whatever be the capability of the PE to handle) - improves convergence in the event of paths going away, since there is more than a single path available locally.

Regards

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

-----Original Message-----
From: Rob Shakir [mailto:[email-masked]] 
Sent: 08 June 2011 15:45
To: Vinod Joseph
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection

Hi Vinod,

Kind regards,
r.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 08 Jun 2011 17:58:40 +0200

Vinod,

> Firstly the ORR (Robert's) draft only offers best path based on the
> IGP. If a preferred list of paths (lets say PE1 needs ASBR1, ASBR2,
> ASBR3) is needed by a PE - Then a manual policy is needed to override
> this behaviour as Robert pointed out. Let us say the network largely
> needs a set of pre-defined paths as mentioned above, then you would
> end up manually configuring policies on the RR(s) to reflect each
> requirement of such. This is a lot of manual configurations.
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I think we have more basic problems here ...

You said you have requirement to set 1-10 levels of ASBR preference on a 
per POP basis. Assume you have 20 POPs and each POP needs to get unique 
set of paths.

So this "a lot of manual configuration" on RR would result assuming you 
want two paths to be send to each client in 40 additional lines of 
configuration. And this configuration stays there in the same way as it 
stays on your PEs.

Now assume you want more then per POP .. you have 1000 PEs and want it 
per PE. Why not ... screw the network completely. What you do then you 
use peer templates which depending on the peer's policy are applied in 
the same manner to many peers.

So if you have 1-10 exit preferences and you want to send 2 paths to 
each PE combination of 2 out of 10 without repetition is:
10!/(2!(10-2)!) = 45

Is 45 lines of additional configuration a lot ?

I don't know about you, but I have seen production configurations of 
large networks and adding 45 lines of config there would be in the noise.

Cheers,
R.

---

From: Paul Jakma <[email-masked]>
Date: Wed, 15 Jun 2011 22:21:05 +0100 (BST)

On Wed, 8 Jun 2011, iLya wrote:

> we've already shown multiple times that calculating SPF for N sources to 
> K destinations can be done using single SPF run instead of N runs.

Is that a single SPF run of comparable computational complexity (i.e. 
O(mlogn)?

It seems very unlikely you've achieved this, but it's very big news if you 
have..

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
It would be nice to be sure of anything the way some people are of everything.