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> 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 <+27%2021%20200%209000> > > Mobile: +27 (0) 82 415 5545 <+27%2082%20415%205545> > > Email: b...@workonline.co.za > > SIP: b...@workonline.co.za > > > > [image: 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
