Re: [OSPF] What is the use of MTU field in DD packet

[Acee Lindem <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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
>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>>> _______________________________________________
>>>>>> OSPF mailing list
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>
>> _______________________________________________
>> OSPF mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ospf
>>
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf

_______________________________________________
OSPF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ospf