Re: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02

<bruno.decraene@orange.com> Tue, 06 January 2015 16:38 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66221A040B for <idr@ietfa.amsl.com>; Tue, 6 Jan 2015 08:38:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 oSce2iS_wqZK for <idr@ietfa.amsl.com>; Tue, 6 Jan 2015 08:38:51 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550E01A0387 for <idr@ietf.org>; Tue, 6 Jan 2015 08:38:51 -0800 (PST)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id BB5DA2AC7F7; Tue, 6 Jan 2015 17:38:49 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 8DC481580EF; Tue, 6 Jan 2015 17:38:49 +0100 (CET)
Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Tue, 6 Jan 2015 17:38:48 +0100
From: bruno.decraene@orange.com
To: Susan Hares <shares@ndzh.com>
Thread-Topic: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02
Thread-Index: AdAbkULeZViW4uCIRLy+k1dsWqlgXgOLv8UQ
Date: Tue, 06 Jan 2015 16:38:47 +0000
Message-ID: <2403_1420562329_54AC0F99_2403_19702_1_53C29892C857584299CBF5D05346208A0EAEDDFB@PEXCVZYM11.corporate.adroot.infra.ftgroup>
References: <01c401d01b91$feca19d0$fc5e4d70$@ndzh.com>
In-Reply-To: <01c401d01b91$feca19d0$fc5e4d70$@ndzh.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.4]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0EAEDDFBPEXCVZYM11corpo_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.200030
Archived-At: http://mailarchive.ietf.org/arch/msg/idr/gCqWkjcVmLQ9Cw6PVlc6n_3Lrsg
Cc: "idr@ietf.org" <idr@ietf.org>, "robert@raszuk.net" <robert@raszuk.net>
Subject: Re: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 06 Jan 2015 16:38:59 -0000

Hi Sue, John, all

I support WG adoption.

AFAIK, I don't have a use case for this (so personally I could live without) but the RTC  RFC has an issue and therefore, from and STD standpoint, IMO this at least needs to be documented.

Regarding the solution, I would a priori prefer the alternate solution (from Appendix A in v01 / the original solution proposed in v00; ala "Best External") rather than the solution currently proposed in v02 (ala "Add Path") for the following reasons:
- "Add Path" heavily depend on configuration to be done by the Service Provider. This add complexity to the provisioning system which would need to look at the iBGP client's configuration to see if it itself have an iBGP client session
- It looks to me that even the "Add Path" solution requires protocol extension (not crystal clear but the draft asks for STD track) and implementation change. So no specific advantage for "Add Path" on this point.
-The "Best External" solution is IMO more inlined with the current RTC spec/point of view which is to limit BGP states/path at the cost of a specific iBGP propagation rule. Looks more coherent to me and easier from an operational point to have all sessions within the AS behaving along  the same principles.

Specific comment:
- In §3.1 (add path solution)
"The number of RT-Constrain routes to be advertised is a local decision of operators. »
IMO "add path all" is needed, unless you define a new Add Path mode that you would need to specify.


Thanks,
Regards,
Bruno

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, December 19, 2014 2:45 PM
To: idr@ietf.org
Cc: robert@raszuk.net
Subject: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02


The IDR Chairs intend to adopt the draft-dong-idr-rtc-hierarchical-rr-02 as a WG draft.  This is a 1 week final call for comments on the adoption of this draft as WG draft.  The draft can be found at:

http://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/


Sue Hares and John Scudder



_________________________________________________________________________________________________________________________

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.