Hi Ron and Carlos, Here are my comments on this draft:
Fred [email protected] Section 1.2: ************ Under the bullet: "o Path MTU Discovery (PMTUD)", should add a trailing citation such as: "[RFC2923] documents operational issues with PMTUD that apply equally to IPv4 and IPv6." Section 2.1: ************ Under the heading: "In Strategy 1", this seems to be taking a view that applies only to IPv4 (and not IPv6). Suggest rewriting as: "In Strategy 1, the tunnel ingress router encapsulates the entire payload into a single GRE-delivery packet, then fragments the packet if necessary and forwards each fragment in the direction of the tunnel egress. For IPv4, if any fragment exceeds the LMTU of any link along the path to the tunnel egress, the router directly upstream of that link fragments it (further). The tunnel egress router reassembles the GRE-delivery packet, de-encapsulates its payload, and processes the payload appropriately." Section 2.1: ************ Under the heading: "In Strategy 2", this again seems to be taking a view that applies only to IPv4. Suggest rewriting as: "In Strategy 2, the tunnel ingress router performs PMTUD procedures or some variant thereof (e.g., PLMTUD). When the tunnel ingress router receives a non-fragmentable packet that is larger than the minimum IP MTU and also so large that it cannot be forwarded through the tunnel, it discards the packet and sends an ICMPv4 "fragmentation needed" [RFC0792][RFC1191] or an ICMPv6 "packet too big" [RFC1981] message to the packet source. The ICMP message contains a Next-hop MTU equal to the TMTU associated with the tunnel. If the ICMP message reaches the packet source, and if the packet source executes PMTUD procedures, the packet source adjusts its PMTU for the packet destination and emits subsequent packets with size less than the TMTU." Section 2.1: ************ Under the heading: "In Strategy 3", change: "less than the TMTU of any tunnel" to: "greater than the TMTU of any tunnel". Section 2.1: ************ Under the heading: "Strategy 1 is an attractive alternative to Strategy 1...", Suggest rewriting to: "Strategy 1 is an attractive alternative to Strategy 2, because it does not rely on PMTU. However, Strategy 1 may not be operationally practical in all environments because it assigns the task of reassembly to the tunnel egress router. When the tunnel supports high data rates, reassembly at the tunnel egress can be cost-prohibitive. For IPv4, the tunnel ingress must also monitor the rate at which it sends in order to avoid reassembly misassociations [RFC4963]." Section 2.2: ************ This section seems to forget that the tunnel MUST support the minimum MTU for IPv4/IPv6. So, if PMTUD within the tunnel is broken, and if the tunnel receives a non-fragmentable packet that is no larger than minMTU but larger than the tunnel can pass in one piece, the tunnel ingress MUST encapsulate the packet and perform fragmentation on the encapsulated packet before sending each fragment toward the egress. The same is true for both IPv4 and IPv6, and the text needs to say this. Section 3.2: ************ The statement: "When PMTUD is disabled, the TMTU MUST be set to a value that is less than or equal to the LMTU associated with the next-hop towards the tunnel egress, minus the GRE overhead." In this statement, how can the tunnel ingress discover the smallest LMTU of all links on the path to the tunnel egress if PMTUD is disabled? Only options are to either do some sort of out-of-band path probing, or to assume the minimum MTU (1280 for IPv6 or 576 for IPv4). The text doesn't currently say this, but needs to. Section 4.1: ************ This section is missing the mark in that it does not talk at all about the minimum MTU the tunnel MUST support. Packets that are no larger than the IPv4/IPv6 minimum MTU MUST be admitted into the tunnel even if it means some fragmentation may be necessary. Section 4.2: ************ This section needs re-working. For tunnels over IPv6, if the packet is no larger than the IPv6 minMTU (1280 bytes) but larger than TMTU, then the tunnel ingress MUST fragment it and have the fragments reassembled by the tunnel egress; it has no other choice if it means to be compliant with RFC2460. Section 5.1: ************ This section does not currently honor the IPv4 minMTU of 576 bytes. In particular, for packets that are no larger than the IPv4 minMTU the tunnel ingress MUST ensure that the packet is delivered to the tunnel egress even if some fragmentation is necessary. Section 5.2: ************ This section does not currently honor the IPv6 minMTU of 1280 bytes. In particular, for packets that are no larger than the IPv6 minMTU the tunnel ingress MUST ensure that the packet is delivered to the tunnel egress even if some fragmentation is necessary. _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
