> -----Original Message----- > From: Xuxiaohu > Sent: Wednesday, June 01, 2016 3:16 PM > To: 'Joe Touch'; Brian E Carpenter > Cc: joel jaeggli; Fred Baker (fred); Wassim Haddad; [email protected] > Subject: RE: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03 > > > > > -----Original Message----- > > From: Joe Touch [mailto:[email protected]] > > Sent: Wednesday, June 01, 2016 1:03 PM > > To: Xuxiaohu; Brian E Carpenter > > Cc: joel jaeggli; Fred Baker (fred); Wassim Haddad; [email protected] > > Subject: Re: [Int-area] Call for adoption of > > draft-xu-intarea-ip-in-udp-03 > > > > > > > > On 5/31/2016 7:43 PM, Xuxiaohu wrote: > > > In the above case, there are three FEASIBLE ways: > > Let's take these in order then: > > > > > 1) Configure the transit core to carry an MTU at least large enough > > > to accommodate the added encapsulation headers. Note that this is > > > the dominant and mature choice in most MPLS networks; > > > > So you are deploying IPv6 over an IPv6 tunnel. Even without UDP, you > > still need > > 40 bytes for the encapsulation header. > > > > So in order to deploy a compliant IPv6 1280-byte MTU tunnel, you need > > to use a core that you know can transit IPv6 packets that are 1320 bytes. > > 1320 is not a problem at all. Many modern routers can even support 9000-byte > and even large MTU. In a words, setting the MTU of the core large enough to > accommodate the added encapsulation headers is easy in Softwire networks > which are well-managed SP networks. > > > Unless you examine every physical link to ensure that the technology > > supports a larger MTU, you're stuck assuming that your IPv6 equipment > > can only guarantee 1280. Which means you can't know this will work.
BTW, assume SPs couldn't guarantee the tunnel path MTU is large than 1280, the network throughput would be sharply decreased by 50% to 90% (according to some vendor's document). Please ask SPs whether they could afford that cost. Xiaohu > > It's no problem to ensure each physical link supports a larger MTU. It's a > Best > Current Practice in MPLS networks which are well-managed SP networks as > well. > > > Even if you do know this for a physical path, every path you *think* > > is physical will be virtualized at some point, and at some point the > > number of layers of tunneling will end up eating the whole of any "headroom" > > you engineer. > > It's true that some paths in the MPLS networks are virtualized (e.g., LDP > over TE) > as well. However, as said before, configuring the MTU of the core large enough > is still be Best Current Practice in MPLS networks. Imagine that the MTU of > the > core is set to 5000, it will accommodate many layers of tunneling. It's hard > to > understand that large headroom is eaten up in reality. > > > > 2) Fragment the packet before encapsulation if allowed; > > > > That covers only IPv4 with DF=0. It won't cover DF=1 or IPv6. > > Yes "if allowed" means IPv4 with DF=0. > > > > 3) Drop it if inner fragmentation is not allowed. > > You've now black-holed your network, all because you didn't want to > > use the 1500-byte fragmentation and reassembly that every IPv6 source > > and sink are already required to support (per RFC2460). > > > > Note that every tunnel ingress is a IPv6 source and every IPv6 egress > > is an IPv6 sink, so if you claim that many vendors don't support this, > > you're just pointing out that they don't satisfy existing IPv6 requirements. > > IMHO, RFCs are not academic papers. Hence it would be beneficial for both > vendors and operators if the requirements specified in RFCs could take the > reality, especially the best current practices more into account. > > Xiaohu > > > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
