Hi Will, Thanks for the comments. Please see inline [Bruno]
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Will Hargrave > Sent: Saturday, June 24, 2017 12:46 PM > > 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: [Bruno] ok. " g-shut neighbor ASBR" feels not so easy to read. Proposing OLD: On each ASBR supporting the g-shut procedure, NEW: On each ASBR supporting the g-shut neighbor procedure, > > I don’t think the ‘neighbor’ / ‘initiator’ terminology is very > clear, but I struggle to find more appropriate terms right now. > ‘g-shut receiver’? [Bruno] would work for me as this is close to the "Graceful Restart" terminology using Restarting Speaker / Receiving Speaker. Would also require changing the same of the neighbor AS: OLD: Neighbor AS: the Autonomous System of the g-shut neighbor. NEW: Receiver AS: the Autonomous System of the g-shut receiver. Waiting for some more feedback before applying the change. > > 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’. [Bruno] would the below change work for you? OLD: apply an outbound BGP route policy on the maintained eBGP session to tag the paths propagated over the session with the g-shut community. NEW: apply an outbound BGP route policy on the eBGP session to be shutdown. This policy tags the paths propagated over the session with the g-shut community. > 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. [Bruno] I feel that this is useful to state that the establishment of an EBGP session can trigger loss of connectivity, as I don't feel that this is obvious to everyone, nor intuitive. (this is supposed to be a "good news"). In term of draft clarity, this draft mix both an operational procedure and discussion related to BGP convergence. Possibly the draft could be reorganized to better identify the operational procedure (currenly in §4.2.1 "EBGP g-shut". I'm considering the following change OLD: 4. Practices to avoid packet losses 4.1. Improving availability of alternate paths 4.2. Make before break convergence: g-shut 5. Forwarding modes and transient forwarding loops during convergence 6. Link Up cases 6.1. Unreachability local to the ASBR 6.2. iBGP convergence NEW: 4. Practices to avoid packet losses 4.1. Improving availability of alternate paths 4.2. Make before break convergence: g-shut [4.2 introduction only] 4.3 Forwarding modes and transient forwarding loops during convergence 5 EBGP g-shut procedure 5.1 pre-configuration 5.2 operation at maintenance time 5.4 BGP implementation support for g-shut 6. Other cases 6.1 IBGP g-shut 6.2 Link Up cases Thanks again for the comments, Regards, --Bruno > 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 > GROW@ietf.org > 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
