Re: Comments on draft-zhao-opsec-routing-capabilities-01.txt

[Warren Kumari <warren@kumari.net>]

On Jun 2, 2006, at 12:07 PM, Ted Seely wrote:

> Section 2.1
>
> Max Prefix - needs language added to address what to do when max  
> number of
> routes/prefixes is reached.  Doc says "may reset the BGP session",  
> which
> is true, but perhaps it should be left admin down.  usually when this
> happens, it continues to happen becasue there has been a BGP
> mis-configuration on the other side, and you will continue to have the
> sessions come up and go down unitl this is discovered, which  
> introduces
> instability into the overall routing table.
>
> most tier 1s communicate what this number needs to be, and add some  
> sane
> amount of overhead to it for growth, swings etc, but when 60K goes to
> 120K over and over, bad things happen.

I fully agree that having the session flap wildly is not a good thing  
-- I think that one of  the standard capabilities (and it's currently  
implemented by some vendors) should be to perform some sort of  
exponential dampening of the session. I think that the action  
(immediately try bring the session back up, exponentially back off  
session reestablishment or admin down the session) should be  
configurable. Also, having the device alert at some fraction of  
MAX_PREFIX would lead to more adoption of max prefix limits, but this  
is probably off-topic....

What confuses me is the phrase: "or may reject excess routes." -- to  
my mind, if a peer has suddenly exceeded the configured number of  
prefixes,  it is probably broken and you can no longer trust ANY of  
the data you have from it (also, what do you do if a prefix is  
withdrawn -- do you now have a free slot and install the next prefix?)

 Warren
[1] What I would actually like, but have never seen, is a back off  
where the (bounded) penalty is a function of how much the threshold  
was exceeded by.


> make sense?
>
> would you like me propose some text?
>
> -ted
>
>
> On Thu, 1 Jun 2006, George Jones wrote:
>
> > Comments on  draft-zhao-opsec-routing-capabilities-01.txt attached.
> > Word format.  Apologies.   It was sent to me in that format.
> > Changebars inline.    Hope the list does not strip attachments.
> >
> > ---George Jones
>
>
>
> Ted Seely
> Principal Network Design Engineer
> Internet Engineering - SprintLink
> (W) 703.689.6425
> (M) 703.967.3289
> AIM - wanpro00
> Yahoo IM - tseely01
>
> "Serious damage and router meltdown could be avoided by strict
> configuration validation"