Prasanna, I'm not that keen on using the same field for different purposes. I would hope that in most cases the MTUs would be the same anyway. Thanks, Acee
On May 29, 2008, at 3:03 AM, Prasanna Kumar A.S wrote: > Hi > I suggest following mechanism to communicate both the MTUs > Initial DD packet should carry the MTU of Address-family which > should > match with the mtu of that address-family otherwise mtu check should > fail, (I.e. if initial DD packet with AF bit set and matching MTU then > MTU check should pass) > > and subsequent DD packets should carry the ipv6-MTU (ignore MTU check > for non initial DD packet with Af bit set), And the ipv6 MTU of each > neighbor should be saved in the neighbor data-structure, then smallest > MTU of all the neighbors on the link is used for constructing the > ospf-packets to be transmitted on that link > > Regards > Prasanna > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of > Sina Mirtorabi > Sent: Thursday, May 29, 2008 7:42 AM > To: Acee Lindem; Paul Wells > Cc: OSPF List > Subject: Re: [OSPF] What is the use of MTU field in DD packet > > Hi Acee, > >>> This still leaves the question of what to do for af-alt when >>> routing address families other than IPv6. It seems that there are >>> two cases of interest in deciding which MTU to advertise in >> the DBD >>> packets: >>> >>> 1. IPv6 MTUs match, but IPv4 MTUs differ. >>> 2. IPv6 MTUs differ, but IPv4 MTUs match. >>> >>> In the first case I don't think we're doing anyone a favor by >>> installing routes in the IPv4 RIB that will be unreliable due to a >>> MTU mismatch. >>> >>> In the second case OSPFv3 flooding and synchronization may be >>> compromised. A side effect of this may be that the adjacency never >>> forms, or having formed may later fail. >>> >>> Short of resorting to LLS or some other way of communicating both >>> MTUs it seems we have to pick one or the other. >>> >>> I'd like to propose that we use the DBD packet to communicate the >>> IPv4 MTU when routing that address family, and use the IPv6 >> minimum >>> MTU of 1280 bytes for OSPFv3 protocol packets. >> >> This is a coherent proposal. I'd like to bounce this off the other >> authors and would solicit general comments. The question is whether >> the OSPFv3 protocol checking for MTU mismatches is worth relegated >> OSPFv3 exchange and flooding to the the IPv6 minimum MTU. I'm not >> sure it does but I'd like to open it up to a brief discussion. > > One issue is backward compatibility, if there is any implementation of > alt draft, then we cannot just change the MTU in the DD packet from > IPv6 > to IPv4 MTU. If we don't worry about backward compatibility (no > deployed > implementation) then we have a shot to define as appropriate. There > are > couple of options > > 1) Paul's proposal however I would add that IPv6 Path MTU discovery > should be used. > > 2) We can set a bit in the DD packet to indicate that the MTU value is > for both v4 and v6, if this bit is clear (i.e. MTU mismatch between v4 > and v6) then the MTU field in DD packet is for corresponding AF, e.g. > IPv4 and for IPv6 mtu we have to use 1) (minimum MTU), the > advantage of > this is that unless MTU is really different between v4 and v6 you > don't > blindly reduce the IPv6 mtu > > 3) carry the MTU value for both IPv6 and IPv4 either in DD packet > (there > are unused octet although not contiguous block) or through LLS. > > 4) any other options > > > The advantage of 2) a part from simplicity is that by not knowing the > IPv6 MTU we fall back to minimum MTU and adj will be formed, for 3) if > there is a MTU mismatch then unless you change the rule and state that > in case of mismatch, default minimum MTU should be used, the adj will > not be established if we follow the MTU mismatch rule. The only > advantage of the 3) compared to 2) is that in case IPv4 and IPv6 does > not match AND IPv6 are the same between the system, the actual IPv6 > MTU > (which is carried) is used instead of Minimum MTU. > > thanks > Sina > >> >> Thanks, >> Acee >> >> >> >>> >>> Thanks, >>> Paul >>> >>> Acee Lindem wrote: >>>> Hi Paul, >>>> On May 28, 2008, at 2:05 PM, Paul Wells wrote: >>>>> Hi Acee, >>>>> >>>>> I disagree about the "original intent" of the MTU field. >> As I see >>>>> it, it's function is to prevent an OSPF adjacency from forming >>>>> over a link where the endpoints disagree about the link MTU. We >>>>> do this primarily to prevent the data plane from using a link >>>>> that will drop packets sent to a system with an MTU smaller than >>>>> ours. >>>> I happen to remember the discussion of this problem on the OSPF >>>> list and this was not the primary motivation. There were lots of >>>> problems with bridged heterogeneous LANs with mismatched MTUs >>>> (ethernet, FDDI, token ring, and the worst of all technologies - >>>> ATM emulated LANs :^). Adjacencies would come up fine initially >>>> but the exchange process would hang indefinitely when they were >>>> restarted due to the router with the larger MTU having a larger >>>> database and trying to use full DD packets. Unfortunately, the >>>> OSPF list was hosted on a server at Microsoft Corporation >> in those >>>> days and I don't have access to archives. Here is some text from >>>> RFC 2178, appendix G: G.9 Detecting interface MTU mismatches >>>> When two neighboring routers have a different interface >> MTU for >>>> their >>>> common network segment, serious problems can ensue: large >>>> packets are >>>> prevented from being successfully transferred from one router >>>> to the >>>> other, impairing OSPF's flooding algorithm and possibly creating >>>> "black holes" for user data traffic. >>>> This memo provides a fix for the interface MTU mismatch >> problem by >>>> advertising the interface MTU in Database Description packets. >>>> When a >>>> router receives a Database description packet advertising an MTU >>>> larger than the router can receive, the router drops >> the Database >>>> Description packet. This prevents an adjacency from forming, >>>> telling >>>> OSPF flooding and user data traffic to avoid the connection >>>> between >>>> the two routers. For more information, see Sections >> 10.6, 10.8, >>>> and >>>> A.3.3. >>>> On the other hand, once the MTU checking was implemented, I >>>> believe data plane MTU consistency has been purported as a >>>> benefit. If we used the IPv4 MTU in the IPv4 address database >>>> exchanges, we could still have an IPv6 MTU mismatch. One could >>>> depend on the unicast IPv6 address family for this checking but, >>>> heretofore, we've kept the instances independent. Thanks, >>>> Acee >>>>> >>>>> While OSPFv3 certainly needs to know the IPv6 link MTU when >>>>> building it's packets, this information should be available >>>>> locally without reference to the MTU field in the DBD packet. >>>>> >>>>> So, I would argue that in af-alt the MTU in the DBD >> packet should >>>>> be for the address family we are routing, not IPv6 in all cases. >>>>> >>>>> Regards, >>>>> Paul >>>>> >>>>> Acee Lindem wrote: >>>>>> Hi Prasanna, >>>>>> On May 28, 2008, at 8:18 AM, Prasanna Kumar A.S wrote: >>>>>>> Hi >>>>>>> I just wanted to understand what the primary use of >>>>>>> exchanging MTU in >>>>>>> DD packets and doing MTU-check is? Is it only for the control >>>>>>> plane or >>>>>>> is it for the DATA-plane? >>>>>> Control-plane - when sending DD, LSR, and LSU packets, OSPF >>>>>> will attempt to send as many LSA headers or complete LSAs as >>>>>> will fit in a maximum sized packet. >>>>>>> Why I am getting this doubt is, in draft-ietf-ospf-af- >>>>>>> alt-06.txt doesn't >>>>>>> specify which MTU we should use while exchanging the DD packet >>>>>>> for the >>>>>>> ipv4-unicast or ipv4-mutlticast Address-family, is it >> ipv6-mtu or >>>>>>> ipv4-mtu? >>>>>> We have this clarified in the an update which we post soon. >>>>>> Since this is OSPFv3 which using IPv6 for transport, >> you always >>>>>> use the IPv6 MTU. >>>>>> Thanks, >>>>>> Acee >>>>>>> >>>>>>> Regards >>>>>>> Prasanna >>>>>>> _______________________________________________ >>>>>>> OSPF mailing list >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>>> _______________________________________________ >>>>>> OSPF mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://www.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ >> OSPF mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ospf >> > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
