[Idr] draft-ymbk-idr-bgp-open-policy

<bruno.decraene@orange.com> Thu, 01 June 2017 16:41 UTC

From: bruno.decraene@orange.com
To: Alexander Azimov <aa@qrator.net>
CC: idr wg <idr@ietf.org>
Thread-Topic: draft-ymbk-idr-bgp-open-policy
Thread-Index: AdLa8lgJ/9HadtkjQLSyk1+ns+QSqg==
Date: Thu, 01 Jun 2017 16:40:56 +0000
Message-ID: <31600_1496335256_59304398_31600_9730_1_53C29892C857584299CBF5D05346208A31D372FB@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A31D372FBOPEXCLILM21corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/GugEU0AwQL16YFjCbERQP18SjBU>
Subject: [Idr] draft-ymbk-idr-bgp-open-policy
Precedence: list

Hi Alexander,

Thanks for your feedback.
1 follow-up inline [Bruno]


From: aa@highloadlab.com [mailto:aa@highloadlab.com] On Behalf Of Alexander Azimov
Sent: Thursday, June 01, 2017 6:07 PM

[…]

- Possibly, the "Strict mode" could be the only one/the mandated behavior. To allow for backward compatibility, the non-compliant peer could tag routes with "well-known" BGP communities, to be defined by this document, and indicating the role (on a per route basis).
'Strict mode' by default seems to me too radical. It will result in problems at state of partial deployment, when after software update BGP session will not get up back. Also, please keep in mind, that roles are negotiated via OPEN messages, before any communities can be exchanged.

[Bruno] To rephrase, my proposal for this revised strict mode would be:

If my EBGP peer does not advertise the new capability in its OPEN, then this EBGP peer MUST tag its routes with a well know community reflecting its role, otherwise, I’m locally filtering them.
e.g. My Role is “Peer”
My EBGP neighbor advertise no role in its BGP OPEN
Then, I locally accept its routes iif they have the PEER_COMMUNITY and don’t have the CUSTOMER or PROVIDER _COMMUNITY

On the pro side:
- the same role double check is performed.
- faster to deploy as it does not require both EBGP peers to support the new feature, hence more incentive for the first AS(es) to ask for the feature as they will collect benefit; while currently the incentive to pay for the implementation/deployment of the feature is more limited as I don’t get benefits until my peers support it.

On the con side:
- only protects me (received routes), not the other direction
- additional complexity to handle both signaling (capability and community), in order to only provide short term benefits
- the peer needs to tune its policy in order to set the community.

I guess it all depends on whether you believe this feature will be implemented easily by many vendors, or not (in which case more incentive for the first deployment would help bootstrapping implementations and deployments, for the benefit of all/the Internet). You probably know better than anyone, so it’s really up to you.

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

[Idr] draft-ymbk-idr-bgp-open-policy bruno.decraene