Subject: RE: [bmwg] Moving to last call: draft-ietf-bmwg-fib-term-01.txt

From: Nick Ambrose <[email-masked]>
Date: Mon, 18 Jun 2001 16:03:19 -0700

Since this document expired before the last meeting and there was no
successful vote to resume the work by those present, I propose that we
instead focus on the proposed Workplan presented by myself and Debby Stopp -
Proposed Workplan for Routing Protcool Testing

Nick

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, June 15, 2001 5:22 PM
> To: [email-masked]
> Subject: [bmwg] Moving to last call: draft-ietf-bmwg-fib-term-01.txt
> 
> 
> Hi all,
> 
> I would like to move to last call on my draft,
> draft-ietf-bmwg-fib-term-01.txt.
> 
> A copy of the draft can be found at:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-bmwg-fib-term-01.txt
> 
> FYI, the list of changes from version 0 are below.
> 
> I have asked Kevin to move this document to last call.
> 
> Guy
> 
> ==================================
> 
> Changes (from version 0):
> 
> - Broke the definitions into 2 sections: "parameters" and "metrics"
> 
> - Network Prefix Length
> 	- Rephrase "refers to the length in bits of a network prefix" 
>      	  to "Number of bits used to define the network prefix"
> 	- measurement units should just be "bits"
> 
> - Forwarding Information Base (FIB)
> 	- indicate that the FIB is separate from the "routing table"
> 	  (i.e. the RIB).  Indicate that there are no secondary paths	
> 	  in the FIB
> 	- remove text describing the longest length prefix match
> 	  algorithm (out of place)
> 
> - Forwarding Information Base Entry
> 	- added text to indicate that the size refers to the 
> total number
> 	  of active routes within the FIB.  That is, the FIB could 
> 	  potentially hold routes that a router might not be able to use
> 	  to forward packets - this definition indicates the 
> total number
> 	  of routes inside the FIB that can and are used to forward 
> 	  packets
> 	- measurement units, instead of being "positive integer" should
> 	  be "number of routes"
> 
> - Forwarding Information Base Prefix Distribution
> 	- in the 3d paragraph in the discussion, change "will have an 
>   	  impact" to "may have an impact"
> 	- for measurement units,  use absolute number of routes instead 
> 	  of percentages to eliminate any uncertainty as to the number 
> 	  of routes advertised into the router.  I.e. instead of a 
> 	  list like:
> 		{[/16, 10%], [/20, 36%], [/24, 54%]}
> 	  use (in the case that we're advertising 1000 routes):
> 		{[/16, 100], [/20, 360], [/24, 540]}
> 
> - Maximum Forwaring Information Base Size
> 	- measurement units should be "number of routes"
> 
> - Forwarding Information Base Learning Time
> 	- change the definition in the first paragraph from "The
> 	  forwarding information base learning time is the time taken
> 	  for a router to receive and ..." to "The time a router
> 	  takes to process ..."
> 	- extended the definition to specify that the learning time is
> 	  the time from when a router receives the first routing 
> 	  message, through to when it is able to forward packets using
> 	  any entry in the FIB.
> 	- add measurement units "prefixes per second"
> 
> - Per-Interface Forwarding Information Base
> 	- changed this definition to "Per-interface or per-card 
>   	  forwarding information base" to reflect the fact that 
> 	  a FIB can be installed on a per-interface or possibly a 
> 	  per-card basis.
> 
> - Route Aggregation
> 	- in the discussion section, specified that route aggregation
> 	  within the router could be turned on or off, but that the
> 	  routes advertised into the router must be controlled and
> 	  monitored in order to avoid aggregation
> 
> - Fully Meshed Traffic Flows
> 	- I removed this definition, as it is essentially a restatement
>   	  of the definition in RFC 2285.  The application of the 
> 	  fully meshed traffic flows to this type of testing will be
> 	  explained in the methodology.
> 
> - added a short definition for "longest length prefix match"
> 
> - added a note in the introduction specifying that this document is
>   restricted to IPv4 routers.
> 
> --------------------------------------------------------------
> ---------
> Guy Trotter
> Agilent Technologies         phone: +1 604 454 3516
> Advanced Networks Division   fax:   +1 604 454 3401
> #2500 4710 Kingsway          mailto:[email-masked]
> Burnaby, British Columbia    page:  
mailto:[email-masked]
V5H 4M2                      http://www.agilent.com
CANADA 

_______________________________________________
bmwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/bmwg

_______________________________________________
bmwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/bmwg

---

From: Kevin Dubray <[email-masked]>
Date: Tue, 19 Jun 2001 10:52:08 -0400

> Proposed Workplan for Routing Protcool Testing

FIB benchmarks here, convergence benchmarks there, overarching 
Router Protocol testing!!

Perhaps we shouldn't have let the Router Benchmarking Framework
I-D/effort die such a quiet death, eh?? ;-) ;-)

Nick, the fib draft referenced on the BMWG site is current,
has been discussed, and no serious technical deficiencies
have been identified, thus far.

As I peruse the 3 drafts hinted above, I do note that there is
some consistency issues with terminology (e.g., FIB) that
will be tightened up. 

To help that process along, I will issue the last call
on <draft-ietf-bmwg-fib-term-01.txt>.  Because of
the alignment issues, I'll extend the last call period
for adequate discussion.

Hopefully, this will give ALL the opportunity to support
the draft, offer suggestions to make it stronger, or provide
technical reasons why the I-D should not progress.  
 
WG:

To summarize:

   1. A 3 week Last Call on draft-ietf-bmwg-fib-term-01.txt will
      be issued.

   2. The Last Call on the new work proposal on convergence
      will close 29 June 01.

   3. Please familiarize with the Ambrose/Stopp draft and proposal.
      Recommendations to make the related works more complimentary
      are welcome. 

-Kevin