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
- Re: [OSPF] Database Exchange Summary List Optimiz… Acee Lindem
- Re: [OSPF] Database Exchange Summary List Optimiz… Erblichs
- Re: [OSPF] Database Exchange Summary List Optimiz… Acee Lindem
- Re: [OSPF] Database Exchange Summary List Optimiz… Erblichs
- Re: [OSPF] Database Exchange Summary List Optimiz… Hasmit Grover
- Re: [OSPF] Database Exchange Summary List Optimiz… Acee Lindem
- Re: [OSPF] Database Exchange Summary List Optimiz… Erblichs
- Re: [OSPF] Database Exchange Summary List Optimiz… Richard Ogier
- Re: [OSPF] Database Exchange Summary List Optimiz… Erblichs
- Re: [OSPF] Database Exchange Summary List Optimiz… Richard Ogier
- Re: [OSPF] Database Exchange Summary List Optimiz… Acee Lindem
- Re: [OSPF] Database Exchange Summary List Optimiz… Richard Ogier
- Re: [OSPF] Database Exchange Summary List Optimiz… Acee Lindem
- Re: [OSPF] Database Exchange Summary List Optimiz… Paul Jakma
- Re: [OSPF] Database Exchange Summary List Optimiz… Richard Ogier
- Re: [OSPF] Database Exchange Summary List Optimiz… Erblichs
- Re: [OSPF] Database Exchange Summary List Optimiz… Acee Lindem
- Re: [OSPF] Database Exchange Summary List Optimiz… Paul Jakma
- Re: [OSPF] Database Exchange Summary List Optimiz… Erblichs
- Re: [OSPF] Database Exchange Summary List Optimiz… Acee Lindem
- Re: [OSPF] Database Exchange Summary List Optimiz… Richard Ogier
- Re: [OSPF] Database Exchange Summary List Optimiz… Erblichs
- Re: [OSPF] Database Exchange Summary List Optimiz… Acee Lindem
- Re: [OSPF] Database Exchange Summary List Optimiz… Richard Ogier
- Re: [OSPF] Database Exchange Summary List Optimiz… Erblichs
- Re: [OSPF] Database Exchange Summary List Optimiz… Richard Ogier
- Re: [OSPF] Database Exchange Summary List Optimiz… Richard Ogier