On 10/7/2016 8:48 AM, Templin, Fred L wrote: > > Hi Joe, > > > > Ø If the ingress fragments and egress reassembles, the MTU of the > tunnel(or link) is 2000 - encaps overhead. > > > > Unless I am misunderstanding Linda’s comment and your response, the > fact that the > > egress attaches to a 2000B link has no bearing on the MTU size the > egress can configure. >
You are right; I was reading Linda's note as indicating a 2000B reassembly. As you note, the MTUs of the hops of the tunnel have no bearing on the tunnel MTU *if* the egress does reassembly. The egress reassembly payload determines the tunnel's MTU. FYI, all, this is already all in the doc. Joe > > > > As per your doc, it is the reassembly buffer size (and not the sizes > of any links the > > tunnel is configured over) that determines the tunnel MTU. So, in this > example, the > > egress could just as well configure a 9KB reassembly buffer size and > hence the > > tunnel would have a 9KB minus ENCAPS MTU. > > > > Thanks - Fred > > > > *From:*Int-area [mailto:int-area-boun...@ietf.org] *On Behalf Of *Joe > Touch > *Sent:* Friday, October 07, 2016 8:33 AM > *To:* Linda Dunbar <linda.dun...@huawei.com> > *Cc:* towns...@cisco.com; int-area@ietf.org > *Subject:* Re: [Int-area] Questions to draft-intarea-tunnels-03 > > > > > > > On Oct 7, 2016, at 8:15 AM, Linda Dunbar <linda.dun...@huawei.com > <mailto:linda.dun...@huawei.com>> wrote: > > Joe, > > > > You said “The egress MTU determines the largest IP packet (or > fragment) that can traverse either a link or a tunnel.” > > > > If a Tunnel traverse some segments of very old layer 2 network > with MTU = 1500, but the Tunnel Egress node is a modern node with > MTU = 2000 bytes. > > I would think the Tunnel MTU is 1500, not the 2000 at the Tunnel > egress node, correct? > > > > If the ingress fragments and egress reassembles, the MTU of the > tunnel(or link) is 2000 - encaps overhead. The MTU of the hops inside > the tunnel/link determine how the Ingress needs to fragment, not > ultimately what can traverse the tunnel/link. > > > > I.e. The difference is between the MTU *of* the tunnel/link and the > MTU *inside* the tunnel/link. > > > > Joe > > > > > > > > > > Linda > > > > *From:*Joe Touch [mailto:to...@isi.edu] > *Sent:* Thursday, October 06, 2016 11:48 PM > *To:* Linda Dunbar <linda.dun...@huawei.com > <mailto:linda.dun...@huawei.com>>; towns...@cisco.com > <mailto:towns...@cisco.com> > *Cc:* int-area@ietf.org <mailto:int-area@ietf.org> > *Subject:* Re: Questions to draft-intarea-tunnels-03 > > > > Hi, Linda, > > > > On 10/6/2016 4:36 PM, Linda Dunbar wrote: > > Joe, > > > > I strongly agree with what you said “A link MTU is different > from a path MTU”. > > > > A Tunnel MTU is more like “path MTU” because > > - the Tunnel MTU is the minimum of all the links’ > MTU that the “tunnel” traverse, > > > A link MTU is the largest IP packet that can traverse the link > (i.e., without needing to be fragmented to go over the link). > > A tunnel MTU, like a link MTU, is the largest IP packet that can > traverse the tunnel or link layer without needing to be fragmented > FIRST, which is one of two things, whichever is larger: > 1. - the min of the MTUs of the links along the tunnel or the > link-layer hops along the path of the link protocol, minus the > tunnel/link encapsulation overhead > 2. - the reassembly size of the tunnel/link egress, minus the > tunnel/link encapsulation overhead > > Note that (1) would never be larger than (2), so (2) is sufficient > for both a tunnel and a link protocol. > > An IP path MTU is determined only by (1). > > This is one way in which a tunnel is more like a link than an IP path. > > One other way is that an IP packet hopcount/ttl is never > decremented when traversing a link or a tunnel *because* it does > not encounter an IP router along the way, and only IP routers > perform this decrement, i.e., an IP packet with TTL=0 should be > able to traverse both a link and a tunnel, but would not traverse > an IP path. > > > > - the fragmented segments may be out of order when > arriving at the egress node of the tunnel, whereas over a > link, the fragmented frames always arrive at egress port in > the same order (therefore the reassembly is much easier over a > link). > > > A link is not guaranteed to avoid reordering or loss. A particular > link protocol may have one or both of these properties, but it is > not a requirement to be a link. > > > > > > Another question, in Section 5.2: why you specifically discuss > the “egress MTU” ? > > See above. > > > > A tunnel MTU is determined by the minimum MTU of all the > links’ MTU that the tunnel traverse. > > This is incorrect, as noted above (and described in the document). > The egress MTU determines the largest IP packet (or fragment) that > can traverse either a link or a tunnel. > > > > The HSrc and HDst would have considered all the links’ MTU > when they choose the frame size. So the tunnel egress MTU > would be big enough for the original packet size between HSrc > & HDst. > > > Consider a link such as ATM: the ATM cell size is not relevant, > only the ATM AAL5 reassembly payload size. That determines the MTU > because an IP packet that large can traverse an ATM link (with > multiple ATM link hops) without needing to be fragmented before > traversal. > > The same is true for an IP tunnel. The hops of the tunnel are not > relevant *to the packet arriving at the ingress*. The only thing > that is relevant is the largest payload the tunnel egress can > reassemble. The hops within the tunnel determine how the ingress > fragments, not whether a packet arriving at the ingress must be > dropped. > > > > > > A tunnel MTU is a critical issue, not because of Tunnel being > like a link”, but > > - because the ingress adds the outer header > encapsulation which may make the total frame size chosen by > the original source to exceed the MTU of some intermediate > links, > > > The overhead of these encapsulations is relevant only at the > egress reassembly; the effect on the individual fragments is not > relevant. IP doesn't care about the 5-byte overheads for ATM cells. > > > > - because the fragmented segments may be out of order > when arriving at the egress node of the tunnel, whereas over a > link the fragmented frames always arrive at egress port in the > same order (therefore the reassembly is much easier over the > link). > > As noted above, in-order delivery is ensured only for some link > technologies/protocols. > > > > > > A couple of minor typo: > > > > Section 3.6.1: “the term "inner")..”, is the “)” extra? > > Yes - thanks for pointing that out. It'll be fixed in the next rev. > > > > > > Section 4.2 first sentence: “…. It messages might be …”, do > you mean “… its messages might be…” > > > I'll double-check tomorrow, but I'm fairly sure I meant to just > drop the "it" part. Again, it'll be fixed in the next rev. > > Joe > > > > > > Linda > > > > > > *From:*Joe Touch [mailto:to...@isi.edu] > *Sent:* Thursday, October 06, 2016 4:10 PM > *To:* Linda Dunbar <linda.dun...@huawei.com> > <mailto:linda.dun...@huawei.com>; towns...@cisco.com > <mailto:towns...@cisco.com> > *Cc:* int-area@ietf.org <mailto:int-area@ietf.org> > *Subject:* Re: Questions to draft-intarea-tunnels-03 > > > > Hi, Linda, > > > > On 10/6/2016 1:34 PM, Linda Dunbar wrote: > > Joe and Mark, > > > > > > You said “Because tunnels are links, they are subject to > the same issues as any link, e.g. MTU..” > > The MTU issue exist between any two points in a network. > > > A link MTU is different from a path MTU, as explained in the > document. The MTU issues of a link are different than those of > a path, as described. > > > > > > The MTU issue for tunnel is more like the MTU issue > between any two points in the network (i.e. traverse many > links, and can change over time), less like the MTU for a > single link because the single link MTU is only determined > by the fixed TWO endpoints of the link, whereas the MTU of > a tunnel (and a path) is impacted by many links in > between, i.e. more dynamic and can change depending which > path the packet traverse through. > > > Both a link and tunnel may have multiple hops not visible to > IP, each of which may have a different MTU; this is no > different than an IP path MTU. The difference is that the > link/tunnel hops are not visible to IP. > > > > > > > In the section 1 of your draft, you stated: “.. tunnels > emulate a link”. To me, “tunnel” hide the inner > addresses, but the packets can traverse many links. So > Tunnels hardly emulate a link. > > > There are many link layer technologies which use multiple > link-layer hops and relaying, including Ethernet, ATM, SONET, etc. > > Joe > > > > >
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
