Hi Enke, If we are going to take a long time to reach any consensus, I would rather not change the OPEN size.
The gain with large MESSAGE is within the UPDATE processing. Having large MESSAGE will drastically reduce the processing of attributes per NLRI [1]. Having a smaller OPEN is something we can decide ignore at the moment, there is no problem a larger OPEN fixes today. I would advocate to just change the draft to clarify that all MESSAGEs but OPEN are affected and be done with it. Let progress by step: this one is very easy to implement, anything more would require more code and therefore is less likely to get in production soon (it seems to be the lesson coming from RFC 8092). I would then advocate to look at extending the OPEN as another draft (that we can then argue for years until there is pressure from the operational to get consensus and another draft with happen instead :p), it does not delay the benefit of 65k UPDATEs. Thomas [1] BGP was designed in a time where CPU and memory were expensive. So it does did not disjoint ATTRIBUTE and NRLI. They were both were packed in a same message to be processed together (but if someone want to create new named attribute messages and a new attribute to use to link it to an UPDATE - I am all in favour to even reduce the CPU load on my routers). On 2017-03-09 20:09, Enke Chen wrote: > 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 large OPEN size. In this > case the remote speaker has to be upgraded to support the large message capability. > > Case 2: Prefer a large OPEN, but can live with a normal size, predefined OPEN > > Option 1: Start with a large OPEN. In case a NOTIFICATION is received due to the > large OPEN size, fall back to using the predefined normal size OPEN. > > Option 2: Start with the normal size OPEN. If the OPEN from the remote speaker > does not contains the large message capability, proceed with the session > establishment. Otherwise send a CEASE message (with a new subcode) and > terminate the session (before sending the KEEPALIVE), and then start a > new session with the large OPEN. > > With either Option, there should be no impact on the GR or LLGR as the session > did not reach the ESTABLISHED state with the first OPEN. > > Option 1 is more preferred when the local speaker has the knowledge that the > capability is supported by the remote speaker based on the previous OPEN or via > administrative means. It also does not require any new protocol definitions (like > a new CEASE subcode). > > In addition, I believe that the large OPEN will not be needed any time soon and > by the time it is needed the large message capability should have been widely > deployed. Thus I think Option 1 is good and there should be no need to specify > Option 2. > > Thanks. -- Enke > > On 3/9/17 6:41 AM, Randy Bush wrote: > >>> 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 an optional extended open randy _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow [1] Links: ------ [1] https://www.ietf.org/mailman/listinfo/grow
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
