I've been waiting for the feedback (which has been great) before commenting or
editing up a revision to the document; however this is one point that's worth
noting.
We did a test on a Jumbo Frame enabled IX (NETNOD). We looked at all the peers
and listed the MSS against the Jumbo or non-Jumbo VLAN. By doing a simple "show
ip bgp nei" and "show ipv6 bgp nei" command, collecting the data and looking at
it; I find:
MSS IP ADDRESS HARDWARE VLAN
---- ----------------- -------- ----
1240 ***.***.**.189 Cisco 1500
...
1440 ***.***.**.26 Cisco 1500
1420 ****:***:*:**::26 Cisco 1500
...
1440 ***.***.**.34 Cisco 4470
1420 ****:***:*:**::34 Cisco 4470
...
1460 ***.***.**.172 Brocade 4470
...
4410 ****:***:*:**::19 Juniper 4470
4430 ***.***.**.19 Juniper 4470
...
4410 ****:***:*:**::24 Juniper 4470
4430 ***.***.**.24 Juniper 4470
...
4430 ***.***.**.143 Cisco 4470
4430 ***.***.**.181 Juniper 4470
I only included the interesting peers. There's tons of peers within the 1,4xx
MSS range; but there are ONLY six with ~4,400 Byte MSS.
The hardware column is the hardware of the peer (we run Brocade).
Hence ... There is MSS negotiation; hence there is "value"; but I believe I
should only note this fact within the document and not make in any way a
requirement to tune or change the BGP or TCP knobs to take advantage of the
large MTU path. The fact that some sessions enable this and some don't is
perfectly OK. It's being decided by the routers for whatever reason they
choose.
NETNOD's Jumbo Frame setup has been working for many many years (over various
h/w platforms) and has stood the test of time.
Does this help?
Martin
PS: I'll respond to other points in a bit.
On Nov 17, 2011, at 3:55 PM, Tony Li wrote:
>
> On Nov 17, 2011, at 3:51 PM, john heasley wrote:
>
>> Thu, Nov 17, 2011 at 06:46:12PM -0500, Jakob Heitz:
>>> BGP uses TCP. Differing MTU has no impact on update generation in BGP. BGP
>>> today has a maximum message size of 4096 bytes. TCP slices and dices that
>>> into IP packets of its own choosing.
>>
>> i was about to reply with the same, then it occured to me that an
>> implementation may have closer ties to the underlying mtu for rfc2385
>> or similar. so the question becomes where implementation-specific
>> limitation belong in the draft.
>
>
> They don't.
>
> Tony
>
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
