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, [email protected] 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). > 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. 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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
