On Apr 16, 2012, at 5:24 PM, Christopher Morrow wrote:
> If the concern is, this peer keeps sending me an update that is
> unparsable, ignoring it (and logging a note/alert/etc) seems ok. If
> the problem is that the neighbor did something quite wrong on the
> session as a whole more immediate ac
On Mon, Apr 16, 2012 at 6:01 PM, Robert Raszuk wrote:
> Nope.
>
> This is about recognizing duplicate update which good implementation should
> be able to do regardless.
I think 'good implementations' don't then exist, since ... as
shane/danny have presented a few times, a large percentage of upd
Nope.
This is about recognizing duplicate update which good implementation
should be able to do regardless.
Nothing to do with error itself.
Regards,
R.
So you're going to _remember what error occurred_
Complexity++
No thanks,
Tony
On Apr 16, 2012, at 12:43 PM, Robert Raszuk wrote:
So you're going to _remember what error occurred_
Complexity++
No thanks,
Tony
On Apr 16, 2012, at 12:43 PM, Robert Raszuk wrote:
> Ilya,
>
> I meant to say that you would increment the counter only for unique updates.
> So duplicate updates with the same NLRIs would not be counted N ti
Ilya,
I meant to say that you would increment the counter only for unique
updates. So duplicate updates with the same NLRIs would not be counted N
times.
> On the other hand, if a session is reset (due to errors per other
> rules) there's chance that problems will occur again. Rather than
> b
> From: Jakob Heitz
> 1. Error handling must be simple, lest we have to handle errors of the
> error handling, ad infinitum...
> 2. Error handling should be restricted to error isolation and
> reporting. It should refrain from attempting error recovery.
I'm going to agree wi
On Apr 16, 2012, at 7:50 AM, Jakob Heitz wrote:
> This should not overwhelm a router.
> However, a more serious consequence is a lot of flapping routes.
> Serious enough to consider. We could dust off some dampening code for it.
>
> Note the previous discussion was about repeated "treat as withd
This should not overwhelm a router.
However, a more serious consequence is a lot of flapping routes.
Serious enough to consider. We could dust off some dampening code for it.
Note the previous discussion was about repeated "treat as withdraw"
errors. I support the use of an operational message for
On 16 Apr 2012, at 04:22, Jakob Heitz wrote:
> IMO
> 1. Error handling must be simple, lest we have to handle errors
> of the error handling, ad infinitum...
>
> 2. Error handling should be restricted to error isolation
> and reporting. It should refrain from attempting error recovery.
>
> If a
Hi,
Thanks for the feedback.
On 13 Apr 2012, at 21:24, Tony Li wrote:
> This may be a nit, but I think it's important to recall that UPDATE messages
> include withdrawn routes. These MUST NOT be ignored by the receiver. Doing
> so will simply result in forwarding loops or black holes.
>
> P
Robert,
> -Original Message-
> Algorithm:
> --
>
> If such counter get's exceeded session get's reset.
>
> There is tracking (counter++ operation) and one additional conditional if
> statement. There is no analysis what so ever.
>
Let's consider following scenario: a router in
11 matches
Mail list logo
