[j-nsp] Re: policy question

Daniel Roesen dr at cluenet.de
Fri Jun 24 17:11:28 EDT 2005

On Fri, Jun 24, 2005 at 01:25:11PM -0700, Pedro Roque Marques wrote:
> Export policies cannot have different behaviour from different members
> of a group... the definition of a BGP group is a set of peers w/ a
> consistent export policy.

Hm, where is that defined? JunOS docs say:

"BGP peer groups share a common type, peer autonomous system (AS)
number, and cluster ID, if present."

source: http://www.juniper.net/techpubs/software/junos/junos72/swconfig72-routing/html/bgp-summary17.html#1014292

I can see nothing that mandates or even recommends that all export
policies have to / should match.

IMHO it's just the "old style IOS way of doing things". Current IOS is
more like JunOS in the way that peer groups are just a method to not
have to repeat identical configuration for every neighbor. IOS (similar
but superior to JunOS) internally calculates "update groups" who have
the same egress characteristics to optimize BGP UPDATE generation process.

Can we please finally get rid of this (not strict anymore) old-style
"bgp peer==update group" thinking? Computing UPDATE groups is an
optimization that the software can do easily and not something that
in the year 2005 the users should be bothered with. The same goes for
unnecessary session resets.

Please let us just configure logical groups as kind of templates, with
arbitrary per-neighbor specific configuration tweaks. Compute update
groups internally, and don't reset any session where the the fundamental
session(!) parameters (which are being negotatiated in the session
opening) weren't changed.

Is that asking too much? IOS can do that:

It's 2005. Software is there to make our lives easier.

> As such "to neighbor [...]" clauses are automatically ignored for BGP
> export policies.

That's... unfortunate.

Best regards,

CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0

More information about the juniper-nsp mailing list