Subject: Re: Withdrawls and announcements attempt 2
From: Yakov Rekhter <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 21 Jun 96 15:23:18 PDT

Curtis,

> Moved to bgp list.

Thanks.

> > Please note that propagating withdrawals to all neighbors is
> > *not* the problem we are trying to solve now, as such propagation
> > accounts for only a small fraction of the total withdraws (see attached).
> > 
> > In fact, we've yet to see any empirical evidences that propagating
> > withdrawals to all neighbors is a problem.
> 
> At MaeEast in many cases 30 to 50 peers hear a withdrawl and then
> withdraw the same route thenselves.  You would expect to see N times
> as many withdraws as was needed for a given withdrawl depending on who
> withdrew it and how many Ciscos they peer with.

As was indicated in the original message from MERIT, this accounts for
only a small fraction of the total withdraws (for the benefits of those
not on the NANOG list I attached the original message from MERIT). So,
to repeat what I said in my previous note let's focus on what seems to
be a much more important issue - ~5*10^6 daily withdraws.

> If you look at the stats and add up the withdraws and announces and
> take the ratio you have a ratio of about 12.  Someone with a Cisco
> router that hears a lot of withdraws will have a very high ratio.
> Someone that flaps a lot will just cause others to have a very high
> ratio.  The ratio of totals should be in line with the average number
> of Cisco peers.
> 
> This should be sufficient emperical evidence to consider fixing the
> problem.  

What you presented is a number - 12. This number, by itself, tells very
little about the *operational* impact of these withdraws. To assess the
operational impact you need to provide such parameters as extra
bandwidth consumed by these withdraws, and extra CPU load imposed
by processing these withdraws. 

Yakov.
--------------------------------------------------------------------------

 -- using template mhl.format --
Date:    Fri, 21 Jun 96 12:04:59 EDT
To:      [email-masked]

From:    Craig Labovitz <[email-masked]>
Subject: Re: Withdrawls and announcements attempt 2 

Reply-To: [email-masked]
Sender:  [email-masked]

A quick clarification -- the liberal BGP widthraw policy implemented by Cisco 
(and a few other vendors) only accounts for a small fraction of the ~5 million 
plus daily withdraws in the default-free Internet. The real source of all 
these spurious withdraws remains a bit of a mystery. Our data shows some 
strange sort of 30 second looping/oscilation behavior is taking place. 
Possible causes of this behavior include configuration errors, unexpected 
IGP-EGP interactions, vendor implementation bugs, and problems inherent with 
the BGP protocol itself.

The source of the millions of BGP withdraws is NOT Cisco's "liberal BGP 
withdraw" policy -- this generates a fairly minor number of extra withdraws 
(O(n) per router), and there are a quite a few valid and compelling reasons 
for wanting implementing BGP this way.

- Craig

at Fri, 21 Jun 1996 11:24:25 EDT, you wrote:
> 
> "Justin W. Newton" <[email-masked]> writes
> 
>  * Its /a little/ more complex than that.  The RFC does /not/ call for closin
g
>  * down a BGP session when you change your route filters.  Cisco's have to do
>  * this, but its not part of the RFC.  So, if I, for the sake of argument,
>  * added a new filter /after/ I made an announcement to someone I would have 
to
>  * somewhere keep track of the fact that I made the announcement.  It seems t
o
>  * me that this could get to be a bit memory intensive (keeping track of the
>  * state of every announcement made to every peer).
>  * 
>  * This leads me to wonder whether if we had infinite memory (just for the sa
ke
>  * of argument), if it would be more processor intensive to keep track of all
>  * of your announcements or if the overhead invloved in dealing with withdraw
ls
>  * that don't affect me is less.
> 
> There are however vendors out there that do exactly what you described
> above and can therefore change policies and have them take effect
> without having to take down a BGP session. And they only withdraw a
> prefix if they sent an update for it in the first place.
> 
> -Marten

-- 
Craig Labovitz				[email-masked]
Merit Network, Inc.			(313) 764-0252 (office) 
4251 Plymouth  Road, Suite C.		(313) 747-3745 (fax)
Ann Arbor, MI 48105-2785

> 
> Curtis
- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Withdrawls and announcements attempt 2 
Date: Fri, 21 Jun 1996 17:50:31 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

Yakov,

Moved to bgp list.

> Please note that propagating withdrawals to all neighbors is
> *not* the problem we are trying to solve now, as such propagation
> accounts for only a small fraction of the total withdraws (see attached).
> 
> In fact, we've yet to see any empirical evidences that propagating
> withdrawals to all neighbors is a problem.

At MaeEast in many cases 30 to 50 peers hear a withdrawl and then
withdraw the same route thenselves.  You would expect to see N times
as many withdraws as was needed for a given withdrawl depending on who
withdrew it and how many Ciscos they peer with.

> Now could we return (perhaps on the BGP list) to the discussion
> about the *real* issue we need to solve - ~5*10^6 daily withdraws.
> 
> Yakov.

If you look at the stats and add up the withdraws and announces and
take the ratio you have a ratio of about 12.  Someone with a Cisco
router that hears a lot of withdraws will have a very high ratio.
Someone that flaps a lot will just cause others to have a very high
ratio.  The ratio of totals should be in line with the average number
of Cisco peers.

This should be sufficient emperical evidence to consider fixing the
problem.  The ratio of 12:1 out of does not seem out of line fora
weighted average number of the number of Ciscos that a given flapper
flaps to.  I think some of the smaller providers do have less peers
than the major providers, so this does seem reasonable to me.

Curtis

Peer                 Packets    Ann        With       Ann+With
ANS (690)            2572       8226       5732       13958   
Advantis (2685)      83         76         59         135     
Alternet (701)       16370      85551      145672     231223  
BBNplanet (AS1)      4223       5643       22486      28129   
BayNetworks (6205)     241        306        321        627     
CAIS (3491)          3043       1285       197688     198973  
CWInet (4445)        2875       67         267503     267570  
CWix (5683)          2317       527        31636      32163   
CWix (5683)          2970       486        141007     141493  
Compuserve (4183)     18         3          19         22      
DIGEX (2548)         1442       253        9323       9576    
DRAnet (1746)        2          2          0          2       
DialNet (5552)       85         35         113        148     
ESnet1 (293)         237        130        682        812     
ESnet2 (293)         243        282        509        791     
EUNet (286)          1931       7167       4577       11744   
Erols (6079)         869        100        11438      11538   
Exodus (3967)        1443       16884      16860      33744   
HLCnet (4565)        2685       11         112495     112506  
INAP.net (5646)      4017       1276       115737     117013  
INSnet (5378)        588        5          7812       7817    
IOSnet (5000)        23         20         7          27      
IconNet (3951)       12         9          15         24      
Interpath (3407)     2895       174        266051     266225  
MAI (6082)           8          29         0          29      
MCI (3561)           8687       24039      198729     222768  
Net99 (3830)         2858       0          217279     217279  
Netcom (2551)        7040       23747      213759     237506  
Netrail (4006)       29         54         12         66      
PIPEX (1849)         14858      2890       366578     369468  
PrimeNet (3549)      15         47         29         76      
SPRINT (1239)        10561      34816      94378      129194  
USCyber (4136)       2921       185        157816     158001  
VoiceNet (3932)      60         57         373        430     
		Totals		214382	   2606695	ratio: 12.2
- - - - - - - - - - - - - - - - -

To: IETF-Announce:;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: BGP communities attribute to Proposed Standard
Date: Wed, 19 Jun 96 13:46:03 -0400
Sender: [email-masked]
Reply-To: [email-masked]

  The IESG has approved the Internet-Draft "BGP communities attribute"
  <draft-ietf-idr-communities-00.txt> as a Proposed Standard.

  The IESG also approved the publication of BGP Community Attribute in
  Multi-home Routing <draft-ietf-idr-community-usage-00.txt> as an
  Informational RFC.

These documents are the product of the Inter-Domain Routing Working
Group. The IESG contact person is Joel Halpern.

Technical Summary

 The new community attribute for BGP provides a mechanism for labelling
 BGP advertisements with common attributes.

 The accompanying usage document provides information on one situation
 where this attribute is useful.

Working Group Summary

 There was no significant dissent in the working group. The group
 agreed that this appeared to be a useful addition to BGP.

Protocol Quality

 The protocol has been reviewed by the Routing Area Director, Joel M.
 Halpern, and appears sound. There are at least two independent
 implementations (cisco and BayNetworks, per the WG Chair).

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

To: IETF-Announce:;
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-idrp2-00.txt
Date: Fri, 14 Jun 96 09:41:30 -0400
Sender: [email-masked]
Reply-To: [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     : Inter-Domain Routing Protocol, Version 2                
       Author(s) : Y. Rekhter, P. Traina
       Filename  : draft-ietf-idr-idrp2-00.txt
       Pages     : 110
       Date      : 06/13/1996

The Inter-Domain Routing Protocol (IDRP) permits a routing domain to 
exchange information with other routing domains to facilitate the operation
of the routing and relaying functions of the Network Layer.                

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-idrp2-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-idrp2-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa                                   
        Address:  ftp.is.co.za (196.4.160.8)	
	                                                
     o  Europe                                   
        Address:  nic.nordu.net (192.36.148.17)	
        Address:  ftp.nis.garr.it (193.205.245.10)
	                                                
     o  Pacific Rim                              
        Address:  munnari.oz.au (128.250.1.21)	
	                                                
     o  US East Coast                            
        Address:  ds.internic.net (198.49.45.10)	
	                                                
     o  US West Coast                            
        Address:  ftp.isi.edu (128.9.0.32)  	
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [email-masked]. In the body type: 
     "FILE /internet-drafts/draft-ietf-idr-idrp2-00.txt".
							
NOTE: The mail server at ds.internic.net 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.
							
For questions, please mail to [email-masked].

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-idrp2-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-idr-idrp2-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

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

--OtherAccess--

--NextPart--
- - - - - - - - - - - - - - - - -

From: [email-masked] (Paul Traina)
To: [email-masked]
Subject: draft-ietf-idr-idrp2-00.txt
Date: Thu, 13 Jun 1996 12:41:34 -0700
Sender: [email-masked]
Reply-To: [email-masked]

The draft for IDRP v2 (for IPv4/v6) will be in the archives shortly.
Until then, it may be found at ftp://ftpeng.cisco.com/yakov/idrp2.txt

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

To: [email-masked]
Subject: Re: IDR WG agenda 
Date: Thu, 06 Jun 96 09:58:19 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

> The only piece would be a document status update as we've had several
> documents move along since last meeting.

I'll add this to the agenda.

Yakov.
- - - - - - - - - - - - - - - - -

From: [email-masked] (Bill Manning)
Subject: Re: IDR WG agenda
To: [email-masked]
Date: Wed, 5 Jun 1996 18:53:36 -0700 (PDT)
Sender: [email-masked]
Reply-To: [email-masked]

> 
> Please let me know if there are any other items you'd like to discuss.
> 
> Yakov.
> 

	I had put together a draft on documenting BGP options.
	There was a small flurry of discussion and then general
	lethargy set in.  I'd like to see the group take one more
	look at this and then  push this on as an FYI.

--bill
- - - - - - - - - - - - - - - - -

To: [email-masked]
Subject: Re: IDR WG agenda 
From: Tony Bates <[email-masked]>
Date: Wed, 05 Jun 1996 14:01:44 -0700
Sender: [email-masked]
Reply-To: [email-masked]

The only piece would be a document status update as we've had several
documents move along since last meeting.

		--Tony

 Yakov Rekhter <[email-masked]> writes:
  * Folks,
  * 
  * We'll have one slot for the IDR WG in Montreal.  The only item I'd like
  * to talk is to give a brief update on IDRP for IPv[46] (I am going to
  * submit a new I-D next week).
  * 
  * Please let me know if there are any other items you'd like to discuss.
  * 
  * Thanks.
  * 
  * Yakov.
- - - - - - - - - - - - - - - - -

To: [email-masked]
Subject: IDR WG agenda
Date: Wed, 05 Jun 1996 07:46:59 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

Folks,

We'll have one slot for the IDR WG in Montreal.  The only item I'd like
to talk is to give a brief update on IDRP for IPv[46] (I am going to
submit a new I-D next week).

Please let me know if there are any other items you'd like to discuss.

Thanks.

Yakov.
- - - - - - - - - - - - - - - - -