Job, > From: Job Snijders [mailto:j...@ntt.net] > Sent: Monday, June 26, 2017 5:39 > PM > > On Mon, Jun 26, 2017 at 01:58:40PM +0000, bruno.decra...@orange.com wrote: > > Hi Job, all > > > > > From: Job Snijders [mailto:j...@ntt.net] > Sent: Thursday, June 22, > > > 2017 10:47 PM > > [...] > > > > > I think that the neighbor ASBR should _not_ strip the GSHUT > > > well-known community. > > > > I'm personally open to both options. > > Discussing this further: > > > > - First of all, stripping the g-shut well-known community fits the > > goal of the document and its requirements (RFC 6198). The main > > motivation is to have a g-shut solution with no required BGP protocol > > extension, and where the backup path is known to the AS. i.e. we are > > not looking for an Internet wide convergence/g-shut. We are primarily > > interested in a g-shut within the responsibility of the AS. IOW, when > > it's "my fault" if my customer experiences a packet loss. In this > > case, there is no need to propagate the g-shut community further. > > > > - removing the g-shut community reduces Internet wide churns, > > including compared to when g-shut is not used. > > Here are the 3 cases, focusing on the first step of the BGP > > convergence (searching for the backup path) > > - No g-shut: a WITHDRAW is propagated to other ASes > > - g-shut propagating the community: an UDPDATE is propagated to > > others ASes (same path, adding the community) > > - g-shut removing the community: no BGP messages propagated to > > others ASes (same path, same communities/attribute) > > > > In general, reducing the BGP churn is considered as a feature. By > > removing the g-shut community, we are at the same time: > > a) g-shut in both affected ASes > > b) reducing Internet churn. > > > > Now if we choose to not remove the community, we improve "a" by > > covering the cases where the backup path is unknown to the AS. And we > > keep "b" unchanged compared to today (but degrade it compare to > > current g-shut draft). > > I don't think we really have a say in whether BGP Communities are > removed or not. This is outside our control. If we remove the hard > requirement to remove the community, the behaviour falls back to > https://tools.ietf.org/html/rfc7454#section-11 which imho is fine: leave > the choice with the operator. Perhaps the draft does not need to define > whether to strip or not. > > I have to admit that the first time I used a a 'g-shut -06 compliant' > automated process, I was surprised that that I didn't see the community > on the IBGP outbound announcements. Removing the community somewhat > reduces visibility to those involved with the operation. > > > As for my requirements, I'm considering that our ASes have the > > knowledge of the backup path. Hence I don't need for the extra > > coverage. Regarding the extra cost, I agree that one can hardly > > consider this unacceptable since this is the current behavior. > > > > TL;DR: it's a tradeoff between 2 secondary objectives: > > - reducing Internet churned (compared to today) > > - improving the g-shut coverage when the AS does not know the backup path > > + improve visibility into the operation > > > Draft can possibly discuss both options, at the cost of additional > > reading complexity. But this possibly could be discussed in a > > different section. > > > > I'd welcome more opinion, before choosing the main text. > > Bruno, perhaps my interpretation of the above sentence's phrasing is > somewhat mangled because neither of us are a native speaker, but keep in > mind this is a GROW working group document. :-)
To rephrase: I'd welcome more feedback from the GROW WG before reflecting the consensus in the document. --Bruno > Kind regards, > > Job _________________________________________________________________________________________________________________________ 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
