headers
Internet-Drafts | 1 May 2002 13:26
Picon
Favicon

I-D ACTION:draft-ietf-idr-aspath-orf-02.txt

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		: Aspath Based Outbound Route Filter for BGP-4
	Author(s)	: K. Patel, S. Hares
	Filename	: draft-ietf-idr-aspath-orf-02.txt
	Pages		: 
	Date		: 30-Apr-02
	
This document defines a new Outbound Router Filter type for BGP,
termed 'Aspath Outbound Route Filter', that can be used to perform 
aspath based route filtering. This ORF-type supports aspath based 
route filtering as well as regular expression based matching, for 
address groups.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-aspath-orf-02.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-aspath-orf-02.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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Fenner | 1 May 2002 19:21
Picon

Re: Last call on Graceful Restart


A couple of comments on the Graceful Restart draft.

The biggest problem is that the first two paragraphs of section 6
are contradictory: The first says that you may only advertise
graceful restart if you can preserve forwarding state; the second
says to advertise it anyway.  I think changing the first sentence
to start "A BGP speaker should advertise..." and removing the word
"only" gets rid of the contradiction.

RFC2842bis says that the document defining a capability needs to say
what happens if multiple instances of the capability are advertised
with different values; persumably this can happen in section 5.

The document uses the RFC2119 key words without defining them; however it
uses them a total of twice, at the beginning of section 6; the document
has other places where it may want to use these requirements
terms in order to make the meaning clear.  I see two options:
- Reference 2119 and sweep through the document converting the pieces
  that are required for the protocol to 2119-ese.
- Change the MUST and SHOULD NOT in section 6 to lowercase, to avoid
  confusion

Section 5's reference for AFI shouldn't be to the obsolete rfc 1700
(see RFC 3232); in this case the reference should be to
http://www.iana.org/assignments/address-family-numbers .  It should
also have a reference to http://www.iana.org/assignments/safi-namespace
for the SAFI numbers.

The references to 2283 and 2842 could be updated to 2858 and 2842bis.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Shane Wright | 1 May 2002 20:50

Re: Last call on Graceful Restart


On Wed, May 01, 2002 at 10:21:35AM -0700, Bill Fenner wrote:
> 
> A couple of comments on the Graceful Restart draft.
> 
> The biggest problem is that the first two paragraphs of section 6
> are contradictory: The first says that you may only advertise
> graceful restart if you can preserve forwarding state; the second
> says to advertise it anyway.  I think changing the first sentence
> to start "A BGP speaker should advertise..." and removing the word
> "only" gets rid of the contradiction.

Hi Bill,

What the document is trying to say in the second paragraph is that the
graceful restart capability can be sent with no address families in the case
where you want to only send End-of-RIB messages.  Advertising the capability
with an address family implies that you are able to gracefully restart for
that family.  

- Shane Wright
Permalink | Reply | 0 comments |
headers
Enke Chen | 1 May 2002 20:56

Re: Last call on Graceful Restart

Hi, Bill:
Thanks for your comments. We will take care of them and submit a
version.

-- Enke

> From: Bill Fenner <fenner <at> research.att.com>
> Received: (from fenner <at> localhost)
> 	by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA03963;
> 	Wed, 1 May 2002 10:21:36 -0700 (PDT)
> Message-Id: <200205011721.KAA03963 <at> windsor.research.att.com>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> To: idr <at> merit.edu
> Subject: Re: Last call on Graceful Restart
> Date: Wed, 1 May 2002 10:21:35 -0700
> Versions: dmail (solaris) 2.4/makemail 2.9b
> Sender: owner-idr <at> merit.edu
> Precedence: bulk
> 
> 
> A couple of comments on the Graceful Restart draft.
> 
> The biggest problem is that the first two paragraphs of section 6
> are contradictory: The first says that you may only advertise
> graceful restart if you can preserve forwarding state; the second
> says to advertise it anyway.  I think changing the first sentence
> to start "A BGP speaker should advertise..." and removing the word
> "only" gets rid of the contradiction.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Susan Hares | 3 May 2002 01:17

Re: BGP-4 MIBv2 NLRI Table

Ken:

Why do you expect the Prefix before the prefix length?

sue

At 01:29 PM 4/22/2002 -0400, Ken Benstead wrote:
>Hi Folks,
>I noticed that the NLRI Table in the BGP4 MIBv2 (draft 2) has the
>following index clause:
>
>       INDEX {
>             bgpM2PeerIndex,
>             bgpM2NlriAfi,
>             bgpM2NlriSafi,
>             bgpM2NlriPrefixLen,
>             bgpM2NlriPrefix,
>             bgpM2NlriIndex
>             }
>
>Is there a reason that the bgpM2NlriPrefixLen and bgpM2NlriPrefix
>objects are the opposite order to what one might normally expect?
>For example, in the BGP-4 Received Path Attribute Table of
>RFC1657 the index clause is:
>
>
>       INDEX {
>             bgp4PathAttrIpAddrPrefix,
>             bgp4PathAttrIpAddrPrefixLen,
>             bgp4PathAttrPeer
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alex Zinin | 3 May 2002 05:18

Re: Last call on Graceful Restart

Please find some comments on the restart draft below.
Regards.

-- 
Alex

Meta-comments:

 - Can the restart capability be dynamically updated?

 - How does this doc address the situation where the admin wants
   the graceful restart to happen for planned restarts
   (during SW upgrades, etc.) but not for unplanned ones?

>                    Graceful Restart Mechanism for BGP
> 
>                      draft-ietf-idr-restart-03.txt
...
> 4. Marker for End-of-RIB
> 
>    An UPDATE message with empty withdrawn NLRI is specified as the End-
>    Of-RIB Marker that can be used by a BGP speaker to indicate to its
>    peer the completion of the initial routing update after the session
>    is established. For IPv4 unicast address family, the End-Of-RIB
>    Marker is an UPDATE message with the minimum length [BGP-4].

I guess this implicitly means that no reachable NLRIs and attributes
should be in it. Why not say this explicitly?

> For any
(Continue reading)

Permalink | Reply | 503 comments |
headers
Internet-Drafts | 3 May 2002 13:28
Picon
Favicon

I-D ACTION:draft-ietf-idr-as4bytes-05.txt

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 support for four-octet AS number space
	Author(s)	: Q. Vohra, E. Chen
	Filename	: draft-ietf-idr-as4bytes-05.txt
	Pages		: 7
	Date		: 02-May-02
	
Currently the Autonomous System number is encoded in BGP [BGP] as a
two-octets field. This document describes extensions to BGP to carry
the Autonomous System number as a four-octets field.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-05.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-as4bytes-05.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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 3 May 2002 13:28
Picon
Favicon

I-D ACTION:draft-ietf-idr-route-filter-06.txt

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		: Cooperative Route Filtering Capability for BGP-4
	Author(s)	: E. Chen, Y. Rekhter
	Filename	: draft-ietf-idr-route-filter-06.txt
	Pages		: 11
	Date		: 02-May-02
	
This document defines a BGP-based mechanism that allows a BGP speaker
to send to its BGP peer a set of route filters that the peer would
use to constrain/filter its outbound routing updates to the speaker.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-06.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-route-filter-06.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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yakov Rekhter | 3 May 2002 16:03
Favicon

draft-ietf-idr-as4bytes-05.txt

Folks,

The only changes are (a) version number increment, (b) updates dates.

Yakov.
------- Forwarded Message

Date:    Fri, 03 May 2002 07:28:33 -0400
From:    Internet-Drafts <at> ietf.org
To:      IETF-Announce: ;
cc:      idr <at> merit.edu
Subject: I-D ACTION:draft-ietf-idr-as4bytes-05.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 support for four-octet AS number space
	Author(s)	: Q. Vohra, E. Chen
	Filename	: draft-ietf-idr-as4bytes-05.txt
	Pages		: 7
	Date		: 02-May-02
	
Currently the Autonomous System number is encoded in BGP [BGP] as a
two-octets field. This document describes extensions to BGP to carry
the Autonomous System number as a four-octets field.

A URL for this Internet-Draft is:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeffrey Haas | 3 May 2002 16:37

Last Call concerns (again): Extended Communities

I've been asked to bring these concerns to the list again one last time.
If no one else has the conerns, I'm happy to yield on the issue.

The base BGP communities specification deals with aggregation by saying:

: Aggregation
: 
:    If a range of routes is to be aggregated and the resultant aggregates
:    attribute section does not carry the ATOMIC_AGGREGATE attribute, then
:    the resulting aggregate should have a COMMUNITIES path attribute
:    which contains all communities from all of the aggregated routes.

As we all know, ATOMIC_AGGREGATE isn't well defined enough to actually
do enough useful things, and isn't implemented by most of the major
distributions.

As a result, BGP communities simply end up aggregated as a union of
the elements in the community sets.

(This is another gripe with the base spec - communities are treated as
a set and thus no duplicates are needed, and implementations seem
to prune duplicates, but this isn't spelled out anywhere.)

The problem with synthesizing aggregates is that if aggregate component
R1 has some communities C1, and we have an R2, C2 that is another
contributing component, the resulting aggregate A1 will have the
union of C1 and C2.  Some elements of C1 or C2 may not be applicable
towards the various components of A1.  Taking the intersection would
have been saner IMO.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane