Re: [Idr] new thread regarding capabilities handling

[Jeffrey Haas <[e-mail]>]

On Thu, Apr 27, 2017 at 08:14:07AM +0200, Mikael Abrahamsson wrote:
> >  https://www.ietf.org/archive/id/draft-ietf-idr-dynamic-cap-14.txt
> 
> So this is a draft first posted in 2001, with a last revision in 2011.
> 
> What's the back story here? This is obviously a well-known
> understood problem then for 16 years already, why don't we still
> have this in 2017?

Part of the issue with dynamic caps was that they renegotiated capabilities
in general.  The edge cases of having to rebuild everything dynamically that
you could negotiate and still keep a peering session up was... ugly.

A simple example would be what would happen if you added or deleted the
add-paths capability. 

I know there was discussion at one point to simplify the proposal to simply
to allow new AFI/SAFI to be re-negotiated.

The BGP multisession proposal tried to cover one other piece of the
headache.  Today, if you get a failure in one AFI/SAFI, we tear down BGP.
(You're allowed to "shut it down", but such well behaved failures are
relatively few.)  By having different sessions for the AFI/SAFI, you get
structural segregation of those classes of packet formatting errors.

The issues with multisession, aside from burning precious sockets, is that
there's state that is really shared among the family types.  The question
then becomes how you share that state appropriately when the sessions can
move at different asynchronous paths.

-- Jeff