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

Yes the proposed text addresses my concerns. I would only to it one more
sentence:

"
The size of individual BGP path attributes MUST be small enough that they
can fit into a BGP UPDATE message of 4096 octets. If a BGP feature requires
a path attribute to be longer, then the required size of the path attribute
MUST be specified in the RFC of the feature requiring it. *Such RFC MUST
also specify the expected behavior on the boundary between peers which do
support extended message size and those which do not."*

Thx,
Robert Raszuk.

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

> I’m happy to add a sentence to the effect of:
> 
> The size of individual BGP path attributes MUST be small enough that they
> can fit into a BGP UPDATE message of 4096 octets. If a BGP feature requires
> a path attribute to be longer, then the required size of the path attribute
> MUST be specified in the RFC of the feature requiring it.
>
> Thanks,
> Jakob.
>
>
> On Nov 22, 2017, at 3:36 PM, Robert Raszuk <robert@raszuk.net> wrote:
>
> 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-exten
>> ded-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>
>>
>>
>>
>>
>