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

["Prasanna Kumar A.S" <[e-mail]>]

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