Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

Robert Raszuk <robert@raszuk.net> Wed, 22 November 2017 20:10 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21D51296CD; Wed, 22 Nov 2017 12:10:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 95STat-GyWhS; Wed, 22 Nov 2017 12:10:04 -0800 (PST)
Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (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 C20A5129C12; Wed, 22 Nov 2017 12:10:03 -0800 (PST)
Received: by mail-wr0-x244.google.com with SMTP id o14so15651396wrf.9; Wed, 22 Nov 2017 12:10:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=m8YE3qLlUumYkQcfblDdSOvZDW4v5PBxVkwrZ9cUpp4=; b=Bb3kTd7J/cqzIE9KgiKBlp3T82ODtjrz4vX7sf5cFJ3tcE/b+1C02dCap9qtlv7WPG CbRDWJ7nB8H0z2p9wclTBV8FcalaFrx204/BFgIXwKlXMnUZfNClDTVU0QJWkYIEEWSO s7AO6Wrz8JZ92usYYAY/55FZW/8gLkCUECAo5/KP1FeuNHw4RErZc6bSs9pyu3hoP8fA iMYhTApUb9miUwTza9VSxchGKdijgAnhjOOsaUGyZUbWA9UeGPYDWzBfDdrhrhp2yJGZ Wxs6+L+Y6vyfrFsi/VIxb9qGpIZQKgfIj40hWP7wrS80b6qdUFtxl/TsbtudemeJ3Jdw JKWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=m8YE3qLlUumYkQcfblDdSOvZDW4v5PBxVkwrZ9cUpp4=; b=lpRzPz5ONyvxUaoG86oAW+TZ10jEYno+tEepYmsBfoICcuoEoarE4+V6hud9lc0PB0 9bGwYUNpjdWgS7ilUQznfb5+slQlke28GLuq3+96UwHy+Gj3jPI4bzP+QN5sxzG6fR0H 9RYpbdzxdxg9xoehcY6VUuM5xO1JZ5JQhql3j3Ok/FF58l8JO2vf07FLFW8JcsKNrz3W FVfq+IoCuqye4DB02iImfbbBdNY0QWBxSTjk6mwDtmbjiVDtsrpseWsTANxAWQGrr4xg 6MOq0RTfoyd8t7KD9EjI+Izl4D3msH+PwpcnagBhhm8Q0guqXA3rGhvPs8g824353pyc kn3Q==
X-Gm-Message-State: AJaThX5RyDLsCOytPjr+KEbkQmDwliFwVJL3VnIErXwvxMePNSr1Gump m/veD39ktGexzEbBvVxEPscZ6Pf5fl5bZ74cDcn1SA==
X-Google-Smtp-Source: AGs4zMbrPj/bJvcX73LZOteCG+Ptb35CctwroBwLi3GWtChIYNmwwNk4Yb0kxZb7B+K39pGn6PMidkQiyACZ7obRZSs=
X-Received: by 10.223.183.39 with SMTP id l39mr10307634wre.175.1511381402104; Wed, 22 Nov 2017 12:10:02 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.28.54.217 with HTTP; Wed, 22 Nov 2017 12:10:01 -0800 (PST)
In-Reply-To: <1D2FD437-0EEF-4FF6-9853-C09E7EEA2A15@nist.gov>
References: <000901d35c08$3f12d950$bd388bf0$@ndzh.com> <B61C3B8F-1168-4EB1-8D8E-88C4BF28B3AA@exa.net.uk> <CA+b+ER=1sHhAqhOc2VipzZMB+Zsxk8n+8cNUshkjPw_A9k9E-A@mail.gmail.com> <39049A8C-6D47-4251-AF87-342F68DDE8AE@exa.net.uk> <CA+b+ER=ANs15BEmRKeqneVHNcTSCsGDMVDQgFV4OucwPSWcLgw@mail.gmail.com> <CACWOCC9Yde99EbhLrveCtoUVSZWiP=sL=k69zrGBeNj5AjCGFQ@mail.gmail.com> <CA+b+ERk_2XZ_Y3EqSjNAbSi1ZqKhD2oThrRR2EOJzckQ41GijA@mail.gmail.com> <CACWOCC-EfzOYdUrHAWQN10LBzofySrKRADc6Zq-dyca1o0DPvw@mail.gmail.com> <CA+b+ER=ppm1N2wnMrPxxS_Nug2EaETBkW5gASTVZ2UKKq0aZJA@mail.gmail.com> <976743ea96934039a85fa74415b45862@XCH-ALN-014.cisco.com> <CA+b+ERmpEghcndHKM+WKKxg1V8ufTwg=xqb0J5jNowZHj2OwAQ@mail.gmail.com> <88d5df779a344b588745108c771d3145@XCH-ALN-014.cisco.com> <deae6e85c3ff47a6bbcac176eb91bd3e@XCH-ALN-014.cisco.com> <F0EAF2D4-656D-48BD-830B-DC2E8B862813@nist.gov> <A0106E1A-272D-4E1D-A0F3-E3531D583AA3@cisco.com> <1D2FD437-0EEF-4FF6-9853-C09E7EEA2A15@nist.gov>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 22 Nov 2017 21:10:01 +0100
X-Google-Sender-Auth: P2SO2iootRRqyxoMXeRAapKquIg
Message-ID: <CA+b+ERmPHChMvdHx2ymHSZCcx0RckkBP8RfY_r5W_Wvi6w9S8A@mail.gmail.com>
To: "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>
Cc: "Jakob Heitz (jheitz)" <jheitz@cisco.com>, idr wg <idr@ietf.org>, "idr-ads@ietf.org" <idr-ads@ietf.org>, Idr <idr-bounces@ietf.org>, Thomas Mangin <thomas.mangin@exa.net.uk>, Randy Bush <randy@psg.com>
Content-Type: multipart/alternative; boundary="f403043868bc97ba5e055e97e7ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Aw6a-WDr-NMuTpQpppXbZe3su6s>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Nov 2017 20:10:07 -0000

Hi Olivier,

The larger updates will contain larger attributes and I think Jakob's point
of those questions was to make sure that what actually creates the extended
size BGP UPDATE MSGs can be handled by the implementations who claim
support for it.

However I must agree with you that implementation report draft or wiki is
really not the right place for those questions. It merely is there to
indicate if the draft has been implemented and what parts of the draft got
implemented.

Those questions are perfect for customer evaluation of given bgp
implementation though, but I am afraid we do not have within IETF a room
for such efforts :)

Best,
R.






On Wed, Nov 22, 2017 at 8:58 PM, Borchert, Oliver (Fed) <
oliver.borchert@nist.gov> wrote:

> To my understanding the wiki should state compliance with the draft in
> question and not particular BGP attributes.
>
>
>
> The draft is about the capability of sending and receiving updates larger
> than 4K and how to handle if the capability is not propagated, as well as
> the “5 mile view” on what to do if an update would exceed the newly
> proposed max length of 64K, it is not about performance issues etc.
>
>
>
> To me the added questions in the wiki are more about the capability to
> process individual attributes that might become large. This is outside the
> scope of the draft in question.
>
>
>
> It seems to me that what you try to solve is not compliance with the
> draft, it is more about the capability of particular implementations on how
> to deal with larger updates and this might change with memory, CPU, quality
> of implementation, etc. but has nothing to do with the draft in question.
>
>
>
> In case there are issues with attributes getting too large and therefore
> causing issues to BGP itself, then I believe the RFC’s dealing with these
> attributes should be updated.
>
>
>
> Again, I believe this is out of scope of this draft and I do not see any
> need to have these questions in the wiki.
>
>
>
> Oliver
>
>
>
> *From: *"Jakob Heitz (jheitz)" <jheitz@cisco.com>
> *Date: *Wednesday, November 22, 2017 at 12:16 PM
> *To: *Oliver Borchert <oliver.borchert@nist.gov>
> *Cc: *Robert Raszuk <robert@raszuk.net>, idr wg <idr@ietf.org>, "
> idr-ads@ietf.org" <idr-ads@ietf.org>, Idr <idr-bounces@ietf.org>, Thomas
> Mangin <thomas.mangin@exa.net.uk>, Randy Bush <randy@psg.com>
>
> *Subject: *Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages
> (11/12 to 11/26)
>
>
>
> Larger message implies larger path attributes. You may answer “no” for the
> parts with which you do not comply.
>
>
>
> If the implied path attribute sizes are too large, then we need to be
> explicit about the maximum sizes for each attribute in the draft. Please
> suggest reasonable maximum sizes.
>
> Thanks,
>
> Jakob.
>
>
> On Nov 22, 2017, at 7:10 AM, Borchert, Oliver (Fed) <
> oliver.borchert@nist.gov> wrote:
>
> Jakob,
>
>
>
> I looked into the added questions for the compliance report you added on
> the wiki.
>
> I am not quite sure that these added questions do apply for a compliance
> of the requested draft. These do more apply to features used within BGP
> that might result in larger BGP messages.
>
> And here the draft has a clear message in the last paragraph of section 3:
>
>
>
> “It is RECOMMENDED that BGP protocol developers and implementers are
>
>
>   conservative in their application and use of Extended Messages.”
>
>
>
> Therefore, they would more apply to proper functioning of implemented BGP
> features rather than the extended message itself. I do not believe that
> these new questions do apply here.
>
>
>
> Said that, BGPSEC-IO is a traffic generator that mainly focusses on BGPSEC
> updates. We did not add communities to the generated traffic and I do not
> intent to do so in the near future (though community contributions are
> welcome) – in this sense, for sending my answer is NA.
>
> On the receiving side, as long as the BGP update in itself is well formed
> and within its length boundaries (4K or < 64K) there is no issue. We just
> dump the update either on the “floor” or screen.
>
>
>
> With QuaggaSRx, as long as Quagga can process communities of that length,
> QuaggaSRx can as well. QuaggaSRx same as BGPSEC-IO do comply with the draft
> itself when it comes to accepting and generating > 4K updates as specified
> in the draft and we tested the processing and memory usage using BGPsec
> traffic of little less than 64 K.
>
>
>
> Oliver
>
>
>
> *From: *Idr <idr-bounces@ietf.org> on behalf of "Jakob Heitz (jheitz)" <
> jheitz@cisco.com>
> *Date: *Tuesday, November 21, 2017 at 6:13 PM
> *To: *Robert Raszuk <robert@raszuk.net>
> *Cc: *idr wg <idr@ietf.org>, "idr-ads@ietf.org" <idr-ads@ietf.org>, Idr <
> idr-bounces@ietf.org>, Thomas Mangin <thomas.mangin@exa.net.uk>
> *Subject: *Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages
> (11/12 to 11/26)
>
>
>
> 1 hour ??
>
> When I tested my large community code, I tested at the limit and over it.
>
> There was no perceptible time for the operations.
>
> 16 times imperceptible would be a blip at the most.
>
> The only operations that take a worrisome amount of time are regexp
> matches with nested wildcards.
>
> Hmm, I should add regexp matches explicitly, because that requires to
> expand the communities into ascii representation in the matching engine.
>
>
>
> Thanks,
>
> Jakob
>
>
>
> *From:* Idr [mailto:idr-bounces@ietf.org <idr-bounces@ietf.org>] *On
> Behalf Of *Jakob Heitz (jheitz)
> *Sent:* Tuesday, November 21, 2017 2:58 PM
> *To:* Robert Raszuk <robert@raszuk.net>
> *Cc:* idr wg <idr@ietf.org>; idr-ads@ietf.org; Thomas Mangin <
> thomas.mangin@exa.net.uk>; Idr <idr-bounces@ietf.org>
> *Subject:* Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages
> (11/12 to 11/26)
>
>
>
> Just that it does it without error.
>
> If the numbers are too large, we should discuss reasonable limits.
>
>
>
> Thanks,
>
> Jakob
>
>
>
> *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com <rraszuk@gmail.com>] *On
> Behalf Of *Robert Raszuk
> *Sent:* Tuesday, November 21, 2017 2:55 PM
> *To:* Jakob Heitz (jheitz) <jheitz@cisco.com>
> *Cc:* Job Snijders <job@ntt.net>; idr wg <idr@ietf.org>; idr-ads@ietf.org;
> Idr <idr-bounces@ietf.org>; Thomas Mangin <thomas.mangin@exa.net.uk>
> *Subject:* Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages
> (11/12 to 11/26)
>
>
>
> Hi Jakob,
>
>
>
> I think what you added is fine, but requires a time limit.
>
>
>
> Statement that implementation can receive, parse/validate, display in CLI
> or match in the policy 16K of communities all actions taking 1h each is
> rather not that interesting isn't it ?
>
>
>
> Or is the indicator of spec compliance a statement that it just does not
> crash regardless of time it takes for execution of each stated action :) ?
>
>
>
> Thx,
>
> //R.
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Nov 21, 2017 at 11:38 PM, Jakob Heitz (jheitz) <jheitz@cisco.com>
> wrote:
>
> The new update message size requires support for:
>
> 16375 communities
>
> 8187 extended communities
>
> 5458 large communities
>
> I have not changed the as-path length, because it is already ridiculously
> high.
>
> If anyone wants to talk about a maximum as-path length, please speak up.
>
>
>
> I have added tests to the implementation report
>
> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-
> extended-implementations
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-bgp-extended-implementations&data=02%7C01%7Coliver.borchert%40nist.gov%7Cc29658d9c708468b0ccd08d5313576ee%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636469028063383089&sdata=zRFsa6v%2BqWcQo44fTcKtmbmqmFZicA495i%2BZfcA4ZSg%3D&reserved=0>
>
> to ensure full compliance with the consequences of the draft.
>
>
>
> Implementers, please update your compliance.
>
>
>
> Thanks,
>
> Jakob
>
>
>
> *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Robert Raszuk
> *Sent:* Tuesday, November 21, 2017 10:41 AM
> *To:* Job Snijders <job@ntt.net>
> *Cc:* idr wg <idr@ietf.org>; idr-ads@ietf.org; Idr <idr-bounces@ietf.org>;
> Thomas Mangin <thomas.mangin@exa.net.uk>
> *Subject:* Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages
> (11/12 to 11/26)
>
>
>
> Great !
>
>
>
> On Tue, Nov 21, 2017 at 6:35 PM, Job Snijders <job@ntt.net> wrote:
>
> Robert/Randy,
>
>
>
> About this being a default:
>
>
>
> Old (Section 4):
>
>
>
> A BGP speaker that is willing to send and receive BGP Extended Messages
> with a peer SHOULD advertise the BGP Extended Message Capability to the
> peer using BGP Capabilities Advertisement RFC5492].
>
>
>
> New (Section 4)
>
>
>
> A BGP speaker that is capable to send and receive BGP Extended Messages
> with a peer SHOULD advertise the BGP Extended Message Capability to the
> peer using BGP Capabilities Advertisement [RFC5492].
>
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Coliver.borchert%40nist.gov%7Cc29658d9c708468b0ccd08d5313576ee%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636469028063383089&sdata=Bt6F5N6zA5v7GCXm7peFu06uK1TCD3sRHIVPffp%2F0O0%3D&reserved=0>
>
>
>
>