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]
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
