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