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: 1.0.1.0/16,
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
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 your
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,
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
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 :)
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.
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 handling
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 cisco
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
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 your
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
that
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 some cycle
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
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 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
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:
[--snip--]
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
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
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
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 which
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:
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 use),
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
in
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 been
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). :)
I've
26 matches
Mail list logo
