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

["Jakob Heitz (jheitz)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> 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) <[e-mail]<mailto:[e-mail]>> 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) <[e-mail]<mailto:[e-mail]>> 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)" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, November 22, 2017 at 12:16 PM
To: Oliver Borchert <[e-mail]<mailto:[e-mail]>>
Cc: Robert Raszuk <[e-mail]<mailto:[e-mail]>>, idr wg <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Idr <[e-mail]<mailto:[e-mail]>>, Thomas Mangin <[e-mail]<mailto:[e-mail]>>, Randy Bush <[e-mail]<mailto:[e-mail]>>
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) <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> on behalf of "Jakob Heitz (jheitz)" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, November 21, 2017 at 6:13 PM
To: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Cc: idr wg <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Idr <[e-mail]<mailto:[e-mail]>>, Thomas Mangin <[e-mail]<mailto:[e-mail]>>
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:[e-mail]] On Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, November 21, 2017 2:58 PM
To: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Cc: idr wg <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Thomas Mangin <[e-mail]<mailto:[e-mail]>>; Idr <[e-mail]<mailto:[e-mail]>>
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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Robert Raszuk
Sent: Tuesday, November 21, 2017 2:55 PM
To: Jakob Heitz (jheitz) <[e-mail]<mailto:[e-mail]>>
Cc: Job Snijders <[e-mail]<mailto:[e-mail]>>; idr wg <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Idr <[e-mail]<mailto:[e-mail]>>; Thomas Mangin <[e-mail]<mailto:[e-mail]>>
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) <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Robert Raszuk
Sent: Tuesday, November 21, 2017 10:41 AM
To: Job Snijders <[e-mail]<mailto:[e-mail]>>
Cc: idr wg <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Idr <[e-mail]<mailto:[e-mail]>>; Thomas Mangin <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
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>