Subject: [RRG] Re: [RAM] Tunnelling & GigE jumbo frame size

From: Lixia Zhang <[email-masked]>
Date: Wed, 12 Sep 2007 13:16:29 -0700

Hi,

On Wed, Sep 12, 2007 at 12:47:58PM -0700, Dino Farinacci wrote:
> To summarize the issue we are trying to put to rest:
>
> o All router-to-router links on the downstream side of an ITR use
> either 4470 or 9180 byte MTUs.

Where is this assumption coming from?  As long as there are FastE links,
this is not going to happen.

Gert Doering
         -- NetMaster
--  
Total number of prefixes smaller than registry allocations:  122119

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner- 
Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 12 Sep 2007 13:18:05 -0700

Hi,

On Wed, Sep 12, 2007 at 04:07:41PM -0400, RJ Atkinson wrote:
>> Where is this assumption coming from?
>> As long as there are FastE links, this is not going to happen.
>
> Are you trying to say that you currently have deployed
> router-to-router links inside an ISP/IX with less than
> 4470 bytes of IP MTU ?

We have no single ethernet link in our network that has a MTU *above*  
1530
(there are some that could be cranked up, but there was no need yet)

I have a large number of links that have a MTU of *exactly* 1500  
(because
there is equipment that cannot handle 1530).

All exchange points that we're connected to run the fabric at 1500 byte
MTU, because they have members that have equipment that cannot handle
more.  There are *some* IXPs that have two different LANs, one with
1500 and one with "Jumbo", but that's not very widespread yet.

So: the answer is "yes".

> Btw, at least some 100baseTX/FX switches/routers can
> support the 9180 IP MTU.  So it is not necessarily
> the case that 100baseTX/FX implies a 1518 byte link MTU.

Switches are easy.  Routers are not.

What good is having a Jumbo-capable switch if there is one peer on the
shared fabric that can only receive 1500-byte (+ Ethernet header)  
packets?

Gert Doering
         -- NetMaster

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 12 Sep 2007 13:16:48 -0700

Ran

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 12 Sep 2007 18:53:26 -0700

> this is not going to happen.

Listen folks, one solution isn't going to solve all of the world's  
problems. Want to throw away this effort because of this one issue?  
You think another solution won't have issues as well?

We design for the optimal case and hopefully with experience and data  
from operators more networks move to the optimal case. And later if  
we have to still solve the suboptimal case, we do fragmentation.

Can we agree with this?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 12 Sep 2007 18:55:23 -0700

> We have no single ethernet link in our network that has a MTU  
> *above* 1530

Then have your providers put the ITR on their side.

Dino

---

From: David Meyer <[email-masked]>
Date: Wed, 12 Sep 2007 19:18:16 -0700

> You think another solution won't have issues as well?

	I have to agree with Dino on this one. What we are
	talking about here is engineering. And more than that,
	its engineering with a large constraint set (i.e., the
	Internet). But engineering is about tradeoffs (well, its
	part art, part economics, and part luck too). So as Dino
	says, other solutions are going to have different
	tradeoffs. Some worse (for sure), and possibly some
	better. But it is clear that all of the solutions on the
	table (and likely any other solution) have complex issues
	sets, so we need to look at the bigger picture (rather
	than focus on any one issue in isolation).

> from operators more networks move to the optimal case. 

	Right, and experience and data are the fundemental
	compliments to both research and engineering.  

> And later if  we have to still solve the suboptimal case, we do
> fragmentation. 
>
> Can we agree with this?

	Really.

	Dave

---

From: David Conrad <[email-masked]>
Date: Wed, 12 Sep 2007 19:58:49 -0700

YES!

I've come to believe that one of the fundamental failures of the IETF  
is that it permits or even encourages protocol design to be directed  
by corner cases.  This results in a rat's nest of often conflicting  
requirements and unimplementable complexity.  There is no perfect  
solution and there will be tradeoffs any direction you choose.   
TANSTAAFL.  Really.

Start simple and evolve to meet the changing environment.  If I have  
one complaint about LISP, it is that it may already be too complicated.

Regards,
-drc

On Sep 12, 2007, at 6:53 PM, Dino Farinacci wrote:
> We design for the optimal case and hopefully with experience and  
> data from operators more networks move to the optimal case. And  
> later if we have to still solve the suboptimal case, we do  
> fragmentation.
>
> Can we agree with this?
>
> Dino
>
> --

---

From: Tony Li <[email-masked]>
Date: Wed, 12 Sep 2007 23:53:48 -0700

> 	compliments to both research and engineering.

I'll second Dave's comments.  Engineering is about tradeoffs.  Our
job is to clearly, honestly and openly asses those tradeoffs, to the
best of our abilities.  This assessment is not well served by
unrealistic positions pro or con, on this or any other issue.

Tony