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. 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”. 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. 3. The draft has deprecated PMTUD and introduced fragmentation instead of it. 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) 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. 5. The draft does break all tunneling specifications. Is everything should be changed in production? It is the cost. For what reason? 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. Hence, 6man and v6ops on the copy. I decided to leave it here for the people that may search for it in the future. Eduard
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
