[j-nsp] BGP Prefix-Limit On A Session

[bbird at epik.net]

#-----Original Message-----
#From: Richard A Steenbergen [mailto:ras at e-gerbil.net] 
#Sent: Wednesday, February 25, 2004 9:47 PM
<snip>
#Are there any operators out there who place the importance of prefix
#limits providing protection of routing resources from someone 
#announcing a
#million routes above or anywhere near the importance of using prefix
#limits to catch "common" leaks by peers/customers/etc which 
#would result
#in suboptimal routing?

I have to partially disagree with you Richard.  I support the JunOS behavior
here, and do implement both an explicit prefix-list (aka.
policy-statement/route-filter) based on IRR data, and a prefix-limit based
on registered routes +overhead.  This is for the reasons already mentioned.
As far as the BGP session bounce when adding the prefix-limit, I completely
understand your point.

There is also much pain involved when a BGP group contains multiple peers
who share a common export-policy, but adding a prefix-limit to one of the
peers, where it didn't exist before causes unchanged peers' BGP session to
reset as well.

I am aware that this will always happen wrt to export-policy changes, and
how JunOS internally groups based on a common set of attributes that control
export policy (for scalability).  However, It didn't make much sense that
this would be related to prefix-limits as well.  I am told that behavior was
a bug, and was due to be fixed at some point?  Can anyone at Juniper confirm
that?

#
#Is this particular disconnect between developers and operators 
#perhaps one
#of the reasons why every operator I know would LOVE to see 
#auto-adjusting
#prefix limits that follow the "normal" number of prefixes 
#announced by a
#peer, and yet no vendor has ever tried to implement it (that I know of 
#anyways)?

This is a wonderful idea!  Obviously not difficult, either.

-Ben