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).
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

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.

Thanks,
Regards,
--Bruno


_________________________________________________________________________________________________________________________

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

Reply via email to