dataplane encapsulation considerations

dataplane encapsulation considerations - fragmentation

"Templin, Fred L" <Fred.L.Templin@boeing.com> Mon, 15 December 2014 17:11 UTC

From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "routing-discussion@ietf.org" <routing-discussion@ietf.org>
Subject: dataplane encapsulation considerations - fragmentation
Thread-Topic: dataplane encapsulation considerations - fragmentation
Thread-Index: AdAYiIhT9EHTGl7tQtOB208XEDdpGw==
Date: Mon, 15 Dec 2014 17:11:26 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832DB6BCC@XCH-BLV-504.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/UnOGzIJ2QSYlxN2y7y83KBl0xb8
Precedence: list

Hi,

Moving this to a different thread, I believe AERO has a workable solution for
fragmentation. See Section 3.12 of:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

In this solution, AERO provides tunnel fragmentation which is neither fragmentation
of the encapsulated packet nor fragmentation of the payload packet. It uses two
magic numbers (1280 and 1500) as fragmentation thesholds. It uses fragmentation
(only when necessary) to take care of the smalls and lets the bigs take care of
themselves.

General observation - there seems to be efforts on tunneling spread far and wide
across numerous IETF working groups. Can we somehow find a way to consolidate
the discussions in one place so we can emerge with a common solution?

Thanks - Fred
fred.l.templin@boeing.com

dataplane encapsulation considerations - fragment… Templin, Fred L