Subject: RE: jumbo frame of GbE and IPv6

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 25 Jul 2005 13:58:01 -0700

Fred, 
 
> The suggestion actually comes from Matt's document, I just 
> pointed it  
> out and suggested a simple first-burst implementation.
>    http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-04.txt
>    "Path MTU Discovery", Matt Mathis, 22-Feb-05

Section 4.2 of: 'draft-templin-ipvlx-02.txt' proposes a link adaptation
method for tunnels that uses a probing strategy similar to what is
described in 'draft-ietf-pmtud-method-04.txt' and also observes most
of the tunnel MTU/MRU determination rules specified in section 3 of
'draft-ietf-v6ops-mech-v2-07.txt'. The proposal supports GbE jumbo
frame MTUs on a per-decapsulator basis and also allows host-based
segmentation for sending the larger packets when the decapsulator
can accept jumbo frames but some L2 switch on the path cannot.

This is being mentioned for the sake of providing completeness to
this discussion, since it addresses the case of tunnels being used
instead of native IPv6 in some deployment scenarios. Although I
cannot give a schedule, the document is due for an update after
the I-D repository re-opens following IETF63.

Fred
[email-masked]     

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Ghanwani, Anoop" <[email-masked]>
Date: Mon, 25 Jul 2005 22:28:36 -0700

> Thinking a bit more about this: ethernet rules the world 
> right now, and I see few competitors on the horizon. Although 
> an ethernet switch detects attachment to a port and even 
> negotiates a few capabilities, there is no mechanism to 
> furter distribute the information learned that way (if any), 
> so the only way to be certain that all systems connected to 
> an ethernet use the same MTU is by observing the 30 year old 
> 1500 byte maximum, or by having an administrator police the 
> MTU of all attached devices. In other words: the current 
> situation, where jumboframe deployment is negligible.

Sticking to 1500 bytes doesn't guarantee that everything will
work with Ethernet.  For example, there's new stuff going
on IEEE 802.3 which extends the Ethernet frame size to
accommodate additional headers such as VLAN tag and security
headers.  The payload size does still stay at 1500.  However
if you have the following scenario:

[new host] <-> [new bridge] <-> [old bridge] <-> [new bridge]

you could easily have a situation where the 1500 bytes +
new headers is greater than what the old bridge can handle.
It's a bit of a corner case, but nevertheless one that 
we need to be aware of.

Anoop

---

From: "Nuno Garcia" <[email-masked]>
Date: Tue, 26 Jul 2005 14:49:09 +0100

Hi all:
 
Sorry to drop in whitout anything that important to say:
 
jumbograms are not the same as jumboframes - the first is IPv6 (and carries a max of 4GB data), the later is Ethernet (and it carries up to 9KB data).
 
So if we want to keep the discussion fine tuned, we might want not to mix up these two concepts.
 
BTW, I'm all in favour in rethinking the "jumbo" issue (or as someone once put it, to give an end to tinygrams), and of course, to makeit as much Autoconf as possible.
 
If we make some simple arithmetics, we can see the size of the switching effort we're posing on networks equipments with this 1500B tinygrams.
 
Cheers,
 
Nuno M. Garcia,
Siemens SA
Portugal

	-----Mensagem original----- 
	De: [email-masked] em nome de Perry Lorier 
	Enviada: ter 26-07-2005 14:22 
	Para: 
	Cc: [email-masked] 
	Assunto: Re: jumbo frame of GbE and IPv6

	>
	> If you enable jumbo frames on end-nodes without a layer 2 infrastructure
	> that supports them, then you get what you deserve - a network that won't
	> work. The solution of course is go back to standard size frames or buy
	> jumbo capable layer 2 infrastructure and enable it. I think it's really
	> as simple as that.
	>
	> Don't fall into the trap of assuming the worst case scenario will be the
	> common one. I think the common one is that people who specifically buy
	> _and want to enable_ jumbo frame capable end-nodes will also make sure
	> they buy jumbo frame capable layer 2 infrastructure.
	>
	
	If you're going to require admins enabling jumbograms on their network,
	it's never going to happen.  People are just going to avoid enabling it
	because when you do everything breaks.  As it stands today the general
	consensus is "disable jumbograms, coz even if you manage to get it all
	working today, something will change tomorrow and you'll have a nasty
	problem to fix".
	
	If a simple solution can be found to having one link support multiple
	MTU's then thats where I think we should be heading :)  If one can't be
	found, then we should investigate what we can do to make this as easy as
	possible for end users.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 26 Jul 2005 08:49:41 -0700

Iljitsch,

> > Matt Mathis in
> > draft-ietf-pmtud-method-04.txt and Fred Templin in
> > draft-templin-ipvlx-02.txt.
> 
> I don't really see how those apply.

They apply in any case where IPv6-in-IPv4 virtual links
are used instead of native IPv6 links. Where are we at
in the decision process for native IPv6 vs tunneled?

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 26 Jul 2005 09:59:06 -0700

Stephen,
 
> >> > Matt Mathis in draft-ietf-pmtud-method-04.txt and Fred Templin
> >> > in draft-templin-ipvlx-02.txt.
> >>
> > Only because from what I remember of Matt's draft, and what Fred
> > said about his, they perform some sort of MTU discovery without
> > relying on a feedback mechanism e.g. ICMP Dest Unreachable,
> > Packet Too Big, which I think you solution would have to deal with,
> > assuming that there wasn't a requirement to add protocols to the
> > switches.
> 
> Any solution which requires an upgrade of all the L1/L2 
> devices in a path 
> will fail in the majority (IMHO) of cases.  Let's stick to 
> smart edges and 
> dumb networks.

Not sure whether you meant this wrt to the drafts mentioned above,
but the PMTUD mechanisms proposed in those drafts operate only
at edge nodes close to the end nodes or at the end nodes themselves.

'draft-templin=ipvlx-02.txt' goes a bit further in proposing a
new encapsulation that would need to be understood by some (but
not all) middleboxes on the path. But, this is a separate issue
from the PMTUD mechanism and if you don't want to touch any
middleboxes you can always apply the PMTUD mechanism proposed
in that document to other tunneling mechanisms that use
"standard" encapsulations.

Fred