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

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

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]>
Cc: idr wg <[e-mail]>; [e-mail]; Thomas Mangin <[e-mail]>; Idr <[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
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