Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Wednesday, October 12, 2016 7:03 AM > To: t.petch <[email protected]>; Templin, Fred L <[email protected]> > Cc: [email protected] > 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" <[email protected]> > > To: "t.petch" <[email protected]>; "Templin, Fred L" > > <[email protected]> > > Cc: <[email protected]> > > 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" <[email protected]> > >>> 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 [email protected] https://www.ietf.org/mailman/listinfo/int-area
