Joe, I am missing something in your wish.
Ethernet, when it defines new heders, also revises the definition of the
actual frame format on the wire. The IETF does not own the frame format
on the wire. We do not own the link MTU.
Unless we want to reinvent X.25 with linkwise fragmentation and
reassembly at each step, and all the problems that implies, I do not see
how the IETF could get out of dealing with link MTU variation. (Doing
this on a tunnel basis is one of the features I think Fred Templin is
arguing for.)
Yours,
Joel
On 12/3/2021 10:21 PM, to...@strayalpha.com wrote:
Hi, Fred,
These both address a way to support *fragmentation*. I clearly said what
we need is a way to stop fragmenting (it was a wish list after all).
Ethernet never fragments because it just keeps adding headers. Nothing
in the docs below does that.
THAT, in a nutshell, is what’s missing, as I said *in my first post* on
this thread.
Joe
—
Joe Touch, temporal epistemologist
www.strayalpha.com <http://www.strayalpha.com>
On Dec 3, 2021, at 5:22 PM, Templin (US), Fred L
<fred.l.temp...@boeing.com <mailto:fred.l.temp...@boeing.com>> wrote:
Joe, go read these and tell me what you think is missing because I
assure you that
nothing is missing:
https://datatracker.ietf.org/doc/draft-templin-6man-omni/
<https://datatracker.ietf.org/doc/draft-templin-6man-omni/>
https://datatracker.ietf.org/doc/draft-templin-dtn-ltpfrag/
And please quit sending the funky html emails - they are corrupting
the list.
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
