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

<bruno.decraene@orange.com> Tue, 31 March 2015 13:30 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 B05061ACD2A for <idr@ietfa.amsl.com>; Tue, 31 Mar 2015 06:30:38 -0700 (PDT)
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 56uLwzt6ya2H for <idr@ietfa.amsl.com>; Tue, 31 Mar 2015 06:30:34 -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 A1BAF1ACD31 for <idr@ietf.org>; Tue, 31 Mar 2015 06:30:33 -0700 (PDT)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id B76B41B80E5; Tue, 31 Mar 2015 15:30:31 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 4CD1A1800D2; Tue, 31 Mar 2015 15:30:31 +0200 (CEST)
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; Tue, 31 Mar 2015 15:30:31 +0200
From: <bruno.decraene@orange.com>
To: Robert Raszuk <robert@raszuk.net>
Thread-Topic: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost
Thread-Index: AQHQa68PUmxQ4n8H1UqmT7iJqJVtdZ02iXig
Date: Tue, 31 Mar 2015 13:30:30 +0000
Message-ID: <27737_1427808631_551AA177_27737_351_1_53C29892C857584299CBF5D05346208A0EB81D34@PEXCVZYM11.corporate.adroot.infra.ftgroup>
References: <20150324212935.GG612698@eidolon> <25308_1427313409_55131301_25308_9958_1_53C29892C857584299CBF5D05346208A0EB7BCF2@PEXCVZYM11.corporate.adroot.infra.ftgroup> <2FF01A48-5057-42C9-81D2-91B864F84E47@cisco.com> <31245_1427797338_551A755A_31245_1405_1_53C29892C857584299CBF5D05346208A0EB817C7@PEXCVZYM11.corporate.adroot.infra.ftgroup> <CA+b+ERn+3NObKOPJb8E6mW_gVO-8qCUL+BgHbWsxhkSWK-1C8Q@mail.gmail.com>
In-Reply-To: <CA+b+ERn+3NObKOPJb8E6mW_gVO-8qCUL+BgHbWsxhkSWK-1C8Q@mail.gmail.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.6]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0EB81D34PEXCVZYM11corpo_"
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.12.3031
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/hfpL2V1H3MJy9MJC8ppLH6bIRu0>
Cc: idr wg <idr@ietf.org>
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: Tue, 31 Mar 2015 13:30:38 -0000

Hi Robert,

Please see inlined.

From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk Sent: Tuesday, March 31, 2015 2:35 PM



Hi Bruno,

Three small questions (to warm up :)

[Bruno] I was waiting for your email ;-)

- do you assume in practice next hop self on ingress border router towards your ibgp

[Bruno] No assumption. Should work for Next-Hop self  and Next-Hop unchanged.

More specifically

- for Next-Hop Self, the Next-Hop Capability must be removed. A new one may be attached, with whatever relevant information.

- for next-hop unchanged, the Next-Hop Capability should be kept

- how do you handle third party next hop behaviour

[Bruno] As the Next-Hop is not changed, the Next-Hop Capability is not changed, hence reflect the capability of the third party.

- do you plan to modify the draft to use it with next hop new SAFI

[Bruno] The Next-Hop Capability is a BGP attribute which can be attached to routes of (a priori) any AFI/SAFI. Therefore it may a priori be used with the next-hop SAFI. That being said, it’s not clear to me what ID.nh-cost sets in the “Network Address of Next Hop” field of the MP_REACH_NLRI attribute. i.e. it’s not clear if ID.nh-cost use the BGP Next-Hop field. I guess first action would be to clarify this in ID.nh-cost.

In the meantime, trying to theorize

 - If this BGP Next-Hop is set to the NEXT_HOP field of the nh-cost SAFI, then it looks like the ID.next-hop-capability can be directly applied to nh-cost SAFI

- Otherwise, short answer is that ID. nh-cost may need to define how the Next-Hop Capability is used for this SAFI. One sub-option would be to advertise a single NLRI (hence next-hop route per update). Or to extend the nh-cost SAFI NLRI to also carry BGP attributes related to this NLRI (NEXT-HOP)…I trust your creativity.

/Bruno



Many thx,
R.
On Mar 31, 2015 3:22 AM, <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> wrote:
Hi Jérome, all

> From: Jerome Durand (jerduran) [mailto:jerduran@cisco.com<mailto:jerduran@cisco.com>] > Sent: Wednesday, March 25, 2015 9:32 PM
>
> Hi Bruno,
>
> Interesting there are some similarities to what I proposed here:
> draft-jdurand-idr-next-hop-liveliness-00

You are right.
I had read your document and had considered chatting this with you, but then understood that you were now favoring a different approach (namely draft-jdurand-auto-bfd).


> Where I tried to describe how we could carry next-hop capability to
> implement a host liveliness mechanism and solve the route-server black-
> holing stuff we have been talking about lately. Having a kind of general
> framework for any capability (ie. not just host liveliness) makes sense.

Thanks. I clearly agree with you.

> But your proposal relies on a non transitive attribute and couldn't pass the
> route-server so I cannot adjust my proposal to fit in yours.

ID. next-hop-capability _needs_ a non transitive attribute so this is not something that I can accommodate.
Can't the route-server be extended to support the capability? Looks like a relatively small change (and if the Route Server is known to never change the next-hop, a (horrible) hack would be just a matter of recognizing the attribute to pass it unchanged. But I will deny having said this ;-) )

> Anyway note that now I more or less stopped that work for the moment to
> focus on a more automated solution as there were some challenges with BGP
> (issues described in the draft). Also it seems that it was quite heavy from a
> processing/memory point of view to have new attributes per route. Note we
> had the idea to use some kind of "magic route" in order to have the attribute
> transported only once. Maybe to be investigated further. This is also
> described in the draft.

Thanks for the feedback. As of today, IMO carrying the attribute in each update is simpler and more flexible. Some NH capability may need this (and as a matter of fact, the entropy label capability needs this).

Thanks for the comments and feedback.
/Bruno


> Thanks!
>
> Jerome
>
>
>
>
>
>
> Le 25 mars 2015 à 20:56, <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>
> <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> a écrit :
>
> > Hi David,
> >
> > Thanks for your comments.
> > Please see inline.
> >
> >> From: David Lamparter [mailto:equinox@diac24.net<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.
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org<mailto:Idr@ietf.org>
> > https://www.ietf.org/mailman/listinfo/idr


_________________________________________________________________________________________________________________________

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.

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr

_________________________________________________________________________________________________________________________

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.