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

Robert Raszuk <robert@raszuk.net> Tue, 31 March 2015 12:34 UTC

Return-Path: <rraszuk@gmail.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 ACA591A911A for <idr@ietfa.amsl.com>; Tue, 31 Mar 2015 05:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 2kX3FbvuLMJF for <idr@ietfa.amsl.com>; Tue, 31 Mar 2015 05:34:38 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F711A9231 for <idr@ietf.org>; Tue, 31 Mar 2015 05:34:38 -0700 (PDT)
Received: by igcau2 with SMTP id au2so11355795igc.1 for <idr@ietf.org>; Tue, 31 Mar 2015 05:34:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=k6IXwWm9McXA6vSNcg7bk3ALP0LT3pPjCUlUXi0BYos=; b=bMuNSXj5a0ZxUssEh8sG2UR791QVqHtgKqKnWSbUxGqmQnawZdYrckcT9nyhWB/Gqs Yo4RZuRikkxmaVUbaHaeWzg4foXAGggRks8qBxYM4/ZEDt3m/rkUgJURWyqVpRHmK2fw lj/4nt53wJWz5FiEB/LU+lDAuzI4/Ekb4KwIDqc/oEBioUk/d2dvdpXZ4FJd+nS72F9R 6Cd/iRCnuxZdtLVwS55fagg2SEdi6KqC9GqvfNff22+RQoy5JKFrl8kCb3B+tpQ9WYwj DmhsCWW7BjhE9RTDOeWGfXxYH8LuHkuOe+IgFXpG15JKq0Ka7x/xthbzhu5rbiRqrXkV czaA==
MIME-Version: 1.0
X-Received: by 10.50.66.141 with SMTP id f13mr3943829igt.9.1427805278177; Tue, 31 Mar 2015 05:34:38 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.107.137.66 with HTTP; Tue, 31 Mar 2015 05:34:38 -0700 (PDT)
Received: by 10.107.137.66 with HTTP; Tue, 31 Mar 2015 05:34:38 -0700 (PDT)
In-Reply-To: <31245_1427797338_551A755A_31245_1405_1_53C29892C857584299CBF5D05346208A0EB817C7@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>
Date: Tue, 31 Mar 2015 07:34:38 -0500
X-Google-Sender-Auth: 8n3YQQrP5l59h6dQ4KQ7bXoROOg
Message-ID: <CA+b+ERn+3NObKOPJb8E6mW_gVO-8qCUL+BgHbWsxhkSWK-1C8Q@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: bruno.decraene@orange.com
Content-Type: multipart/alternative; boundary=047d7bdc0dd26a12ca051294d27b
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/CjW529RSheQn5Tbyx6aRAm7R0u0>
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 12:34:41 -0000

Hi Bruno,

Three small questions (to warm up :)

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

- how do you handle third party next hop behaviour

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

Many thx,
R.
 On Mar 31, 2015 3:22 AM, <bruno.decraene@orange.com> wrote:

> Hi Jérome, all
>
> > From: Jerome Durand (jerduran) [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>
> > <bruno.decraene@orange.com> a écrit :
> >
> > > 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.
> > >
> > > _______________________________________________
> > > Idr mailing list
> > > 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
> https://www.ietf.org/mailman/listinfo/idr
>