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

From: [email-masked]
Date: Fri, 15 Jun 2001 18:22:23 -0600

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

---

From: Nick Ambrose <[email-masked]>
Date: Tue, 19 Jun 2001 12:39:48 -0700

My confusion over the FIB draft was that I recall it being raised as part of
the minutes that we would vote on whether to "resurrect" this dormant work.
Come the end of the meeting, no one even seemed to notice that we had in
fact ignored the document entirely and not voted at all. I believe this is
(somewhat) reflected in the meeting notes.

Well, maybe we should merge the terms with our terminology document.
The disjoint terms seem to be:

5.6 Longest Length Prefix Match Algorithm 
5.7 Forwarding Information Base Prefix Distribution 
5.8 Per-Interface or Per-Card Forwarding Information Base  
5.9 Per-Interface Forwarding Information Base Cache 
5.10 Route Aggregation

Others that are somewhat comparable are ...
6.1 Maximum Forwarding Information Base Size (this is what we measure in the
RoutingProtocolEntry capacity test
but is not explictly called out in our term doc.)
6.2 Forwarding Information Base Learning Time (this is what we measure in
our convergence tests but we separate into RIB and FIB)

It looks like these metrics are coming from applying RFC 2544-style tests to
acknowledge RIB/FIB Entries inserted by Routing Protocols - maybe we need to
make that explicit ?

6.3 Forwarding Information Base-dependent Throughput (we could add a new
test to measure this - we have a similar one with route flapping - this is
even a special case of that)
6.4 Forwarding Information Base-dependent Latency 
6.5 Forwarding Information Base-dependent Frame Loss Rate 

We can merge terms that we both have in common, co-author the terminology
doc and add tests to our methodology doc to ensure we measure all the
metrics above (which I think we do) and maybe Guy could add some sections to
the term or method doc incorporating the FIB/RIB distribution ideas he
presents in his own doc ?

I also see the BGP convergence doc as being able to make use of these terms.
See my reply to David Newmans concerns for more details.

Also, the expiration date is incorrect in the draft as posted (Terminology
for FIB based Router Performance   July, 2000 )

> -----Original Message-----
> From: Kevin Dubray [mailto:[email-masked]]
> Sent: Tuesday, June 19, 2001 7:52 AM
> To: Nick Ambrose
> Cc: [email-masked]'; [email-masked]
> Subject: Re: [bmwg] Moving to last call: 
> draft-ietf-bmwg-fib-term-01.txt
> 
> 
> 
> 
> Nick Ambrose wrote:
> > 
> > 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
> > 
> >
> 
> 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
>

---

From: "TROTTER,GUY (A-Canada,ex1)" <[email-masked]>
Date: Wed, 20 Jun 2001 10:51:39 -0600

Hi Nick,

Thanks for your suggestions.  

However, since I'm trying to getting a last call on
draft-ietf-bmwg-fib-term-01.txt, and considering that your work is still in
the proposed workplan phase, I suggest that we complete the last call on
draft-ietf-bmwg-fib-term-01.txt.  

The appropriate terms from this document can, of course, be referenced in
your proposed terminology document.

Guy

-----------------------------------------------------------------------
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                      yahoo IM: guytrotter
CANADA                       http://www.agilent.com

> From: Nick Ambrose [mailto:[email-masked]]
> Sent: June 19, 2001 12:40 PM
> To: 'Kevin Dubray'; Nick Ambrose
> Subject: RE: [bmwg] Moving to last call:

---

From: Nick Ambrose <[email-masked]>
Date: Wed, 20 Jun 2001 12:29:42 -0700

It seems to me that this is now backwards.

I would far rather see a plan that addressed how we could merge our work,
rather than accept a document to last call that seems to have significant
overlap and then try to fix up the mess later. Just because it is further
along in the process is not a good reason (in my opinion) to accept it.

Maybe we need one consolidated term. doc and two method. docs based on it -
one for RIB and one for FIB testing ?
We could all co-author all three docs and combine our terms, metrics etc. to
produce a far better doc than all of us trying to do it separately

Also, apologies for stating that your doc was expired. I confused the
dropping of the old framework draft with yours - my mistake.

Nick

> From: TROTTER,GUY (A-Canada,ex1) [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 9:52 AM
> To: [email-masked]