I agree with Job's proposals. In particular, the removal of the g-shut community should be carefully considered. On the one hand, the g-shut community may not be originated by the neighbor and is valid wherever the route may be advertised. On the other hand, in the IPv4 and IPv6 address families, if an alternate route is not available, the g-shut community can be spread throughout all routers in the world, causing excessive churn. I understand that this issue has been discussed in the working group, but the concerns should be written into the RFC.
I think section 6 for link up should stay. The cases desctibed are real, whether corner or not. It does not even need route reflectors to happen. All that is required is for a withdraw message to be processed by a router before the new announcement. Consider: R2 is announcing the best-path. R1 was under maintenance and is coming up. R1 advertises the new path to R2. R2 withdraws its path. R1 advertises the new path to R3. R3 receives or processes the withdrawal from R2 before the advertisement from R1. "4.2.3 Router g-shut" should make it clear that the behavior is in addition to the behavior of the links being shut down. Shutting down a router means all its links are going down too. In addition, the gshut community should be tagged onto the originated routes. Thanks, Jakob. > -----Original Message----- > From: GROW [mailto:[email protected]] On Behalf Of Will Hargrave > Sent: Saturday, June 24, 2017 3:46 AM > To: Job Snijders <[email protected]> > Cc: [email protected] > Subject: Re: [GROW] draft-ietf-grow-bgp-gshut > > On 22 Jun 2017, at 21:47, Job Snijders wrote: > > Hi all, a few comments below: > > > NEW (in Pre-configuration): > > On each ASBR supporting the g-shut procedure, an inbound BGP route > > policy is applied on all BGP sessions of the ASBR, that: > > o matches the g-shut community > > o sets the LOCAL_PREF attribute of the paths tagged with the > > g-shut > > community to a low value (a value of zero is recommended). > > Since we define some terminology in 2., we should use it: > > On each g-shut neighbor ASBR, an inbound BGP route policy is applied on > all BGP sessions of the ASBR, that: > > > I don’t think the ‘neighbor’ / ‘initiator’ terminology is very > clear, but I struggle to find more appropriate terms right now. > ‘g-shut receiver’? > > > NEW (in Operations at maintenance time): > > On the g-shut initiator, upon maintenance time, it is required to: > > o apply an outbound BGP route policy on the maintained EBGP > > session > > to tag the paths propagated over the session with the g-shut > > community. This will trigger the BGP implementation to re- > > advertise all active routes previously advertised, and tag them > > with the g-shut community. > > o apply an inbound BGP route policy on the maintained EBGP session > > to tag the paths received over the session with the g-shut > > community and set a low LOCAL_PREF value. > > ‘Maintained’ (in ‘maintained EBGP session’) is not a useful word > to use here, since ultimately the session is not to be maintained at > all! Perhaps “eBGP session” is clear enough, or use ‘impacted’ > or ‘relevant’. > > > I have a further comment on section 6. Link Up cases. I rather feel this > is a separate body of work, and belongs in some sort of ‘gshut-bis’ > where we can extend on this technique. Certainly there is nothing in the > rest of the draft which prevents the use of gshut technique to improve > link-up behaviour, so I would remove sections 6/6.1/6.2 for clarity. > > Behaviour in relation to next-hop reachability across a multi-access > network is of particular interest to me as an IXP operator, and is > probably a whole topic of its own. > > > -- > Will Hargrave > Technical Director > LONAP Ltd > +44 114 303 4444 > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
