Hi Robert, Not that long ago we went via tsunami of IDR on and offline emails when discussing large communities which contained "operators" voice stating *NO* to any well known or predefined meaning to the communities nor welcomed any predefined actions associated with the communities.
Everyone wants to assign his own and inform interested parties about such meaning. Has that already changed just few weeks after the RFC was issued :-) ? I was one of those operators saying *NO*! By definition, well-known communities have a meaning that is not specific to a particular ASN. The lack of encoding space in std-comms for 32bit ASNs is therefore a non-issue. There is certainly operator value in well-known communities, but they don’t need to be recreated in large-comms – unless you think that there are more than 65535 useful meanings that we can all agree on?! Cheers, Ben Maddison Director Workonline Communications (Pty) Ltd Office: +27 (0) 21 200 9000 Mobile: +27 (0) 82 415 5545 Email: [email protected]<mailto:[email protected]> SIP: [email protected]<sip:[email protected]> [Workonline Communications]<http://www.workonline.co.za/> From: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk Sent: Friday, March 17, 2017 2:34 PM To: Ben Maddison <[email protected]> Cc: [email protected] Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status? > The primary benefit is the use of a well-known community Not that long ago we went via tsunami of IDR on and offline emails when discussing large communities which contained "operators" voice stating *NO* to any well known or predefined meaning to the communities nor welcomed any predefined actions associated with the communities. Everyone wants to assign his own and inform interested parties about such meaning. Has that already changed just few weeks after the RFC was issued :-) ? 1. the peer initiating the shutdown (A) sends its peer (B) a NOTIFICATION with a new error code that means “I’m going away shortly, please start re-converging and let me know when you’re done”. 2. B attempts to re-converge around the paths learnt from A (possibly needing to initiate a route-refresh in the process?), and once it no longer has any of those routes in its FIB sends A back a further NOTIFICATION saying “I’m finished” and then shuts the session down. 3. If A hasn’t heard back within a configurable timeout, then it yanks the session anyway. Yes that's good summary. If so, that sounds like a hell of a lot of new protocol spec I don't think this is that complex. And use of NOTIFICATION message was just an example. One could also put it in new OPERATIONAL message. Anyhow just a suggestion how to improve protocol if there is real need. If this however as you said "fairly marginal issue" then let's not bother. Cheers, R.
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
