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

Paul Wells <pauwells@cisco.com> Wed, 28 May 2008 21:31 UTC

Return-Path: <ospf-bounces@ietf.org>
X-Original-To: ospf-archive@optimus.ietf.org
Delivered-To: ietfarch-ospf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49BDF3A6A92; Wed, 28 May 2008 14:31:23 -0700 (PDT)
X-Original-To: ospf@core3.amsl.com
Delivered-To: ospf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19D383A6A92 for <ospf@core3.amsl.com>; Wed, 28 May 2008 14:31:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQMKwG73y3+Y for <ospf@core3.amsl.com>; Wed, 28 May 2008 14:31:20 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E108E3A6835 for <ospf@ietf.org>; Wed, 28 May 2008 14:31:20 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,557,1204531200"; d="scan'208";a="36778484"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 28 May 2008 14:31:30 -0700
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4SLVUPA013640; Wed, 28 May 2008 14:31:30 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m4SLVUqK029842; Wed, 28 May 2008 21:31:30 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 14:31:28 -0700
Received: from pauwells-linux.cisco.com ([10.19.20.100]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 14:31:28 -0700
Message-ID: <483DCF2F.2040801@cisco.com>
Date: Wed, 28 May 2008 16:31:27 -0500
From: Paul Wells <pauwells@cisco.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Acee Lindem <acee@redback.com>
References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> <C71840B5-D198-4EA8-B132-0EFD68F54FD8@redback.com> <FDC03E35ADE75E40946C3E92BE45EA5E01518A42@emailbng2.jnpr.net> <BDF86469-AC88-444C-BABD-A80F4E774A41@redback.com> <483D9ECE.5080300@cisco.com> <DDD4820E-1879-486B-8C3A-66CA4C58AFF4@redback.com>
In-Reply-To: <DDD4820E-1879-486B-8C3A-66CA4C58AFF4@redback.com>
X-OriginalArrivalTime: 28 May 2008 21:31:28.0567 (UTC) FILETIME=[3062BC70:01C8C10A]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5365; t=1212010290; x=1212874290; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pauwells@cisco.com; z=From:=20Paul=20Wells=20<pauwells@cisco.com> |Subject:=20Re=3A=20[OSPF]=20What=20is=20the=20use=20of=20M TU=20field=20in=20DD=20packet |Sender:=20; bh=XWgDhgWmH5m/TnmXOeqSLYB+phioMyA2sbtBT1SdA9w=; b=fb7rv63pEnEqS7ei9n0M8LLbPOnLzTHy31ZsIj5fq67Csnmi1Kj8/Eh89j jDeSYr47BDdZei97yIK8R/yn9awnKM15W614qbZWPfSvx9qF1MyIlasv2mQx IZv1xFFnsx;
Authentication-Results: sj-dkim-2; header.From=pauwells@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
Cc: OSPF List <ospf@ietf.org>
Subject: Re: [OSPF] What is the use of MTU field in DD packet
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ospf-bounces@ietf.org
Errors-To: ospf-bounces@ietf.org

Hi Acee,

That was before my time, so I'll defer to your recollection about 
how OSPF MTU checking came to be. The section of 2178 below does 
seem to give equal weight to both the control and data plane 
benefits of MTU verification however.

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.

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