Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017).

<bruno.decraene@orange.com> Tue, 30 May 2017 16:27 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE780126CD6 for <idr@ietfa.amsl.com>; Tue, 30 May 2017 09:27:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.398
X-Spam-Level:
X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNmT2psWsVSu for <idr@ietfa.amsl.com>; Tue, 30 May 2017 09:27:16 -0700 (PDT)
Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2C1129AA4 for <idr@ietf.org>; Tue, 30 May 2017 09:27:16 -0700 (PDT)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id D2929405CC; Tue, 30 May 2017 18:27:14 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id AA14D1C0069; Tue, 30 May 2017 18:27:14 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0339.000; Tue, 30 May 2017 18:27:14 +0200
From: bruno.decraene@orange.com
To: Susan Hares <shares@ndzh.com>, 'idr wg' <idr@ietf.org>
Thread-Topic: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017).
Thread-Index: AdLRTCaZKPuw1yo2RQSbPHINWp1hYAIFIUbw
Date: Tue, 30 May 2017 16:27:13 +0000
Message-ID: <6485_1496161634_592D9D62_6485_13175_1_53C29892C857584299CBF5D05346208A31D3244C@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <001e01d2d14c$32ed2e10$98c78a30$@ndzh.com>
In-Reply-To: <001e01d2d14c$32ed2e10$98c78a30$@ndzh.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A31D3244COPEXCLILM21corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/AET97JqRledAJogmoUn0tQp3ugE>
Subject: Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017).
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 May 2017 16:27:19 -0000

Hi Sue, authors, all,

Unfortunately, I'm not up-to-date on this subject, so please take my comments with a grain of salt.

Support.
As it looks like a valid idea, with incremental deployment and incremental benefits.

Possible comments:
- possibly, there could be additional usage/value if the iOTC attribute were carrying the role within the AS, rather than being only a flag. For example it could be used in routing policies (as a read-only-memory) e.g. to set the preference of routes. Indeed, my understanding is that this info is double checked hence more reliable than a BGP community that the receiver could set with no additional checks. So a priori a better source of info for a routing policy
- a priori, as per current text, the iOTC attribute seems advertised over EBGP session and not removed on the reception side. I'm not sure whether this is a design goal or a bug.
- 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).

Regards,
--Bruno


From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Saturday, May 20, 2017 11:34 AM
To: 'idr wg'
Subject: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017).

This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017)

The authors should indicate if they know of any IPR related to this document.  You can find the document at:

https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/

Sue Hares



_________________________________________________________________________________________________________________________

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.