[j-nsp] Re: Re: Re: policy question

[Daniel Roesen]

On Fri, Jun 24, 2005 at 04:33:56PM -0700, Pedro Roque Marques wrote:
> 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.

I'm talking about implicitly. There's no reason to renegotiate something
that hasn't changed, and thus there is no reason to break the BGP
session. This is a technical fact and implicit from the protocol spec.

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

I was talking about unexpected (because technically unnecessary...
"clear bgp neighbor soft" exists) session resets in general, just
giving an example. As far as I'm aware that was indeed fixed, but still
sessions are being resetted (thus customer impact) that technically
(protocol perspective) don't need a reset. If I change the export chain
on group level no reset will happen too.

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

OK, I stand corrected. Didn't notice that group names may appear
multiple times there.

Is this a new thing? Even current docs
(http://www.juniper.net/techpubs/software/junos/junos72/swcmdref72/html/bgp-monitor4.html#1013974)
don't have the "Index" attribute, neither in "screenshot" not
explanation...

> >> 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 would be. But I was referring to your discussion regarding the need
for BGP UPDATE group optimization (ignoring that might result in such
'melt downs'), and not about the session reset grief.

It's engineering's job to design the network so that it won't be hit by
BGP scalability problems. Having an IBGP group with 200 neighbors and
everyone having a one-off export policy chain wouldn't be Juniper's
fault. The software should (and does) allow this configuration to happen
(and it splits internally into 200 groups).

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

Indeed. :-)


Best regards,
Daniel (currently sitting between those two chairs, so not bound to any
specific role *g*)

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