[j-nsp] Re: policy question

[Pedro Roque Marques]

Daniel Roesen writes:

> 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.

JunOS calculates operational groups, in the sense that it may split out a
config group into several subgroups. But it cannot do so by completly
rewriting you export policy and spliting out "to neigbor" statements.

The complexity of doing so is honestly not worth it. Even because, in
the case of the previous poster, his config would be much more
readable if he actually express it in terms of a "in-region" group and
and "out-of-region" group.

And much closer to reality... BGP update groups are not a "mear"
optimization. Split out a reasonable config into groups in the wrong
way and the box will become unusable. It is a very important part of
BGP scaling... ignore it at you peril.

There may also be circustances where one may one to split a given set
of neighbors w/ same policy into multiple groups.

> 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.

Unfortunatly that is not the case... the user, specially in a network
of medium/large size, has to be very much aware of what is going
on. Management of networks w/ 1000s of nodes hasn't become any simpler
in the past decade...

> The same goes for unnecessary session resets.

I know that is one of your pet peeves... what is necessary or not is a
question that depends on one's point of view. What may apear
unecessary to you may be the most reasonable trade-off for me.

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

Software can hide details you don't need to worry about... imho, this
is not the case here. You should be concerned about how many operational
groups you have running on your system and which peers are in which
groups.

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

> That's... unfortunate.

What is the alternative... ? to automatically split your 200-peer ibgp
core facing group into individual groups per peer so that the policy
can be evaluated for a single peer at a time ?

I'd rather have you gripe about how unflexible the software is...
As people usually tend to dislike it when their routers melt down
due to the hidden side effects of software "intelligence".

  Pedro.