Re: [Idr] why has 4096 bytes limit on BGP messages size?

In RFC 1105 the maximum message size was 1024 octets.  I suspect
because RFC 1163 added the capability to support multiple prefixes
(i.e., compression/update packing) they bumped the size to 4096. Note
that RFC 1163's Appendix 2 states the UPDATE format was changed
to support multiple "path attributes", when I think they actually meant
multiple "prefixes".

As for why it was constrained in the first place, RFC 1164 talks to this
a bit in section 6.3.  In particular, I suspect the size was constrained
initially because of this:

    Due to the stream nature of TCP, all the data for received messages
    does not necessarily arrive at the same time
    [...]
    This can make it difficult to process the data as messages,
    especially on systems such as BSD Unix where it is not possible to
    determine how much data has been received but not yet processed.

One might hypothesize that the selection of the original value of 1024
had something to the 4.2 BSD-derived systems TCP segment size
common settings of 1024.

RFC 1267 incorporated some of the RFC 1164 text directly, in section
5.2.

Of course, I'm just a youngster compared to some of the old folk here,
especially Yakov, so I'll happily defer  ;-)

-danny

---
RFC 1267

5.2  Processing Messages on a Stream Protocol

    BGP uses TCP as a transport mechanism.  Due to the stream nature of
    TCP, all the data for received messages does not necessarily arrive
    at the same time. This can make it difficult to process the data as
    messages, especially on systems such as BSD Unix where it is not
    possible to determine how much data has been received but not yet
    processed.

    One method that can be used in this situation is to first try to  
read
    just the message header. For the KEEPALIVE message type, this is a
    complete message; for other message types, the header should  
first be
    verified, in particular the total length. If all checks are
    successful, the specified length, minus the size of the message
    header is the amount of data left to read. An implementation that
    would "hang" the routing information process while trying to read
    from a peer could set up a message buffer (4096 bytes) per peer and
    fill it with data as available until a complete message has been
    received.

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr