Subject: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt

From: Yakov Rekhter <[email-masked]>
Date: Fri, 16 Apr 2004 14:21:13 -0700

Folks,

During the Last Call it would be greatly appreciated if folks would
read the document and comment on it to the IDR mailing list. In
other words, we need "yes, looks good" or "should fix this and
that", not just silence.

Thanks in advance.

Yakov.
------- Forwarded Message

Date:    Wed, 14 Apr 2004 13:36:09 -0700
From:    Yakov Rekhter <[email-masked]>
To:      [email-masked]
Subject: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt

Folks,

This is to start the IDR WG Last Call on advancing 
draft-ietf-idr-rfc2796bis-00.txt to Draft Standard. 

The Last Call ends April 28.

Yakov.
- ------- Forwarded Message

Date:    Wed, 14 Apr 2004 15:33:52 -0400
From:    [email-masked]
To:      [email-masked]
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-idr-rfc2796bis-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 IB
GP
	Author(s)	: T. Bates, et al.
	Filename	: draft-ietf-idr-rfc2796bis-00.txt
	Pages		: 11
	Date		: 2004-4-14
	
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-rfc2796bis-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the mess
age.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-rfc2796bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-rfc2796bis-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-rfc2796bis-00.txt

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

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

- - --OtherAccess--

- - --NextPart--

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce

- ------- End of Forwarded Message

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

------- End of Forwarded Message

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Pekka Savola <[email-masked]>
Date: Thu, 22 Apr 2004 12:44:26 +0300 (EEST)

> other words, we need "yes, looks good" or "should fix this and

In general, I think this should be rather close to being ready for 
going forward.

A few quick comments:

 - the text could use a lot more updates, but is readable as it is.
 
 - where are the implementation & interop reports?

 - several ID-nits or other process issues must be fixed, at least:
  o Status of this memo, Abstract, etc. must be unnumbered sections 
    (typically Introduction is section number 1)
  o No references in the abstract.
  o One cannot have normative references to documents of lower 
    maturity level.  I suggest moving everything except [1] (or 
    maybe also [7]) to a new Informational References section.
  o The document should probably say (in Abstract and Introduction) 
    that this document Obsoletes both 2796 and 1966 (note 2796 only 
    Updates 1966, which was probably a bug.)?
  o Standard IPR statement is needed at the end even if there is is no 
    IPR.  The date in the copyright statement is 4 years old as well..
  o every empty line in this memo is duplicated (due to flawed 
    DOS/WINDOWS -> Unix conversion?)

 - food for thought: should we kill two birds in one stone, and also 
   declare RFC1863 ("A BGP/IDRP Route Server alternative to a full 
   mesh routing") historic?  Is that useful anymore?

 - A few rewordings I spotted (I grew bored with the text soon after 
   the abstract, as there would have been a lot of changes):

                                         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.
                                                                                
==> s/Currently in the Internet BGP deployments are configured such 
that that/Typically/ (the same in the Introduction)
                                                                                
   information, as is common in many of todays internet networks.
                                                                                
==> s/todays internet/today's Internet/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Thu, 22 Apr 2004 12:44:26 +0300 (EEST)

A few quick comments:

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 27 Apr 2004 08:10:41 -0700

Pekka,

>  - where are the implementation & interop reports?

Enke is working on it (see his e-mail to the IDR mailing list on 4/14/2004).

>     (typically Introduction is section number 1)

ok.

>   o No references in the abstract.

ok.

>     maybe also [7]) to a new Informational References section.

Correct - [1] should go into the Normative Reference section, the
rest should go into the Non-normative Reference section.

>     Updates 1966, which was probably a bug.)?

Ok.

>     IPR.  The date in the copyright statement is 4 years old as well..

ok.

>     DOS/WINDOWS -> Unix conversion?)

ok.

>    mesh routing") historic?  Is that useful anymore?

This is a good question. May I suggest you'll bring it up to the
IDR mailing list after we'll finish the WG Last Call on this document
(as it deserves discussion on its own).

   
   
> ==> s/todays internet/today's Internet/

Sure.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 27 Apr 2004 08:10:41 -0700

Pekka,

ok.

ok.

Ok.

ok.

ok.

   

Sure.

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 29 Apr 2004 22:40:18 -0400

Additional nits:
>    Their modification could potential result in routing loops.

s/potential/potentially/

In the changes, also note that you corrected transitive to
non-transitive in the introduction.

I think ROUTER_ID should be consistently substituted with "BGP Identifier"
per the current use in draft-ietf-idr-bgp4-23

   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,

s/is looped/has looped/

Original text:
   If the BGP Identifiers of two paths are equal when compared in the
   route selection, then the path with the shorter CLUSTER_LIST length

Suggested change:
   The BGP Decision Process Tie Breaking rules (Section 9.1.2.2 of the
   BGP specification) is modified by inserting the following rule 
   between f and g:

   The BGP Speaker SHOULD prefer all routes with the shorter
   CLUSTER_LIST length.  If no CLUSTER_LIST path attribute is present,
   the CLUSTER_LIST length is zero.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 29 Apr 2004 22:40:18 -0400

s/potential/potentially/

s/is looped/has looped/

Original text:

Suggested change:

-- 
Jeff Haas 
NextHop Technologies

---

From: Enke Chen <[email-masked]>
Date: Fri, 30 Apr 2004 10:43:36 -0700

Hi, Jeff:

> From: Jeffrey Haas <[email-masked]>
> To: Yakov Rekhter <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt
> Message-ID: <[email-masked]>
> References: <[email-masked]>
> 
> Additional nits:

Ok.

Ok.

>    the CLUSTER_LIST length is zero.

will revise the text along these lines.

Thanks.  -- Enke

---

From: Enke Chen <[email-masked]>
Date: Fri, 30 Apr 2004 10:43:36 -0700

Ok.

Ok.

Thanks.  -- Enke