Iljitsch, >-----Original Message----- >From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] >Sent: Friday, February 29, 2008 8:05 AM >To: Templin, Fred L >Cc: Internet Area >Subject: Re: [Int-area] Multi-MTU subnet draft > >On 29 feb 2008, at 2:36, Templin, Fred L wrote: > >> Having read further now, I think I get what is being >> proposed. As I mentioned before, I have also suggested >> adding MTU info in IPv6 ND messages in past efforts: > >> http://www.potaroo.net/ietf/idref/draft-templin-v6v4-ndisc/ >> http://www.potaroo.net/ietf/idref/draft-templin-ndiscmtu/ > >I saw one of them before, yes. But the approach is fairly different.
There are many others I could cite as well. But, the approach is to put extra "stuff" in ND messages that pertains to MTU. >> If I get what is being proposed, I believe the mechanisms >> you are proposing may be useful in conjunction with SEAL. > >> The reason I asked about the router-to-router is that >> that is the SEAL use case, and it would be "interesting" >> to see whether the loose interpretation of RS/RA you are >> making could be applied between a pair of routers at >> either end of a virtual link such as for the SEAL >> ingress/egress tunnel routers. > >Right. That should work well if neighbor discovery is performed >through the tunnel, which is fairly common from what I've seen. > >One issue would be that if the tunnel gets rerouted, the MTU can >change. The draft currently only catches that with dead neighbor >detection, which routers on tunnel endpoints can't do... So that could >be a problem. In theory the same problem can happen on a layer 2 >network but in practice that wouldn't happen very easily. I'm not looking for the RA to tell an MTU size that will work across the tunnel once and for always. I want the RA coming from the tunnel far end to tell the tunnel near end the MRU the TFE is able to receive w/o respect to the tunnel path MTU. That way, the TNE can tell whether it even makes sense to admit a large packet into the tunnel since there is no point in doing so if the TFE's MRU is too small. >> 1) Section 1, text beginning: "However, [RFC4821] must >> be implemented in every transport protocol...", I'm not >> sure I understand/agree with the point. My understanding >> of RFC4821 was that incremental deployment was supported. > >Well, if you have RFC 4821 in your TCP implementation that doesn't buy >you anything for NFS or DNS with EDNS0 over UDP. Oh - I thought when you said "every transport protocol" you were talkng about every transport protocol on all nodes everywhere. It is clear now that you were talking about every transport protocol *of the same node*. I'm not sure on that point though, because I thought that at one point RFC4821 had something to say about MTU sharing between transports of the same node. Need to check to see if it is still there... >It's incremental in >the sense that you can deploy it where it's not deployed and things >get better. But in the case of my draft, we make things worse by >removing the fixed MTU so if you then repair that with something that >doesn't cover 100% of all cases, you're left with a certain number of >cases where there will be problems. > >> Also, I don't understand the part about "significant >> probability for failures"? > >"if hosts implementing [RFC4821] interact with hosts that don't >implement this mechanism but do use a larger than standard MTU." > >Suppose host A lives on a subnet with variable MTUs and host B lives >on a different subnet with a manually configured jumboframe MTU. If A >and A's router support probing as outlined in the draft, then >everything will work. > >However, suppose there is a switch on the network that doesn't support >A's MTU. Without the probing defined in the draft, A can still >discover what packet size it can use towards B, but the router doesn't >see that A can't successfully receive the large packets that B sends >to it can't send back a too big, and B doesn't implement RFC 4821 so >if it sends large packets, it can't recover from the path MTU >discovery black hole. This isn't a failure case for running or not RFC4821, though; this is a failure case for allowing nodes with diverse MTUs on links that don't support diverse MTUs. Indeed, this failure case has nothing to do with RFC4821. >> 2) Section 4.1 and onwards, I'm not so sure about the >> "SLOWMTU" applicability. IMHO, the mechanisms in this >> document should be useful whether the receiver of the >> RA is directly connected to the same physical link as >> the router that sent it, or whether there are potentially >> many physical links with different properties in the >> path (e.g., when the subnet spans multiple bridged links.) > >Absolutely. But what does that have to do with SLOWMTU? > >The idea behind SLOWMTU is twofold: it could be that the slow hosts >are behind switches that don't support the larger MTU, and even if the >slow hosts COULD send large packets, that may be undesirable because >it increases RTTs and jitter. I am considering the case of fast links at the edges and slow links in the middle. Something like GigE at the edges and 100Mbps Ethernet in the middle, i.e., the "dumbell configuration" yet again! If the nodes on fast links think they can send large packets based on their attached link bandwidths, it could be a problem. >> 3) Section 4.2, perhaps this text is part of what you were >> meaning about being careful about node, host, route, etc. >> Particularly interesting is the part beginning: "Devices >> not acting as IPv6 routers ... MAY send out a router >> advertisement ...". I think this is worth considering, >> and also worth considering is whether two routers connected >> by a virtual link that spans an interdomain routing region >> (default-free, perhaps) can mutually send RAs with multi-MTU >> options to one another (with Router Lifetime=0, of course). > >Why would they send out router advertisements? The information about >the supported MTUs is available in neighbor solicitations/ >advertisements, which routers DO send to each other. I thought you were saying the NS/NA functions were optional? Also routers sending RAs to each other can be used as a means to propagate RFC4191 Route Information Options (RIOs). >> The Ras might also contain RFC4191 RIOs, but no RFC4861 PIOs >> and such. > >Hey, a new neighbor discovery RFC... Managed to miss that. No; not at all. Standard ND combined with RFC4191. Fred [EMAIL PROTECTED] >RIO = route information option, PIO = prefix information option (or >something like that)? Note that these acronyms don't appear in those >RFCs. > >I think it could be useful for routers to advertise a maximum packet >size for the default route, or at least, indicate that large packets >can't be used there. The downside is that you can then only use them >on the local subnet, unless you start adding them to RFC 4191 >information... Sticking to PMTUD is simpler. Packet sizes aren't >dependent on addresses so in the prefix options wouldn't make much >sense, IMO. _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
