Hi, Eduard, I’ve repeatedly addressed these, so in the same spirit of “putting it all in one place”, here are the answers.
Joe > On Mar 25, 2021, at 3:52 AM, Vasilenko Eduard <[email protected]> > wrote: > > Hi Experts, > I have not received answers (after a long message thread) for me to > understand: > > 1. It is assumed by the draft that Data Plane in the transit router > operates right now exactly like a host. Then Generalization is attempted for > IP stack operation like on a host. > It is not the case. Moreover, it is not possible in principle because the > hardware is ASIC managing traffic flow, but the host is CPU “running to > completion” for control flow. The architecture of hardware is completely > different. Tunnel endpoints act like hosts. ASIC hardware can and does support fragmentation and reassembly at high speeds, and has *for decades* (all ATM hardware did this). > 2. It is additional complexity: 2 MTUs for one virtual interface > instead of the current 1 in all real data planes. 1st MTU is the buffer size > - called “Tunnel MTU”. 2nd MTU is the old tunnel MTU- called “MAP”. They exist, whether you consider them complex or not. Sometimes they’re the same value (i.e., when no fragmentation is supported over the tunnel) and sometimes they’re fixed and known a-priori, but none of that changes that. > It looks extremely bad after the decision that 1st MTU (buffer size) is > static till some miracle would explain to us how it would become dynamic in > the future. Nobody has claimed that the tunnel pathMTU (MAP in draft-tunnels) or EMTU_R (true tunnel MTU) cannot change. > 3. The draft has deprecated PMTUD and introduced fragmentation instead > of it. Draft-tunnels is intended as BCP. It has no power to deprecate. Draft-tunnels does not imply that PMTUD should be used less frequently; it merely repeats the observation known for over 20 yrs that ICMPs are largely blocked and reliance on PMTUD is only asking to experience black-holes. > To be precise: for all bulk traffic that would happen between MTUs. > Moreover, It is not explained what to do for tunneling that does not want > fragmentation now (currently prefer PMTUD). Should all tunnels support > fragmentation from now on? (L2TPv3, VxLAN, MPLS, RFC 2473) Any tunnel that is used directly recursively (X over X, i.e., L2TPv2 over L2TPv3, etc.) must have an EMTU_R larger than its pathMTU. If it does not, it cannot support that use. Those are factual observations, not requirements to specifications claims. > 4. If PMTUD is deprecated, then why it is still used for the 2nd > interface MTU? If it is dead, then it is dead, right? Anyone could have the > conclusion that the 2nd MTU is static too. PLPMTUD does not use ICMPs but still relies on these two MTUs. > 5. The draft does break all tunneling specifications. Is everything > should be changed in production? It is the cost. For what reason? Draft-tunnels breaks nothing; it observes that some tunneling specifications *are already inherently broken*. Seeing a broken window and reporting it does not mean that you broke that window. > It does affect IPv6 too – I had stumbled upon this problem from that > direction. RFC 2473 is the best tunneling spec that would be damaged severely. RFC2473 has errors - as noted in Sec 5.2 of v10 of draft-tunnels. I welcome discussion on those errors as well as how draft-tunnels should proceed. It is intended for BCP, which cannot update other docs - but it does not itself specify anything. But it could (should?) update all the standards noted in Sec 5.2. Can anyone suggest how best to do that? > Hence, 6man and v6ops on the copy. > > I decided to leave it here for the people that may search for it in the > future. Same here. > Eduard > _______________________________________________ > v6ops mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/v6ops > <https://www.ietf.org/mailman/listinfo/v6ops>
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
