Hi Robert, From: Robert Raszuk Sent: Friday, March 17, 2017 12:30 PM
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. [Bruno] The benefit of using a well-known community is that everyone uses the same. Otherwise, the operator shutting down/reloading a node with 50 EBGP sessions would need to attach 50 different communities. And update this list of communities as peer are configured/unconfigured. - - - 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. [Bruno] - The sending of community may be automated just like the sending of another message. - Again, whatever type of message you use over the EBGP session, on the receiving peer it needs to be translated in deprefering each route and sending N updates to peers. And yes, some peers may converge quicker than others, but there is nothing you can do about this. A clever implementation could use heuristic to evaluate the BGP convergence of its peer (e.g. by measuring inbound traffic). But typically a single timer is enough, because in all cases, people will not wait/delay their maintenance forever. So if they can afford to wait 5 minutes, they wait 5 minutes and then close the BGP session regardless the speed of their peer. 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. _________________________________________________________________________________________________________________________ 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
