Hi Joe, Please run through my text, and you will see that it works. This does not take anything away from the fact that you are the originator of the concept (i.e., it cites 'intarea-tunnels' as the first order of business) but it puts things in simple terms that are easy for an implementer to understand.
Thanks - Fred > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Monday, October 10, 2016 11:15 AM > To: Templin, Fred L <[email protected]>; t.petch <[email protected]> > Cc: [email protected] > Subject: Re: [Int-area] Questions to draft-intarea-tunnels-03 > > 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 _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
