Hi Jakob, Thanks for the comments. Please see inline [Bruno]
> From: GROW [mailto:[email protected]] On Behalf Of Jakob Heitz (jheitz) > Sent: Monday, June 26, 2017 2:16 AM > > 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. [Bruno] I'll initiate a thread to rediscuss this point. Then we'll see the outcome to update the draft. > I think section 6 for link up should stay. > The cases desctibed are real, whether corner or not. [Bruno] agreed. > 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. [Bruno] Indeed. In the draft, we presented the IBGP Route Reflector case, as we though that RR is more common than full mesh. Note that both cases are essentially the same: - IBGP full mesh between ASBR in your example - IBGP full mesh between RR in the draft In both cases, we have: - a distributed convergence with 2 nodes involved, - multiple/many IBGP sessions, creating multiple signaling paths, where a BGP UPDATE flowing along a 'long' path (2 sessions) may arrive after a BGP session flowing along a 'short' path (1 session). (Unfortunately) I agree that this is not theoretical. > "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. [Bruno] Agreed. Proposed text: OLD: In the case of a shutdown of a router, a reconfiguration of the outbound BGP route policies of the g-shut initiator SHOULD be performed to set a low LOCAL_PREF value for the paths originated by the g-shut initiator (e.g, BGP aggregates redistributed from other protocols, including static routes). This behavior is equivalent to the recommended behavior for paths "redistributed" from eBGP sessions to iBGP sessions in the case of the shutdown of an ASBR. NEW: In the case of a shutdown of the whole router, in addition to the g-shut of all EBGP sessions, there is a need to g-shut the routes originated by this router (e.g, BGP aggregates redistributed from other protocols, including static routes). This can be performed by tagging such routes with the g-shut community. Thanks, Regards, --Bruno > 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 _________________________________________________________________________________________________________________________ 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 [email protected] https://www.ietf.org/mailman/listinfo/grow
