Looking some more, I think that the carefully defined terminology is not
then used so carefully!

s.2.2 defines the term 'forwarder' but by 3.5, 'router' moves in and
forwarder is never used again.  Is this of technical significance, or
just a question of the style of the author(?s)?  I think the latter, but
see it as introducing uncertainty.

s.2.2 defines Link MTU, Path MTU, Tunnel MTU but the document then uses
link MTU, path MTU, tunnel MTU.  A common convention is for capitalised
words to have a particular meaning, lower case not (a bit like SHOULD
and should) so is this of technical significance, or just a question of
the style of the author(?s)?  I think the latter, but see it as
introducing uncertainty.

s.2.2 defines ingress as
     'the virtual link interface of a tunnel which receives
      messages within a node, encapsulates them according to the tunnel
      protocol, and transmits them into the tunnel. '
which I think of as rather a lot for an interface to do but equally not
all that needs doing, such as finding a path, selecting an interface,
finding link and path MTU, inspecting the packet for such as DF=1,
fragmenting when called for and so on.
It could be that ingress is intended to cover all these box functions.
(I would like to use the term 'node' here but that has been defined as
'a device that can act as an endpoint or forwarder, which does not seem
to fit here).

But reading on, in figure 4, I see the box that has everything to do
labelled I(ngress) which suggests that Ingress includes everything.  But
when I get to s.3.3, I encounter 'ingress nodes' (um oxymoron?) and then
'source (ingress) ' - what does 'source' add that 'ingress' does not
already have? - and then I get a mixture in s.3.6 of 'ingress' and
'tunnel ingress'  - what does 'tunnel' add that ingress is not already
defined to have?

I think you get my laboured point.  Technical writing, for me, is
boring.  Get a set of concepts, as small as is necessary, give them an
identifier, easy to read, write, say as you read, and use them over and
over again; boring, but easy to understand.

(If I look at MTU, I expect I will find the same only more so).

Tom Petch

----- Original Message -----
From: "Joe Touch" <>
To: "t.petch" <>; "Templin, Fred L"
Cc: <>
Sent: Tuesday, October 11, 2016 4:22 PM

> Hi, Tom,
> I do agree that the terminology in the current version is confusing
> it would be useful to be both more clear and more consistent.
> As I noted, I'll discuss this with Mark further and revise.
> Joe
> On 10/11/2016 3:05 AM, t.petch wrote:
> > ----- Original Message -----
> > From: "Joe Touch" <>
> > Sent: Monday, October 10, 2016 7:15 PM
> >
> >> HI, Fred (et al.),
> >>
> >> ...
> >>> IMHO, your draft is getting wrapped up with too many new acronyms
> > for no
> >>> good reason when simple English-language text would make things
> > easier to
> >>> understand.
> >> We're dealing with legacy use of the term MTU and path MTU too,
> > though.
> >>> In 'draft-templin-aerolink', there are only five acronyms:
> >>>
> >>>   MTU - the MTU of the tunnel as seen by the IP layer
> >> That's the term we need to specify in more detail - to some, it's
> >> one-hop IP MTU, to others it means path MTU, to others it means
> > we
> >> would call egress reassembly MTU.
> >>
> >> We need to either avoid the term MTU in our definitions or provide
> >> adjective to specify each type (as I have done).
> >>
> >>>   MFU - the maximum fragment size within the tunnel
> >> This is confusing because the fragment could refer to the payload
> > the
> >> entire IP datagram.
> >>
> >>>   MRU - the maximum reassembly size supported by the egress
> >> Sure.
> >>
> >>>   ENCAPS - the size of the encapsulation headers inserted by the
> > ingress
> >> Sure.
> >>
> >>>   PTB - an IP Packet Too Big message
> >> ICMPv4 or IPv6...
> >>
> >> You have omitted the concept of a transit MTU, which is only the
> >> when the ingress supports fragmentation and reassembly (which not
> >> tunnels or links do).
> >>
> >> Therein lies the problem with "simple" English, IMO.
> > Joe
> >
> > I echo Fred's point about acronyms; yes you need adjectives to
> > MTU but when I read
> > ' The TMTU (d) is not limited by TIMTU (e), but by ERMTU (f), the
> >    tunnel equivalent of RMTU (c). '
> > I have to pause, expand and think.  Spelling out the adjectives
> > time would make it easier.
> >
> > Likewise, when 'MTU' or 'protocol' or some such is unqualified, I
> > to stop and think which is meant.  I think that most uses of MTU
> > have an adjective or two in front of them.
> >
> > I would say the same of protocol.  At times, the I-D seems specific,
> > that this is IP in IP and so protocol is IP but other usages seem
> > generic.  After all, you can tunnel Ethernet in ATM and while I
> > that most of this I-D does not cater for that, I think there are
> > places where 'protocol' is not limited to IP so if IP protocol (or
> > protocol or IPv6 protocol) is intended, then I would write that
> > explicitly.
> >
> > Tom Petch
> >
> >
> >> Joe

Int-area mailing list

Reply via email to