On Mon, Jun 26, 2017 at 01:58:40PM +0000, [email protected] wrote: > Hi Job, all > > > From: Job Snijders [mailto:[email protected]] > 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. :-) Kind regards, Job _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
