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 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: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Robert Raszuk Sent: Friday, March 17, 2017 12:39 PM To: bruno.decra...@orange.com Cc: 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
