Hi Robert, If we all agree community approach is the best for signalling to peer that this prefix should be avoided why folks just do not do it today already ? Why do we need IETF draft for that :) ?
If this is about publishing a communities which include "warning" to peers "Hey I am bringing this prefix down soon .. "(maybe even with parameter how soon :))) what stopping Orange to declare we will attach YZ:MN community and re-advertise routes when we are to take down the session. That way any peer of Orange may use it at their own discretion. [BEN] Nothing is stopping them. The primary benefit is the use of a well-known community that can be matched in generically constructed policies without prior knowledge of whether the peer makes use of this procedure, and what community they use for the purpose if they do. - - - The idea behind putting single message in NOTIFICATION was just to automate it and make it deterministic. When you send community some peers may converge quicker some much slower. You never know when your peer is done. Here only after his best path and rib insertion of new paths around you is complete he would tear the session. Some timeout would be defined as well. And it will apply to all AFI/SAFIs as well as current and future BGP messages send over given session. [BEN] From a quick read of RFC4271: “A NOTIFICATION message is sent when an error condition is detected. The BGP connection is closed immediately after it is sent.” I can’t find any updates that contradict that. If I understand your suggestion correctly, you mean: 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. If so, that sounds like a hell of a lot of new protocol spec and router code, to solve a fairly marginal issue. The determinism that you gain only goes one hop into the remote network (as B’s other peers may still be converging when the session goes down), and is therefore only guaranteed to be useful if that network tunnels between ASBRs. It is also unclear what a BGP speaker that didn’t understand the new code would do when receiving a NOTIFICATION that wasn’t immediately followed by a session reset. I suspect that would vary widely by implementation and be the source of some fairly nasty bugs! Compared to a line in an RFC suggesting reasonable timer values between gshut and shutdown, this seems to be a lot more work for very little benefit. Cheers, Ben Maddison Director Workonline Communications (Pty) Ltd Office: +27 (0) 21 200 9000 Mobile: +27 (0) 82 415 5545 Email: b...@workonline.co.za<mailto:b...@workonline.co.za> SIP: b...@workonline.co.za<sip:b...@workonline.co.za> [Workonline Communications]<http://www.workonline.co.za/> From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk Sent: Friday, March 17, 2017 1:30 PM To: Ben Maddison <b...@workonline.co.za> Cc: bruno.decra...@orange.com; grow@ietf.org Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status? Hi Ben & Bruno, If we all agree community approach is the best for signalling to peer that this prefix should be avoided why folks just do not do it today already ? Why do we need IETF draft for that :) ? If this is about publishing a communities which include "warning" to peers "Hey I am bringing this prefix down soon .. "(maybe even with parameter how soon :))) what stopping Orange to declare we will attach YZ:MN community and re-advertise routes when we are to take down the session. That way any peer of Orange may use it at their own discretion. - - - The idea behind putting single message in NOTIFICATION was just to automate it and make it deterministic. When you send community some peers may converge quicker some much slower. You never know when your peer is done. Here only after his best path and rib insertion of new paths around you is complete he would tear the session. Some timeout would be defined as well. And it will apply to all AFI/SAFIs as well as current and future BGP messages send over given session. Best, R. On Fri, Mar 17, 2017 at 12:14 PM, Ben Maddison <b...@workonline.co.za<mailto:b...@workonline.co.za>> wrote: Hi Robert, There is no requirement that peers implement anything at all. In the absence of any configured policy, the community gets ignored, and no action is taken prior to shutdown – which is exactly the status-quo without the draft, so no harm done. Each network is free to implement whatever ingress policy is sensible in their own view, which should be to take the same action as when receiving an IXP list mail saying “we’re gonna shut x,y,z down shortly…”. The difference is they can now handle that in BGP policy to avoid the manual NOC activity. Also, there is no additional code required (assuming support for 1997) in order to implement the bare bones of the functionality – e.g. match on 65535:0, set local-pref. The automation features around it (such as neighbor shutdown graceful on XE) need new software, but are also trivial to recreate in an in house EMS if people are that pathological about touching their routers. The only problem scenario that I can see is where someone is using 65535:0 for a different purpose in eBGP. But some people are beyond help! Cheers, Ben Maddison Director Workonline Communications (Pty) Ltd Office: +27 (0) 21 200 9000<tel:+27%2021%20200%209000> Mobile: +27 (0) 82 415 5545<tel:+27%2082%20415%205545> Email: b...@workonline.co.za<mailto:b...@workonline.co.za> SIP: b...@workonline.co.za<mailto:b...@workonline.co.za> [Workonline Communications]<http://www.workonline.co.za/> From: GROW [mailto:grow-boun...@ietf.org<mailto:grow-boun...@ietf.org>] On Behalf Of Robert Raszuk Sent: Friday, March 17, 2017 12:39 PM To: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> Cc: grow@ietf.org<mailto:grow@ietf.org> Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status? Hi Bruno, [Bruno] The goal was to be able to use gshut even if both EBGP peer are not enhanced to support it. The benefit of flagging routes with a community is that gshut may be implemented on vanilla routers using a BGP route map/policy. Sure thing. However peers need to be consistently configured with the same policy to understand the meaning of the community. If you think this is easy - great. Incremental deployment in a benefit, in particular between AS/organisations, and in particular on small/low end routers which are not replaced every 4 years. Well it is not router replacement .. it is software upgrade. But sure if you can convince peers to setup same error free policy that is perfect. No objections at all :). Best, R.
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
