Subject: Fathers Day is near, Are you ready?
From: [email-masked]
To: [email-masked]
Date: Thu, 28 May 1998 01:58:19 -0700 (PDT)

FATHER'S DAY - SUNDAY - JUNE 21st

Are you like most people who are looking for a truly unique Father's Day gift to let Dad know how much you love, respect, admire him, and to say thanks for everything he's done for you?   Send Dad an e-mail.  Give him the ability to send one back, and open up a whole new world for him!  

Treat Dad to something really special this year, explore the latest dimension in global communication together.  Give him a gift you can both enjoy on Father's Day and everyday thereafter. 

For those Dads who do not have access to a home based computer you can introduce him to the world of TV-Internet with "THE CRUZIR". "THE CRUZIR" is not geared to replace the computer. "THE CRUZIR"  is a revolutionary features packed telecommunications hardware driven device, which provides access to the Internet using two services, that are already in the home, the TV set and the telephone line. If he has a computer, the advantage of "THE CRUZIR" is it is very light and portable and travels well.  

What a fun way to help bring Dad on-line!  He can e-mail his local friends, he can look for long lost buddies and email them, he can explore the information and services available on the Internet. This can all be done from his favorite easy chair, because there are no wires to hold him back!

For more information you can visit our website:  WWW.TheCruzir.Com

Or Visit our store at:  www2.icat.com/store/thecruzir  

We wish you, your father, and your loved ones, a very Happy Fathers Day!  

VARCOM TECHNOLOGY of Santa Cruz, LLC 

From: [email-masked]
Date: Sat, 23 May 1998 04:43:37 -0400 (EDT)
To: <[email-masked]>
Subject: Free Advertising For Your Business!
Sender: [email-masked]

***Our research indicates that the following material may be of interest to you.

(However, so that we may be courteous, please reply by email with the word "remove" to be immediately removed from further mailings.  You must type "remove".)

Hi,

Just wanted to pass along some info about some new software I now call my "secret weapon".  It's truly amazing!  Listen to this...

Me and hundreds of others can now reach "millions of potential  customers, locally or worldwide" - absolutely FREE!  A lot of us are creating immediate "cash flow explosions" -literally overnight.  And blowing our competition right out of the water!

You have to check this thing out.  To get some details, all you have to do is email a request for more info to [email-masked] and you'll get some information Email'ed right back to you in a few minutes.  Simple.

Take care.  I'll talk with you later.

Bill :-)

To: [email-masked]
Subject: WG last call
Date: Fri, 22 May 98 09:01:57 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

This is to start the WG Last Call on draft-ietf-idr-route-damp-03.txt,.ps.
The end of the last call is on June 5. 

Yakov.
------- Forwarded Message

To: IETF-Announce:;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-route-damp-03.txt,.ps
Date: Mon, 18 May 1998 10:03:36 -0400
Sender: [email-masked]

- --NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: BGP Route Flap Damping
	Author(s)	: C. Villamizar, R. Govindan, R. Chandra
	Filename	: draft-ietf-idr-route-damp-03.txt,.ps
	Pages		: 33
	Date		: 15-May-98
	
  A usage of the BGP routing protocol is described which is capable of
  reducing the routing traffic passed on to routing peers and therefore
  the load on these peers without adversely affecting route convergence
  time for relatively stable routes.  This technique has been
  implemented in commercial products supporting BGP. The technique is
  also applicable to IDRP.
 
  The overall goals are:
 
     o  to provide a mechanism capable of reducing router processing load
        caused by instability
 
     o  in doing so prevent sustained routing oscillations
 
     o  to do so without sacrificing route convergence time for generally
        well behaved routes.

  This must be accomplished keeping other goals of BGP in mind:
 
     o  pack changes into a small number of updates
 
     o  preserve consistent routing
 
     o  minimal addition space and computational overhead
  
  An excessive rate of update to the advertised reachability of a subset
  of Internet prefixes has been widespread in the Internet.  This
  observation was made in the early 1990s by many people involved in
  Internet operations and remains the case.  These excessive updates are
  not necessarily periodic so route oscillation would be a misleading
  term.  The informal term used to describe this effect is ``route
  flap''.  The techniques described here are now widely deployed and are
  commonly referred to as ``route flap damping''.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-route-damp-03.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-route-damp-03.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-idr-route-damp-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-route-damp-03.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-route-damp-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-route-damp-03.txt,.ps
Date: Mon, 18 May 1998 10:03:36 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: BGP Route Flap Damping
	Author(s)	: C. Villamizar, R. Govindan, R. Chandra
	Filename	: draft-ietf-idr-route-damp-03.txt,.ps
	Pages		: 33
	Date		: 15-May-98
	
  A usage of the BGP routing protocol is described which is capable of
  reducing the routing traffic passed on to routing peers and therefore
  the load on these peers without adversely affecting route convergence
  time for relatively stable routes.  This technique has been
  implemented in commercial products supporting BGP. The technique is
  also applicable to IDRP.
 
  The overall goals are:
 
     o  to provide a mechanism capable of reducing router processing load
        caused by instability
 
     o  in doing so prevent sustained routing oscillations
 
     o  to do so without sacrificing route convergence time for generally
        well behaved routes.

  This must be accomplished keeping other goals of BGP in mind:
 
     o  pack changes into a small number of updates
 
     o  preserve consistent routing
 
     o  minimal addition space and computational overhead
  
  An excessive rate of update to the advertised reachability of a subset
  of Internet prefixes has been widespread in the Internet.  This
  observation was made in the early 1990s by many people involved in
  Internet operations and remains the case.  These excessive updates are
  not necessarily periodic so route oscillation would be a misleading
  term.  The informal term used to describe this effect is ``route
  flap''.  The techniques described here are now widely deployed and are
  commonly referred to as ``route flap damping''.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-route-damp-03.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-route-damp-03.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-idr-route-damp-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-route-damp-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-route-damp-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: [email-masked]
Date: Wed, 13 May 98 22:38:29 EST
To: [email-masked]
Subject: MASTER MARKETER RESOURCE CD....
Reply-To: [email-masked]
Sender: [email-masked]

Hello Fellow Marketer,

We have everything you need to promote your online
business and target your advertising!!

The "Master Marketers Resource CD."

This CD has over 20 Million categorized, targeted and
general email addresses! Targeted email addresses are 
by far the most expensive... but for a limited time, we 
are including them on the Master Marketers Resource CD.

Do not be mistaken... this offer is not like any other
you have ever received. We have seen randomly gathered
email address CD's selling for as much as $249.00 
Just one I received today was offering 15 million AOL 
addresses for $189.95!! They were not targeted, categorized,
or nothing! Just 15 million AOL addresses of who knows what.

We also have AOL addresses on the Master Marketers
Resource CD; 4,000,000... We also have addresses of
Business Opportunity Seekers; 1,000,000... Adult Web Site 
Subscribers; 135,000 (we sell this list alone for $250.00 - 
but it is included on this Resource CD). 

Investor oriented addresses; 300,000... E-Mail addresses 
sorted by city; 200,000... General consumer lists; 290,000 
Email addresses of those interested in Health; 230,000... 
and over 150,000 Food Enthusiasts!! Make no mistake!!... 
this is by far the best collection of email addresses available 
anywhere. 

In all... there are 11 categories (over 2,500,000 of targeted 
email addresses) and over 20,000,000 addresses from the top
three internet/online providers. We have also included a 
remove/undeliverable list that's over 100 meg in size!! We 
have already cleaned the addresses on the Master Marketer 
Resource CD using this massive remove file... they are ready to
mail right now.

As A Special Bonus...

In addition to the email addresses... we have also included
on the CD over 30 CGI Scripts (one will hide where your
mail is being sent to on your order forms - must have for 
taking orders). There are forum scripts, chat scripts and
just about any other cgi script you will ever need.

We have also included over 50 java scripts! Many are
scripts for adding rotating banners to your site, adding
scrolling ticker and marque messages and scripts that password
protect a page on your web site.

We have also included demos of over 15 of the top bulk
email programs on the Internet. Stealth, Rapid Fire, NetContact
and many more! We have also included demo's of email address
harvesters like Hurricane, Grabber and Atomic Harvestor that
let you extract fresh email addresses out of forums and
right out of web pages. 

There is much more on the CD than we can go into on a short
letter like this one (there is over 10 html editors, over
200 marketing reports and more). In all... in addition to
the bulk email and html editors... there is over 20 of the
top software programs on the Internet. From programs that
keep you connected to the Internet... to programs that let
you accept checks online (this one is a registered version)! 

You will save hours (if not weeks) in download time as we have
included the top shareware and freeware programs available
anywhere. 

If you are serious about making money on the Internet... you
must have the Master Marketers Resource Cd! There is nothing
like it currently available! 

If you are ready to target your advertising... you can order
the Master Marketers Resource CD by completing the form
below. Don't miss out... we are only selling a limited number
of the Master Marketer Resource CD's. In order to preserve the
responsiveness of the addresses, this offer may be withdrawn 
at anytime.

------------------------------------------------------------
Please note: Most of the software on the CD is shareware. If
you like it... buy it. We have included the programs because
we feel most are pertinent to Internet marketing.
-----------------------------------------------------------

"You can buy from the REST or you can buy from the BEST."   Your choice. 

>>> NOW ONLY $199.00!   

This price is effective for the next seven days, thereafter the price will be $249.00 so ORDER NOW!

To order our email package, simply print out the EZ ORDER FORM 
below and fax or mail it to our office today.

We accept Visa, Mastercard, Discover, Amex and  Checks by Fax and Mail.

_________________
EZ Order Form 

_____Yes! I would like to order the Master Marketers Resource CD
     Email addresses and much, much more for only $199.00.

*Please select one of the following for shipping..

____I would like to receive my package OVERNIGHT. I'm including 
$15 for shipping. (outside US add an additional $25 for shipping)

____I would like to receive my package 2 DAY delivery. I'm including 
$10 for shipping.  (outside US add an additional $25 for shipping)

DATE_____________________________________________________

NAME____________________________________________________

COMPANY NAME___________________________________________

ADDRESS_________________________________________________

CITY, STATE, ZIP___________________________________________

PHONE NUMBERS__________________________________________

FAX NUMBERS_____________________________________________

EMAIL ADDRESS___________________________________________

TYPE OF CREDIT CARD: 

______VISA _____MASTERCARD ______AMEX______DISC

CREDIT CARD# __________________________________________

EXPIRATION DATE________________________________________

NAME ON CARD___________________________________________

AMOUNT $____________________

(Required) SIGNATURE:x________________________

DATE:x__________________

You may fax your order to us at:   1-704-784-5595

CHECK BY FAX SERVICES!

If you would like to fax a check, paste your check below and fax it to 
our office along with all forms to: 1-704-784-5595

******************************************************

***24 HOUR FAX SERVICES*** PLEASE PASTE YOUR 

CHECK HERE AND FAX IT TO US AT 1-704-784-5595

*******************************************************

If You fax a check, there is no need for you to send the original check. We will draft up a new check, with the exact information from your original check. All checks will be held for bank clearance.

If you feel more comfortable sending payment through the mail, 
please send all forms and Check or Money Order to:

CONSUMER CONNECTIONS
10223-B UNIV. CITY BLVD. #197 
CHARLOTTE, NC  28213

Date: Tue, 12 May 1998 02:55:04 +0000
From: Bo Ryu <[email-masked]>
Organization: Hughes Research Labs
To: TCP-over-Satellite <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: First CFP for WOSBIS'98 (Mobicom'98 workshop)
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------B691B2BF999D8B6F84EBFEBA
Content-Type: text/plain; charset=iso-2022-kr
Content-Transfer-Encoding: 7bit

Enclosed please find the first CFP for the Third Workshop on
Satellite-Based Information Society (WOSBIS'98). Please accept my
appology if you receive duplicates.

Regards,

-Bo

--
-----------------------------------
Bo Ryu                          E-mail:[email-masked]
HRL, LLC. (formerly Hughes Research Labs)
3011 Malibu Can. Rd.            Tel: +1 (310) 317-5487, Fax: +1 (310) 317-5695
Malibu, CA 90265                URL: http://www.wins.hrl.com/people/ryu

--------------B691B2BF999D8B6F84EBFEBA
Content-Type: text/plain; charset=iso-2022-kr; name="WOSBIS98-CFP.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="WOSBIS98-CFP.txt"

			      CALL FOR PAPERS
        3rd Int'l Workshop on Satellite-based Information Services (WOSBIS'98)

			      October 30, 1998 
                               Dallas , Texas
                      In conjunction with ACM MobiCom'98 

           Sponsored by ACM Sigmobile and technical co-sponsored by IEEE 

Scope:

We are witnessing that satellites are becoming an integral part of our daily
lives in this information-rich and global society.  This is evidenced by the
systems  currently in operation (e.g., DirecTV(TM), DirecPC, GPS, and Iridium)
as well as those to offer broadband, interactive, and multimedia Internet
services around the next millennium (SpaceWay, Teledesic, Astrolink, Celestri,
etc.). 

In conjunction with MOBICOM'98, this workshop provides a forum for exploratory
research contributions on lifting the technological barriers to achieve 
innovative satellite applications and services, and seamless integration with
terrestrial networks. The services are characterized by direct or global
broadcast capabilities of LEO/MEO/GEO satellites, high and possibly asymmetric
bandwidth, and unconventional network routing/switching. Applications of such
services include Internet access, telemedicine, public information services,
distance learning, entertainment, digital battlefield, emergency and disaster
response, and many more.    

Topics:

Papers are solicited in all research and applied areas related to
satellite-based information services (including, but not limited to):  

   * Innovative applications using satellite services
   * System architectures for hybrid satellite systems (LEO and GEO or MEO and
GEO) 
   * Distributed computing using satellite communications
   * Protocol and service interoperability with terrestrial networks 
   * Software techniques for reducing latency in satellite applications
   * ATM over satellites 
   * Quality of Service interoperability with terrestrial networks
   * Medium Access Control protocols for LEO/MEO/GEO or hybrid networks.
   * Routing protocols in satellite networks
   * TCP/IP for satellite communications
   * Internet applications, WWW access and cache through satellites
   * Direct broadcast and multicast applications
   * Reliability and scalability in satellite applications
   * Software for satellite switch control
   * Mobile computing and location tracking in satellite applications
   * Inter-satellite communication and network management
   * Middleware for satellite-based information services development

The setting of the workshop will be informal, and will encourage discussion
and interaction.  We solicit the submission of research papers, position
papers, experience papers, and panel proposals.

SUBMISSIONS

We invite papers for presentation and discussion at the workshop.  Send a
postscript copy of the paper by email to: [email-masked].  The page
limit on all submissions is 5-10 pages, double spaced, 10 pt minimum
(approximately 1500-2500 words). If electronic submission is not possible,
send three (3) hard copies to:

        Bo Ryu
	HRL Laboratories,
	MA/254/RL96,
	3011 Malibu Canyon Road 
        Malibu, CA 90265

PROCEEDINGS:

An informal proceedings will be published and distributed at the workshop.
The format will be similar to standard ACM proceedings: double column,
single spaced and the page limit on each paper is 12.

Papers with outstanding merit will be considered for publication in a special
issue of ACM MONET.

IMPORTANT DATES:

   * Papers Due: July 1st, 1998
   * Acceptance Notification: Sep. 1st, 1998
   * Camera ready: Sep. 30, 1998
   * Workshop: Oct. 30, 1998

WEB SITE:
http://www.wins.hrl.com/conferences/WOSBIS98/

GENERAL CO-CHAIRS:

Son K. Dao, HRL Labs., USA
Randy Katz, UC Berkeley, USA

TECHNICAL PROGRAM CO-CHAIRS:

Horst Clausen, U. of Salzburg, Austria
Bo Ryu, HRL Labs., USA

PUBLICITY:

Yongguang Zhang, HRL Labs.

TECHNICAL PROGRAM COMMITTEE:

Mark Allman, NASA LeRC, USA
Rafael Alonso, David Sarnoff Research Center, USA 
Imrich Chlamtac, U. Texas at Dallas, USA 
Walid Dabbous, INRIA, France 
Anthony Ephremides, U. of Maryland, USA 
Barry G. Evans, U. of Surrey, UK 
Mike Fitch, British Telecom, UK 
Raj Jain, Ohio State U., USA 
Hans Kruse, Ohis U., USA 
David Lee, Bell Labs, USA
Mischa Schwartz, Columbia U., USA
Csaba Szabo, Technical U. of Budapest, Hungary 
Bharghavan Vaduvur, UIUC, USA.
Nitin Vaidya, Texas A&M U., USA
Thomas VonDeak, NASA LeRC, USA 
Ouri Wolfson, U. of Illinois at Chicago, USA 

--------------B691B2BF999D8B6F84EBFEBA--

To: [email-masked]
cc: [email-masked]
Subject: Re: BGP Route Flap Damping -03-preview 
Date: Thu, 07 May 98 06:01:32 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Curtis,

> btw- If there are no further comments I'll drop the -preview and send
> this off to the internet-drafts editor (IETF secretariate).  The WG

Yes, please.

> chairs then have the task of deciding how to proceed given that this
> has already reached the IESG.  Start over from the WG last call?

Yes, as soon as the new internet draft will become available.

Yakov.

To: [email-masked]
cc: [email-masked]
Reply-To: [email-masked]
Subject: BGP Route Flap Damping -03-preview
Date: Wed, 06 May 1998 21:49:33 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

The web pages were updated at:

  http://engr.ans.net/route-damp/

The BGP Route Flap Damping is now available in -03-preview flavor.

The following summarizes the changes (from the web page):

    The current (-03-preview) draft in this directory is a preview of the
    draft about to be resubmitted to the Internet Draft editors.  This
    preview corrects a few errors noted in the prior version in the
    additional implementation details added after the first two
    implementations were completed.  The errors were noted by individuals
    during the process of writing what will be the third, fourth, and
    fifth independent implementations of the draft.

And the following was added to the acknowledgements.

    Thanks to Rob Coltun (Fore Systems), John Scudder (IENG) and Jayesh
    Bhatt (Bay Networks) for pointing out errors in the math uncovered
    during coding of more recent implementations. These errors appeared in
    the details of the implementation suggestion sections written after
    the first two implementations were completed.

If you **really** want to know what changed and just **love** reading
unified diffs of latex source, I've included diffs below.  :-)

Curtis

btw- If there are no further comments I'll drop the -preview and send
this off to the internet-drafts editor (IETF secretariate).  The WG
chairs then have the task of deciding how to proceed given that this
has already reached the IESG.  Start over from the WG last call?

Index: route-damp.rfc
===================================================================
RCS file: /usr/local/CVS-routing-dev/doc/ietf/route-dampen/route-damp.rfc,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- route-damp.rfc	1998/02/13 19:51:50	1.7
+++ route-damp.rfc	1998/05/07 01:17:24	1.8
@@ -9,7 +9,7 @@
 \author{Ramesh Govindan}
 \address{ISI}
 \footer{Villamizar, Chandra, Govindan}
-\filename{draft-ietf-idr-route-damp-02}
+\filename{draft-ietf-idr-route-damp-03-preview}
 \begin{document}
 \begin{alltt}
 \bibliographystyle{plain}
@@ -493,9 +493,10 @@
 reuse index array is needed for each decay rate in use.  The reuse
 index array is used to estimate which reuse list to place a route when
 it is suppressed.  Proper placement avoids the need to periodically
-evaluate decay to determine if a route can be reused.  Using the reuse
-index array avoids the need to compute a logarithm to determine
-placement.  One additional system wide parameter can be introduced.
+evaluate decay to determine if a route can be reused or when storage
+can be recovered.  Using the reuse index array avoids the need to
+compute a logarithm to determine placement.  One additional system
+wide parameter can be introduced.
 
 \begin{description}
 \resync
@@ -542,12 +543,12 @@
 \label{flap-rates}
 \end{figure}
 
-From either maximum hold time value (\mathortext{$ Tmax _ {ok} $ or $
-Tmax _ {ng} $}{Tmax-ok or Tmax-ng}), a ratio of the cutoff to a
-ceiling can be determined.  An integer value for the ceiling can then
-be chosen such that overflow will not be a problem and all other
-values can be scaled accordingly.  If both cutoffs are specified or if
-multiple parameter sets are used the highest ceiling will be used.
+From the maximum hold time value (\mathortext{$T_{hold}$}{T-hold}),
+a ratio of the cutoff to a ceiling can be determined.  An integer
+value for the ceiling can then be chosen such that overflow will not
+be a problem and all other values can be scaled accordingly.  If both
+cutoffs are specified or if multiple parameter sets are used the
+highest ceiling will be used.
 
 \begin{figure}
 \unitlength=0.8in
@@ -609,6 +610,15 @@
 used to arrange suppressed routes according to the time remaining
 until they can be reused.
 
+A separate reuse list can be used to hold unreachable routes for the
+purpose of later recovering storage if they remain unreachable too
+long.  This might be more accurately described as a recycling list.
+The advantage this would provide is making free data structures
+available as soon as possible.  Alternately, the data structures can
+simply be placed on a queue and the storage recovered when the route
+hits the front of the queue and if storage is needed.  The latter is
+less optimal but simple.
+
 If multiple sets of configuration parameters are allowed per route,
 there is a need for some means of associating more than one figure of
 merit and set of parameters with each route.  Building a linked list
@@ -668,13 +678,13 @@
   \mathortext{( $ Size _ D $ )}{(decay-array-size)}
 \item
   decay array
-  \mathortext{( $ D [ \  ] $ )}{(decay)}
+  \mathortext{( $ D [ \  ] $ )}{(decay[])}
 \item
   reuse index array size
   \mathortext{( $ Size _ {R_{index}} $ )}{(reuse-index-array-size)}
 \item
   reuse index array
-  \mathortext{( $ R _ {index} [ \  ] $ )}{(reuse-index-array)}
+  \mathortext{( $ R _ {index} [ \  ] $ )}{(reuse-index-array[])}
 \end{itemize}
 
 For each decay rate specified, an array will be used to store the
@@ -792,6 +802,22 @@
 number of values that will be used repeatedly and retain these to
 speed later computations that will be required frequently.
 
+Scaling is usually dependent on the highest value that
+\mathortext{$\epsilon$}{figure-of-merit} can attain, referred to here
+as the ceiling\mathortext{ ($\epsilon_{ceiling}$)}{}.  The real number
+value of the ceiling will typically be determined by the following
+equation.
+
+\mathortext{%
+  \begin{displaymath}
+  \epsilon_{ceiling} = \epsilon_{cut} e ^ {\frac{T_{hold}}{\lambda} \log 2}
+  \end{displaymath}
+}{\begin{quotation}
+  \resync
+  ceiling = reuse * (exp(T-hold/decay-rate) * log(2))
+\end{quotation}
+}
+
 The methods of scaled integer arithmetic are not described in detail
 here.  The methods of determining the real values are given.
 Translation into scaled integer values and the details of scaled
@@ -808,7 +834,7 @@
   the scaled integers to be multiplied by the scaled decay value and
   then shifted down.  Implementations may prefer to use real numbers
   or may use any integer scaling deemed appropriate for their
-  architecture.
+  architecture.  
 \item{penalty value and thresholds (as proportional scaled integers)} \par
   The figure of merit penalty for one route withdrawal and the cutoff
   values must be scaled according to the above scaling factor.
@@ -898,13 +924,13 @@
   ratio _ {max} = min( \frac{\epsilon _ {ceiling}}{ \epsilon _ {reuse} } ,
 		       e ^ { \frac{1}
 			     { \left( \frac{\lambda}{T_{reuse}} \right) } }
-		       \log { \frac{1}{2} } )
+		       \log {2} )
   \end{displaymath}
   }{%
   \begin{quotation}
     \resync
     max-ratio = min(ceiling/reuse,
-                    exp((1 / (half-life/reuse-array-time)) * log(1/2)))
+                    exp((1 / (half-life/reuse-array-time)) * log(2)))
   \end{quotation}
   }
 \item{reuse array scale factor
@@ -915,16 +941,16 @@
   used.
   \mathortext{%
   \begin{displaymath}
-  scale _ {reuse} = \frac{{ ratio _ {max} } - 1 }{ Size _ R }
+  scale _ {reuse} = \frac{ Size _ {R_{index}} }{{ ratio _ {max} } - 1 }
   \end{displaymath}
   }{%
   \begin{quotation}
     \resync
-    scale-factor = (max-ratio - 1) / reuse-array-size
+    scale-factor = reuse-index-array-size / (max-ratio - 1)
   \end{quotation}
   }
 \item{reuse index array
-  \mathortext{( $ R_{index} [] $ )}{(reuse)}
+  \mathortext{( $ R_{index} [\ ] $ )}{(reuse-index-array[])}
   } \par
   Each reuse index array entry should contain an index into the reuse list
   array pointing to one of the list heads.  This index should
@@ -934,15 +960,15 @@
   the the reuse array entry.
   \mathortext{%
   \begin{displaymath}
-  R_{index} [ i ] = integer \left( \log 
-    \frac{ \frac{1}{ { 1 + ( ( j + 1 ) (  { ratio_{max} } - 1 ) ) } }
-	  }{ \Delta { t _ {reuse} } } \right)
+  R_{index} [ j ] = integer \left( \frac{\lambda}{\Delta{t_{reuse}}}
+    \log {\left( frac{1}{\epsilon_{reuse}(1+\frac{j}{scale_{reuse}})} \right)}
+    \log {\frac{1}{2}} \right)
   \end{displaymath}
   }{%
   \begin{quotation}
     \resync
-    reuse-array[j] = integer(log(1 / (1 + ((j+1) * (max-ratio-1))))
-                             / reuse-time-granularity)
+    reuse-index-array[j] = integer((decay-rate / reuse-time-granularity)
+        * log(1/(reuse * (1 + (j / scale-factor)))) / log(1/2))
   \end{quotation}
   }
 \end{description}
@@ -950,10 +976,14 @@
 To determine which reuse queue to place a route which is being
 suppressed, the following procedure is used.  Divide the current
 figure of merit by the cutoff.  Subtract one.  Multiply by the scale
-factor.  This is the array index.  If it is off the end of the array
-use the last queue otherwise look in the array and pick the number of
-the queue from the array at that index.  This is quite fast and
-well worth the setup and storage required.
+factor.  This is the index into the reuse index array \mathortext{( $
+R_{index} [\ ] $ )}{(reuse-index-array[])}.  The value fetched from
+the reuse index array \mathortext{( $R_{index} [\ ] $
+)}{(reuse-index-array[])} is an index into the array of reuse lists
+\mathortext{( $R[\ ]$ )}{(reuse-array[])}.  If this index is off the
+end of the array use the last queue otherwise look in the array and
+pick the number of the queue from the array at that index.  This is
+quite fast and well worth the setup and storage required.
 
 \subsection{A Sample Configuration}
 
@@ -1556,6 +1586,12 @@
 comments and implementation feedback were shared by many individuals
 on the IETF IDR WG and the RIPE Routing Work Group and in NANOG and
 IEPG.
+
+Thanks also to Rob Coltun (Fore Systems), John Scudder (IENG) and
+Jayesh Bhatt (Bay Networks) for pointing out errors in the math
+uncovered during coding of more recent implementations.  These errors
+appeared in the details of the implementation suggestion sections
+written after the first two implementations were completed.
 
 % References

To: [email-masked]
cc: [email-masked]
Reply-To: [email-masked]
Subject: BGP Route Flap Damping - reader comments
Date: Wed, 06 May 1998 21:36:28 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

Rob, John,

Thanks for the comments.

Curtis

------- Forwarded Message

To: Rob Coltun <[email-masked]>
cc: [email-masked], John Scudder <[email-masked]>
Reply-To: [email-masked]
Subject: Re: more comments on dampening... 
Date: Wed, 06 May 1998 17:47:35 -0400
From: Curtis Villamizar <[email-masked]>

In message <[email-masked]>, Rob Coltun write
s:
> ...from sanjay
> 
> In addition to the last equation in section 4.6 pointed out here
> (also had it marked as an error) :

John point this section out.  According to John the text was OK but
the equations were wrong.  I'll address this below.

Keep in mind that this section was written after the first two
implementations so it is not surprising that the 3rd and 4th stumbled
on the error.

> There is another one that I think might be an error .
> Last line on page 8 (section 4.3) :
>   From either Tmaxok or Tmax-ng a ratio of cutoff to a celing
>   can be determined.
>   
> I think it should be T-hold rather than T-max. And penalty ceiling
> should be related to penalty-reuse rather than penalty-cutoff.

I changed that paragraph to read:

    From the maximum hold time value (\mathortext{$T_{hold}$}{T-hold}),
    a ratio of the cutoff to a ceiling can be determined.  An integer
    value for the ceiling can then be chosen such that overflow will not
    be a problem and all other values can be scaled accordingly.  If both
    cutoffs are specified or if multiple parameter sets are used the
    highest ceiling will be used.

Before this the text was saying hold time but had T-max in parens.
Good catch.  This error was probably there from the start.

> I think the equation to determine ceiling should be :
>   penalty-ceiling = (penalty-reuse) * (exp((T-hold/T) * log 2))
> 
>  (where log is natural-log).
>  T-hold, T and penalty-reuse are all configurable.
>  penalty-celing can therefore be determined from the above
>  equation. Basically this means that penlaty is being limited 
>  to penalty-ceiling so that it can decay to re-use value 
>  in some multiple of half life time.

I never actually gave an equation to compute the ceiling.  What you
have here is not quite right though (just variable name confusion
again).  You can get the ceiling by going backwards from the reuse
value (\epsilon_{reuse}), the max hold time (T_{hold}), and the decay
rate (\lambda).

In text it is:

  ceiling = reuse * 2 ^ (T-hold/decay-rate)

  ceiling = reuse * log(2) * exp(T-hold/decay-rate)

In math mode this is:

  \epsilon_{ceiling} = \epsilon_{cut} * \log 2 e ^ \frac{T_{hold}}{\lambda}

Doesn't the latex source clear things up nicely.  :-)

>  Another thing is that the spec talks about putting routes on
>  the re-use list based on how much time it will take for the
>  route's current penalty to decay to penalty-reuse. 
>  However when a route becomes re-usable we still have to track 
>  it's penalty till it reaches a value at which we can forget it
>  i.e. stop tracking it altogether. The route should be put onto
>  another timer-list (say penalty-remove-list) based on the time
>  it will take the penalty to decay enough so that we can stop
>  tracking it. Spec does not talk abt this. Might be more of an   
> implementation issue, but since they talk about re-use lists 
>  (which is also implementation issue) they can probably indicate 
>  this too.

I thought I had covered that but apparently not.  It is necessary to
clean up unused storage.  A second set of reuse arrays, maybe we
should call them recycle arrays, could be described.  Sometimes I
think it would have been easier to just provide code.

I added the following paragraph:

    A separate reuse list can be used to hold unreachable routes for the
    purpose of later recovering storage if they remain unreachable too
    long.  This might be more accurately described as a recycling list.
    The advantage this would provide is making free data structures
    available as soon as possible.  Alternately, the data structures can
    simply be placed on a queue and the storage recovered when the route
    hits the front of the queue and if storage is needed.  The latter is
    less optimal but simple.

That ought to cover recycling adequately.  At least I hope so because
adding a recycling array where the math is identical to the reuse
array would be a substantial pain and probably would not add to
clarity.

Back to section 4.6.  The best thing at this point is to try out the
math on an example, see if it works, fix if necessary, and check the
text to see if it matches.

The first equation is:

    max-ratio = min(ceiling/reuse,
	exp((1 / (half-life/reuse-array-time)) * log(1/2)))

Looks like this should be log(2).

If:

	ceiling = 5
	reuse = 1.5
	half-life = 30*60
	reuse-array-time = 300*60

then:

	max-ratio = min(5/1.5, exp((300/30) * 0.69315))
	max-ratio = min(3.3333, 1024)

If reuse-array-time is small, for example 45*60:

	max-ratio = min(3.3333, 2.8284)

This seems to work.

Next equation is:

    scale-factor = (max-ratio - 1) / reuse-array-size

If reuse-array-size = 32 (and we're back to 300):

    scale-factor = (3.33 - 1) / 32 = 0.072813

Next and final is:

    reuse-array[j] = integer(log(1 / (1 + ((j+1) * (max-ratio-1))))
	/ reuse-time-granularity)

Lets use reuse-time-granularity of 5.

This is all wrong.

We want the property:

  reuse-array[j] = delay-until-reuse / reuse-time-granularity

  j = ((X / reuse) - 1) / scale-factor
  X = reuse * (1 + (j * scale-factor))

  D[1] = exp((1 / (decay-rate/delta-t)) * log (1/2))
  D[i] = D[1] ** i

  D[i] = exp(i * ((1 / (decay-rate/delta-t)) * log (1/2)))

  i = T/delta-t
  X = 1/D[i]

  D[i] = 1/X

  reuse-array[j] = T / reuse-time-granularity

Need to solve for T in:

  1/X = exp((T/delta-t) * ((1 / (decay-rate/delta-t)) * log (1/2)))

  T = decay-rate * log(1/X) / log(1/2)

  T = decay-rate * log(1/(reuse * (1 + (j * scale-factor)))) / log(1/2)

Try it:

  reuse-array[j] = (30*60)/(5*60)*log(1/(1.5*(1+(j*0.072813))))/log(1/2)

	j	reuse-array[j]	X
	 0	 3.5	 3	1.5
	 1	 4.1	 4	1.6
	 2	 4.7	 4	1.7
	 3	 5.2	 5	1.8
	 4	 5.7	 5	1.9
	 5	 6.2	 6	2.0
	 6	 6.6	 6	2.2
	 7	 7.1	 7	2.3
	 8	 7.5	 7	2.4
	 9	 7.8	 7	2.5
	10	 8.2	 8	2.6
	12	 8.9	 8	2.8
	14	 9.6	 9	3.0
	16	10.2	10	3.2
	20	11.3	11	3.7
	24	12.3	12	4.1
	28	13.1	13	4.6
	32	13.9	13	5.0

This tells us that the array need only be 16 long for a half life of
30 minutes and evaluation of the reuse array every 5 minutes.  When
using the array take X, or epsilon elsewhere, multiply by
1/scale-factor to get J, truncate, look up in reuse-array, get an
integer index K, put the structure in the Kth list.

Now to get that in the draft.

Curtis

------- End of Forwarded Message

To: [email-masked]
cc: [email-masked]
Reply-To: [email-masked]
Subject: Route Flap Damping - more reader comments
Date: Wed, 06 May 1998 21:38:15 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

Jayesh,

Thanks for the comments.

Curtis

------- Forwarded Message

To: [email-masked] (Jayesh Bhatt)
cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: Route Flap Damping question ... 
Date: Wed, 06 May 1998 18:19:03 -0400
From: Curtis Villamizar <[email-masked]>

In message <[email-masked]>, Jayesh Bhatt 
writes:
> Hi,
> 
> I was going through the Route Flap Damping draft:
>     draft-ietf-idr-route-damp-02.txt
> and was wondering if I could ask you some questions 
> to understand it better since I think it's a really clever
> way to manage the penalties without having
> to walk all the BGP routes and adjusting penalties.

Sorry for the delay in answering this.  I've been busy with other
science projects.  :-)

> I was trying to understand some of the equations to
> calculate decay-arrays and reuse-lists.  I understand
> the calculations in concept [if that's possible :-)]
> but I had some questions on some of the equations
> themselves.

We've just found out a few are wrong.  Lets see if you've hit on yet
another error or just lack of clarity.

> I  - When you say "log" you mean the natural log correct??

log is natural log and exp is e raised to some power.

> II - On page 18 of the draft, I understand that the decay-factor per
>      decay timer "delta-t" is 
> 
>      decay[1] = exp( (1/ (decay-rate/delat-t)) * log(1/2) )
> 
>      which reduces to:  [e**(ln(a)) = a  where ln is log base e] 
> 
>      (1/2)**( 1/(half-life/delta-t) )
> 
>      OR
> 
>      (1/2)**( delta-t/half-life)
>  
>      where ** means "to the power of"
> 
>      Is my understanding correct??

Yes.  This was decay[half-life/delat-t] = 1/2, which is the definition
of half life.

> III - On  page 18 and 19, section 4.6 - "Building the Reuse Index Array":
> 
>      max-ratio = min(    ceiling/reuse, 
>                          exp( (1/(half-life/reuse-array-time))*log(1/2) )    
> )
> 
>      ceiling = the max-value the figure-of-merit can reach
> 
>      reuse   = the value of figure-of-merit below which the route will be 
>                reuseable.
> 
>      half-life = time over which the figure-of-merit reduces to half.
> 
>      reuse-array-time = total time that reuse lists cover.
>                         i.e. if we have 1024 reuse lists and 
>                         reuse-time-granularity is 5 seconds, reuse-array-time
>  
>                         = 1024*5 = 5120.
> 
>     Is this correct???
> Or is 
>      reuse-array-time = the reuse-time-granularity = the time interval after
>                         which the reuse list will be looked up again to move 
>                         reuseable routes into reuseable lists. 

How observant.  Rob Coltun (or actually Sanjay) already pointed this
out.  I can see you are also going through the draft carefully.  The
short answer is the log(1/2) was supposed to be a log(2).

> IV 
> 
>               So the max-ratio is minumum of ceiling/reuse and
> 
>                (1/2)**( 1/(half-life/reuse-array-time) )
>               OR 
>                (1/2)**( reuse-array-time/half-life) )
> 
>     If I use the reuse-array-time to be the total time (e.g. 1024 above)
>     the max-ratio approaches 0 very quickly.
> 
>     If I use the reuse-array-time to be the time a single reuse list covers
>     (i.e. 5 seconds above), the max-ratio remains less than 1 approaching
>     1 very slowly. 

This is not right.  See 4.8.6 "Inserting into the Reuse Timer List"
and 4.8.7 "Handling Reuse Timer Events".  This describes how the reuse
data structures are used.  These are not decay arrays.

> V  Further in section 4.6 I am a little confused by the terminology:
> 
>   reuse-array-scale-factor, or simply the scale-factor is used to
>   determine which reuse-list to insert a route into correct? 
> 
>   This is either 0 or less than 1 from above if
> 
>    scale factor is = (max-ratio-1)/reuse-array-size
> 
>   Where did I go wrong??

max-ratio is usually a small number.  Take 3 for example.  If the
array has 32 elements, then scale-factor is 1/16.  See the message to
Rob that I will shortly forward for some clarification on this.  I'll
also try to make the I-D a bit more clear.  Rob got it and John
Scudder got it but it is true that the draft could be better here.

> VI Is reuse-array-size the number of entries per reuse list and is
>    reuse-index-array = the array which indexes into the reuse lists based
>    on current figure-of-merit?

The second equation in section 4.6 should use reuse-index-array-size
rather than reuse-array-size.  

You multiply the figure-of-merit by 1/scale-factor (it might have
helped to invert the definition).  You truncate and look up in
reuse-index-array and get an integer.  You use that integer to pick a
reuse-list.  reuse-index-array-size is the size of the
reuse-index-array.

The third equation is 4.6 is completely wrong.  I guess this just
proves I can't do algebra reliably.

> Thanks and sorry for the loooong mail.

Not so long considering that it seems you are going through this is
sufficient detail to implement it.  If so, that would make yours
implementation #5 AFAIK.  (Cisco, ISI, IENG, Fore, Bay).

> J
> 
> -- 
> -------------------------------------------------
> Jayesh Bhatt
> 600 Technology Park
> Mail Stop: 60-304
> Billerica, MA  01821
> Bay Networks                FAX    (508) 670-8760
> [email-masked]      Direct (508) 916-3566
> -------------------------------------------------

Again.  Sorry it took so long to respond.

Curtis

------- End of Forwarded Message

To: Paul Traina <[email-masked]>
cc: [email-masked], [email-masked] (Christian Huitema), Quaizar Vohra <[email-masked]>, Dimitry Haskin <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: (IPng 4522) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Mon, 04 May 1998 12:22:40 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Paul Traina writes:
> 
>   From: Curtis Villamizar <[email-masked]>
>   Subject: Re: (IPng 4522) Re: BGP and renumbering.. was /126 or /127 -- neit
> he
> >>r! 
>   
>   
>   This could be done with IPv4 as long as there is a way to send a CEASE
>   that results in putting the routes on a withdrawl timer rather than
>   immmediately withdrawing them.  You could even static configure the
>   BGP peering for this behavior and not change the protocol at all.
> 
> A cease with a sanely limited short timer is a damn fine swiss-army knife
> for solving a lot of problems.
> 
> I feel an ID coming on. :-)

John,

This was in ftp://ftp.merit.edu/mail.archives/idr/idr.96.09.gz

The rest of the conversation seems to be in this archive file.

Curtis

- - - - - - - - - - - - - - - - -

>From [email-masked] Sat Sep 14 00:19:57 1996
To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Subject: diffs to draft-ietf-idr-bgp4-03.txt
Date: Sat, 14 Sep 1996 00:20:09 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

Yakov et al.

Here are some suggested changes to the BGP4 draft.  Briefly, there are
a few separable issues:

  1.  Some wording changes (ie: hunk 1, 6, 7, 8, 14)

  2.  Proposing "BGP resynchronization".  See below.

  3.  Replace descriptions of route selection with something more
      clear and accurate.

  4.  Replace some text about route overlap that is wrong and reflects
      earlier indecision on the part of the WG.

The "BGP resynchronization" warents further mention.  The idea was to
make something 100% compatible with current BGP4 implementations that
addresses the following:

  1.  Allows a better recovery if running a hosed implementation.  No
      more clearing the BGP conection.

  2.  Allows a cheap policy reconfig (maybe less desirable than a true
      dynamic reconfig) that doesn't involve clearing the BGP conection.

  3.  Reduces the impact of occasional loss of BGP connections.  Might
      even allow you to squeeze in a reload if it was real fast.

  4.  Reduces the exposure to TCP RST attacks.

Given some of the talk on the NANOG list, #4 might not be a bad
feature.  Fixing BGP to use UDP is a bigger job and this and a good
TCP PCB hashing and long listen queue for TCP SYN attack could prove
very valuable changes.

Curtis

Just apply the diffs to draft-ietf-idr-bgp4-03.txt to get the new
document.  The diff hunks are:

  1  an attempt to clear up wording regarding IBGP, EBGP, and IGP and
     the role of IBGP.

  2  First mention of BGP resynchronization

  3  I couldn't resist.  Might want to leave this one out.

  4  Add RESYNCHRONIZATION message type

  5  Define RESYNCHRONIZATION message format

  6  Clarifying sentence - path attributes are for the purpose
     of supporting a protocol extension mechanism.

  7  Added the table with discresionary, required, or disallowed, etc.

  8  Clarification of MULTI_EXIT_DISC usage.

  9  Add BGP resynchronization to Error Handling section.

 10  Allow marking routes for withdrawl on disconnect.

 11  BGP Resynchronization section

 12&13  Fixed overlap route jabber that was just plain wrong.

 14  Clarified setting LOCAL_PREF.

 16  Replaced description of route slection with one that is much more
     concise and clear and covers the route loop avoidance, including
     a brief description of the reasons loops can form.

 17  Got rid of unclear tie breaker section.

 18&19  Replaced the route overlap section with one that reflects
     reality now that we have plenty of experience with BGP4.

 20&21  Eliminated a great deal of repitition and referred back to 9.1.2.
     btw- why can't 9.2.1 be as simple as 9.2.2 - or does 9.2.2 need
     to spell things out in detail like 9.2.1?

*** draft-ietf-idr-bgp4-03.txt	Sat Aug 17 08:34:53 1996
--- draft-ietf-idr-bgp4-03.txt.new	Sat Sep 14 00:01:33 1996
***************
*** 205,230 ****
     router in another Autonomous System.  The implications and
     applications of this architecture are for further study.
  
     If a particular AS has multiple BGP speakers and is providing transit
     service for other ASs, then care must be taken to ensure a consistent
     view of routing within the AS.  A consistent view of the interior
     routes of the AS is provided by the interior routing protocol.  A
     consistent view of the routes exterior to the AS can be provided by
!    having all BGP speakers within the AS maintain direct BGP connections
!    with each other.  Using a common set of policies, the BGP speakers
!    arrive at an agreement as to which border routers will serve as
!    exit/entry points for particular destinations outside the AS.  This
!    information is communicated to the AS's internal routers, possibly
!    via the interior routing protocol.  Care must be taken to ensure that
!    the interior routers have all been updated with transit information
!    before the BGP speakers announce to other ASs that transit service is
!    being provided.
! 
!    Connections between BGP speakers of different ASs are referred to as
!    "external" links.  BGP connections between BGP speakers within the
!    same AS are referred to as "internal" links.  Similarly, a peer in a
!    different AS is referred to as an external peer, while a peer in the
!    same AS may be described as an internal peer.

  
--- 205,231 ----
     router in another Autonomous System.  The implications and
     applications of this architecture are for further study.
  
+    Connections between BGP speakers of different ASs are referred to as
+    "external" links.  BGP connections between BGP speakers within the
+    same AS are referred to as "internal" links.  Similarly, a peer in a
+    different AS is referred to as an external peer, while a peer in the
+    same AS may be described as an internal peer.  Internal BGP and
+    external BGP are commonly abbreviated IBGP and EBGP.
+ 
     If a particular AS has multiple BGP speakers and is providing transit
     service for other ASs, then care must be taken to ensure a consistent
     view of routing within the AS.  A consistent view of the interior
     routes of the AS is provided by the interior routing protocol.  A
     consistent view of the routes exterior to the AS can be provided by
!    having all BGP speakers within the AS maintain direct IBGP connections
!    with each other.  Alternately the interior routing protocol can
!    pass BGP information among routers within an AS, taking care not to
!    lose BGP attributes that will be needed by EBGP speakers if transit
!    connectivity is being providided.  For the purpose of discussion,
!    it is assumed that BGP information is passed within an AS using
!    IBGP.  Care must be taken to ensure that the interior routers have
!    all been updated with transit information before the EBGP speakers
!    announce to other ASs that transit service is being provided.

  
***************
*** 282,291 ****
        Information can be advertised, or
  
        c) the BGP speaker - BGP speaker connection can be closed, which
!       implicitly removes from service all routes which the pair of
!       speakers had advertised to each other.
! 
! 

  
--- 283,297 ----
        Information can be advertised, or
  
        c) the BGP speaker - BGP speaker connection can be closed, which
!       implicitly marks all routes hte pair of speakers had advertised
!       to each other for removal from service if a connection is not
!       reestablished and the routes readvertised before a resynchronization
!       completed message or before a configured expiration timer elapses.
! 
!       d) the BGP speaker or listenner may request a resynchronization
!       which explicitly marks all routes for removal from service if not
!       readvertised before a resynchronization completed message or before
!       a configured expiration timer elapses.

  
***************
*** 333,339 ****
     implementation must maintain three separate copies of the routing
     information. The choice of implementation (for example, 3 copies of
     the information vs 1 copy with pointers) is not constrained by the
!    protocol.
  
  4.  Message Formats
  
--- 339,346 ----
     implementation must maintain three separate copies of the routing
     information. The choice of implementation (for example, 3 copies of
     the information vs 1 copy with pointers) is not constrained by the
!    protocol.  And in fact you'd be pretty stupid to maintain separate
!    copies though it has been tried.
  
  4.  Message Formats
  
***************
*** 435,440 ****
--- 442,448 ----
                                      2 - UPDATE
                                      3 - NOTIFICATION
                                      4 - KEEPALIVE
+ 				    5 - RESYNCHRONIZATION

  4.2 OPEN Message Format
***************
*** 1127,1135 ****
--- 1135,1182 ----

  
+ 4.5 RESYNCHRONIZATION Message Format
+ 
+ 
+    A RESYNCHRONIZATION message is sent when there is reason to believe
+    that routing information in either the speaker of the listenner is
+    not correct or routing policy has been changed and the speaker is
+    unable to process the routing policy change without readvertising
+    the full set of routes.  A RESYNCHRONIZATION message should never
+    be required except where a policy change has occurred or unless
+    either the speaker of listenner implementation is in error.
+ 
+ 
+    In addition to the fixed-size BGP header, the RESYNCHRONIZATION
+    message contains the following fields:
+ 
+ 
+         0                   1                   2                   3
+         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+        | Request Type  | Reserved      |
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  
+       Request Type:
+ 
+          This 1-octet unsigned integer indicates the type of
+          RESYNCHRONIZATION request.  The following Request Codes have
+          been defined:
+ 
+             Request Code     Symbolic Name               Reference
+ 
+               1         Sender Resynchronizing Request   Section 6.9
+ 
+               2         Receiver Resynchronize Request   Section 6.9
+ 
+               3         Resynchronizion Completed        Section 6.9
+ 
+ The length of the RESYNCHRONIZATION message is 21 octets (including
+ message header).
+ 
+ 
  
  Expiration Date February 1996                                  [Page 19]
  
***************
*** 1145,1151 ****
  
     This section discusses the path attributes of the UPDATE message.
  
!    Path attributes fall into four separate categories:
  
                 1. Well-known mandatory.
                 2. Well-known discretionary.
--- 1192,1199 ----
  
     This section discusses the path attributes of the UPDATE message.
  
!    Path attributes fall into four separate categories for the purpose
!    of supporting a protocol extension mechanism:
  
                 1. Well-known mandatory.
                 2. Well-known discretionary.
***************
*** 1208,1213 ****
--- 1256,1275 ----
     The same attribute cannot appear more than once within the Path
     Attributes field of a particular UPDATE message.
  
+    The manditory category refers to a field which must be present in
+    both IBGP and EBGP exchanges.  Attributes classified as optional
+    for the purpose of the protocol extension mechanism may be purely
+    discresionary, or discresionary, required, or disallowed in certain
+    contexts.
+ 
+       attribute           EBGP                    IBGP
+        ORIGIN             manditory               manditory
+        AS_PATH            manditory               manditory
+        NEXT_HOP           discresionary           discresionary
+        MULTI_EXIT_DISC    discresionary           discresionary
+        LOCAL_PREF         disallowed              required
+        ATOMIC_AGGREGATE   discresionary           discresionary
+        AGGREGATOR         discresionary           discresionary

  5.1 Path Attribute Usage
***************
*** 1342,1348 ****
     preferred.  If received over external links, the MULTI_EXIT_DISC
     attribute may be propagated over internal links to other BGP speakers
     within the same AS.  The MULTI_EXIT_DISC attribute is never
!    propagated to other BGP speakers in neighboring AS's.

  5.1.5   LOCAL_PREF
--- 1404,1410 ----
     preferred.  If received over external links, the MULTI_EXIT_DISC
     attribute may be propagated over internal links to other BGP speakers
     within the same AS.  The MULTI_EXIT_DISC attribute is never
!    propagated from IBGP to other BGP speakers in neighboring AS's.

  5.1.5   LOCAL_PREF
***************
*** 1411,1423 ****
     attribute which shall contain its own AS number and IP address.

! 6.  BGP Error Handling.

     This section describes actions to be taken when errors are detected
!    while processing BGP messages.
  
!    When any of the conditions described here are detected, a
     NOTIFICATION message with the indicated Error Code, Error Subcode,
     and Data fields is sent, and the BGP connection is closed.  If no
     Error Subcode is specified, then a zero must be used.
--- 1473,1485 ----
     attribute which shall contain its own AS number and IP address.

! 6.  BGP Error and Resynchronization Handling.

     This section describes actions to be taken when errors are detected
!    while processing BGP messages or during resynchronization.
  
!    When any erro conditions described here are detected, a
     NOTIFICATION message with the indicated Error Code, Error Subcode,
     and Data fields is sent, and the BGP connection is closed.  If no
     Error Subcode is specified, then a zero must be used.
***************
*** 1425,1431 ****
     The phrase "the BGP connection is closed" means that the transport
     protocol connection has been closed and that all resources for that
     BGP connection have been deallocated.  Routing table entries
!    associated with the remote peer are marked as invalid.  The fact that
     the routes have become invalid is passed to other BGP peers before
     the routes are deleted from the system.
  
--- 1487,1494 ----
     The phrase "the BGP connection is closed" means that the transport
     protocol connection has been closed and that all resources for that
     BGP connection have been deallocated.  Routing table entries
!    associated with the remote peer are either marked as invalid or
!    optionally marked as if a resynchronization had occurred.  The fact that
     the routes have become invalid is passed to other BGP peers before
     the routes are deleted from the system.
  
***************
*** 1754,1759 ****
--- 1817,1888 ----
        message with the Error Code Cease.

+ 6.9 BGP Resynchronization
+ 
+ 
+    BGP implementation may optionally support a form of graceful
+    resynchronization rather than closing the BGP connection in certain
+    conditions and may optionally allow resynchronization rather than
+    immediate route withdrawl when a BGP connection is closed.  BGP
+    implementation which support resynchronization must be prepared to
+    detect and interoperate with implementations which do not.
+ 
+    A resynchronization request will generally be made in response to
+    operator intervention.  A resynchronization request can also be
+    made when conditions indicate internal inconsistency, such as
+    failure of a coded assertion.  Implementations which require
+    resynchronization should be considered in error, however the BGP
+    protocol accomodates the possibility that errant implementation may
+    exist (transiently) and provides resynchronization as a means to
+    restore operational integrity with minimal disruption.
+ 
+    After sending a RESYNCHRONIZATION message with a Sender
+    Resynchronizing Request (Request Code 1) or receiving a
+    RESYNCHRONIZATION message with a Receiver Resynchronize Request
+    (Request Code 2), the sender must empty the associated Adj-RIBs-Out
+    and readvertise all route in its Loc-RIB to its peer as described
+    in section 9.1.3, as if no routes had ever been advertised to that
+    peer.
+ 
+    After receiving a RESYNCHRONIZATION message with a Sender
+    Resynchronizing Request (Request Code 1) or sending a
+    RESYNCHRONIZATION message with a Receiver Resynchronize Request
+    (Request Code 2), the receiver must mark all entries in the Loc-RIB
+    for removal and empty the Adj-RIBs-In.  As the Adj-RIBs-In is
+    repopulated the marks in the associated Loc-RIB entires are
+    removed.  After a configured expiration timer has elapsed or a
+    RESYNCHRONIZATION message with a Resynchronizion Completed (Request
+    Code 3) is received, all entries in the Loc-RIB still marked are
+    removed as it they had been withdrawn.
+ 
+    Optionally when a BGP connection is closed the Loc-RIB entries may
+    be treated in the same way they would be when receiving a
+    RESYNCHRONIZATION message with a Sender Resynchronizing Request.
+    It should be possible to configure a different expiration timer
+    value for this condition or disable it entirely.
+ 
+    Optionally a BGP speaker may send a RESYNCHRONIZATION message with
+    a Resynchronizion Completed after a connection has been
+    established, in effect treating the entry to the established state
+    as an implied RESYNCHRONIZATION message with a Receiver Resynchronize 
+    Request from the peer.
+ 
+    An implementation which does not support BGP Resynchronization must
+    send a NOTIFICATION with a Message Header Error (Error Code 1) and a
+    Bad Message Type (Error subcode 3).  
+ 
+    An implementation which does support BGP Resynchronization must
+    have the ability to configure a peer as not supporting BGP
+    Resynchronization and not send any form of RESYNCHRONIZATION
+    message to such a peer.  It must also be able to record the fact
+    that a peer has sent a NOTIFICATION in response to a
+    RESYNCHRONIZATION message and disable sending any further
+    RESYNCHRONIZATION messages to that peer, even after the BGP
+    connection if broken and reestablished, unless that peer later
+    sends a RESYNCHRONIZATION message (which would be interpretted as a
+    code update adding support for BGP Resynchronization).
+ 
+ 
  7.  BGP Version Negotiation.

***************
*** 2085,2095 ****
     shall run its Decision Process since the older route is no longer
     available for use.
  
-    ii) If the new route is an overlapping route that is included (see
-    9.1.4) in an earlier route contained in the Adj-RIB-In, the BGP
-    speaker shall run its Decision Process since the more specific route
- 
- 
  
  Expiration Date February 1996                                  [Page 35]
  
--- 2214,2219 ----
***************
*** 2100,2121 ****
  INTERNET DRAFT                                               August 1996

!    has implicitly made a portion of the less specific route unavailable
!    for use.
! 
!    iii) If the new route has identical path attributes to an earlier
!    route contained in the Adj-RIB-In, and is more specific (see 9.1.4)
!    than the earlier route, no further actions are necessary.
! 
!    iv) If the new route has NLRI that is not present in any of the
!    routes currently stored in the Adj-RIB-In, then the new route shall
!    be placed in the Adj-RIB-In. The BGP speaker shall run its Decision
!    Process.
! 
!    v) If the new route is an overlapping route that is less specific
!    (see 9.1.4) than an earlier route contained in the Adj-RIB-In, the
!    BGP speaker shall run its Decision Process on the set of destinations
!    described only by the less specific route.

  9.1 Decision Process
--- 2224,2235 ----
  INTERNET DRAFT                                               August 1996

!    ii) If the new route has NLRI that is not present in any of the
!    routes currently stored in the Adj-RIB-In, regardless of whether
!    the new route overlaps an earlier route contained in the Adj-RIB-In
!    that is either more specific or less specific (see 9.1.4), then the
!    new route shall be placed in the Adj-RIB-In. The BGP speaker shall
!    run its Decision Process.

  9.1 Decision Process
***************
*** 2199,2213 ****
     operating on all new or unfeasible routes contained within it.
  
     For each newly received or replacement feasible route, the local BGP
!    speaker shall determine a degree of preference. If the route is
!    learned from a BGP speaker in the local autonomous system, either the
     value of the LOCAL_PREF attribute shall be taken as the degree of
!    preference, or the local system shall compute the degree of
!    preference of the route based on preconfigured policy information. If
!    the route is learned from a BGP speaker in a neighboring autonomous
!    system, then the degree of preference shall be computed based on
!    preconfigured policy information.  The exact nature of this policy
!    information and the computation involved is a local matter.  The

  
--- 2313,2327 ----
     operating on all new or unfeasible routes contained within it.
  
     For each newly received or replacement feasible route, the local BGP
!    speaker shall determine a degree of preference.  If the route is
!    learned from a BGP speaker in the local autonomous system, the
     value of the LOCAL_PREF attribute shall be taken as the degree of
!    preference.  If the route is learned from a BGP speaker in a
!    neighboring autonomous system, then the degree of preference shall
!    be computed based on preconfigured policy information and used as
!    the LOCAL_PREF value in any IBGP readvertisement.  The exact nature
!    of this policy information and the computation involved is a local
!    matter.  The 

  
***************
*** 2243,2259 ****
     the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
     route SHOULD be excluded from the Phase 2 decision function.
  
!    For each set of destinations for which a feasible route exists in the
!    Adj-RIBs-In, the local BGP speaker shall identify the route that has:
! 
!       a) the highest degree of preference of any route to the same set
!       of destinations, or
! 
!       b) is the only route to that destination, or
! 
!       c) is selected as a result of the Phase 2 tie breaking rules
!       specified in 9.1.2.1.
! 
  
     The local speaker SHALL then install that route in the Loc-RIB,
     replacing any route to the same destination that is currently being
--- 2357,2416 ----
     the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
     route SHOULD be excluded from the Phase 2 decision function.
  
!   It is critical that routers within an AS do not make conflicting
!   decisions regarding route selection that would cause forwarding
!   loops to occur (routers pointing traffic as each other or in a
!   cycle).  BGP speakers will consider the following attributes in
!   determining preference and will consider no others.
! 
!        1.  NEXT_HOP.  The next hop must be reachable, or if NEXT_HOP is
!            not provided, the advertising router must be reachable)
! 
!        1.  LOCAL_PREF.
! 
!        2.  MULTI_EXIT_DISC.  This comparison is applicable only when
!            comparing MULTI_EXIT_DISC received from the same
!            neighboring AS, including those received from the same
!            neighboring AS and passed via IBGP.
! 
!        3.  Internal routing protocol cost.  Lower costs are preferred.
!            Select the route that has the lowest cost (interior
!            distance) to the entity depicted by the NEXT_HOP attribute
!            of the route.
! 
!        4.  Advertising router BGP Identifier.  If at least one of the
!            candidate routes was advertised by the BGP speaker in a
!            neighboring autonomous system, select the route that was
!            advertised by the BGP speaker in a neighboring autonomous
!            system whose BGP Identifier has the lowest value among all
!            other BGP speakers in neighboring autonomous systems.
!            Otherwise, select the route that was advertised by the BGP
!            speaker whose BGP Identifier has the lowest value.
! 
!   The MULTI_EXIT_DISC may be dropped when passing a route via IBGP.
!   To prevent routing loops a route with a MULTI_EXIT_DISC (if the
!   routes and received from the same neighboring AS and therefore the
!   comparison is applicable) is preferred over one without.
! 
!   The outcome of a comparison must be independent of the order in
!   which routes are placed in the Adj-Rib-In and Local-Rib.  Due to
!   difference in the backlog of propogated routes among IBGP peers, the
!   same set of routes may arrive in different orders on differnt
!   routers.  If routes are compared in arbitrary order, under certain
!   conditions routing loops can occur.  This is a consequence of the
!   use of MULTI_EXIT_DISC in comparing routes received from the same
!   neighboring AS but not considering MULTI_EXIT_DISC when comparing
!   routes received from differing neighboring AS.
! 
!   The comparison algorithm must insure a deterministic decision
!   outcome.  To accomplish this, routes are compared in a constrained
!   order.  First all routes are checked for feasibility, insuring that
!   the NEXT_HOP is reachable.  All routes from the same neighboring AS
!   are first compared using the criteria above, LOCAL_PREF,
!   MULTI_EXIT_DISC, internal routing protocol cost, and Advertising
!   router IP address.  Then the best route selected from each
!   neighboring AS are compared using the criteria, LOCAL_PREF, internal
!   routing protocol cost, and Advertising router BGP Identifier.
  
     The local speaker SHALL then install that route in the Loc-RIB,
     replacing any route to the same destination that is currently being
***************
*** 2280,2325 ****
  INTERNET DRAFT                                               August 1996

!    RIBs-In.
! 
! 
! 9.1.2.1 Breaking Ties (Phase 2)
! 
! 
!    In its Adj-RIBs-In a BGP speaker may have several routes to the same
!    destination that have the same degree of preference. The local
!    speaker can select only one of these routes for inclusion in the
!    associated Loc-RIB. The local speaker considers all equally
!    preferable routes, both those received from BGP speakers located in
!    neighboring autonomous systems, and those received from other BGP
!    speakers located in the local speaker's autonomous system.
! 
!    The following tie-breaking procedure assumes that for each candidate
!    route all the BGP speakers within an autonomous system can ascertain
!    the cost of a path (interior distance) to the address depicted by the
!    NEXT_HOP attribute of the route.  Ties shall be broken according to
!    the following algorithm:
! 
!       a) If the local system is configured to take into account
!       MULTI_EXIT_DISC, and the candidate routes differ in their
!       MULTI_EXIT_DISC attribute, select the route that has the lowest
!       value of the MULTI_EXIT_DISC attribute.  A route with
!       MULTI_EXIT_DISC shall be preferred to a route without
!       MULTI_EXIT_DIST.
! 
!       b) Otherwise, select the route that has the lowest cost (interior
!       distance) to the entity depicted by the NEXT_HOP attribute of the
!       route.  If there are several routes with the same cost, then the
!       tie-breaking shall be broken as follows:
! 
!          - if at least one of the candidate routes was advertised by the
!          BGP speaker in a neighboring autonomous system, select the
!          route that was advertised by the BGP speaker in a neighboring
!          autonomous system whose BGP Identifier has the lowest value
!          among all other BGP speakers in neighboring autonomous systems;
! 
!          - otherwise, select the route that was advertised by the BGP
!          speaker whose BGP Identifier has the lowest value.

  9.1.3   Phase 3: Route Dissemination
--- 2437,2443 ----
  INTERNET DRAFT                                               August 1996

!    RIB-In.

  9.1.3   Phase 3: Route Dissemination
***************
*** 2425,2451 ****
     the less specific route.
  
     If a BGP speaker receives overlapping routes, the Decision Process
!    shall take into account the semantics of the overlapping routes. In
!    particular, if a BGP speaker accepts the less specific route while
!    rejecting the more specific route from the same peer, then the
!    destinations represented by the overlap may not forward along the ASs
!    listed in the AS_PATH attribute of that route. Therefore, a BGP
!    speaker has the following choices:
! 
!       a)   Install both the less and the more specific routes
! 
!       b)   Install the more specific route only
! 
!       c)   Install the non-overlapping part of the less specific
!                  route only (that implies de-aggregation)
! 
!       d)   Aggregate the two routes and install the aggregated route
! 
!       e)   Install the less specific route only
! 
!       f)   Install neither route
  
!    If a BGP speaker chooses e), then it should add ATOMIC_AGGREGATE
     attribute to the route. A route that carries ATOMIC_AGGREGATE
     attribute can not be de-aggregated. That is, the NLRI of this route
  
--- 2543,2554 ----
     the less specific route.
  
     If a BGP speaker receives overlapping routes, the Decision Process
!    shall consider both routes based on configured acceptance policy.
!    If both are accepted the Decision Process will install both the
!    less and the more specific routes or aggregate the two routes and
!    install the aggregated route.
  
!    If a BGP speaker chooses to aggregate, then it should add ATOMIC_AGGREGATE
     attribute to the route. A route that carries ATOMIC_AGGREGATE
     attribute can not be de-aggregated. That is, the NLRI of this route
  
***************
*** 2462,2470 ****
  
     can not be made more specific.  Forwarding along such a route does
     not guarantee that IP packets will actually traverse only ASs listed
!    in the AS_PATH attribute of the route.  If a BGP speaker chooses a),
!    it must not advertise the more general route without the more
!    specific route.

  9.2 Update-Send Process
--- 2565,2573 ----
  
     can not be made more specific.  Forwarding along such a route does
     not guarantee that IP packets will actually traverse only ASs listed
!    in the AS_PATH attribute of the route.  If a BGP speaker chooses to
!    install both routes it must not advertise the more general route
!    without the more specific route.

  9.2 Update-Send Process
***************
*** 2500,2531 ****
     When a BGP speaker receives a new route from a BGP speaker in a
     neighboring autonomous system, it shall advertise that route to all
     other BGP speakers in its autonomous system by means of an UPDATE
!    message if any of the following conditions occur:
! 
!       1) the degree of preference assigned to the newly received route
!       by the local BGP speaker is higher than the degree of preference
!       that the local speaker has assigned to other routes that have been
!       received from BGP speakers in neighboring autonomous systems, or
! 
!       2) there are no other routes that have been received from BGP
! 
! 
! 
! Expiration Date February 1996                                  [Page 42]
! 
! 
! 
! 
! 
! INTERNET DRAFT                                               August 1996
! 
! 
!       speakers in neighboring autonomous systems, or
! 
!       3) the newly received route is selected as a result of breaking a
!       tie between several routes which have the highest degree of
!       preference, and the same destination (the tie-breaking procedure
!       is specified in 9.2.1.1).
  
     When a BGP speaker receives an UPDATE message with a non-empty
     WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all
--- 2603,2610 ----
     When a BGP speaker receives a new route from a BGP speaker in a
     neighboring autonomous system, it shall advertise that route to all
     other BGP speakers in its autonomous system by means of an UPDATE
!    message if this route has become the best route installed in the
!    Local-Rib according to the route selection rules in 9.1.2.
  
     When a BGP speaker receives an UPDATE message with a non-empty
     WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all
***************
*** 2554,2598 ****
     All feasible routes which are advertised shall be placed in the
     appropriate Adj-RIBs-Out, and all unfeasible routes which are
     advertised shall be removed from the Adj-RIBs-Out.
- 
- 
- 9.2.1.1 Breaking Ties (Internal Updates)
- 
- 
-    If a local BGP speaker has connections to several BGP speakers in
-    neighboring autonomous systems, there will be multiple Adj-RIBs-In
-    associated with these peers. These Adj-RIBs-In might contain several
-    equally preferable routes to the same destination, all of which were
-    advertised by BGP speakers located in neighboring autonomous systems.
-    The local BGP speaker shall select one of these routes according to
-    the following rules:
- 
-       a) If the candidate routes differ only in their NEXT_HOP and
- 
- 
- 
- Expiration Date February 1996                                  [Page 43]
- 
- 
- 
- 
- 
- INTERNET DRAFT                                               August 1996
- 
- 
-       MULTI_EXIT_DISC attributes, and the local system is configured to
-       take into account the MULTI_EXIT_DISC attribute, select the route
-       that has the lowest value of the MULTI_EXIT_DISC attribute. A
-       route with the MULTI_EXIT_DISC attribute shall be preferred to a
-       route without the MULTI_EXIT_DISC attribute.
- 
-       b) If the local system can ascertain the cost of a path to the
-       entity depicted by the NEXT_HOP attribute of the candidate route,
-       select the route with the lowest cost.
- 
-       c) In all other cases, select the route that was advertised by the
-       BGP speaker whose BGP Identifier has the lowest value.
- 

  9.2.2 External Updates
--- 2633,2638 ----
- - - - - - - - - - - - - - - - -