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

<bruno.decraene@orange.com> Wed, 07 January 2015 08:18 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 01D0D1A8982 for <idr@ietfa.amsl.com>; Wed, 7 Jan 2015 00:18:53 -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 V3i5NdGofCsR for <idr@ietfa.amsl.com>; Wed, 7 Jan 2015 00:18:46 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 784091A8980 for <idr@ietf.org>; Wed, 7 Jan 2015 00:18:45 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id A5C4626448E; Wed, 7 Jan 2015 09:18:43 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 8F5EA4C0BF; Wed, 7 Jan 2015 09:18:43 +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.0224.002; Wed, 7 Jan 2015 09:18:43 +0100
From: <bruno.decraene@orange.com>
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>
Thread-Topic: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02
Thread-Index: AdAbkULeUJzReBiSYA0MoRmxPsIV2wOLv8UQ//+aqAD//pCdUP/9ECgQ
Date: Wed, 7 Jan 2015 08:18:43 +0000
Message-ID: <21469_1420618723_54ACEBE3_21469_9364_1_53C29892C857584299CBF5D05346208A0EAF7B7F@PEXCVZYM11.corporate.adroot.infra.ftgroup>
References: <01c401d01b91$feca19d0$fc5e4d70$@ndzh.com> <2403_1420562329_54AC0F99_2403_19702_1_53C29892C857584299CBF5D05346208A0EAEDDFB@PEXCVZYM11.corporate.adroot.infra.ftgroup> <01c901d029d0$a53fc2a0$efbf47e0$@ndzh.com> <76CD132C3ADEF848BD84D028D243C927337F4503@nkgeml512-mbx.china.huawei.com>
In-Reply-To: <76CD132C3ADEF848BD84D028D243C927337F4503@nkgeml512-mbx.china.huawei.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_53C29892C857584299CBF5D05346208A0EAF7B7FPEXCVZYM11corpo_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.190922
Archived-At: http://mailarchive.ietf.org/arch/msg/idr/PVO40kgPLFfNwFdYQS6l9NajSAM
Cc: "idr@ietf.org" <idr@ietf.org>
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: Wed, 07 Jan 2015 08:18:53 -0000

Hi Jie,

Thanks for the discussion. I agree with you.

1 point:

> "add-path all" can definitely meet the requirement, while we also want to check the possibility of advertising a subset of paths to solve this problem, for example, the "advertise N paths" mode in draft-ietf-idr-add-paths-guidelines.

Agreed, but IMO you would need to be more prescriptive in the document rather than just say that operator will figure out.
I agree that advertising N paths can do the job. I'd like to see a text helping operators to define N. A priori, with little to no thinking,  I would say N must at least be (the number of iBGP clients sessions with clients having the same cluster ID) +1. E.g.  2+1=3 in typical scenarios (with redundant RR). This N value would be for the "down" way, assuming in the "up" way a single path is advertised.
Then which paths get advertised is a priori not important, so an option would be to use the mode "Add Path N" defined in draft-ietf-idr-add-paths-guidelines. On the pro side, it's already defined & implemented. On the con side, it's a priori overkilling and comes with a computational cost. Given that RTC is used for scalability purpose, the scale is a priori a point to consider (but the good news is that the states/path are not very dynamic as they are configuration (and failure) driven)


Clearly, this discussion is moot if we select the "best external" solution ;-)

Thanks,
Best regards,
Bruno

From: Dongjie (Jimmy) [mailto:jie.dong@huawei.com]
Sent: Wednesday, January 07, 2015 8:19 AM
To: Susan Hares; DECRAENE Bruno IMT/OLN
Cc: robert@raszuk.net; idr@ietf.org
Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02

Hi Bruno, Sue,

Thanks for the discussion on this draft. Since now it is a WG document, we expect to have more discussions on this list about the choice of a suitable solution, and this is a good start:)

Personally, I'd also prefer the "best external" one, as it does not rely on the "add-path" capability, also does not add complexity in provisioning. The cost is to define new propagation rules for RTC AFI/SAFI. Note that the current propagation rule of RTC is already a little bit different from the BGP default rules.

As for the "add-path" solution, IMO this depends on the requirement of operators. If some of them plan to use add-path and RTC together, this can be one solution for them. "add-path all" can definitely meet the requirement, while we also want to check the possibility of advertising a subset of paths to solve this problem, for example, the "advertise N paths" mode in draft-ietf-idr-add-paths-guidelines.

Regarding the "standard track", we didn't expect protocol extensions with the "add-path" solution, but since the solution space is still open, it is likely that this document will include some protocol extensions.

Thanks again and we'd appreciate more discussions on this list.

Best regards,
Jie

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Wednesday, January 07, 2015 12:49 AM
To: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>
Cc: robert@raszuk.net<mailto:robert@raszuk.net>; idr@ietf.org<mailto:idr@ietf.org>; Dongjie (Jimmy)
Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02

Bruno:

The document has been accepted as a WG document.   I hope that people will engage you in debating the primary solution version the second solution.   I expect this evening Jie will respond to this email during his working hours (this evening).

I agree with many of your points regarding Add-path versus RTC approach.   One question should we allow two solutions - one for people already taking the heavy weight of add-path and another for the RTC.

AddPath grouping has entered the standard process, but I did not hold it for this work.  We can append a standard to the AddPath standard if operators need this feature.

Sue

From: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> [mailto:bruno.decraene@orange.com]
Sent: Tuesday, January 06, 2015 11:39 AM
To: Susan Hares
Cc: robert@raszuk.net<mailto:robert@raszuk.net>; idr@ietf.org<mailto:idr@ietf.org>; Dongjie (Jimmy)
Subject: RE: [Idr] 1 Week Final Call for adoption of draft-dong-idr-rtc-hierarchical-rr-02

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<mailto:idr@ietf.org>
Cc: robert@raszuk.net<mailto: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.

_________________________________________________________________________________________________________________________

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.