> From: Job Snijders [mailto:j...@instituut.net] > Sent: Wednesday, March 15, > 2017 4:37 PM > > On Tue, Mar 14, 2017 at 04:55:25PM +0100, Gert Doering wrote: > > On Tue, Mar 14, 2017 at 04:49:10PM +0100, Job Snijders wrote: > > > On Tue, Mar 14, 2017 at 04:41:06PM +0100, Gert Doering wrote: > > > > On Tue, Mar 14, 2017 at 03:07:32PM +0000, bruno.decra...@orange.com > > > > wrote: > > > > > 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). > > > > > > > > How's the IXP operator going to introduce a gshut message into a > > > > BGP session between IXP customer A and IXP customer B? > > > > > > an IXP can't, and I am not under the impression that Bruno was > > > suggestion to do so. I took his comments as applicable to section 2.1 > > > > > > this is why the proposed draft contains two angles: one for IXPs and one > > > for ISPs, each with their different nuances. > > > > Indeed, for a direct ISP-ISP link, and the maintenance being > > controlled by one of the peering parties, gshut would be a useful > > approach (if it's known that the other party has deployed it). > > I've come to understand that even if the remote party does not support > gshut, at least in one direction there will be benefit (downpreffing of > routes received from the BGP neighbor which is about to be shut down).
You are right. Most network usages are bidirectional, in which case improving one way has probably no benefit. However, this may still be beneficial when: - routing is asymmetric - BGP convergence time is different in both directions (which is typically the case) and we can improve the slowest direction (typically the one receiving a higher number of routes, although hardware/software also plays a significant role) > > Since the title of the draft is "session-culling" it feels somewhat > > out of scope to go more into detail on gshut, but a reference might be > > useful. > > Perhaps if the gshut draft is revived, a reference indeed is appropiate. We will revive it, probably removing the non-transitive community part. Kind regards, --Bruno > I may have been too soon in my dismissal. Ben Maddison aptly pointed out > that gshut is part of Ben's Current Practices. :-) > > Kind regards, > > Job _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
