Re: [OSPF] Database Exchange Summary List Optimization

Acee Lindem <acee@cisco.com> Mon, 17 July 2006 22:41 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2blz-0003ow-3Y; Mon, 17 Jul 2006 18:41:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2blx-0003om-Vy for ospf@ietf.org; Mon, 17 Jul 2006 18:41:05 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2blv-0001lR-Ga for ospf@ietf.org; Mon, 17 Jul 2006 18:41:05 -0400
Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-2.cisco.com with ESMTP; 17 Jul 2006 15:41:03 -0700
X-IronPort-AV: i="4.06,252,1149490800"; d="scan'208"; a="329567160:sNHT28131628"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6HMf2Fl002439; Mon, 17 Jul 2006 15:41:02 -0700
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6HMf2HS001515; Mon, 17 Jul 2006 15:41:02 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 18:41:02 -0400
Received: from [10.82.224.204] ([10.82.224.204]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 18:41:02 -0400
Message-ID: <44BC11FD.6000809@cisco.com>
Date: Mon, 17 Jul 2006 18:41:01 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Erblichs <erblichs@earthlink.net>
Subject: Re: [OSPF] Database Exchange Summary List Optimization
References: <44B7E563.3000706@cisco.com> <44B7E6D0.6030304@cisco.com> <44B7FCC8.BFE9F407@earthlink.net> <44B80637.2060704@cisco.com> <44B81707.3237A28@earthlink.net>
In-Reply-To: <44B81707.3237A28@earthlink.net>
Content-Type: text/plain; charset="ISO-8859-2"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Jul 2006 22:41:02.0103 (UTC) FILETIME=[14B20A70:01C6A9F2]
DKIM-Signature: a=rsa-sha1; q=dns; l=4502; t=1153176062; x=1154040062; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20<acee@cisco.com> |Subject:Re=3A=20[OSPF]=20Database=20Exchange=20Summary=20List=20Optimization; X=v=3Dcisco.com=3B=20h=3DVwI3WZywBXmh7qJ9oTkEHQ724GE=3D; b=rXx/ArcIsbFf4V0raBVvva/TbqSWh0gPrVfUv0rnU5fFAe+RFaeUP4tqtOflBzrcqNVfMl+0 HIiEU/HCyCkvx43DdyP7Rka2rCLeTBmJyoJZOcV9dLzVMamGh4M6+RQe;
Authentication-Results: sj-dkim-5.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Cc: OSPF List <ospf@ietf.org>
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi Mitchell,

Erblichs wrote:
> Acee Lindem,
>
> 	The one benefit that I "sliently" thought of was the
> 	ability to re-send the REQ at any time AFTER LSDB
> 	synch has occured. A flag could be set for re-synch
> 	versus a new synch, which could flush the LSAs that
> 	originated from the REQ router.
>   
I was hoping one of the draft authors would have said "Been there, done 
that".
See the experimental draft in the link below:

      
http://www.ietf.org/internet-drafts/draft-nguyen-ospf-oob-resync-05.txt

Note that flushing stale LSAs happens naturally via the existing 
database exchange
process.

Thanks,
Acee

> 	It is assumed that for one of many reasons, the router's
> 	LSDB has become un-sync'ed and is unwilling to wait
> 	for normal flooding or non-flooding if DNA LSAs are
> 	implemented. Doing a full LSDB is un-necessary.
>
> 	It also has a non-permanence to it, where a system's
> 	functionality support could be updated without a
> 	reboot / graceful restart. Isn't this an issue with
> 	the usage of these bits?
>
> 	Are any of these items on his wish/requirements list?
>
> 	Mitchell Erblich
> 	-------------------
>
> 	
> 	
>
> Acee Lindem wrote:
>   
>> Mitchell,
>>
>> First let's see if anyone can come up with a requirement for
>> explicit signaling of the Richard's proposal. However, I see
>> absolutely on advantage to the signaling you are suggesting over
>> simply setting a bit in the database exchange packet I_M_MS
>> field.
>>
>> Thanks,
>> Acee
>>
>> Erblichs wrote:
>>     
>>> Acee and Richard,
>>>
>>>       A "ugly workaround" instead of using the DB exhange
>>>       field could be:
>>>
>>>       Sending a new OSPF pkt type as a REQ and if a RESP
>>>       of that pkt type is recv, then that functionality is
>>>       supported..
>>>
>>>       Since, it would only be sent at the begining of the
>>>       initial DB synch, the overhead of recving one unknown pkt
>>>       type should be minimial. A short timeout is needed and
>>>       if a response is not seen within the timeout, standard
>>>       initial LSDB synch should take place.
>>>
>>>       This is backward supported in v2 because unknown types
>>>       are discarded. This effectively generates a private set
>>>       of pkt types where only the aware routers will read this
>>>       pkt type and the unaware will discard the unknown type.
>>>
>>>       So, with that out-of-the-way.
>>>
>>>       This same new pkt type could be a TVL type pkt, where
>>>       each known OSPF LSA type is specified with a count, and
>>>       a checksum-summation. If the summation matches and the
>>>       count matches the LSA type COULD be considered synched.
>>>
>>>       If their is any interest, I can write up a short EXP RFC
>>>       to validate this type of functionality.
>>>
>>>       Mitchell Erblich
>>>       -------------------
>>>
>>>
>>>
>>> Acee Lindem wrote:
>>>
>>>       
>>>> Hi Richard,
>>>>
>>>> Richard Ogier wrote:
>>>>
>>>>         
>>>>> I have one concern.  What if some future extension of OSPF assumes that
>>>>> DD packets list all LSAs as specified in RFC 2328, e.g., so that some
>>>>> action can be taken that depends on how "out of sync" the new neighbor
>>>>> was.  If someone implements the optimization without any indication
>>>>> (such as a new option bit), then a future extension
>>>>> might incorrectly conclude that the new neighbor was out of sync
>>>>> and take the wrong action.  This could be fixed either by including
>>>>> a new option bit, or by changing the spec of OSPF to allow the
>>>>> optimization.  Is this a valid concern?
>>>>>
>>>>>           
>>>> I'm not sure that I can think of any optimization that would rely on
>>>> the neighbor sending a full database snapshot. Especially, when you
>>>> consider that it would need to be fully backward compatible Can
>>>> you imagine any?
>>>>
>>>> Anyway, if this is a concern the document would needs to be standards
>>>> track and I think we should use a bit in the database exchange I_M_MS
>>>> field rather than the options (there are no free bit left in OSPFv2).
>>>>
>>>> Thanks,
>>>> Acee
>>>>
>>>>
>>>>         
>>>>> Richard
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> _______________________________________________
>>>> OSPF mailing list
>>>> OSPF@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/ospf
>>>>
>>>>         
>>>       
>
>   

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf