[j-nsp] RE: bgp config changes (was: autonomous-system N loops L)

[bbird at epik.net]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Comments inline.  Thank you for discussing this.

#-----Original Message-----
#From: Pedro Roque Marques [mailto:roque at juniper.net] 
#Sent: Friday, December 12, 2003 2:18 AM
#To: bbird at epik.net
#Cc: pr at isprime.com; ras at e-gerbil.net; juniper-nsp at puck.nether.net
#Subject: bgp config changes (was: autonomous-system N loops L)
#
#bbird at epik.net writes:
#
#> -----BEGIN PGP SIGNED MESSAGE-----
#> Hash: SHA1
#> 
#> I also agree.
#>
#[...] 
#> I was informed by JTAC, this is an "artifact of the design". 
Since
#> JunOS creates an internal group structure, based on common
#> attributes/options that affect import policy, the peers can be
#> internally regrouped, so to speak.
#
#Just a correction. It is export policy. An operational group (as
#oposed to configuration template) must have a coherent export
policy.

Thank you for the correction.  I now recall it pertaining to export
policies.  But it still remains that neighbors, with unchanged
configurations, were being reset for one of the reasons you've
stated.

The reason I mentioned import policy, is because of an event that was
originally attributed to the behavior you've described.  The policy I
changed on a neighbor, was a prefix-limit filter.  And upon making
that change, I discovered other neighbors being reset.  In the
configuration template, the prefix-limit is neither import nor export
policy.  However, I equate this to a test condition on import, more
than an export policy.  I was later advised, that this shouldn't have
occurred, and wouldn't if I upgraded to something newer (speaking
only of the prefix-limit).

#
#This is because BGP updates to a group are replicated among peer
group
#members, an export policy is evaluated only once. It is more than
just
#an implementation quirk. It is essential for scaling purposes.

This *might* make sense architecturally, based on scalability and
software design, etc.  However, the operational inconsistencies
between the configuration template, and the operational group cause
unpredictable (or very difficult to predict) results.  What I think
Juniper should do (outside of redesign that piece), is inform the
operator, when making changes to the configuration template.  Let us
know which peers would be reset, as a result.  This is deterministic,
at some level.  Why not let the computer figure it out and tell us? 
And, of course, notify prior to making the change, or give us a way
to test, as Richard S. pointed out. 

#
#As far as sessions resets are concerned, you can always expect a
reset
#if you change a parameter that is negotiated on session
#establishement. Remember that the idea in JunOS is that the
#operational state should always reflect the config. i.e. JunOS
doesnt
#leave the session in a state that doesnt match the config. While in
#some cases the behaviour may be unexpected it has its advantages
#also.

This makes sense.  And I can easily determine these conditions. 
However, we are experiencing session resets to unchanged peers, where
the export policy changes made, cause no adjustment to parameters
negotiated on session establishment.  This is for either the changed
or unchanged peers.  Your paragraph below explains why.

#
#I agree that in some circumstances the behaviour is less than
#ideal. If you do change the export policy of the 1st (in config)
order
#peer of a group, the group is modified to follow the config you
apply
#to the 1st peer and the remaining peers in the group that do not
match
#its export policy are reset.

This behavior is almost unacceptable, in my opinion (not worth
much...I know).  If re-tooling this to be more user friendly isn't
likely. Then, at least, tell the operator what is going to happen,
before it does.  As I see it, the code knows which peers are going to
be removed from their groups and thus reset, as a result of the
changes about to be committed.  But, I still don't see why the peer
needs reset, simply because of the bucket change, as long as session
negotiated parameters aren't affected.  It seems like this is being
done just because.

#
#However if you deactivate the peer first and then modify its export
#policy this will not happen. I hope you can use that as a workaround
#while we don't get around to do something smarter in the code.

Let the software do this.  Peers are going down either way.  Why not
minimize impact.  Having the default behavior reset the peer I am
changing, is much less shocking to the operator, than dumping other
seemingly unchanged peers.

#We have also been asked by several customers to document the current
#behaviour bettter...
#
#  Pedro.
#

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBP9mC8NFQh6ARB7TZEQKOKQCfVKc7XGG94GT890WYVAhqshZqCB4An3y2
8HqNRq9AkEqydRlk6OlOcNWc
=Eh2C
-----END PGP SIGNATURE-----