[j-nsp] Re: Re: policy question

[Daniel Roesen]

On Fri, Jun 24, 2005 at 02:48:15PM -0700, Pedro Roque Marques wrote:
> JunOS calculates operational groups, in the sense that it may split out a
> config group into several subgroups.

Yep, I'm aware of that. This is what I meant with "not strict anymore".

> But it cannot do so by completly rewriting you export policy and
> spliting out "to neigbor" statements.

Correct. See my followup on the "to neighbor" thing.

> The complexity of doing so is honestly not worth it.

Agreed. The work to evaluate the chain for each neighbor would be
approximately the same as to actually generate the individual BGP
UPDATE, so... :-)

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

Yes and no. Yes, that's IMHO the preferred workaround. No, in the sense
that it makes having standardized configs more difficult.

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

I don't ignore it. I totally agree that optimizing BGP UPDATE generation
is probably necessary on today's RE CPUs (dunno wether this would hold
true for e.g. a 3GHz CPU anymore). I just say that they the intelligence
can be done by the software. Juniper seems to agree, otherwise there
would be no internal regrouping.

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

I don't question that, but I'm curious of what those scenarios could be.
:-)

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

Yes. That's what good engineering folks are there for, who design the
setups, standard configs and configuration guidelines. And to verify
in ops, there is <IOS>show ip bgp replication</IOS> and <IOS>show ip bgp
update-group</IOS>.

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

I disagree. It's a very strictly technical question which is answered by
the BGP spec.

> What may apear unecessary to you may be the most reasonable trade-off
> for me.

Have fun discussing that with customers who experienced some very
impacting technically unnecessary and unexpected(!) session resets.

We _were_ bitten by that, hard (back then it wasn't documented, and
isn't very well today). It's really cool to modify a customer's export
policy chain to give him an additional default route he requested and
suddenly notice that the other ~20 customer sessions were resetted at
best day time for no apparent reason (it was the first or last neighbor
of the "customers" peer group whose export chains was being modified).
Or change an export chain of one peer at a large IXP and all the other
potentially 100-200 peers do reset.

In fact, when discussing that with other operators I haven't met anyone
who thinks that the trade-off "avoid bugs by doing it simple internally
but introduce technically unnecessary operational impact" is reasonable.
Looks like we're all unreasonable. :-)

> You should be concerned about how many operational groups you have
> running on your system and which peers are in which groups.

Given that JunOS automatically does internal re-grouping, this is
already blurry. And in contrast to IOS I have no chance to check (other
by guessing from config) into which internal update groups JunOS re-sorts
the neighbors.

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

If it does, it's the operator's engineering fault. Not Juniper's.
Then again engineering need solid documentation of what JunOS does
internally - which doesn't exist. Engineering defines how the boxes
get configured. They have to make the informed decision on what config
standards to set in order to operate a reliable network. That DOES
involve in-depth know-how about BGP and it's scaling properties, and
MUST be reflected in the designs. But that's nothing JunOS should try
to enforce. Again, given that JunOS _does_ allow changing export
semantics and _does_ do internal re-grouping, it looks like Juniper
agrees to this. Now just make that non-impacting. :-)


Best regards,
Daniel

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