Thomas:
I’m sorry I missed this until this morning. I cannot speak about operational issues as I do not run an AS any longer. Some who codes the OPEN code will need to comment on the need for a larger OPEN capability. My experience in coding this is several years old at this time. In RFC4271, the text indicates Connect(Retry)Timer and DelayOpenTime these are local implementations values. If Grow wants to recommend values for Connect(Retry)Timer and Open Delay Time, based on concerns about Extended-Message size processing, this is a good thing to put in the extended message as a recommendation . Sue From: Thomas Mangin [mailto:[email protected]] Sent: Thursday, March 9, 2017 8:27 AM To: [email protected] Cc: Susan Hares; 'Thomas Mangin'; [email protected] Subject: 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 likely un-avoideable whatever is done. The issue which keeps me thinking would be which capabilities/feature should dropped in order to fulfil the 4096 bytes limit when the NOTIFICATION is received. I would rather see the OPEN stay at 4096 and have an “extended OPEN capability” than the Notification trick as otherwise newer drafts/RFCs will otherwise not cover the point. If a extended OPEN feature is added, new drafts can then decide to require the implementation of this OPEN extension, making the split easy (current capabilities in OPEN, newer in extension). Modifying the state machine to include a new MESSAGE (or extra OPEN of 65k) should not be too hard (I am sure you have heard the before :p) In every scenario, some wording about the Connect(Retry)Timer and DelayOpenTime may also need to be considered to make sure no large delay is introduced during the BGP setup - re-sending an OPEN immediately after the NOTIFICATION or extra OPEN/Message (if doing so does not cause an issue with the state machine). At the moment, with all the current RFC and drafts implemented, AFAIK we are still far from filling the OPEN, but perhaps “we" should take the time to see what the sum of of the capabilities for all the families is, to see what space is definitively left in the OPEN .. It is not unreasonable to consider that a valid capability may need some large space at some point .. https://tools.ietf.org/html/draft-walton-bgp-hostname-capability-02 made me consider the size of the OPEN back in early 2016 - as I implemented it “for fun” at the time - So in Jan 2016 and ExaBGP still had 2*255 + 2 = 512 bytes spare in the OPEN but not much more AFAICR. Sincerely, Thomas On 2017-03-09 12:20, Nick Hilliard wrote: 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 4097 bytes on open due to e.g. unintentional coding reasons, that it actually supports 4097 bytes by design and that it actually works properly. Nick Susan Hares wrote: Thomas: It is possible to create an option that requires implementation support extended messages upon receiving a notification. If the sequence is: Open-(4097 bytes) --> <-----notification (with indication message length is too long) (sequence allowed RFC4271 current FSM) The extended messages would know to back down to 4096 and negotiate forward. This would not let your BGP speaker get stuck. It seems reasonable to make the code take care of this problem rather than have a crisis in an operator's day. Open (< 4096) bytes) ---> Just let us know what you want. Sue -----Original Message----- From: Thomas Mangin [mailto:[email protected]] Sent: Tuesday, March 7, 2017 4:39 PM To: [email protected]: Susan Hares Subject: Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES. Hello Nick, I can see one reason why it would become undesirable in the future: If a then recent speaker, with support with this draft/RFC, and with a yet-to be defined large number of capabilities, happened to generate an OPEN message of 4097 bytes (to match its configuration), this OPEN would most likely be seen as invalid by current implementations not supporting the extension. The excessive/invalid length when checking the OPEN message size will surely caused the session to be terminated. It would therefore prevent any session to come up (even if otherwise everything is fine). Therefore should this size extension be applied, it should be applied to all message types BUT the OPEN message. I think we are currently not near needing 4096 bytes for OPEN (but the day will/may come). ExaBGP would suffer from this issue as the check is currently performed on ALL messages as currently specified including the OPEN. So I would suggest to just change the wording to include all message type but OPEN, and leave it as an exercise to the reader to write another draft allowing to break capabilities over multiple messages. Sincerely, Thomas On 7 Mar 2017, at 21:08, Nick Hilliard <[email protected]> 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 extended for all BGP messages or just UPDATE messages? This probably is more important if you want to have a larger size OPEN, ROUTE-REFESH, and UPDATES. The IDR co-chairs value the operational input from GROW WG. I don't see any reason an extended message size should be limited to just UPDATEs. Enke's suggestion for handling the single anomalous case (OPEN) looks reasonable. I'd say, go for it! Nick _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
