Re: [GROW] draft-iops-grow-bgp-session-culling-00

[Job Snijders <[e-mail]>]

On Tue, Mar 14, 2017 at 03:07:32PM +0000, [e-mail] wrote:
> > From: Job Snijders [mailto:[e-mail]]
> > 
>  > On Tue, Mar 14, 2017 at 02:28:56PM +0000, [e-mail] wrote:
>  > > > From: GROW [mailto:[e-mail]] On Behalf Of heasley
>  > > >
>  > >  > Mon, Mar 13, 2017 at 02:07:21AM +0100, Alejandro Acosta:
>  > >  > > What do you think in including also some suggestions when bringing up
>  > >  > > the BGP sessions?.  Sometimes it´s good idea to bring them up one by one
>  > >  > > or something like that, the idea is to make the device to fill out the
>  > >  > > forwarding table, create cache, perform ARP lookups, ND, and so on. To
>  > >  > > bring up all the session at once many times is not that good.
>  > >  >
>  > >  > I'd expect this to prolong and exacerbate the 'path hunting', while the
>  > >  > min-advert-timer might help to squelch it if all sessions are enabled
>  > >  > at the same time - after the IGP settles, which is automatic in some
>  > >  > impl..
>  > >  >
>  > >  > randy, link to path hunting paper?  i can't seem to find it.
>  > >
>  > > For the BGP shut, in section 2.1. " Voluntary BGP Session Teardown
>  > > Recommendations" you could propose or at least reference BGP Graceful
>  > > shutdown https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06
>  > > In very short, it initiates the path hunting for the backup BGP path,
>  > > _before_ the withdraw of the nominal path. Tests have shown that 0
>  > > packet loss is achievable (assuming that within the AS, tunneling is
>  > > used in order to avoid micro-loops during iBGP convergence). But if
>  > > one is not targeting 0 packet loss, which is typically the case in the
>  > > Internet ecosystem, there is no requirement for tunneling.
>  > >
>  > > In short, over eBGP, routes to be withdrawned are tagged with a "well
>  > > known" community, in order to be de-preferred on the receiving side.
>  > >
>  > > Some vendors have automated this. But one may also do it manually
>  > > using BGP policies.
>  > 
>  > I appreciate the effort and thought that has gone into gshut, but I am
>  > not aware of actual deployments and as scuh certainly cannot vouch for
>  > using this method as a 'best current practise'. it may be a 'future best
>  > practise' - but that is not now.
> 
> Referencing does not necessarily imply recommending as BCP.
> 
> On a side note, I'd be interesting to know why reducing the impact of
> the maintenance using gshut is not considered as worth it, while it is
> for culling. Especially since the benefit of the latter is 90 second
> (and configurable)  while the former is minutes (and not
> configurable).

well, to be frank: because one is an existing practise, the other isn't?

But I'm not closing the door: BCPs can be enhanced over time, which
makes them a very useful vehicle for such ongoing betterment of
interconnection maintenance strategies. Perhaps when gshut is either a
commonly accepted practise, and maybe has a different document status it
would be good to add it to the toolbox.

Kind regards,

Job