[j-nsp] Re: Re: policy question

[Pedro Roque Marques]

Daniel Roesen writes:

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

IETF specifications are supposed to document interoperability. They do
not and cannot mandate how protocols are implemented.

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

That is a rather different discussion than stating "no session
resets"... it has to do w/ impact on group members you did not modify
the config for. And you know that has been fixed... i fail to see the
purpose of bringing this issue up again.


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

That is not correct. "show bgp groups" displays the operational groups
and which are the members.

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

The incident you where complaining about on the 2nd paragraph i quote
is nothing if a circunstance in which the software is doing a guess as
to what the distribution of members to groups should be.

This statement, to me, seems to conflict with the displeasure stated
above with the previous algorithm for member group assignment.

It is very rare, on a suplier / customer relation, regardless of
what product we are talking about, to have the customer say "things
broke spectacularly, but it ain't your fault".

  Pedro.