Hi all, In-line as [BM]
On Mon, 2017-06-26 at 17:39 +0200, Job Snijders wrote: > 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. > > [BM] However, if by propagating the community we get reasonable Internet-wide g-shut coverage, then why prevent that? > > - 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) [BM] This generates an "interim" UPDATE (adding the community) only where the propagating AS has no alternate path. In that case, the additional UPDATE provides the remote AS an opportunity to re-converge around the shutdown at the AS-graph level, and therefore seems to me to have value. Alternatively, if the receiving AS does have an alternate path then: a) the alternate path is eligible for export, then an UPDATE may be generated if the alt-path has differing attributes. This UPDATE would eventually be generated at shutdown-time anyway, so no additional churn here; or b) the alternative path is not eligible for export, then a WITHDRAW is generated, which would be generated eventually at shutdown-time anyway, so no additional churn here either. > > - g-shut removing the community: no BGP messages propagated to > > others ASes (same path, same communities/attribute) [BM] Correct, but also no opportunity to reroute traffic around the AS that will shortly be sending a WITHDRAW anyway. > > > > 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. [BM] Agreed. I don't see a case for treating this community differently from any other 1997 community in this respect. > > 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 > [BM] In particular, a 3rd party that is trying to self-service an answer to the question "why did the traffic move" will be looking at a looking-glass rather than a router CLI. More visibility is particularly helpful in this case. Cheers, Ben > > 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 > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow -- Ben Maddison Director Workonline Communications (Pty) Ltd Office: +27 (0) 21 200 9000 Mobile: +27 (0) 82 415 5545 Email: b...@workonline.co.za SIP: b...@workonline.co.za _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
