Subject: Question on BGP-4 routing decision case
From: "Jon 'tex' Boone" <[email-masked]>
To: [email-masked]
Cc: "Jon 'tex' Boone" <[email-masked]>
Date: Thu, 28 Aug 1997 15:20:43 -0400

Folks,
  
  In the following network diagram, the two routers (router A and
router B) are both in AS 55.  They will both have PVC connections to
the vBNS through the ASX 200 ATM switch.  The interface on Router A
also has a PVC for a RFC 1577 network which Router B is *not*
connected to (it is a research network).

  Both Router A and Router B advertise the same four networks to vBNS:
128.91/16, 130.91/16, 158.130/16 and 165.123/16.  However, we would
like to have the vBNS router prefer to send traffic for 158.130/16
through Router A, while preferring to send traffic for the other three
networks through Router B [this is mainly due to politics -
Administrative control of Router A is done by a different department
than that of Router B.]

  Is it the case that the use of Multi-Exit Discriminator attributes
on each route can be used to enforce this policy?  I imagine that the
Routers would make the following announcements to the vBNS router:

Router    Network      MED
------    ----------   ---
  A       128.91/16     10
          130.91/16     10
          158.130/16     1
          165.123/16    10
  B       128.91/16      1
          130.91/16      1
          158.130/16    10
          165.123/16     1

Since these are Cisco routers, I imagine using route-maps to set the
MED attribute for each of these routes.  Is this a coherent idea?

                     ------------
                     | Router A |
                     ------------
                          |
                          |
  --------           -----------
  | vBNS |-----------| ASX 200 |
  --------           -----------
                          |
                          |
                     ------------
                     | Router B |
                     ------------

--------------------------------------------------
Jon Boone                         Network Engineer
ISC Networking          University of Pennsylvania
[email-masked]                   (215) 898-2477

To: Rohit Dube <[email-masked]>
cc: Yakov Rekhter <[email-masked]>, [email-masked], [email-masked]
Subject: Re: WG Last Call 
From: Tony Bates <[email-masked]>
Date: Wed, 27 Aug 1997 20:48:27 -0700
Sender: [email-masked]

 Rohit Dube <[email-masked]> writes:
  * On Thu, 21 Aug 97 09:19:51 PDT [email-masked] writes:
  * =>Folks,
  * =>
  * =>This is the IDR WG Last Call for advancing 
  * =>draft-ietf-idr-as-dedicated-00.txt to an Informational RFC.
  * 
  * 
  * I had some comments on the draft -
  * 
  *    3.1 Full Routing Table Announcement
  * 
  *    A BGP customer using	the dedicated AS must carry a default route
  *    (preferably receiving from its provider via BGP).
  * 
  * I assume this is because (using the example) X can't see the routes 
  * from Y and vice-versa. Given that the proposed RFC is informational, the
  * authors may want to ellaborate.
  * 
That's correct. This is becuase of the BGP loop detection. I am not
sure we really need to ellaborate as to why as this is in the
implications section.

  * 
  *    3.2  Change of External	Connectivity
  * 
  *    The dedicated AS specified by a provider is purely for use in peering
  *    between its customers and the provider. When	a customer using the
  *    dedicated AS	changes	its external connectivity, it may be necessary
  *    for the customer to reconfigure their network to use	a different AS
  *    number (either a globally unique one	if homed to multiple providers,
  *    or a	dedicated AS of	a different provider).
  * 
  * Does using a dedicated AS preclude a back-up connection between two
  * customers of the same provider? BGP peering between two customer networks
  * using _the_ deidicated AS number is ofcourse not possible, but what
  * about peering between a customer who has a dedicated AS number and another 
  * who has a "real" AS number assigned to it. It seems to me that this 
  * would work fine. Perhaps this is worth commenting on in this section.
  * 
  *

It in fact does not preclude this ability but is to some degree not
the problem we are trying to solve and I would argue that this is the
slippery slope. If you have a backup connection you really have a
different routing policy for your ISP and should be looking at getting
a unique ASN. RFC1930 explicity allows for such a requirement.

  *    3.4  Routing Registries
  * 
  *    For example, the	"mntner" attribute or the "community"
  *    attribute of	a route	object can be used along with the "origin"
  *    attribute in	generating the filtering lists.
  * 
  * Again, because this is a proposed informational RFC, the authors may want t
  * o
  * provide a reference for the "mntner" (is there an RFC for this yet?) and 
  * "community" (RFC 1997) attributes.
  * 
There is a reference in the para above. It is [5]. RFC1786 which
details both of these attributes.

  * 
  * On a different note, I am curious about the reasoning behind the 
  * restriction that there be only _one_ dedicated AS number. It appears to 

We do not explicitly restrict you to one dedicated ASN and could in
fact be more than one. However, eventually you will still have the
same implications as using one dedicated AS which is why we describe
it this way. The other slight downside is you also have to manage/keep
track of all of these AS's for potentially very little gain.

  * me that any number of dedicated AS numbers can be handed out by the provide
  * r, 
  * as long as the provider is able to strip out these AS numbers at its 
  * egress points (to other providers). If one such AS number is handed out
  * per customer which needs an AS number, we would have the added advantage 
  * that defaults need not be propagated to the customers and they would see 
  * the full routing table.
  * 
Except that this clearly only scales for (65535 - 64512) 1023
customers at most.

  * Am I missing something? 
  * 

Doesn't scale.

	Cheers,
			--Tony

From: "Jagannadham Jonnalag" <[email-masked]>
To: [email-masked]
Subject: bgp2ospf route exports
Date: Mon, 25 Aug 1997 12:32:39 PDT
Sender: [email-masked]

Subject:BGP2OSPF external type1 and type 2 routes entry into routing 
table

When routes are exported from BGP to OSPF, after setting the appropriate
fields the external LSAs are flooded through (RFC1583, section 12.4.5)
all the links.

Section 16.4 says:
(2) If the advertisement was originated by the calculating
    router itself, examine the next advertisement.

Basically a router  should not process it's own external LSA 
advertisement.

My question: how do I introduce routes imported from OSPF into a local
instance of OSPF's roting table. They will make into the neighbors
databases because of external LSA flooding, but how about adding the
entry to the local OSPF's routing table.

OR did misunderstand something.
Any pointers are welcome.

Thanks,
-Jag
CC replies to: [email-masked]

Clip from OSPF draft:
According to the OSPF specification (page 131 of draft 2.05):

                In the above example, the forwarding address field has
                been set to 0.0.0.0, indicating that packets for the
                external destination should be forwarded to the
                advertising OSPF router (RT7).  This is not always
                desirable.  Consider the example pictured in Figure 16.
                There are three OSPF routers (RTA, RTB and RTC)
                connected to a common network.  Only one of these
                routers, RTA, is exchanging EGP information with the
                non-OSPF router RTX.  RTA must then originate AS
                external link advertisements for those destinations it
                has learned from RTX.  By using the AS external link
                advertisement's forwarding address field, RTA can
                specify that packets for these destinations be forwarded
                directly to RTX.  Without this feature, Routers RTB and
                RTC would take an extra hop to get to these
                destinations.

                Note that when the forwarding address field is non-zero,
                it should point to a router belonging to another
                Autonomous System.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

To: Yakov Rekhter <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: WG Last Call 
Date: Fri, 22 Aug 1997 21:30:45 -0400
From: Rohit Dube <[email-masked]>
Sender: [email-masked]

On Thu, 21 Aug 97 09:19:51 PDT [email-masked] writes:
=>Folks,
=>
=>This is the IDR WG Last Call for advancing 
=>draft-ietf-idr-as-dedicated-00.txt to an Informational RFC.

I had some comments on the draft -

   3.1 Full Routing Table Announcement

   A BGP customer using	the dedicated AS must carry a default route
   (preferably receiving from its provider via BGP).

I assume this is because (using the example) X can't see the routes 
from Y and vice-versa. Given that the proposed RFC is informational, the
authors may want to ellaborate.

   3.2  Change of External	Connectivity

   The dedicated AS specified by a provider is purely for use in peering
   between its customers and the provider. When	a customer using the
   dedicated AS	changes	its external connectivity, it may be necessary
   for the customer to reconfigure their network to use	a different AS
   number (either a globally unique one	if homed to multiple providers,
   or a	dedicated AS of	a different provider).

Does using a dedicated AS preclude a back-up connection between two
customers of the same provider? BGP peering between two customer networks
using _the_ deidicated AS number is ofcourse not possible, but what
about peering between a customer who has a dedicated AS number and another 
who has a "real" AS number assigned to it. It seems to me that this 
would work fine. Perhaps this is worth commenting on in this section.

   3.4  Routing Registries

   For example, the	"mntner" attribute or the "community"
   attribute of	a route	object can be used along with the "origin"
   attribute in	generating the filtering lists.

Again, because this is a proposed informational RFC, the authors may want to
provide a reference for the "mntner" (is there an RFC for this yet?) and 
"community" (RFC 1997) attributes.

On a different note, I am curious about the reasoning behind the 
restriction that there be only _one_ dedicated AS number. It appears to 
me that any number of dedicated AS numbers can be handed out by the provider, 
as long as the provider is able to strip out these AS numbers at its 
egress points (to other providers). If one such AS number is handed out
per customer which needs an AS number, we would have the added advantage 
that defaults need not be propagated to the customers and they would see 
the full routing table.

Am I missing something? 

TIA.
--rohit.
#include <stddisclaimers.h>

To: [email-masked]
cc: [email-masked]
Subject: WG Last Call
Date: Thu, 21 Aug 97 09:19:51 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

This is the IDR WG Last Call for advancing 
draft-ietf-idr-as-dedicated-00.txt to an Informational RFC.
The Last Call ends in two week (Sep 4).

Yakov.

From: Dave Thaler <[email-masked]>
Subject: disregard "default SAFI"
To: [email-masked]
Date: Wed, 13 Aug 1997 13:15:46 -0400 (EDT)
Sender: [email-masked]

If you got a message entitled "default SAFI", please disregard it.
I answered my own question before I finished writing it, and it looks
like it got sent rather than aborted.  
(There's only one non-broken option.)

-Dave

From: Dave Thaler <[email-masked]>
Subject: default SAFI
To: [email-masked]
Date: Wed, 13 Aug 1997 05:51:48 -0400 (EDT)
Sender: [email-masked]

One thing that I didn't see addressed by the BGP4+ spec is the issue
of default SAFI.  That is, what SAFI value should be assumed by
a BGP4+ speaker who receives an update with normal NLRI only?

There are (at least) three options:
1) State that SAFI=1 is the default.  That is, assume that prefixes
   are not valid for multicast unless you're specifically informed
   via MP_REACH_NLRI that they are.

2) State that SAFI=3 is the default.  That is, assume that prefixes
   are valid for multicast unless you're specifically informed
   via MP_REACH_NLRI they they're not.

From: Dave Thaler <[email-masked]>
Subject: SAFI's
To: [email-masked]
Date: Wed, 13 Aug 1997 05:45:03 -0400 (EDT)
Sender: [email-masked]

I had a conversation after Monday's session with Dave Meyer and Yakov
and I forget who else, and I agreed to post to the list what we talked
about...

My contention was that there was no need for a new SAFI to hold
class-D prefixes, that they properly belong with the other prefixes
with SAFI=2 (reasoning below).  The others were tentatively convinced
(at least that's the impression I got, I'm sure they'll correct me
if not...), so I'd like to see if anyone on the list disagrees.

Reasoning:
 1) Class-D and non-Class-D prefixes are not semantically different
    in terms of the way inter-domain multicast routing (i.e.
    BGMP, aka GUM) uses the multicast RIB.  They're all just 
    "addresses to send Joins towards".  For multicast-knowledgeable
    people: joining a source-specific tree entails sending a Join
    towards the source address, where towards is defined by the
    best next hop in BGP4+'s multicast RIB.  Joining a group-shared
    tree entails sending a Join towards the group address.  As far as 
    multicast RIB usage is concerned, there's no distinction between 
    class-D and non-class-D destination addresses.

 2) Simpler implementation.  Since the prefixes all go in the same RIB
    anyway in an implementation, reusing SAFI=2 simplifies things 
    considerably (definitely in gated, although I believe it's true in
    general).

 3) Doesn't require reserving another value (and also means fewer code 
    points).  All the BGP4+ spec would need is two words deleted (though 
    a clarifying sentence should probably be added).

    Specifically, in section 4, on MP_REACH_NLRI:
    >      2 - Unicast Network Layer Reachability Information used for
    >       multicast forwarding
    The word "Unicast" would be removed, and potentially a sentence
    explicitly stating that Class-D prefixes are allowed for this
    SAFI value.

    Again in section 5, the same text is duplicated as above when
    describing MP_UNREACH_NLRI.

-Dave Thaler

From: [email-masked]
Date: Sat, 9 Aug 1997 14:11:17 -0400 (EDT)
To: [email-masked]
Subject: IDRP for IPv6 specification
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

The next message is the IDRP for IPv6 specification.

You can obtain this document on:

http://www.gated.org/new_web/reference/drafts/idrp-ipv6.txt

You can obtain the IETF presentation at:

http://www.gated.org/new_web/reference/drafts/idrp/idrp.announce.html

We will discuss the IDRP for IPv6 in the 8/12 IDR Session.
 
Please send any questions about to me.

Susan Hares 

From: [email-masked]
Date: Fri, 8 Aug 1997 16:21:45 -0400
To: [email-masked]
Subject: Best prices on Web Page Hosting
Sender: [email-masked]

Dear Important Web Page Customer,

  Here at Flashlink Web Services your business is very 
important to us which is why we would like to take this 
opportunity to help you save money on your web page 
hosting.  Flashlink Web Services takes a unique approach 
to web hosting which keeps costs down and offers excellent 
customer service and savings.  Our philosophy - have a 
large number of customers that pay a small monthly fee, 
therefore eliminating the need to overcharge as many other 
hosting services with fewer customers do.  If you are 
interested in saving money on your web page hosting fees, 
just reply to this message and let us know what you are 
currently paying for your web page and we will do our best 
to offer you a lower rate.  We have been able to offer a 
lower rate and better service for the people who have 
replyed to this message over 94% of the time saving our 
customers as much as hundreds of dollars per year!  Flashlink 
Web Services is also available to provide services such 
as Inexpensive Web Page Design; Secure Servers; CGI Scripting; 
Shopping Carts for Online Ordering; Java Scripts; Daily, 
Weekly, or Monthly Updates to your Web Site; Remote 
Administration; Bulk E-Mail Services; Advertising for your 
Web Site; and Much, Much More.  There is NO OBLIGATION if you 
reply to this message, so click the reply button now or send 
us E-Mail (mailto:[email-masked]) for a price quote 
(don't forget to include your current web page address) 
and you can start saving money on your web services today!

Sincerely,
Wayne Steiner
Sales Department - Flashlink Web Services - mailto:[email-masked]

Date: Thu, 7 Aug 1997 10:09:47 -0400 (EDT)
From: [email-masked]
Sender: [email-masked]

From: [email-masked] (Ajay Agrawal)
Subject: Internal updates
To: [email-masked]
Date: Thu, 7 Aug 1997 18:28:32 -0530 (IST)
Sender: [email-masked]

Hi!
	I have a query regarding internal update processing as a part of Phase-1
(RFC-1771 section 9.1.1). 
When an update message is received from an External peer as a part 
of phase-1 we calculate Degree of Preference associated with this route.
If this route is more preferred we advertise the same to all the internal
peers.
My query is that Will it make any difference if for ease of processing
internal updates are sent just after completion of phase-2?

regards
Ajay

To: [email-masked]
Subject: additions to the agenda
Date: Mon, 04 Aug 97 12:01:51 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

There are few Internet Drafts that we need to discuss during
our Monday's meeting in Munich:

draft-ietf-idr-aggregation-framework-01.txt
draft-ietf-idr-aggregation-tutorial-00.txt

draft-ietf-idr-as-dedicated-00.txt

Yakov. 

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION: draft-ietf-idr-aggregation-framework-01.txt
Date: Thu, 31 Jul 1997 09:56:48 -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		: A Framework for Inter-Domain Route Aggregation
	Author(s)	: J. Stewart and E. Chen
	Filename	: draft-ietf-idr-aggregation-framework-01.txt
	Pages		: 13
	Date		: 1997-07-30
	
This document presents a framework for inter-domain route aggregation
   and shows an example router configuration which 'implement' this
   framework.  This framework is flexible and scales well as it
   emphasizes the philosophy of aggregation by the source, both within
   routing domains as well as towards upstream providers, and it also
   strongly encourages the use of the 'no-export' BGP community to
   balance the provider-subscriber need for more granular routing
   information with the Internet's need for scalable inter-domain
   routing.

Internet-Drafts are available by anonymous FTP.  Login wih the username
'anonymous' and a password of your e-mail address.  After logging in,
type 'cd internet-drafts' and then
	'get draft-ietf-idr-aggregation-framework-01.txt'.
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-aggregation-framework-01.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: ds.internic.net
	
	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-aggregation-framework-01.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.

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-aggregation-framework-01.txt

--OtherAccess
Content-Type:	Message/External-body;
	name='draft-ietf-idr-aggregation-framework-01.txt';
	site='ds.internic.net';
	access-type='anon-ftp';
	directory='internet-drafts'
	
Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION: draft-ietf-idr-as-dedicated-00.txt
Date: Thu, 31 Jul 1997 09:56:44 -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		: Using a Dedicated AS for Sites Homed to a Single Provider
	Author(s)	: E. Chen and T. Bates and R. Chandra and John Stewart  III
	Filename	: draft-ietf-idr-as-dedicated-00.txt
	Pages		: 6
	Date		: 30-Jul-97
	
With the increased growth of the Internet, the number of customers
   using BGP4 has grown significantly. RFC1930 outlines a set of guide-
   lines for when one needs and should use an AS. However, the customer
   and service provider (ISP) are left with a problem as a result of
   this in that while there is no need for an allocated AS under the
   guidelines, certain conditions make the use of BGP4 a very pragmatic
   and perhaps only way to connect a customer homed to a single ISP.
   This paper proposes a solution to this problem in line with recommen-
   dations set forth in RFC1930.

Internet-Drafts are available by anonymous FTP.  Login wih the username
'anonymous' and a password of your e-mail address.  After logging in,
type 'cd internet-drafts' and then
	'get draft-ietf-idr-as-dedicated-00.txt'.
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-as-dedicated-00.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: ds.internic.net
	
	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-as-dedicated-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.

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-as-dedicated-00.txt

--OtherAccess
Content-Type:	Message/External-body;
	name='draft-ietf-idr-as-dedicated-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]
Date: Thu, 31 Jul 1997 23:58:06 -0700
To: [email-masked]
Subject: Free Link for your Web Site !
Sender: [email-masked]

OnLineNow recently visited your site and in recognition of it's
quality and uniqueness, we wanted to personally invite you to 
"Add Your Link, Free" to OnLineNow World Wide Directories.

Just go to: http://onlinenow.net/intro/html/add_your_link.htm
Fill out the form, selecting the category and city or country you
would like your link in, and then submit it. Your link will be added 
right then and there.

If you do not have a web page or you feel you recieved this invitation
by mistake, then your address was probably given to us as a referral on
our Guest Registration Page. You can however create yourself a Free
Web Page with OnlineNow.

In appreciation of a free Net!

OnLineNow World Wide
http://onlinenow.net

From: [email-masked] (H C Mahesh)
Subject: ORIGIN attribute values..
To: [email-masked]
Date: Fri, 1 Aug 1997 12:48:08 -0530 (IST)
Cc: [email-masked] (H C Mahesh)
Sender: [email-masked]

Hi,

  I was going through RFC1771 and in section 9.2.4.2, paragraph 5,
  it is mentioned that,

   ORIGIN attribute: If at least one route among routes that are
   aggregated has ORIGIN with the value INCOMPLETE, then the
   aggregated route must have the ORIGIN attribute with the value
   INCOMPLETE. Otherwise, if at least one route among routes that are
   aggregated has ORIGIN with the value EGP, then the aggregated
   route must have the origin attribute with the value EGP. In all
   other case the value of the ORIGIN attribute of the aggregated
   route is INTERNAL.
            ^^^^^^^^^
 I am under the impression that, ORIGIN attribute can have only
 IGP or EGP or Incomplete as value. But the last line in the above
 paragraph says, it can have the value as INTERNAL.

 Does is it mean ORIGIN attribute value to be set to IGP ?
 Could you please clarify this.

 Thanks,
 HCM.

From: [email-masked] (H C Mahesh)
Subject: MinASOriginationInterval..
To: [email-masked]
Date: Fri, 1 Aug 1997 21:27:05 -0530 (IST)
Sender: [email-masked]

Hi,

1)  Could you please explain the correct use of MinASOriginationInterval.

2)  In RFC1771, under section 9.2.3.2, Frequency of Route Origination
  is explained as:

  The parameter MinASOriginationInterval determines the minimum amount
  of time that must elapse between successive advertisements of UPDATE
  messages that report changes within the advertising BGP speaker's own
  autonomous systems.  ^^^^^^^

Now, let us consider this situation:
>From an AS1, a route (call it rt1) is advertised at time 't'.
Am I restricted from advertising rt2, before MinASOriginationInterval
elapses? 
(assume both rt1 and rt2 are originated in AS1)

Thanks,
HCM.

To: [email-masked] (H C Mahesh)
cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: MinASOriginationInterval.. 
Date: Fri, 01 Aug 1997 14:47:44 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, H C Mahesh writes:
> Hi,
> 
> 1)  Could you please explain the correct use of MinASOriginationInterval.
> 
> 2)  In RFC1771, under section 9.2.3.2, Frequency of Route Origination
>   is explained as:
> 
>   The parameter MinASOriginationInterval determines the minimum amount
>   of time that must elapse between successive advertisements of UPDATE
>   messages that report changes within the advertising BGP speaker's own
>   autonomous systems.  ^^^^^^^
> 
> Now, let us consider this situation:
> From an AS1, a route (call it rt1) is advertised at time 't'.
> Am I restricted from advertising rt2, before MinASOriginationInterval
> elapses? 
> (assume both rt1 and rt2 are originated in AS1)
> 
> 
> Thanks,
> HCM.

This is mearly intended to keep performance of your implementation and
the implementation within reasonable bounds.  In practice, BGP updates
can be and are sent as fast as they can be (by the better
implementations) with the exception that if any one prefix that has
changed is not readvertised too frequently.  Typically withdraws are
propogated quickly (5 seconds) and announcements are delayed (15-30
seconds) if they come shortly after a withdraw or shortly after
another announcement that is being changed.

If your implementation can't keep track of when individual prefixes
are announced then rate limit the updates as described.  Some
implementations accomplish this by doing a periodic routing table scan
and limiting the number of updates per scan.

Keep in mind that on the receiving end, the peer may do route flap
damping, so changing you mind a lot (advertising every little change
during a transient) would be a bad idea.

Also, expect writes to occasionally block on writes to the TCP sockets
used for BGP.  This is the other ends way of slowing down the sender.
You'll have to set the sockets to non-blocking write.  Whatever you do
DON'T allow the sessions to drop if the write fails due to blocking.
If you allow the TCP writes to block, your peer's timers can expire
while you wait for a blocked TCP write to clear (keep in mind that the
reader may be busy processing someone else's updates and IGP timers
tend to be shorter than BGP timers).

Curtis