Re: [RRG] Six/One Router Design Clarifications

Pekka Savola <pekkas@netcore.fi> Mon, 28 July 2008 23:12 UTC

Envelope-to: rrg-data@psg.com
Delivery-date: Mon, 28 Jul 2008 23:13:48 +0000
Date: Tue, 29 Jul 2008 02:12:03 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: Dino Farinacci <dino@cisco.com>
cc: Christian Vogt <christian.vogt@nomadiclab.com>, Tony Li <tony.li@tony.li>, Routing Research Group Mailing List <rrg@psg.com>, "Drake, John E" <John.E.Drake2@boeing.com>
Subject: Re: [RRG] Six/One Router Design Clarifications
Message-ID: <alpine.LRH.1.10.0807290204550.5036@netcore.fi>
User-Agent: Alpine 1.10 (LRH 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"

(perhaps I shouldn't have done catching up on rrg mails, but..)

On Fri, 25 Jul 2008, Dino Farinacci wrote:
[long list of encap/decap vs translation discussions omitted]
>> You have to do the same with encapsulation.

One thing I didn't see mentioned here is probably relevant. 
Encap/decap has a potential to be much more difficult if fragmentation 
would be incurred (especially outer header fragmentation); I have hard 
time seeing how you could even implement a line-speed decapsulator 
that would reassemble fragments as required by Full Standard IP RFCs.

The same problem could happen if you translated v4->v6 as well (i.e., 
payload size shrinkage).

See draft-touch-intarea-tunnels-00 and rfc4459.

As a result for encap/decap schemes I specifically want to see how 
they 100% avoid fragmentation, or describe how they deal with it.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--
to unsubscribe send a message to rrg-request@psg.com 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