Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:to...@isi.edu]
> Sent: Wednesday, October 12, 2016 7:03 AM
> To: t.petch <ie...@btconnect.com>; Templin, Fred L <fred.l.temp...@boeing.com>
> Cc: int-area@ietf.org
> Subject: Re: [Int-area] Questions to draft-intarea-tunnels-03
> 
> Hi, Tom,
> 
> 
> On 10/12/2016 2:32 AM, t.petch wrote:
> > Joe
> >
> > Looking some more, I think that the carefully defined terminology is not
> > then used so carefully!
> I agree; we have been asking for this sort of feedback for several
> years. I'm glad to finally receive it, though I would note that the
> focus has been on converging on the details of advice first. Now that
> we've done that, it's very useful to get this feedback so we can update
> the doc.

Yes, the time has come - time to move this work forward.

Thanks - Fred

> > 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.
> It's used in 2.2 because of the confusion that arises when we talk about
> hosts and routers. Many documents (and entire bodies of IETF work)
> erroneously imply or assume that these are mutually-exclusive functions.
> Most devices we call routers include all the requirements of being a
> host because control protocols originate or terminate at that node.
> "Forwarding" is intended to describe the exclusive functions a router
> performs that a host does not.
> 
> The Internet architecture is based on the concept of a host, a
> forwarder, and a link, but the Internet is implemented with devices of a
> host, a router (which is both a forwarder and a host), and a link.
> 
> It's important to discuss this issue, which is why it is grounded in the
> definitions. I will add text to explain why the rest of the doc refers
> to the device (router) rather than the function (forwarding).
> 
> > 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)
> It's also convention that sentences start with capital letters. In this
> case, all list items start with a capital letter as well.
> > 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.
> don't think it's confusing, and all the terms defined have the same
> issue, but it seems to be consistent (e.g., we don't use Path MTU
> anywhere else except at the beginning of a sentence or a bullet). I'll
> doublecheck that.
> 
> > 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.
> 
> That's exactly correct - the other functions you describe are the
> responsibility of the originating host or forwarder (router).
> 
> And that's not a lot for a link; that's exactly what all link layers do.
> 
> > 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?
> Good point to clarify.
> 
> The clarification will be intended to highlight the following:
>     - a tunnel ingress is an INTERFACE, not a node
>     - a node where the tunnel ingress is attached is just a node using a
> link
> 
> So in the diagrams, the nodes should be labeled "ingress node" and that
> term defined as "a node on which the ingress interface is attached".
> 
> > 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.
> I agree, but it should be as simple as we can while still being clear.
> It's tempting to have fewer variants of the different MTU values or to
> merge the idea of a tunnel ingress as interface with an ingress as node,
> but then we lose exactly the distinction that lets us correctly reason
> about their role in the Internet architecture.
> 
> Joe
> 
> 
> >
> > (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