Re: [Idr] comment on draft-ietf-idr-bgp-extended-messages

[Nick Hilliard <[e-mail]>]

Robert Raszuk wrote:
> Sorry, but MTU is not dependent on the router vendor, but on the
> circuits specifications you get from carriers to construct your WAN. Our
> circuits (usually emulated ones) are guaranteed to carry 1500 byte
> packets regardless of routers used on both ends. 

mtu is dependent on both the router interface characteristics and the
underlying circuit characteristics:  it's not just vendor-dependent,
it's specific to the hardware used on the particular interface.

I don't think this fragmentation argument is very important in the
context of draft-ietf-idr-bgp-extended-messages because BGP is just
sending out data in a tcp stream, and the MTU management is handled at
the TCP level.  So TCP won't attempt to put a 65535-byte update message
into a single TCP packet which is then fragmented; it will stream out a
series of packets of packetlen=MTU until the update has been fully
transmitted.

This behaviour is confirmed in rfc4271, section 3:

> BGP uses TCP [RFC793] as its transport protocol.  This eliminates the
>    need to implement explicit update fragmentation, retransmission,
>    acknowledgement, and sequencing.

Fragmentation happens occasionally in practice if there is a path mtu
mismatch between sender and receiver bgp speaker.  Generally speaking,
if it happens and there's a problem with transmitting the fragments,
then the bgp session will fail outright because most bgp implementations
will bundle lots of updates into a single TCP packet of size == MTU.

I.e. the concern that was raised is not an actual problem.

Nick