On Oct 27, 2011, at 3:38 PM, Tima Maryin wrote:
> On 25.10.2011 20:21, Brad Fleming wrote:
>> Are there any tricks to auto-summarize the contents of a RIB where the
>> tributary routes are not originated locally?
>>
>> Example:
>> Input routes:
>> prefix: 1.0.0.0/16, next-hop: 5.5.5.5
>> prefix:
On 25.10.2011 20:21, Brad Fleming wrote:
Are there any tricks to auto-summarize the contents of a RIB where the
tributary routes are not originated locally?
Example:
Input routes:
prefix: 1.0.0.0/16, next-hop: 5.5.5.5
prefix: 1.0.1.0/16, next-hop: 5.5.5.5
prefix: 1.0.2.0/16, next-hop: 4.4.4.4
p
Hi Shane,
First I would like to actually thank all who provided some points reg
simple-va during the discussion since yesterday.
By all means I agree in some concerns expressed if additional CPU or
RIB/FIB installation times for possibly batches of more specifics in
relatively short time win
Chris,
On Oct 26, 2011, at 7:21 AM, Chris Morrow wrote:
> On 10/26/2011 12:10 AM, Shane Amante wrote:
>> With respect to S-VA, it appears you would need to play games with
>> carrying either a default route or less specifics (aggregates) with
>> NO_EXPORT, etc. around your network and having the p
Robert,
You are correct that I was referring to "full VA" vs. "simple VA". Having gone
back, just now, and read "Simple VA", I'm still not convinced it's the better
direction to go -- but, we'll likely have to agree to disagree, I guess.
On Oct 25, 2011, at 11:56 PM, Robert Raszuk wrote:
[--sn
On 10/26/2011 11:45 AM, Mark Tinka wrote:
I'm the first person that will preach against MPLS for all
the useless buzz it gets, but even I think that it has a
use-case here, if it's not a bother to the operator.
Yeah, I'm really happy that LFA should work 100% in my network topology,
leaving MP
On Wednesday, October 26, 2011 10:45:31 PM Chris Morrow
wrote:
> this is a LOT of overhead though, where 'how about we
> just supress these /24s k?' could work 'as well'.
I'm just offering an option (which I'm sure operators have
considered anyway), to the growing list of how we can handle
an
On 10/26/2011 1:07 AM, Robert Raszuk wrote:
As described to Shane semantically this is identical in default
behaviour as installing all prefixes into RIB and FIB. However I would
argue that if you do it within the POP you can do much better savings
that the default behavior. But this is perhaps
On 10/26/2011 10:24 AM, Mark Tinka wrote:
> On Wednesday, October 26, 2011 09:26:11 PM Chris Morrow
> wrote:
>
>> As I've said in the grow-wg sessions several times (and
>> at nanog and other places) VA, and other solutions like
>> it, may be fine in some deployments, they may even save
>> you
On Wednesday, October 26, 2011 09:26:11 PM Chris Morrow
wrote:
> As I've said in the grow-wg sessions several times (and
> at nanog and other places) VA, and other solutions like
> it, may be fine in some deployments, they may even save
> you some cycle time on RP/RE/linecards, each operator
> th
On 10/26/2011 09:56 AM, Pavel Lunin wrote:
>
>> The removal of a large aggregate (say 4/8) and the subsequent required
>> addition of all of the subnets under 4/8 could certainly be
>> 'interesting' to observe.
>> Interesting as well is that 4/8's origin doesn't have to be the flapper,
>> just y
The removal of a large aggregate (say 4/8) and the subsequent required
addition of all of the subnets under 4/8 could certainly be
'interesting' to observe.
Interesting as well is that 4/8's origin doesn't have to be the flapper,
just your network (or an intermediate) changing attributes (or exi
On 10/26/2011 04:30 AM, Pavel Lunin wrote:
> With simple-va a single prefix flap can mean quite a lot of new entries.
> The problem, which can arise here, is not the number of FIB entries, but
> the speed of populating (BTW, EX8200 is not the best here either). I'm
> not saying this is a problem
On 10/26/2011 03:06 AM, Robert Raszuk wrote:
> Hi Pavel,
>
>> Robert, is there any non-production implementation of simple-va, which we
>> could play with?
>
> The only implementation I am aware of is cisco ios component code. Yes
> there are non-production EFT images you could perhaps get from
On 10/26/2011 02:07 AM, Robert Raszuk wrote:
> Chris,
>
> Have you read draft-ietf-grow-simple-va-04 ? There is nothing in the
> draft nor in the implementation reg "route to the left".
it's a joke, essentially: "Remove lots of granularity, make someone else
in the network more capable of handl
On 10/26/2011 12:10 AM, Shane Amante wrote:
> With respect to S-VA, it appears you would need to play games with
> carrying either a default route or less specifics (aggregates) with
> NO_EXPORT, etc. around your network and having the potential to
> accidentally leak them beyond your network. H
> The router with simple-va functionality enabled will not install nor
> withdraw even single additional route on top of what it would do when
> simple-va feature is not enabled. So it is guaranteed to be no less then
> today.
>
OK, OK, I've read the draft quite some time ago, and I also liked it
Hi Pavel,
Robert, is there any non-production implementation of simple-va, which we
could play with?
The only implementation I am aware of is cisco ios component code. Yes
there are non-production EFT images you could perhaps get from cisco to
play around with it.
Since I have switched rec
Robert, is there any non-production implementation of simple-va, which we
could play with?
The main concern here is, of course, whether a router will
be infinitely installing/withdrawing tons of FIB entries because of
'natural' prefix flaps, how much black-hole/loop this will create in
practice, a
Chris,
Have you read draft-ietf-grow-simple-va-04 ? There is nothing in the
draft nor in the implementation reg "route to the left".
It is all about "take the same door as your big boss when you exit and
when you get new smaller boss in the middle who exist differently via
different doors yo
Hi Shane,
As author of simple-va idea in the current form -04 version let me
explain few points you have brought below:
SMALTA can be implemented completely local to a one router, several
routers or all routers
Exactly same case with simple-va.
-- the whole point is that: i) the SMALTA
al
Hi Mark,
On Oct 25, 2011, at 8:09 PM, Mark Tinka wrote:
> On Wednesday, October 26, 2011 05:12:09 AM Richard A
> Steenbergen wrote:
>
>> c) Vendors would much rather sell you new cards wih more
>> FIB capacity than find a way to implement a "free"
>> solution in software (big shocker, I know). :
On 10/25/2011 10:09 PM, Mark Tinka wrote:
> On Wednesday, October 26, 2011 05:12:09 AM Richard A
> Steenbergen wrote:
>
>> c) Vendors would much rather sell you new cards wih more
>> FIB capacity than find a way to implement a "free"
>> solution in software (big shocker, I know). :)
>
> I've
On Wednesday, October 26, 2011 05:12:09 AM Richard A
Steenbergen wrote:
> c) Vendors would much rather sell you new cards wih more
> FIB capacity than find a way to implement a "free"
> solution in software (big shocker, I know). :)
I've been chatting with a major vendor about their interest
i
On Tue, Oct 25, 2011 at 06:45:27PM +0100, Phil Mayers wrote:
>
> This (aggregate routes on next-hop) comes up now and again, and the
> idea seems to be controversial for some people. Various criticisms are
> cited - unpredictability (a single route change could result in a
> large jump in FIB u
On 10/25/2011 05:21 PM, Brad Fleming wrote:
Are there any tricks to auto-summarize the contents of a RIB where the
tributary routes are not originated locally?
Example:
Input routes:
prefix: 1.0.0.0/16, next-hop: 5.5.5.5
prefix: 1.0.1.0/16, next-hop: 5.5.5.5
prefix: 1.0.2.0/16, next-hop: 4.4.4.
Ahh.. good point. I didn't think about the problem from the machine's
standpoint. It would need a target / hard number of prefixes or the table would
be the exact same.
Thanks for the response!
On Oct 25, 2011, at 11:56 AM, Stefan Fouant wrote:
> You can use aggregate
> /generated routes whic
You can use aggregate
/generated routes which require more specific contributing routes to become
active, and then only advertise the protocol aggregate routes to your
downstream nodes that have smaller tables, however you still need to create the
aggregates which is a manual process.
You can g
Are there any tricks to auto-summarize the contents of a RIB where the
tributary routes are not originated locally?
Example:
Input routes:
prefix: 1.0.0.0/16, next-hop: 5.5.5.5
prefix: 1.0.1.0/16, next-hop: 5.5.5.5
prefix: 1.0.2.0/16, next-hop: 4.4.4.4
prefix: 1.0.3.0/16, next-hop: 5.5.5.5
Conso
29 matches
Mail list logo
