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

Hi Jakob,

You are very correct. But the way to address this point (and yes it would
be great to address it) is to include in this current draft (a WG document
after all) sections pertaining to each current BGP Attribute and its
maximum size in the extended message. I think this is what was also
Olivier's main point - not that your observations were wrong - they just
did not fit with the current way documents are progressed.

Or as I suggested add one line to the current spec stating that current
attributes MUST not be extended in size unless a new specific RFC will
allow for it as provide interop between 4k/65K boundary rules for each such
attribute.

Just placing those on implementation report wiki (while not being part of
the document) is not part of the IDR process I am afraid. Besides even if
someone reports it works today you have zero guarantees that it will work
the same way tomorrow unless it is clearly spelled out in the RFC given
implementation claims to support.

Thx,
R.

On Thu, Nov 23, 2017 at 12:26 AM, Jakob Heitz (jheitz) <jheitz@cisco.com>
wrote:

> If router A follows this draft, then it can quite legitimately send an
> update with 16000 communities. If router B cannot receive and process it,
> then it’s broken.
>
> If path attribute size is not addressed, then this draft will cause
> inoperable implementations. As such, it is not fit for standardization.
> Either we assume the maximum possible size for all attributes or specify
> shorter maximum sizes. Anything less leads to failure to interoperate.
>
> Oliver, what maximum sizes does your implementation support?
> You can put those sizes into the wiki.
>
> Thanks,
> Jakob.
>
>
> On Nov 22, 2017, at 11:58 AM, 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>
>
>
>
>