[j-nsp] BGP Prefix-Limit On A Session

[bbird at epik.net]

#-----Original Message-----
#From: Paul Goyette [mailto:pgoyette at juniper.net] 
#Sent: Thursday, February 26, 2004 9:58 AM
#To: juniper-nsp at puck.nether.net
#Subject: RE: [j-nsp] BGP Prefix-Limit On A Session
#
#> I am aware that this will always happen wrt to export-policy 
#> changes, and how JunOS internally groups based on a common set
#> of attributes that control export policy (for scalability).  
#> However, It didn't make much sense that this would be related 
#> to prefix-limits as well.  I am told that behavior was a bug, 
#> and was due to be fixed at some point?  Can anyone at Juniper 
#> confirm that?
#
#As far as I know, this is not a bug.  When you add the peer's
#new attribute, you differentiate that peer from the rest within
#the group.  As a result, internally the group is "split" into
#two groups, one with the new attribute and one without it.  If
#the "other" peers end up in the newly created group, you will
#see the described behavior, since they are actually moved from
#one group to another.  If the "other" peers remain in their
#original group (and thus it is the "modified" peer that moves)
#you will not see this behavior, since the "other" peers don't
#move.

I completely understand that behavior (even though I don't always agree with
it).  I understood that behavior only pertained to export policy, no?  The
way I understand it is, JunOS organizes peers into operational groups for
the purpose of consolidating bgp updates and export policy evaluation. This
being done for scalability.  Let me clarify... 

What I am concerned with is 'family inet any prefix-limit'.  I don't see how
that knob relates to export-policy, at all.  However, it produces similar
behavior, where unchanged peers are bounced when a prefix-limit is applied
to a neighbor in the same group (5.3R2.4...I know, I know...).  When I
originally opened a TAC case (which history has been removed) on it, I was
told that adding a prefix-limit should not affect other sessions in the same
bgp group, and would be fixed at a later date.

I can "almost" understand why JunOS would reset the BGP session where a
newly added prefix-limit is applied.  I would have to do my research, but I
didn't think that prefix-limit was a session negotiated parameter (could be
wrong here).  So even resetting the session being changed, with respect to
prefix-limit, doesn't even make much sense to me.  But I see no reason why
unchanged peers should be reset, when adjusting a locally significant
attribute that doesn't pertain to export policy.

-Ben Bird