Subject: Fwd: WG Last Call: new BGP spec

From: Alex Zinin <[email-masked]>
Date: Fri, 15 Nov 2002 14:01:18 -0800

Folks-

 This one is quite important. Reviews by the end of
 the WG last call would be _greatly_ appreciated.

 Thanks.

-- 
Alex

This is a forwarded message
From: Yakov Rekhter <[email-masked]>
To: [email-masked]
Cc: 
Date: Tuesday, November 05, 2002, 5:21:11 PM
Subject: WG Last Call

===8<==============Original message text===============
Folks,

This is to start the WG Last Call on draft-ietf-idr-bgp4-18.txt.
The Last Call ends Nov 29.

Yakov.
------- Forwarded Message

Date:    Tue, 05 Nov 2002 06:08:56 -0500
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-18.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           : A Border Gateway Protocol 4 (BGP-4)
        Author(s)       : Y. Rekhter et al.
        Filename        : draft-ietf-idr-bgp4-18.txt
        Pages           : 81
        Date            : 2002-11-4
        
The Border Gateway Protocol (BGP) is an inter-Autonomous System rout-
ing protocol.
The primary function of a BGP speaking system is to exchange network
reachability information with other BGP systems. This network reacha-
bility information includes information on the list of Autonomous
Systems (ASs) that reachability information traverses.  This informa-
tion is sufficient to construct a graph of AS connectivity from which
routing loops may be pruned and some policy decisions at the AS level
may be enforced.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-18.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-bgp4-18.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-bgp4-18.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-bgp4-18.txt

- --OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-idr-bgp4-18.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

===8<===========End of original message text===========

---

From: Alex Zinin <[email-masked]>
Date: Wed, 27 Nov 2002 01:33:58 -0500

Guys-

 The LC ends this coming Fri.
 I've only gotten comments from Mark (thanks!).
 Please try to find some time to review this
 document. It is _really_ important. If you could
 engage developers from your companies, this would
 also be very useful.

 Thanks.

-- 
Alex

---

From: David Meyer <[email-masked]>
Date: Wed, 27 Nov 2002 11:26:35 -0800

Alex/All,

	A few comments 

	(i).	I agree with the concern voiced on the IDR list
		by Tom Petch (and possibly others), namely, that
		it appears that the FSM specification is
		inconsistent when describing the action that
		places a value in a MIB object when a
		NOTIFICATION is sent.  

	(ii).	It might be useful for section 3 to describe the
		relationship between the various (conceptual)
		RIBs (Adj-RIB-In, Adj-RIB-Out, and Loc-RIB) and
		what we are currently calling a FIB. This,
		however, is not critical to the protocol
		specification. 

	(iii).	Page 23, 3rd paragraph says "The sender of an
		UPDATE message should order ..."

		Is this "should" a "SHOULD" (in the RFC 2119
		sense)? Likewise section 5.1.2 (AS_PATH), section
		a): "the advertising speaker shall not
		modifiy..."

		Actually, there seems to be a lot of use of the
		terms "shall" and "shall not" which are not
		capitalized, so it is unclear what the exact
		meaning is. "may" is also used in the same way. 

	(iv).	I know that we don't want to perturb the spec too
		much, but maybe the whole of the BTSH stuff could
		fix in an appendix (somewhat like Appendix E or
		F) of this document? I don't feel strongly about
		this, just wondering what people think.

	Dave

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 29 Nov 2002 20:39:03 -0500

Dave,

> 		this, just wondering what people think.

IMO, it wont hurt.  However, we're trying to document what *is* 
implemented.  For that reason, I don't think it will make it into
the current effort.

It would be nice though. :-)

-- 
Jeff Haas 
NextHop Technologies

---

From: Alex Zinin <[email-masked]>
Date: Fri, 29 Nov 2002 23:08:52 -0800

David,

  Thanks a lot.
  
  I will proxy your comments to the list
  excluding (iv), because, as Jeff said,
  we're documenting what is already implemented.

-- 
Alex