[c-nsp] behavior of BGP when new address families are enabled (BGP dynamic capability)

[Tassos Chatzithomaoglou]

Nick, that's what also i'm doing in case of dual RRs. But, as you say, it's pain in the a**.
I was hoping for at least a simple knob like "activate-on-reset" which would enable this and similar capabilities only after the BGP session was reset (for whatever reason).
Then i could pre-configure all sessions with the new address families and just do a bgp reset on the RRs to activate them.

Nick Hilliard wrote on 08/08/2013 15:49:
> On 08/08/2013 13:36, Tassos Chatzithomaoglou wrote:
>> Can anyone provide any inside info what we should expect in this area?
> broadly speaking, you need to plan on lots of bgp session resets.  As you
> note there is no option in the bgp protocol at the moment to renegotiate
> capabilities after session startup.  So each side would need to be aware of
> all future AFIs that you would want to run on each session.
>
> In practice, I've been handling this recently having a preexisting
> configuration which uses multiple RRs for each client bgp speaker.  This
> means that you can upgrade one RR to supporting the new afi / capability,
> then upgrade each session, one by one, then when everything is configured
> up on the migrated RR, you can shift the other side over.  This is very
> messy though.  It means that you need to disentangle the peer-group
> configurations for each RR session, and then reconfigure them once the work
> is done.  So while it can be done hitlessly (and in many cases scriptably)
> with some planning, it's still a pain.
>
> Nick
>
>
>