Re: [Idr] draft-ietf-idr-aigp-11.txt

<bruno.decraene@orange.com> Thu, 05 December 2013 16:39 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 64BA51AE0E1 for <idr@ietfa.amsl.com>; Thu, 5 Dec 2013 08:39:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 t6UW3DNc5VAb for <idr@ietfa.amsl.com>; Thu, 5 Dec 2013 08:39:53 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id A488D1AE0E7 for <idr@ietf.org>; Thu, 5 Dec 2013 08:39:52 -0800 (PST)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 96FC61B86A3; Thu, 5 Dec 2013 17:39:48 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 763B815805E; Thu, 5 Dec 2013 17:39:48 +0100 (CET)
Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 17:39:48 +0100
From: <bruno.decraene@orange.com>
To: "erosen@cisco.com" <erosen@cisco.com>
Thread-Topic: [Idr] draft-ietf-idr-aigp-11.txt
Thread-Index: AQHO74pcuoSGo+bDGECi5cTVyQxP7JpFzAUg
Date: Thu, 5 Dec 2013 16:39:46 +0000
Message-ID: <2500_1386261588_52A0AC54_2500_5002_1_53C29892C857584299CBF5D05346208A070B75F7@PEXCVZYM11.corporate.adroot.infra.ftgroup>
References: Your message of Mon, 02 Dec 2013 16:07:21 +0000. <8149_1386000442_529CB03A_8149_6663_1_53C29892C857584299CBF5D05346208A070A9D39@PEXCVZYM11.corporate.adroot.infra.ftgroup> <2578.1386008078@erosen-linux>
In-Reply-To: <2578.1386008078@erosen-linux>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.5.143019
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] draft-ietf-idr-aigp-11.txt
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: Thu, 05 Dec 2013 16:39:55 -0000

Eric,

Thanks for the updated version of the draft.
More inline.

>> - I understand why ADD PATH would be useful, while it is not cited in the
>>   text.
>> - I'm not sure to understand why conn-rest is useful.
>
>For context, here's the paragraph in question:
>
>   Using the AIGP attribute to achieve a desired routing policy will be
>   more effective if each BGP speaker can use it to choose from among
>   multiple routes. Thus is it highly recommended that the procedures of
>   [BESTEXT] and [CONN-REST] be used in conjunction with the AIGP
>   Attribute.
>
>The two references talk about conditions under which a path or paths other
>than (or in addition to) the bestpath should be announced.  The add-path
>draft itself really only provides a mechanism for distributing multiple
>paths.  So it seemed like a less informative reference.

Thanks for the clarification. Agreed.
And for clarification, my point was that fast-conn-restore seemed to target more the "fast restoration" application of add path than the "optimal routing" application. (and to some extent, this may also be true for BESTEXT)
As you wish, you may also cite draft-ietf-idr-add-paths-guidelines and possibly the add path mode(s) that you would recommend for AIGP. (e.g. AS-wide best path).

Best regards,
Bruno

>However, if the reference to conn-rest raises issues or leaves open
>questions, it might be best to replace it with a reference to add-path.  I
>certainly don't want to deal in this draft with issues like the one Robert
>mentioned, of whether AIGP can be used in place of Edge_Discriminator.

_________________________________________________________________________________________________________________________

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.