Subject: BGP-IGP interaction
From: James Huang <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: James Huang <[email-masked]>
Date: Wed, 23 Dec 1998 15:30:24 -0800

Hi,
	Can anybody give me some pointers to the issue of BGP-IGP
interaction?
	For example, suppose a AS has two BGP routers (X, and Y) and one
internal non-BGP
	router (Z).   
                       
                            128.213.0.0/16         128.213.0.0/16 
                                    ^                           ^
                                    |                            |
 
------------------------------------------------------------------------
-----------  AS boundary
                                    |                            | 
                                    |                            | 
                                   X ----------  Z ---------- Y
                                                  |
                                                  |
                                                host H

	Suppose X sets the local preference for the route to
128.213.0.0/16 with a value of 300 and 
	Y sets the local preference for the route to 128.213.0.0/16 with
200.
	When host H sends a packet to 128.213.1.1, how does router Z
know that it should forward
	the packet to X instead of Y?
	
	If Z forwards the packet to Y (for example, the next hop of the
default route in Z is Y), is it 
	possible that Y may send the packet back to Z (since Y knows
that X is the better exit point) 
	and form a loop?
	 
		I look up RFC's like RFC 1403 and RFC 1745 that talk
about interaction betwen OSPF and BGP.
		But there seems to be no answer there.

James Huang
Scientist, Vertex Networks, Inc
Email: [email-masked]
Tel:    1-949-252-8880 ext 122

To: [email-masked]
Subject: WG Last Call
Date: Wed, 23 Dec 1998 05:37:53 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

We begin the WG Last Call on draft-ietf-idr-route-reflect-v2-00.txt
(advancing the document to a Proposed Standard).

The Last Call will end on Jan 10.

Yakov.
------- Forwarded Message

Date:    Tue, 22 Dec 1998 16:29:05 -0500
From:    [email-masked]
To:      IETF-Announce:;
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-idr-route-reflect-v2-00.txt

- --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 Reflection An alternative to full mesh IBGP
	Author(s)	: T. Bates, R. Chandra, E. Chen
	Filename	: draft-ietf-idr-route-reflect-v2-00.txt
	Pages		: 9
	Date		: 16-Dec-98
	
   The Border Gateway Protocol [1] is an inter-autonomous system routing
   protocol designed for TCP/IP internets. Currently in the Internet BGP
   deployments are configured such that that all BGP speakers within a
   single AS must be fully meshed so that any external routing
   information must be re-distributed to all other routers within that
   AS. This represents a serious scaling problem that has been  well
   documented with several alternatives proposed [2,3].
 
   This document describes the use and design of a method known as
   'Route Reflection' to alleviate the the need for 'full mesh' IBGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-route-reflect-v2-00.txt

Internet-Drafts are also 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-reflect-v2-00.txt".

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.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-reflect-v2-00.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-reflect-v2-00.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-route-reflect-v2-00.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: Bradley Reynolds <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: route-reflectors 
Date: Fri, 11 Dec 1998 21:42:16 -0500
From: Rohit Dube <[email-masked]>
Sender: [email-masked]

On Thu, 10 Dec 1998 22:23:31 +0000 (GMT) [email-masked] writes:
=>It would seem to me that some guidelines for setting up
=>RR clusters should be in order to prevent people
=>from configureing in such a fashion.  Instead of pointing
=>out how you can misconfigure, point out steps that
=>will ensure loop free configuration would be beneficial
=>
=>something to the effect of: the administrator should ensure
=>that the path between the rr and rrclient does not include speakers
=>listening to a seperate rr.  

Bradley,

You are right. The document should have a "this is what you should do"
slant besides pointing out the problems that one could get into if
not careful with reflectors.

Given the various comments on this list and others that I received at
IETF, it seems to me that there is place for a somewhat detailed 
"usage and precautions" informational document for Route-reflectors.  
To this effect John and I will be respinning the draft that we submitted 
as one such. I'll take this opportunity to request others on this list to 
contribute deployment scenarios (besides the common "POP" scheme) for 
inclusion.

Thanks,
--rohit.

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: route-reflectors 
Date: Fri, 11 Dec 1998 02:38:29 -0700
Sender: [email-masked]

> Perhaps my experience with RRs is limited, but I have had
> the habit of configuring them in places where the client
> group has only one exit back into the core/public network.  
> The resultant loc-rib on the clients == the loc-rib you
> would have derived from a full mesh.  

Or at most, *potential* suboptimal path selection. 

I believe the "impractical" examples in the draft were simply for ease of 
explanation purposes, to make the issues more visible.  Any real-world 
deployment configured in such a manner is unlikely, and, IMO, the comments in 
Section 9 of draft-ietf-idr-route-reflect-v2-00.txt should suffice.

-danny

Date: Thu, 10 Dec 1998 22:23:31 +0000 (GMT)
From: Bradley Reynolds <[email-masked]>
To: [email-masked]
Subject: route-reflectors 
Sender: [email-masked]

Per the presentation today about possible ways
to foul up route reflector configuration, I have
a few questions.

First, has anyone actually configured a network
(with paying customers) into the looping situation?

It would seem to me that some guidelines for setting up
RR clusters should be in order to prevent people
from configureing in such a fashion.  Instead of pointing
out how you can misconfigure, point out steps that
will ensure loop free configuration would be beneficial

something to the effect of: the administrator should ensure
that the path between the rr and rrclient does not include speakers
listening to a seperate rr.  

Perhaps my experience with RRs is limited, but I have had
the habit of configuring them in places where the client
group has only one exit back into the core/public network.  
The resultant loc-rib on the clients == the loc-rib you
would have derived from a full mesh.  

To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Subject: diff for draft-ietf-idr-route-reflect-v2-00.txt 
Date: Mon, 07 Dec 1998 18:01:19 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, folks:
Due to popular request, I am attaching the diff of the source
file for your review.  Thanks.  -- Enke

> Date:    Wed, 25 Nov 1998 11:35:02 -0800
> From:    Enke Chen <[email-masked]>
> To:      [email-masked]
> CC:      [email-masked], [email-masked], [email-masked]

> Hi, folks:
> A revised route reflection document has been submitted 
> as an Internet Draft. It may not got published on time
> as the submission missed the deadline. In the meantime,
> you can ftp the file draft-ietf-idr-route-reflect-v2-00.txt 
> from ftp-eng.cisco.com:enkechen/
> 
> Your comments and feedback are welcome.
> Thanks.
> 
> -- Enke
> 
> 

*** r-reflect.ms.bates	Mon Nov 16 14:43:11 1998
--- r-reflect.ms	Mon Dec  7 17:33:02 1998
***************
*** 63,69 ****
  Abstract
  
  The Border Gateway Protocol [1] is an inter-autonomous system routing protocol
! designed for TCP/IP internets. BGP deployments are configured
  such that that all BGP speakers within a single AS must be fully meshed
  so that any external routing information must be re-distributed to all other
  routers within that AS. This represents a serious scaling problem that has 
--- 65,72 ----
  Abstract
  
  The Border Gateway Protocol [1] is an inter-autonomous system routing protocol
! designed for TCP/IP internets. Currently in the Internet BGP deployments
! are configured
  such that that all BGP speakers within a single AS must be fully meshed
  so that any external routing information must be re-distributed to all other
  routers within that AS. This represents a serious scaling problem that has 
***************
*** 77,98 ****
  .ti 0
  1.  Introduction
  
! Currently in the Internet, BGP deployments are configured
! such that that all BGP speakers within a single AS must be fully meshed 
! and any external routing information must be re-distributed to all other
! routers within that AS. This "full mesh" requirement
! clearly does not scale when there are a large number of IBGP speakers 
! as is common in many of todays internet networks. 
! 
! For n BGP speakers within an AS you must maintain 
! n*(n-1)/2 unique IBGP sessions. With finite resources in both 
! bandwidth and router CPU this clearly does not scale.
  
  This scaling problem has been well documented and a number of proposals 
  have been made to alleviate this [2,3]. This document represents another 
  alternative in alleviating the need for a "full mesh" and is known as 
! "Route Reflection". It represents a change in the commonly understood concept
! of IBGP and the addition of two new optional transitive BGP attributes.  

  .ti 0
--- 80,102 ----
  .ti 0
  1.  Introduction
  
! Currently in the Internet, BGP deployments are configured such
! that that all BGP speakers within a single AS must be fully meshed
! and any external routing information must be re-distributed to all
! other routers within that AS.  For n BGP speakers within an AS that
! requires to maintain n*(n-1)/2 unique IBGP sessions.  This "full mesh"
! requirement clearly does not scale when there are a large number
! of IBGP speakers each exchanging a large volume of routing
! information, as is common in many of todays internet networks.
  
  This scaling problem has been well documented and a number of proposals 
  have been made to alleviate this [2,3]. This document represents another 
  alternative in alleviating the need for a "full mesh" and is known as 
! "Route Reflection". This approach allows a BGP speaker (known as "Route
! Reflector") to advertise IBGP learned routes to certain IBGP peers.
! It represents a change in the commonly understood concept of IBGP, and
! the addition of two new optional transitive BGP attributes to prevent
! loops in routing updates.

  .ti 0
***************
*** 105,113 ****
            Any alternative must be both simple to configure as well
            as understand.
  
!         o Easy Migration
  
!           It must be possible to migrate from a full mesh 
            configuration without the need to change either topology 
            or AS. This is an unfortunate management overhead of the 
            technique proposed in [3].
--- 109,117 ----
            Any alternative must be both simple to configure as well
            as understand.
  
!         o Easy Transition
  
!           It must be possible to transition from a full mesh 
            configuration without the need to change either topology 
            or AS. This is an unfortunate management overhead of the 
            technique proposed in [3].
***************
*** 122,128 ****
  experiences of a very large and topology rich network with many external
  connections.
  
- .bp
  .ti 0
  3.  Route Reflection
  
--- 126,131 ----
***************
*** 155,161 ****
  RTR-C (as IBGP speakers) will not re-advertise
  these IBGP learned routes to other IBGP speakers. 
  
! If this rule is relaxed and RTR-C is allowed to reflect IBGP learned routes, 
  then it could re-advertise (or reflect) the IBGP routes learned from 
  RTR-A to RTR-B and vice versa. This would eliminate the need for the 
  IBGP session between RTR-A and RTR-B as shown in Figure 2 below. 
--- 158,165 ----
  RTR-C (as IBGP speakers) will not re-advertise
  these IBGP learned routes to other IBGP speakers. 
  
! If this rule is relaxed and RTR-C is allowed to advertise IBGP learned
! routes to IBGP peers,
  then it could re-advertise (or reflect) the IBGP routes learned from 
  RTR-A to RTR-B and vice versa. This would eliminate the need for the 
  IBGP session between RTR-A and RTR-B as shown in Figure 2 below. 
***************
*** 183,201 ****
  .ti 0
  4.  Terminology and Concepts
  
! We use the term "Route Reflector" (RR) to represent an IBGP speaker that
! participates in the reflection. 
  The internal peers of a RR are divided into two groups:
  
          1) Client Peers
          
          2) Non-Client Peers
  
! A RR reflects routes between these groups. 
  A RR along with its client peers form a
  Cluster. The Non-Client peer must be fully meshed but the Client peers
! need not be fully meshed. The Client peers should not peer with internal
! speakers outside of their cluster. Figure 3 depicts a simple example outlining
  the basic RR components using the terminology noted above.
  .DS C
  / - - - - - - - - - - - - -  -\\\&
--- 187,209 ----
  .ti 0
  4.  Terminology and Concepts
  
! We use the term "Route Reflection" to describe the operation of
! a BGP speaker advertising an IBGP learned route to another IBGP
! peer.  Such a BGP speaker is said to be a "Route Reflector" (RR),
! and such a route is said to be a reflected route.
! 
  The internal peers of a RR are divided into two groups:
  
          1) Client Peers
          
          2) Non-Client Peers
  
! A RR reflects routes between these groups, and may reflect routes among
! client peers.
  A RR along with its client peers form a
  Cluster. The Non-Client peer must be fully meshed but the Client peers
! need not be fully meshed.
! Figure 3 depicts a simple example outlining
  the basic RR components using the terminology noted above.
  .DS C
  / - - - - - - - - - - - - -  -\\\&
***************
*** 229,254 ****
  .ti 0
  5. Operation
  
! When a route is received by a RR, it selects the best path based on
! its path selection rule. After the best path is selected, it must
  do the following depending on the type of the peer it is receiving the
  best path from:
  
!         1) A Route from a Non-Client peer
  
!            Reflect to all other Clients.
  
          2) A Route from a Client peer 
  
             Reflect to all the Non-Client peers and also to the 
!            Client peers other than the originator. (Hence the 
!            Client peers are not required to be fully meshed).
!  
!          3) Route from an EBGP peer
! 
!             Send to all the Client and Non-Client Peers.
! 
  
  An Autonomous System could have many RRs. A RR treats other RRs just
  like any other internal BGP speakers. A RR could be configured to have
  other RRs in a Client group or Non-client group. 
--- 237,258 ----
  .ti 0
  5. Operation
  
! When a RR receives a route from an IBGP peer, it selects the best path
! based on its path selection rule. After the best path is selected, it must
  do the following depending on the type of the peer it is receiving the
  best path from:
  
!         1) A Route from a Non-Client IBGP peer
  
!            Reflect to all the Clients.
  
          2) A Route from a Client peer 
  
             Reflect to all the Non-Client peers and also to the 
!            Client peers. (Hence the Client peers are not required
!            to be fully meshed.)
  
+  
  An Autonomous System could have many RRs. A RR treats other RRs just
  like any other internal BGP speakers. A RR could be configured to have
  other RRs in a Client group or Non-client group. 
***************
*** 260,266 ****
  Due to route reflection, all the IBGP speakers will receive 
  reflected routing information.
  
! It is normal in a Autonomous System to have BGP speakers that do not
  understand the concept of Route-Reflectors (let us call them
  conventional BGP speakers). The Route-Reflector Scheme allows such
  conventional BGP speakers to co-exist. Conventional BGP speakers could
--- 264,270 ----
  Due to route reflection, all the IBGP speakers will receive 
  reflected routing information.
  
! It is possible in a Autonomous System to have BGP speakers that do not
  understand the concept of Route-Reflectors (let us call them
  conventional BGP speakers). The Route-Reflector Scheme allows such
  conventional BGP speakers to co-exist. Conventional BGP speakers could
***************
*** 279,309 ****
  Usually a cluster of clients will have a single RR. In that case,
  the cluster will be identified by the ROUTER_ID of the RR. However,
  this represents a single point of failure so to make it possible to have 
! multiple RRs in the same cluster, all RRs in the same cluster must be 
! configured with a 4-byte CLUSTER_ID so that an RR can discern routes from 
  other RRs in the same cluster.

  .ti 0
  7.  Avoiding Routing Information Loops
  
! As IBGP learned routes are reflected, it is possible through 
  mis-configuration to form route re-distribution loops. The Route Reflection
  method defines the following attributes to detect and avoid routing
! information loops.
! 
  
  ORIGINATOR_ID 
  
  ORIGINATOR_ID is a new optional, non-transitive BGP
  attribute of Type code 9. 
  This attribute is 4 bytes long and it will be created by
! a RR. This attribute will carry the ROUTER_ID of the originator of
  the route in the local AS. A BGP speaker should not create an
  ORIGINATOR_ID attribute if one already exists.
! A route reflector must never send routing information back to the
! router specified in ORIGINATOR_ID.
! 
  
  CLUSTER_LIST
  
--- 283,312 ----
  Usually a cluster of clients will have a single RR. In that case,
  the cluster will be identified by the ROUTER_ID of the RR. However,
  this represents a single point of failure so to make it possible to have 
! multiple RRs in the same cluster, all RRs in the same cluster can be 
! configured with a 4-byte CLUSTER_ID so that an RR can discard routes from 
  other RRs in the same cluster.

  .ti 0
  7.  Avoiding Routing Information Loops
  
! When a route is relfected, it is possible through
  mis-configuration to form route re-distribution loops. The Route Reflection
  method defines the following attributes to detect and avoid routing
! information loops:
  
  ORIGINATOR_ID 
  
  ORIGINATOR_ID is a new optional, non-transitive BGP
  attribute of Type code 9. 
  This attribute is 4 bytes long and it will be created by
! a RR in reflecting a route.
! This attribute will carry the ROUTER_ID of the originator of
  the route in the local AS. A BGP speaker should not create an
  ORIGINATOR_ID attribute if one already exists.
! A router should ignore a route recieved with its ROUTER_ID as the 
! ORIGINATOR_ID.
  
  CLUSTER_LIST
  
***************
*** 320,407 ****
  .DE
  Where Length is the number of octets.
  
! When a RR reflects a route from its Clients to a Non-Client
! peer, it must append the local CLUSTER_ID to the CLUSTER_LIST. If
! the CLUSTER_LIST is empty, it must create a new one. Using this
  attribute an RR can identify if the routing information is looped
  back to the same cluster due to mis-configuration. If the local 
! CLUSTER_ID is found in the cluster-list, the advertisement will be ignored.

- .bp
  .ti 0
! 8.  Implementation and Configuration Considerations
  
  Care should be taken to make sure that none of the BGP path
  attributes defined above can be modified 
  through configuration when exchanging internal routing information between 
! RRs and Clients and Non-Clients. This could result is looping of routes.  
  
! In some implementations, modification of the BGP path attribute, NEXT_HOP 
! is possible. For example,
! there could be a need for a RR to modify NEXT_HOP for EBGP
! learned routes sent to its internal peers. However, it must not 
! be possible for an RR to set on reflected IBGP routes as this breaks the 
! basic principle of Route Reflection and will result in potential black
! holeing of traffic.
! 
! An RR should not modify any AS-PATH attributes (i.e. LOCAL_PREF, MED,
! DPA)that could change consistent route selection. This could result
! in potential loops.
  
  The BGP protocol provides no way for a Client to identify itself dynamically
! as a Client to an RR configured BGP speaker
! and the simplest way to achieve this is by manual configuration.

  .ti 0
! 9.  Security
  
  Security considerations are not discussed in this memo.

  .ti 0
! 10. Acknowledgments
  
  The authors would 
! like to thank Dennis Ferguson, Enke Chen, John Scudder, Paul Traina 
! and Tony Li 
  for the many discussions resulting in this work. This idea was
  developed from an earlier discussion between Tony Li and Dimitri Haskin.

  .ti 0
! 11. References
  
  .IP [1]
  Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", RFC1771, March 1995.
  .IP [2] 
  Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh routing", RFC1863, October 1995.
  .IP [3]
! Traina, P. "Limited Autonomous System Confederations for BGP", INTERNET-DRAFT,
! <draft-traina-bgp-confed-00.txt>, April 1995.
  
  .bp
  .ti 0
! 12. Author's Addresses
  
  .nf
  Tony Bates
! MCI
! 2100 Reston Parkway
! Reston, VA 22091
  
! phone: +1 703 715 7521
! email: [email-masked]

  Ravishanker Chandrasekeran
  (Ravi Chandra)
! cisco Systems
  170 West Tasman Drive
  San Jose, CA 95134 
  
  email: [email-masked]
  
  .fi
  \"  LocalWords:  Chandra FORMFEED BGP ietf idr txt MCI Ravi cisco IBGP IP ASX
--- 323,465 ----
  .DE
  Where Length is the number of octets.
  
! 
! When a RR reflects a route, it must append the local CLUSTER_ID to the
! CLUSTER_LIST.
! If the CLUSTER_LIST is empty, it must create a new one. Using this
  attribute an RR can identify if the routing information is looped
  back to the same cluster due to mis-configuration. If the local 
! CLUSTER_ID is found in the cluster-list, the advertisement received
! will be ignored.

  .ti 0
! 8. Implementation Considerations
  
  Care should be taken to make sure that none of the BGP path
  attributes defined above can be modified 
  through configuration when exchanging internal routing information between 
! RRs and Clients and Non-Clients. Their modification could potential result
! in routing loops.
! 
! In addition, when a RR reflects a route, it should not modify the following
! path attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED. Their modification
! could potential result in routing loops.
  
! 
! .ti 0
! 9. Configuration and Deployment Considerations
  
  The BGP protocol provides no way for a Client to identify itself dynamically
! as a Client of an RR.  The simplest way to achieve this is by manual
! configuration.
! 
! One of the key component of the route reflection approach in
! addressing the scaling issue is that the RR summarizes routing
! information and only reflects its best path.
! 
! Both MEDs and IGP metrics may impact the BGP route selection.
! Because MEDs are not always comparable and the IGP metric may differ
! for each router, with certain route reflection topologies the
! route reflection approach may not yield the same route selection
! result as that of the full IBGP mesh approach. 
! A way to make route selection the same as it would be with the
! full IBGP mesh approach is to make sure that route reflectors
! are never forced to perform the BGP route selection based on
! IGP metrics which are significantly different from the IGP 
! metrics of their clients, or based on imcomparable MEDs. 
! The former can be achieved by configuring the intra-cluster IGP
! metrics to be better than the inter-cluster IGP metrics, and
! maintaining full mesh within the cluster. 
! The latter can be achieved by:
! 
!        o setting the local preference of a route at the border router
!          to reflect the MED values.
! 
!        o or by making sure the AS-path lengths from different ASs are
!          different when the AS-path length is used as a route
!          selection criteria.
! 
!        o or by configuring community based policies using which the
!          reflector can decide on the best route.
! 
! One could argue though that the latter requirement is overly restrictive,
! and perhaps impractical in some cases.  One could further argue that as
! long as there are no routing loops, there are no compelling reasons to
! force route selection with route reflectors to be the same as it would
! be with the full IBGP mesh approach.
! 
! To prevent routing loops and maintain cosistent routing view, it is
! essential that the network topology be carefully considered in
! designing a route reflection topology. In general, the route
! reflection topology should congruent with the network topology when
! there exist multiple paths for a prefix. One commonly used approach
! is the POP-based reflection, in which each POP maintains its own
! route reflectors serving clients in the POP, and all route reflectors
! are fully meshed. In addition, clients of the reflectors in each POP are
! often fully meshed for the purpose of optimal intra-POP routing, and
! the intra-POP IGP metrics are configured to be better than the
! inter-POP IGP metrics.

  .ti 0
! 10.  Security
  
  Security considerations are not discussed in this memo.

  .ti 0
! 11. Acknowledgments
  
  The authors would 
! like to thank Dennis Ferguson, John Scudder, Paul Traina and Tony Li 
  for the many discussions resulting in this work. This idea was
  developed from an earlier discussion between Tony Li and Dimitri Haskin.
  
+ In addition, the authors would like to acknowledge valuable review and
+ suggestions from Yakov Rekhter on this document, and helpful comments
+ from Tony Li, Rohit Dube, and John Scudder on Section 9. 
+ 
  
  .ti 0
! 12. References
  
  .IP [1]
  Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", RFC1771, March 1995.
  .IP [2] 
  Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh routing", RFC1863, October 1995.
  .IP [3]
! Traina, P. "Limited Autonomous System Confederations for BGP", RFC1965,
! June 1996.
  
  .bp
  .ti 0
! 13. Author's Addresses
  
  .nf
  Tony Bates
! Cisco Systems
! 170 West Tasman Drive
  
! email: [email-masked]

  Ravishanker Chandrasekeran
  (Ravi Chandra)
! Cisco Systems
  170 West Tasman Drive
  San Jose, CA 95134 
  
  email: [email-masked]
+ 
+ 
+ Enke Chen
+ Cisco Systems
+ 170 West Tasman Drive
+ San Jose, CA 95134
+ 
+ email: [email-masked]
+ 
  
  .fi
  \"  LocalWords:  Chandra FORMFEED BGP ietf idr txt MCI Ravi cisco IBGP IP ASX