Hi, Joe and Mark are right - a tunnel has the same characteristics as a link. Just as you would never admit a 9KB packet into a 1500B link without fragmentation, a tunnel ingress must never admit a packet into the tunnel if it is larger than the egress reassembly buffer size.
Joe's analogy of ATM AAL5 is also exactly correct. And, as Joe says, the cell size does not matter *as long as the cell size can traverse the tunnel without loss due to a size restriction*. That is why the nominal cell size should be no larger than 1280B (minimum IPv6 link MTU) unless there is assurance that larger cell sizes can be used. Thanks - Fred From: Int-area [mailto:[email protected]] On Behalf Of Joe Touch Sent: Thursday, October 06, 2016 9:48 PM To: Linda Dunbar <[email protected]>; [email protected] Cc: [email protected] Subject: Re: [Int-area] 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:[email protected]] Sent: Thursday, October 06, 2016 4:10 PM To: Linda Dunbar <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/int-area
