RE: [bmwg] IGP Data Plane Convergence work item
"Howard C. Berkowitz" <hcb@gettcomm.com> Thu, 15 April 2004 18:30 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11023 for <bmwg-archive@lists.ietf.org>; Thu, 15 Apr 2004 14:30:06 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEBTy-0002IX-7G; Thu, 15 Apr 2004 14:21:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEBNz-00011s-Ue for bmwg@optimus.ietf.org; Thu, 15 Apr 2004 14:14:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10351 for <bmwg@ietf.org>; Thu, 15 Apr 2004 14:14:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEBNx-0006M2-00 for bmwg@ietf.org; Thu, 15 Apr 2004 14:14:49 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEBMz-0006KJ-00 for bmwg@ietf.org; Thu, 15 Apr 2004 14:13:49 -0400
Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1BEBM4-0006IF-00 for bmwg@ietf.org; Thu, 15 Apr 2004 14:12:52 -0400
Received: from [192.168.0.2] (pcp09296126pcs.arlngt01.va.comcast.net[69.143.165.226]) by comcast.net (sccrmhc11) with ESMTP id <200404151812220110099q1ue> (Authid: hcb8); Thu, 15 Apr 2004 18:12:22 +0000
Mime-Version: 1.0
X-Sender: hcb8@smtp.comcast.net (Unverified)
Message-Id: <p05100322bca47e039174@[192.168.0.2]>
In-Reply-To: <496A8683261CD211BF6C0008C733261A0430DD96@email.quarrytech.com>
References: <496A8683261CD211BF6C0008C733261A0430DD96@email.quarrytech.com>
Date: Thu, 15 Apr 2004 14:12:19 -0400
To: bmwg@ietf.org
From: "Howard C. Berkowitz" <hcb@gettcomm.com>
Subject: RE: [bmwg] IGP Data Plane Convergence work item
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: bmwg-admin@ietf.org
Errors-To: bmwg-admin@ietf.org
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
At 1:42 PM -0400 4/15/04, sporetsky@quarrytech.com wrote: >-----Original Message----- >From: Howard C. Berkowitz [mailto:hcb@gettcomm.com] >Sent: Thursday, April 15, 2004 1:07 PM >To: bmwg@ietf.org >Subject: Re: [bmwg] IGP Data Plane Convergence work item > > > >Perhaps it would be worth knowing -- are there any terminology >harmonization issues between the IGP and EGP documents? > >Scott> None that I know of. > >Is it the >sense of the working group that IGP and EGP terminology are >essentially separate? >Scott> Yes. In fact there are two separate terminologies for IGP >convergence- 1 for OSPF >Control Plane Convergence and 1 for IGP Data Plane Convergence. > >Is there a union-of-sets of terminology common >to both? > >Scott> None that I see. > >Any general thoughts? Ouch. You reminded me that the problem is worse than I thought. Again, I have to go over the papers in detail, but it would surprise me that there is zero overlap between IGP control and data, much less EGP. Let me explain my thinking, which may mean there is a term not defined that perhaps should be. Assumption 1: The control plane will converge before the data plane. Any objection here? Let's call this convergence C. Assumption 2: Since the data plane has to get forwarding tables loaded (unless the FIB and RIB are the same data structure), data plane convergence will usually take a little longer than control plane convergence. Again, any objections? Let's call this D. If the RIB and FIB are identical, D - C is zero or near zero. I say near zero, on the chance that the test methodology is such that a packet enters the router before the combined table converges, so you get ICMP Destination Unreachable. For separate FIB and RIB, D - C is a somewhat longer value. D, C, and D-C are all useful numbers. D is the practical time it will take for the router to start forwarding. D-C is the overhead time needed to set up forwarding, and C is the overhead time to compute the RIB. I would think that the terminology/common terminology should be able to show the relationships among these three numbers. Perhaps the specific IGP terminology drafts aren't the place to discusss this -- maybe it comes back to the separate document Russ is proposing. Since there is no EGP data plane document as yet, we can only talk about C in draft-ietf-bmwg-conterm-05.txt. Russ, is this an area that gives your proposal new life? It's certainly arguable that C gets defined in the control plane documents, and I would hope this can harmonize between IGP and EGP. D gets defined in the data/forwarding plane, but I can see that the authors of a D plane document might not feel it within their scope to discuss D-C. D-C, however, is a useful number for designers. It becomes especially significant when the router architecture is such that a withdrawal-and-reconvergence even flushes the FIB and stops forwarding while it rebuilds. We are all aware of some older cache schemes in which this happens. Is a data plane document the right place to talk about cache miss and cache rebuild overhead, or, again, is it a meta-issue that might fall under Russ' potential scope? _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg
- [bmwg] IGP Data Plane Convergence work item sporetsky
- Re: [bmwg] IGP Data Plane Convergence work item Howard C. Berkowitz
- RE: [bmwg] IGP Data Plane Convergence work item sporetsky
- RE: [bmwg] IGP Data Plane Convergence work item Howard C. Berkowitz
- RE: [bmwg] IGP Data Plane Convergence work item Russ White
- Re: [bmwg] IGP Data Plane Convergence work item Russ White