On Tue, Mar 14, 2017 at 03:07:32PM +0000, bruno.decra...@orange.com wrote: > > From: Job Snijders [mailto:j...@instituut.net] > > > > On Tue, Mar 14, 2017 at 02:28:56PM +0000, bruno.decra...@orange.com wrote: > > > > From: GROW [mailto:grow-boun...@ietf.org] 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 _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
