Re: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost

<bruno.decraene@orange.com> Wed, 25 March 2015 19:56 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 35DD41A893F for <idr@ietfa.amsl.com>; Wed, 25 Mar 2015 12:56:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 AuYsk_qNpF65 for <idr@ietfa.amsl.com>; Wed, 25 Mar 2015 12:56:51 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EB411A899F for <idr@ietf.org>; Wed, 25 Mar 2015 12:56:51 -0700 (PDT)
Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id D63B73B42F7; Wed, 25 Mar 2015 20:56:49 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id AFEC8C804F; Wed, 25 Mar 2015 20:56: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.0224.002; Wed, 25 Mar 2015 20:56:49 +0100
From: bruno.decraene@orange.com
To: David Lamparter <equinox@diac24.net>
Thread-Topic: decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost
Thread-Index: AQHQZnmjSF6fofZKJU2JukfyUyESZp0tg4OQ
Date: Wed, 25 Mar 2015 19:56:48 +0000
Message-ID: <25308_1427313409_55131301_25308_9958_1_53C29892C857584299CBF5D05346208A0EB7BCF2@PEXCVZYM11.corporate.adroot.infra.ftgroup>
References: <20150324212935.GG612698@eidolon>
In-Reply-To: <20150324212935.GG612698@eidolon>
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.25.163622
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/U0PMiXdWYhw1kVehri1jWTla2q4>
Cc: idr wg <idr@ietf.org>, "ilya.varlashkin@easynet.com" <ilya.varlashkin@easynet.com>, "robert@raszuk.net" <robert@raszuk.net>
Subject: Re: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost
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, 25 Mar 2015 19:56:54 -0000

Hi David,

Thanks for your comments.
Please see inline.

> From: David Lamparter [mailto:equinox@diac24.net] > Sent: Tuesday, March 24, 2015 4:30 PM
> 
> Hi Bruno, Ilya, Robert,
> Hi idr list,
> 
> 
> the next-hop-capability draft currently seems to target using the new nexthop
> capability on a per-advertisement level.  Considering that draft-idr-bgp-nh-
> cost adds a new SAFI to convey information about nexthops, it seems natural
> to tranposrt the capability information in that place?

That's a valid comment.

1)  cost/benefit 
Avertising the next-hop-capability on a per update basis has indeed a cost but also a benefit.
In term of cost, the simplest next-hop-capability is 5 octets. Compared to an update in the range of 100-1000 octets, that's 5% to 0,5%.
In term of benefit, this allow customizing the capability on a per update/routes granularity if required, which may be a useful possibility for some capabilities.
Engineering is about trade-off. IMO, the benefit, especially long term, out weight the fixe cost, which is small and will become smaller, in relative term, in the future (thanks to Moore's law).

2) deployability 
In addition, in term of deployability, a new attribute has no impact.  On the other hand draft-idr-bgp-nh-cost use a new AFI/SAIF which requires reconfiguration and reboot of all BGP sessions. This is a much higher cost for IBGP alone. For EBGP, this is simply not an option IMO.

 
So, I agree that this is a valid option to consider, however I don't think that it's a better one.

> (That would also remove the question of what behaviour should be when you
> get different advertisements with the same nexthop, but with a different
> nexthop capability attribute.)

For a given route/NLRI, you use the next-hop capability attached to this route.
To rephrase, you do not consider next-hop capability that may have been advertised in another update.
I agree that this may not be crystal clear in the text, I will clarify in the next revision.

Thanks again for your comments,
Bruno

> 
> 
> -David

_________________________________________________________________________________________________________________________

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.