Joe

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...@isi.edu>
To: "t.petch" <ie...@btconnect.com>; "Templin, Fred L"
<fred.l.temp...@boeing.com>
Cc: <int-area@ietf.org>
Sent: Tuesday, October 11, 2016 4:22 PM

> Hi, Tom,
>
> I do agree that the terminology in the current version is confusing
and
> 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" <to...@isi.edu>
> > 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
what
> > we
> >> would call egress reassembly MTU.
> >>
> >> We need to either avoid the term MTU in our definitions or provide
an
> >> 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
or
> > 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
ERU
> >> when the ingress supports fragmentation and reassembly (which not
all
> >> 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
qualify
> > 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
every
> > time would make it easier.
> >
> > Likewise, when 'MTU' or 'protocol' or some such is unqualified, I
have
> > to stop and think which is meant.  I think that most uses of MTU
should
> > 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
more
> > generic.  After all, you can tunnel Ethernet in ATM and while I
think
> > that most of this I-D does not cater for that, I think there are
some
> > places where 'protocol' is not limited to IP so if IP protocol (or
IPv4
> > protocol or IPv6 protocol) is intended, then I would write that
> > explicitly.
> >
> > Tom Petch
> >
> >
> >> Joe
>

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to