Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.

Hi, Folks: Let me add some specifics: Case 1: large OPEN only If the local speaker is only interested in getting the session established using a large OPEN, then it SHOULD go ahead with the large OPEN and deal with the issue administratively upon receiving a NOTIFICATION due to the

Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.

+1 - it makes lots of sense. Thomas > On 7 Mar 2017, at 21:08, Nick Hilliard wrote: > > Susan Hares wrote: >> This email is to make you aware of the discussion on the Extended >> Messages draft (draft-ietf-idr-bgp-extended-messages-21). Do you >> want the message size

Re: [GROW] Code nannies (Re: Do you want BGP to extend the message size for all BGP messages or just UPDATES.)

heasley wrote: > Ignoring support or opposition for the topic of the thread, why should > the ietf concern itself with programming (and testing) incompetency of > this magnitude? The RFCs should document the procedure to negotiate > the capability, not endeavor to design for every possible

[GROW] Code nannies (Re: Do you want BGP to extend the message size for all BGP messages or just UPDATES.)

Thu, Mar 09, 2017 at 12:20:43PM +, Nick Hilliard: > First, it's not guaranteed > that some badly coded bgp stack wouldn't crash with a 4097 byte OPEN > message, and secondly, you're not guaranteed that just because the stack > supports 4097 bytes on open due to e.g. unintentional coding

Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.

Hi Randy, To never have to revisit this point, I would suggest for a capability containing a char of value N, for the N extra MESSAGE to be read before the KA, the extra MESSAGEs being OPENs, which should have the Version to Identifier data zero'ed (and ignored) with then the extra capabilities

Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.

> Thank you for sharing this scenario. It would indeed work at the small > cost (or perhaps not so small) to require an extra round trip at setup > time which is most likely un-avoideable whatever is done. then a double open. i.e. a 4096 open which has the extended capability exchange and then

Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.

Hi Nick, Looking at Quagga, Bird, GoBGP (I took a few minutes to read their code and I am not overly familiar with any of them), they all seems to perform the 4096 bytes check and send NOTIFICATION, so I would only expect badly home brewed solution to suffer from the issue (not to say we should

Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.

(Resending as I previously use an email address which is not registered on grow) Hello Susan. Just thinking out loud here ... Thank you for sharing this scenario. It would indeed work at the small cost (or perhaps not so small) to require an extra round trip at setup time which is most

Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.

Thomas: you have more experience with this and your advice sounds reasonable. Sue: I'd be cautious with your approach. First, it's not guaranteed that some badly coded bgp stack wouldn't crash with a 4097 byte OPEN message, and secondly, you're not guaranteed that just because the stack supports