Subject: draft-ietf-idr-bgp-confed-00.txt to experimental
From: Yakov Rekhter <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Sun, 31 Mar 96 06:29:31 PST

Folks,

At the last WG meeting we discussed  draft-ietf-idr-bgp-confed-00.txt
and agreed to ask the IESG to publish it as an Experimental RFC. This
is the WG last call on this document. If there will be no objections
within 2 weeks (4/14/96), I'll send a note to the IESG asking the IESG
to advance the Internet Draft to an Experimental RFC.

Yakov.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp-confed-00.txt
Date: Fri, 29 Mar 96 09:02:27 -0500
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     : Autonomous System Confederations for BGP                
       Author(s) : P. Traina
       Filename  : draft-ietf-idr-bgp-confed-00.txt
       Pages     : 7
       Date      : 03/28/1996

Border Gateway Protocol [1] is an inter-autonomous system routing protocol 
designed for TCP/IP networks.               
                               
This document describes an extension to BGP which may be used to create a 
confederation of autonomous systems which is represented as one single 
autonomous system to BGP peers external to the confederation.  
            
The intention of this extension is to aid in policy administration and 
reduce the management complexity of maintaining a large autonomous system.
 
The extension this document describes is widely deployed 
in the Internet today.                                                                     

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-bgp-confed-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp-confed-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-bgp-confed-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-bgp-confed-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-idr-bgp-confed-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: Sun, 24 Mar 1996 19:14:34 -0500 (EST)
To: [email-masked]
Subject: Curtis's Route Damping Document
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

It's located at 

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

Sue Hares

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-mib-02.txt
Date: Mon, 18 Mar 96 15:48:30 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

A Revised 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.                                                         

Note: This revision reflects comments received during the last call period.

       Title     : Definitions of Managed Objects for the Fourth Version of
                   Border Gateway Protocol (BGP-4)                         
       Author(s) : S. Willis, J. Burruss, J. Chu, J. Johnson
       Filename  : draft-ietf-idr-bgp4-mib-02.txt
       Pages     : 17
       Date      : 03/15/1996

This memo is an extension to the SNMP MIB.  It specifies an IAB standards 
track protocol for the Internet community, and requests discussion and 
suggestions for improvements.  The origin of this memo is from RFC 1269 
"Definitions of Managed Objects for the Board Gateway Protocol (Version 3)"
written by the first two authors of this memo, which was updated to support
BGP-4 in RFC 1657.  This memo fixes errors introduced when the MIB was 
converted to use the SNMPv2 SMI, as well as updates references to the Draft
Standard SNMPv2 SMI documents.    
                                  
Distribution of this memo is unlimited.  Please forward comments to 
[email-masked].                                                               

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-bgp4-mib-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-mib-02.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-bgp4-mib-02.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-bgp4-mib-02.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-idr-bgp4-mib-02.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], [email-masked]
Subject: Re: Version 2 of working group notes 
From: Tony Bates <[email-masked]>
Date: Mon, 18 Mar 1996 09:09:04 -0500
Sender: [email-masked]
Reply-To: [email-masked]

Here are a few minor corrections.

 [email-masked] writes:
  * 
  * I've included the comments I've received.  Please review
  * these notes.  If I don't hear anything by 3/21/96, the notes
  * will be considered correct.   Please note ">" indicates a
  * line that was changed.
  * 
  * 			Sue Hares
  * 
....
stuff deleted
....

  * =======
  * 
  * >	Consensus has been reached by all parties and will be put out as
  * >	draft-ietf-idr-bgp-dpa-06.txt.   After the document
  * >	to the working and Internet Drafts this document will be
  * >	moved to Proposed Standard.  
  *
This in fact turned out to be 05 as I was able to get to the
Internet-drafts folks in time.
 
  * >	The associated documents:  
  * >	 draft-ietf-idr-dpa-application-02.txt
  * >	 draft-ietf-idr-symm-multi-prov-02.txt 
  * >
  * >	will be moved to informational RFCs.
  * >
  * >
  * >		draft-ietf-idr-community-usage.txt
  *
This should be  draft-ietf-idr-community-usage-00.txt

		Thanks,
			--Tony

To: [email-masked]
Subject: Re: Version 2 of working group notes 
Date: Fri, 15 Mar 1996 06:43:42 -0800
From: Paul Traina <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

thanks.

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Version 2 of working group notes 
Date: Fri, 15 Mar 1996 08:38:14 -0500
From: Susan Hares <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

Paul:

I am making the following correction to the notes:

  6) BGP Confederations
  
  	draft-traina-bgp-confed-00.txt
  
  	It was moved that is be moved to experimental.
  	Cisco has implemented this approach and deployed
	it in networks.

I apologize for the comments in the earlier notes regarding
this specification.

	In deployment Cisco discovered some problems with
  	this approach.
 
This comment was attempt to record in the notes the discussion you gave at the
meeting.  It was not an evaluation or an attempt of an evaluation
on your fine work on confederations.  Thank-you for your corrections.

Sue Hares

Date: Thu, 14 Mar 1996 23:08:25 -0500
From: [email-masked] (Yung-Chao Yu)
To: [email-masked]
Subject: Re: Version 2 of working group notes
Sender: [email-masked]
Reply-To: [email-masked]

Sue, in last NANOG, you said you know where to get doc which defines
route flapping. Can you pass it to me? Thanks.

Yung Yu
AT&T

From: "Jeffrey T. Johnson" <[email-masked]>
Subject: Re: Version 2 of working group notes
To: [email-masked]
Date: Thu, 14 Mar 1996 14:18:02 -0800 (PST)
Cc: [email-masked], [email-masked]
Content-Length: 269       
Sender: [email-masked]
Reply-To: [email-masked]

[email-masked] sez:
>1) BGP-4 MIB (draft-ietf-bgp-mibv4-06.txt)

actually, draft-ietf-idr-bgp4-mib-01.txt is the current draft, although
i just submitted draft-ietf-idr-bgp4-mib-02.txt for publication.

draft-ietf-bgp-mibv4-06.txt was the predecessor to RFC 1657

/jeff

From: [email-masked]
Date: Thu, 14 Mar 1996 16:57:31 -0500 (EST)
To: [email-masked]
Subject: Version 2 of working group notes
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

I've included the comments I've received.  Please review
these notes.  If I don't hear anything by 3/21/96, the notes
will be considered correct.   Please note ">" indicates a
line that was changed.

			Sue Hares

=======

BGP Working Group   

Date: 3/5/96 time 3:30pm -5:30pm PST 
(note taker: Susan Hares)
(version 2: changes have > in front of line)

1) BGP-4 MIB (draft-ietf-bgp-mibv4-06.txt)

	Jeff Johnson (Cisco), the latest editor,
	of the BGP-4 MIB document will make the
	few minor editorial changes given by the list. 

	The working group needs to forward two
	reports of those using the BGP-4 MIB.
	Cisco and GateD have BGP-4 mibs.

	Someone from Cisco, and Sue Hares from
	Merit will forward experience reports to
	Yakov to send to the IESG.  At this point
	the BGP-4 MIB will be forwarded to
	Draft Standard.

	MIB entries for newer attributes (Destination Preference Attribute,
	BGP communities, and Conferations) will go in a separate
	document. 

2) IDRP for IPv[46] (draft-ietf-idr-idrp-v4v6-02.txt)

	Yakov will produce a complete IDRP specification
	based on the the difference document and the 
	IDRP specification.  Anyone wishing to comment
	on features in BGP-4 or the features in the
	existing document should send mail to the
	mailing list or Yakov Rekhter.

3) Confederation  (Ramesh Govindan) (draft-ietf-idr-rdc-config-00.txt) 

	One problem with IDRP confederations is that
	every BGP speaker must know what confederations it
	belongs to.  This amount of configuration guarantees
	that the correct processing of confederations even if
	individual nodes are mis-configured.  If instead you,
	configure 
		- only the border routers AND
		- if there is ambiquity, assume nesting

	You may be able to limit configuration amounts. 
	
	This proposal had some discussion from the floor and
	will continued to be discussed on the mailing list.

4) Destination Preference Attribute (DPA)

>	(draft-ietf-idr-bgp-dpa-05.txt
>	 draft-ietf-idr-dpa-application-02.txt
	 draft-ietf-idr-symm-multi-prov-02.txt)

	The processing of the the DPA value is currently
	included in the route policy calculation as:

	Multi-Exit-Discriminator (MED)  - 1st
	Destination Preference Attribute (DPA) - 2nd 

>	Consensus has been reached by all parties and will be put out as
>	draft-ietf-idr-bgp-dpa-06.txt.   After the document
>	to the working and Internet Drafts this document will be
>	moved to Proposed Standard.  

>	The associated documents:  
>	 draft-ietf-idr-dpa-application-02.txt
>	 draft-ietf-idr-symm-multi-prov-02.txt 
>
>	will be moved to informational RFCs.
>
>
>  New text for this decision in the DPA document is:
>	
>  A router may use DPA to influence LOCAL_PREF computation. DPA shall
>  not directly affect route selection.
> 
>  DPA influence of the LOCAL_PREF attribute computation is a local
>  matter. In general a route with a higher DPA indicates a higher
>  preference by the originator of the DPA attribute.	

5) BGP communities
	
	The BGP community specification has been release for
	over a year. It has been implemented
	by Bay networks and Cisco.  It is suggested that
	Yakov make the last call, and move it to proposed standard. 
>	(document was at: draft-chandra-bgp-communities-00.txt
>	 will be at: draft-ietf-idr-bgp-communities-00.txt)	

	Tony Bates and Enke Chen has released a draft
	on the usage of communities.  Enke Chen made a presentation
	of this feature at the NANOG meeting in February 1996.
>	This document is currently listed as:
>		draft-ietf-idr-community-usage.txt

6) BGP Confederations

	draft-trainia-bgp-confed-00.txt

	It was moved that is be moved to experimental.
	In deployment Cisco discovered some problems with
	this approach.

7) Route Reflection

	draft-ietf-idr-route-reflect-00.txt
	
	Cisco has implemented the route reflection a year ago.
	MCI has used this in it's network for a year.
	(Has Bay implemented this?) 	
	 
	The working group recommends that this move forward to 
	experimental.  A work item for the group is to
	decide which solution to the IBGP mesh problem will
	be selected by the group: the Route Reflection 
	or the Route Server (Dimitry Haskins) or a cobmination
	of both. 

Fun quotes:

	"You forced this @#* MIB down my throat."
	"Standards don't matter if the code is running 
	 in all the routers"  

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-rfc-config-00.txt
Date: Thu, 14 Mar 96 10:29:29 -0500
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     : Configuring IDRP Confederations                         
       Author(s) : R. Govindan
       Filename  : draft-ietf-idr-rfc-config-00.txt
       Pages     : 5
       Date      : 03/13/1996

In the Inter-Domain Routing Protocol (IDRP), all border routers (border 
intermediate systems (BISs) in ISO terminology) of a routing domain 
confederation (RDC) must be configured with the identity of all RDCs that 
overlap or enclose that RDC. This draft describes some minor modifications 
to IDRP specification that removes this requirement.                       

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-rfc-config-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-rfc-config-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-rfc-config-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-rfc-config-00.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-community-usage-00.txt
Date: Thu, 14 Mar 96 09:43:32 -0500
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     : An Application of the BGP Community Attribute in 
                   Multi-home Routing                                      
       Author(s) : E. Chen, T. Bates
       Filename  : draft-ietf-idr-community-usage-00.txt
       Pages     : 10
       Date      : 03/13/1996

This document presents an application of the BGP community attribute [2] in
simplifying the implementation and configuration of routing policies in the
multi-provider Internet. It shows how the community based configuration can
be used to replace the AS-based customization of the BGP "LOCAL_PREF" 
attribute, a common method used today.  Not only does the technique 
presented simplifies configuration and management at the provider level, it
also represents a paradigm shift in that it gives the potential for the 
customer to control its own routing policy with respect to its service 
provider, as well as providing the ability for policy configuration to be 
done at a prefix based granularity rather than the more common AS based 
granularity.                                                               

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-community-usage-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-community-usage-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-community-usage-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-community-usage-00.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp-dpa-05.txt
Date: Thu, 14 Mar 96 09:43:11 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

A Revised 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     : Destination Preference Attribute for BGP                
       Author(s) : E. Chen, T. Bates
       Filename  : draft-ietf-idr-bgp-dpa-05.txt
       Pages     : 4
       Date      : 03/13/1996

The Border Gateway Protocol [1] is an inter-autonomous system routing 
protocol designed for TCP/IP internets.   
                                 
This document describes a new BGP path attribute termed "Destination 
Preference Attribute" (DPA) which can be used by a single autonomous system
(AS) to specify globally transitive metrics in its routing announcement via
BGP.  The metric can then be used by upstream BGP speakers to favor certain
path for return traffic.  The application of this attribute includes 
facilitating the implementation of symmetric routing and load sharing in 
the multi-provider Internet.                                               

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-bgp-dpa-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp-dpa-05.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-bgp-dpa-05.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
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-route-reflect-00.txt
Date: Thu, 14 Mar 96 09:43:25 -0500
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     : BGP Route Reflection  
                   An alternative to full mesh IBGP  
       Author(s) : T. Bates, R. Chandra
       Filename  : draft-ietf-idr-route-reflect-00.txt
       Pages     : 8
       Date      : 03/13/1996

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 
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.                

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-reflect-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-route-reflect-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-route-reflect-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"

--OtherAcceserAccess"

--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-bgp-dpa-05.txt

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

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

--OtherAccess--

--NextPart--

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

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

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

--OtherAccess--

--NextPart--

Date: Sat, 9 Mar 1996 10:52:20 -0800
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: load-sharing/load-balancing 2 T1s (fwd)
Sender: [email-masked]
Reply-To: [email-masked]

	Why does BGP pick only one route when it has several options? 

     90% historical reasons.

   I don't consider those reasons historical.  There's no practical way, with
   the currently specified BGP-4 to carry the kind of information you need to
   even make equal-cost path determinations,  much less unequal-cost load
   sharing.  However, that's really not necessary.  

Agreed.  It is the AS path problem that was the historical reason.

Tony

To: [email-masked]
Subject: Re: load-sharing/load-balancing 2 T1s (fwd) 
Date: Sat, 09 Mar 1996 10:22:01 -0800
From: Paul Traina <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

  From: Tony Li <[email-masked]>
  Subject: Re: load-sharing/load-balancing 2 T1s (fwd)
  
     Why does BGP pick only one route when it has several options? 
  
  90% historical reasons.

I don't consider those reasons historical.  There's no practical way, with
the currently specified BGP-4 to carry the kind of information you need to
even make equal-cost path determinations,  much less unequal-cost load
sharing.  However, that's really not necessary.  That sort of determination
is a local matter between two ASs,  so it's reasonable (not pretty, but
reasonable) to run an IGP instance to cover those local pipes and have
your IGP route you across the DMZ and take care of the load sharing.

  In the general case, it was very difficult with BGP3 to select multiple
  paths and not lie about the AS path.  Such lies have the obvious bad
  consequence.  ;-(
  
  More sophisticated behavior is obviously possible.   But requires more CPU
  cycles.  ;-)

Among other things.

For what it's worth, Yakov and I have already discussed this heavily and
we have something up or sleeves for making this work well in the general
case,  however it will require a non-standard protocol extension and is
still in the whiteboard stage.

[The rest of this note is inappropriate for the mailing list in general,
 however since it's good for the protocol as a whole...sorry]

Should cisco customers be interested in seeing time allocated to this
activity,  please contact your sales or marketing representatives and
tell them that this is important to you.  Remember,  development time is
not an infinite resource.  As with all features if we do this, we don't
do something else,  which means that there has to be customer support for
such work to continue.

Date: Sat, 9 Mar 1996 09:40:46 -0800
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: load-sharing/load-balancing 2 T1s (fwd)
Sender: [email-masked]
Reply-To: [email-masked]

   Why does BGP pick only one route when it has several options? 

90% historical reasons.

In the general case, it was very difficult with BGP3 to select multiple
paths and not lie about the AS path.  Such lies have the obvious bad
consequence.  ;-(

More sophisticated behavior is obviously possible.   But requires more CPU
cycles.  ;-)

Tony

To: [email-masked]
Subject: Re: load-sharing/load-balancing 2 T1s (fwd) 
Date: Fri, 08 Mar 1996 11:51:16 -0800
From: Ravi Chandra <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

> > > Subject: Re: load-sharing/load-balancing 2 T1s
> > > 
> > > Yes, as I sit looking at our DS-3 and our now somewhat useless DS-1's (tr
y
> > > load balancing across links that differ in size by a factor of 30), I sit
> > > here and wish that there was an Exterior Gateway Protocol of some sort th
at
> > > did costing of links like OSPF does, but, Alas, there isn't.  Anyone want
 to
> > > implement one? :)
> > > 
> > > At 03:09 PM 3/7/96 -0500, you wrote:
> > > >This becomes an issue just a tad more complicated than 'tweaking the
> > > >routing'.  :-)
> > > >
> > > >You will, of course, have to run BGP if you are not already doing so.
> > > >Insofar as BGP does not 'do' load-balancing, it becomes an exercise for
> > > >the reader to figure out how to manually direct specific portions of
> > > >internal traffic in a distributed fashion across multiple external gatew
ays.
> > > >
> > > >- paul
> > 
> > 
> > 	A cry from the community!
> > 
> > 
> > -- 
> > --bill
> 
> Yes, let me second the cry. Why does BGP pick only one route when
> it has several options? Load spliting would be a valuable tool.

FYI: cisco is investigating about installing multiple routes under
certain circumstance for load spliting ..

--ravi

> 
> Erik

To: [email-masked]
Subject: Re: load-sharing/load-balancing 2 T1s (fwd) 
Date: Fri, 08 Mar 1996 10:57:14 -0800
From: Paul Traina <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

Noted,  we're planning to include some support for load-balancing in
limited situations in IDRP-2.  However, this load balancing scenario that
you mention is clearly a "local matter" and as such, should be solved with
the tools that best handle this kind of situation.

Run a common IGP between loopback interfaces in your border routers and
open the peering from one loopback to the other.  This won't tell you when
your DS3 goes down, but it doesn't sound like you care.

Paul

  From: [email-masked]
  Subject: Re: load-sharing/load-balancing 2 T1s (fwd)
  > Subject: Re: load-sharing/load-balancing 2 T1s
  > 
  > Yes, as I sit looking at our DS-3 and our now somewhat useless DS-1's (try
  > load balancing across links that differ in size by a factor of 30), I sit
  > here and wish that there was an Exterior Gateway Protocol of some sort that
  > did costing of links like OSPF does, but, Alas, there isn't.  Anyone want t
>>o
  > implement one? :)
  > 
  > At 03:09 PM 3/7/96 -0500, you wrote:
  > >This becomes an issue just a tad more complicated than 'tweaking the
  > >routing'.  :-)
  > >
  > >You will, of course, have to run BGP if you are not already doing so.
  > >Insofar as BGP does not 'do' load-balancing, it becomes an exercise for
  > >the reader to figure out how to manually direct specific portions of
  > >internal traffic in a distributed fashion across multiple external gateway
>>s.
  > >
  > >- paul

  	A cry from the community!

  -- 
  --bill

To: [email-masked]
Subject: Re: load-sharing/load-balancing 2 T1s (fwd) 
Date: Fri, 08 Mar 1996 11:25:05 -0500
From: Erik Sherk <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

> > Subject: Re: load-sharing/load-balancing 2 T1s
> > 
> > Yes, as I sit looking at our DS-3 and our now somewhat useless DS-1's (try
> > load balancing across links that differ in size by a factor of 30), I sit
> > here and wish that there was an Exterior Gateway Protocol of some sort that
> > did costing of links like OSPF does, but, Alas, there isn't.  Anyone want to
> > implement one? :)
> > 
> > At 03:09 PM 3/7/96 -0500, you wrote:
> > >This becomes an issue just a tad more complicated than 'tweaking the
> > >routing'.  :-)
> > >
> > >You will, of course, have to run BGP if you are not already doing so.
> > >Insofar as BGP does not 'do' load-balancing, it becomes an exercise for
> > >the reader to figure out how to manually direct specific portions of
> > >internal traffic in a distributed fashion across multiple external gateways.
> > >
> > >- paul
> 
> 
> 	A cry from the community!
> 
> 
> -- 
> --bill

Yes, let me second the cry. Why does BGP pick only one route when
it has several options? Load spliting would be a valuable tool.

Erik

From: [email-masked]
Posted-Date: Fri, 8 Mar 1996 07:26:05 -0800 (PST)
Subject: Re: load-sharing/load-balancing 2 T1s (fwd)
To: [email-masked]
Date: Fri, 8 Mar 1996 07:26:05 -0800 (PST)
Content-Length: 874       
Sender: [email-masked]
Reply-To: [email-masked]

> Subject: Re: load-sharing/load-balancing 2 T1s
> 
> Yes, as I sit looking at our DS-3 and our now somewhat useless DS-1's (try
> load balancing across links that differ in size by a factor of 30), I sit
> here and wish that there was an Exterior Gateway Protocol of some sort that
> did costing of links like OSPF does, but, Alas, there isn't.  Anyone want to
> implement one? :)
> 
> At 03:09 PM 3/7/96 -0500, you wrote:
> >This becomes an issue just a tad more complicated than 'tweaking the
> >routing'.  :-)
> >
> >You will, of course, have to run BGP if you are not already doing so.
> >Insofar as BGP does not 'do' load-balancing, it becomes an exercise for
> >the reader to figure out how to manually direct specific portions of
> >internal traffic in a distributed fashion across multiple external gateways.
> >
> >- paul

	A cry from the community!

-- 
--bill

From: David Whipple <[email-masked]>
To: "[email-masked]"@microsoft.com, [email-masked], [email-masked]
Date: Fri,  8 Mar 96 11:16:53 PST
Subject: Re: load-sharing/load-balancing 2 T1s (fwd) 
Sender: [email-masked]
Reply-To: [email-masked]

Can I third that cry...
----------
From: Erik Sherk  <[email-masked]>
To:  <"[email-masked]">;  <[email-masked]>
Subject: Re: load-sharing/load-balancing 2 T1s (fwd)
Date: Friday, March 08, 1996 8:25AM

> > Subject: Re: load-sharing/load-balancing 2 T1s
> >
> > Yes, as I sit looking at our DS-3 and our now somewhat useless DS-1's
(try
> > load balancing across links that differ in size by a factor of 30), I
sit
> > here and wish that there was an Exterior Gateway Protocol of some sort
that
> > did costing of links like OSPF does, but, Alas, there isn't.  Anyone
want to
> > implement one? :)
> >
> > At 03:09 PM 3/7/96 -0500, you wrote:
> > >This becomes an issue just a tad more complicated than 'tweaking the
> > >routing'.  :-)
> > >
> > >You will, of course, have to run BGP if you are not already doing so.
> > >Insofar as BGP does not 'do' load-balancing, it becomes an exercise for
> > >the reader to figure out how to manually direct specific portions of
> > >internal traffic in a distributed fashion across multiple external
gateways.
> > >
> > >- paul
>
>
> 	A cry from the community!
>
>
> --
> --bill

Yes, let me second the cry. Why does BGP pick only one route when
it has several options? Load spliting would be a valuable tool.

Erik

Subject: Apologies....
To: [email-masked]
Date: Thu, 7 Mar 1996 03:25:18 +0000 (GMT)
Content-Length: 85        
From: Michael Behringer <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

Apologies for the mail I just sent. This was not meant to go to the 
list.

Michael

Subject: Checking MCI -> DANTE routing
To: [email-masked]
Date: Thu, 7 Mar 1996 03:05:33 +0000 (GMT)
Cc: [email-masked] (DANTE Network Management Centre)
Content-Length: 571       
From: Michael Behringer <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

Tony,

Just to folow up on our discussion and to sum up all the details:

There are special preferences set in MCI to route traffic to DANTE on other
than shortest path routes. Could you please check if you have preferences
set for ASes in as-dante? I know about DFN's ASes, but am not sure about 
others. Just want to be sure. 

Second thing, could you please forward the aggregation tool from Bjorn
to nmc? (The one you use for doing the routing table analysis). We can then 
write a little script to feed in the actual routing table. 

Thanks for your help,

Michael

To: [email-masked]
Subject: Re: Notes from 3/5/96 working group meeting 
Date: Wed, 06 Mar 1996 15:35:41 -0800
From: Paul Traina <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

  From: [email-masked] (Howard C.  Berkowitz)
  Subject: Re: Notes from 3/5/96 working group meeting
  >
  >
  >Fun quotes:
  >
  >        "You forced this @#* MIB down my throat."
  >        "Standards don't matter if the code is running
  >         in all the routers"
  
  You missed,
  
           "What's wrong with making it an experimental RFC?  The Internet is
  experimental."

:-)

To: [email-masked]
Subject: Re: Notes from 3/5/96 working group meeting 
Date: Wed, 06 Mar 1996 15:24:03 -0800
From: Paul Traina <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

  > 6) BGP Confederations
  > 
  > 	draft-trainia-bgp-confed-00.txt
  > 
  > 	It was moved that is be moved to experimental.

  > 	In deployment Cisco discovered some problems with
  > 	this approach.

This is an utterly incorrect summary.  All of the "problems" with this
approach were documented fully in the draft itself before-hand.  The only
protocol problem is the requirement of upgrading the entire-AS to confed-
capable routers before deploying confederations.  There is nothing wrong
with this approach.

Date: Wed, 6 Mar 1996 13:51:41 -0800
To: [email-masked]
From: [email-masked] (Howard C.  Berkowitz)
Subject: Re: Notes from 3/5/96 working group meeting
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

>
>
>Fun quotes:
>
>        "You forced this @#* MIB down my throat."
>        "Standards don't matter if the code is running
>         in all the routers"

You missed,

         "What's wrong with making it an experimental RFC?  The Internet is
experimental."

To: [email-masked]
Subject: Re: Notes from 3/5/96 working group meeting 
Date: Wed, 06 Mar 1996 14:00:29 -0500
From: Erik Sherk <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

> 6) BGP Confederations
> 
> 	draft-trainia-bgp-confed-00.txt
> 
> 	It was moved that is be moved to experimental.
> 	In deployment Cisco discovered some problems with
> 	this approach.
> 
> 7) Route Reflection
> 
> 	draft-bates-route-reflect-00.txt
> 	
> 	Cisco has implemented the route reflection a year ago.
> 	MCI has used this in it's network for a year.
> 	(Has Bay implemented this?) 	
> 	 
> 	The working group recommends that this move forward to 
> 	experimental.  A work item for the group is to
> 	decide which solution to the IBGP mesh problem will
> 	be selected by the group: the Route Reflection 
> 	or the Route Server (Dimitry Haskins) or a cobmination
> 	of both. 

Hi,
	I'm sorry that I wasn't at the meeting, but I would like to
add my 2 cents worth.
	
	As someone who has deployed both route reflectors and
confederations (on seperate networks) I would say that a combination
of both is need if we are to scale to truly large networks.

	RRs work really well when you have a lot of hierarchy in your
network and confeds work well when you a mesh. Since most large networks
will have a combination of these, we will need to deply both.

Erik

To: [email-masked]
Cc: [email-masked]
Subject: Re: Notes from 3/5/96 working group meeting 
From: Tony Bates <[email-masked]>
Date: Wed, 06 Mar 1996 11:51:54 -0500
Sender: [email-masked]
Reply-To: [email-masked]

Sue,
	some comments.

 [email-masked] writes:
  * BGP Working Group   
  * 
  * Date: 3/5/96 time 3:30pm -5:30pm PST
  * (note taker: Susan Hares)
  * 
  * 
  * 4) Destination Preference Attribute (DPA)
  * 
  * 	(draft-ietf-idr-bgp-dpa-05.txt
  * 	 draft-ietf-idr-dpa-application-02.txt
  * 	 draft-ietf-idr-symm-multi-prov-02.txt)
  * 
  * 	The processing of the the DPA value is currently
  * 	included in the route policy calculation as:
  * 
  * 	Multi-Exit-Discriminator (MED)  - 1st
  * 	Destination Preference Attribute (DPA) - 2nd 
  * 	 
  * 	Cisco and RsD implement the preference in that
  * 	way.  Discussions will continue offline and a
  * 	new internet draft will capture joint agreement of
  * 	current authors and implementors.  Watch your mailing
  * 	list for an announcement of this document.   
  *
Consensus has been reached ;-). Document should be coming as soon as
the internet-draft announcement makes it out of cnri. Here's the
changed piece of text regarding route selction....

   A router may use DPA to influence LOCAL_PREF computation. DPA shall
   not directly affect route selection.
 
   DPA influence of the LOCAL_PREF attribute computation is a local
   matter. In general a route with a higher DPA indicates a higher
   preference by the originator of the DPA attribute.
....

Also, other bits for the minutes. It was agreed that once the change
to the document was made to move dpa to PS and the two associated
documents to Informational.
 
  * 5) BGP communities
  * 	
  * 	-draft-chandra-bgp-communities-00.txt
  * 
  * 	The BGP community specification has been release for
  * 	over a year. It has been implemented
  * 	by Bay networks and Cisco.  It is suggested that
  * 	Yakov make the last call, and move it to proposed standard. 
  * 
  * 
  * 	Tony Bates and Enke Chen has released a draft
  * 	on the usage of communities.  Enke Chen made a presentation
  * 	of this feature at the NANOG meeting in February 1996.
  * 	[draft-bgp-communities-00.txt)
  * 	(The editor needs the draft name of the document.)
  *
It is known as 

	draft-chen-community-usage-00.txt
	
As noted in the meeting this will be changed to an idr document and then
published as informational. The idr document has already been sent to
the internet-drafts folks.

  * 6) BGP Confederations
  * 
  * 	draft-trainia-bgp-confed-00.txt
  * 
  * 	It was moved that is be moved to experimental.
  * 	In deployment Cisco discovered some problems with
  * 	this approach.
  * 
  * 7) Route Reflection
  * 
  * 	draft-bates-route-reflect-00.txt
  * 	
  * 	Cisco has implemented the route reflection a year ago.
  * 	MCI has used this in it's network for a year.
  * 	(Has Bay implemented this?) 	
  *
Also it has to be turned into an idr document which I've also snet in.
 	 
  * 	The working group recommends that this move forward to 
  * 	experimental.  A work item for the group is to
  * 	decide which solution to the IBGP mesh problem will
  * 	be selected by the group: the Route Reflection 
  * 	or the Route Server (Dimitry Haskins) or a cobmination
  * 	of both. 
  * 
  * 
	--Tony.

From: [email-masked]
Date: Wed, 6 Mar 1996 10:32:29 -0500 (EST)
To: [email-masked]
Subject: Notes from 3/5/96 working group meeting
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

BGP Working Group   

Date: 3/5/96 time 3:30pm -5:30pm PST
(note taker: Susan Hares)

1) BGP-4 MIB (draft-ietf-bgp-mibv4-06.txt)

	Jeff Johnson (Cisco), the latest editor,
	of the BGP-4 MIB document will make the
	few minor editorial changes given by the list. 

	The working group needs to forward two
	reports of those using the BGP-4 MIB.
	Cisco and GateD have BGP-4 mibs.

	Someone from Cisco, and Sue Hares from
	Merit will forward experience reports to
	Yakov to send to the IESG.  At this point
	the BGP-4 MIB will be forwarded to
	Draft Standard.

	MIB entries for newer attributes (Destination Preference Attribute,
	BGP communities, and Conferations) will go in a separate
	document. 

2) IDRP for IPv[46] (draft-ietf-idr-idrp-v4v6-02.txt)

	Yakov will produce a complete IDRP specification
	based on the the difference document and the 
	IDRP specification.  Anyone wishing to comment
	on features in BGP-4 or the features in the
	existing document should send mail to the
	mailing list or Yakov Rekhter.

3) Confederation  (Ramesh Govindan) (draft-ietf-idr-idr-config-00.txt) 

	One problem with IDRP confederations is that
	every BGP speaker must know what confederations it
	belongs to.  This amount of configuration guarantees
	that the correct processing of confederations even if
	individual nodes are mis-configured.  If instead you,
	configure 
		- only the border routers AND
		- if there is ambiquity, assume nesting

	You may be able to limit configuration amounts. 
	
	This proposal had some discussion from the floor and
	will continued to be discussed on the mailing list.

4) Destination Preference Attribute (DPA)

	(draft-ietf-idr-bgp-dpa-05.txt
	 draft-ietf-idr-dpa-application-02.txt
	 draft-ietf-idr-symm-multi-prov-02.txt)

	The processing of the the DPA value is currently
	included in the route policy calculation as:

	Multi-Exit-Discriminator (MED)  - 1st
	Destination Preference Attribute (DPA) - 2nd 
	 
	Cisco and RsD implement the preference in that
	way.  Discussions will continue offline and a
	new internet draft will capture joint agreement of
	current authors and implementors.  Watch your mailing
	list for an announcement of this document.   

5) BGP communities
	
	-draft-chandra-bgp-communities-00.txt

	The BGP community specification has been release for
	over a year. It has been implemented
	by Bay networks and Cisco.  It is suggested that
	Yakov make the last call, and move it to proposed standard. 

	Tony Bates and Enke Chen has released a draft
	on the usage of communities.  Enke Chen made a presentation
	of this feature at the NANOG meeting in February 1996.
	[draft-bgp-communities-00.txt)
	(The editor needs the draft name of the document.)

6) BGP Confederations

	draft-trainia-bgp-confed-00.txt

	It was moved that is be moved to experimental.
	In deployment Cisco discovered some problems with
	this approach.

7) Route Reflection

	draft-bates-route-reflect-00.txt
	
	Cisco has implemented the route reflection a year ago.
	MCI has used this in it's network for a year.
	(Has Bay implemented this?) 	
	 
	The working group recommends that this move forward to 
	experimental.  A work item for the group is to
	decide which solution to the IBGP mesh problem will
	be selected by the group: the Route Reflection 
	or the Route Server (Dimitry Haskins) or a cobmination
	of both. 

Fun quotes:

	"You forced this @#* MIB down my throat."
	"Standards don't matter if the code is running 
	 in all the routers"  

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Question 
Date: Wed, 06 Mar 1996 10:14:29 -0500
From: Enke Chen <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

Hi, Hwang: 
I do no think that these questions are appropriate for the 
BGP mailing list. Please allow me to make two suggestions: 

(1) Work with your provider to resolve operational problems. 
(2) If you are multi-homed to more than one provider, BGP
    is the protocol to use. 

-- Enke

> Date:    Wed, 6 Mar 1996 13:49:06 +0900
> From:    Hwang Hyojung <[email-masked]>
> To:      [email-masked]
> CC:      [email-masked], [email-masked], [email-masked],
	   [email-masked], [email-masked], [email-masked],
	   [email-masked], [email-masked]

> 
> Thanks. That makes me know one more about RADB.
> 
> Then, 
> 
> Network X can receive routing information of one area of AS200 and one 
> area of AS100. 
>  
> With default routing to AS200, it can reach only one area of AS100 of which 
> routing information is received. 
> Even other sites in AS100 except that one area of AS100, it can reach through
 
> AS200. Is it right ? 
> 
> If it is right, it is very ineffiecient, isn't it ? 
> Any other method ? 
> 
> -- Jung

Date: Wed, 6 Mar 1996 13:49:06 +0900
From: Hwang Hyojung <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Question
Sender: [email-masked]
Reply-To: [email-masked]

Thanks. That makes me know one more about RADB.

Then, 

Network X can receive routing information of one area of AS200 and one 
area of AS100. 
 
With default routing to AS200, it can reach only one area of AS100 of which 
routing information is received. 
Even other sites in AS100 except that one area of AS100, it can reach through 
AS200. Is it right ? 

If it is right, it is very ineffiecient, isn't it ? 
Any other method ? 

-- Jung

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Question 
Date: Tue, 05 Mar 1996 09:16:58 -0500
From: Enke Chen <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

> Date:    Tue, 5 Mar 1996 11:16:38 +0900
> From:    Hwang Hyojung <[email-masked]>
> To:      [email-masked]
> CC:      [email-masked], [email-masked], [email-masked],
	   [email-masked], [email-masked], [email-masked]

> 
> Hi, 
> I am a engineer of KT, Korea Telcom. My name is Hwang, Hyojung and e-mail is
> [email-masked]. 
> I have a question on Routing Architecture as follows.
> 
> For example, 
> A network X which belongs to AS100 is about to connected to AS200 not with  
> BGP but with OSPF.
> Then, Network X belongs to AS100 and AS200.
> Basically AS200 accepts network X only and network X is one area of AS200. 
> 
> Is it possible that network X beloings to AS100 and AS200, that is 
> they have 2 entries in RADB with origin AS100 and AS200 ? 

The answer is "yes". The unique key for a route object is <route, origin>.  

-- Enke

> 
> If not, Is there any method that network X is connected to AS200 with OSPF 20
0 
> and network X belongs to AS100 ?
> 
> This situation is as following :
> 
>                 |-- AS100         ----|
>     AS200  ----- network X ----- AS100
> 
>     Network X belongs to AS100, that is its origin is AS100. 
>     Network X is about to be routed with AS200 with OSPF 200. 
> 
> If you have any idea and any peices of advices, let me know it.
> 
> Jung, 
> 
>  

Date: Tue, 5 Mar 1996 11:16:38 +0900
From: Hwang Hyojung <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Question 
Sender: [email-masked]
Reply-To: [email-masked]

Hi, 
I am a engineer of KT, Korea Telcom. My name is Hwang, Hyojung and e-mail is
[email-masked]. 
I have a question on Routing Architecture as follows.

For example, 
A network X which belongs to AS100 is about to connected to AS200 not with  
BGP but with OSPF.
Then, Network X belongs to AS100 and AS200.
Basically AS200 accepts network X only and network X is one area of AS200. 

Is it possible that network X beloings to AS100 and AS200, that is 
they have 2 entries in RADB with origin AS100 and AS200 ? 

If not, Is there any method that network X is connected to AS200 with OSPF 200 
and network X belongs to AS100 ?

This situation is as following :

                |-- AS100         ----|
    AS200  ----- network X ----- AS100

    Network X belongs to AS100, that is its origin is AS100. 
    Network X is about to be routed with AS200 with OSPF 200. 

If you have any idea and any peices of advices, let me know it.

Jung,