Re: bgp18 WG Last Call fsm peer oscillation dampiing

[Yakov Rekhter <[e-mail]>]

Tom,

> There is an action in the FSM relating to damping persistent peer
> oscillation which is referred to in several different ways (I give a
> list
> below).
> 
> I believe we should have one consistent phrase everywhere; I suggest
>    - [optionally] performs peer oscillation damping

Accepted.

> as the action (drop the BGP as that is evident from the context and
> drop the persistent as that makes the phrase overlong) with a similar
> phrase in the description in Events 6 and
> 8.  (Currently these last refer to flap which I find particularly
> misleading as this could be a reference to the mechanism of RFC2439).
> 
> And I do not believe there should be a reference, at least in the
> actions listed in the FSM - [2] appears in several places and I
> suspect is/was a reference to
> "BGP Peer Restart Backoff Mechanisms", S. Hares
> draft-skh-bgp-backoff-00.txt

You are correct - references to [2] will be removed.

Yakov.

> (And of course, any reference anywhere in the document needs to be
> handled with care because of the need for normative references to be
> Full Standard when this is to be Full Standard with the implications
> that has for implementation reports).
> 
> List of oscillation references follows
> 
>        Event6: Automatic start with bgp_stop_flap option set
> 
>   persistent peer oscillation damping
>   damping persistent peer oscillations
>   damping persistent BGP adjacency flapping
>   damping persistent BGP peer flapping.
> 
>        Event8:  Idle hold timer expires
> 
>   persistent BGP oscillation damping functions
>   persistent BGP peer oscillation damping functions
> 
> 
>       Idle
>              - persistent BGP peer oscillation
> 
>       Connect State:
>              - [optionally] performs bgp peer oscillation damping
> 
>       Active State:
> 
>              - perform the BGP peer oscillation damping process [2].
> 
>              - optionally performs BGP peer oscillation damping,
> 
>       Open Sent:
> 
>               - bgp peer oscillation damping process,
> 
>               - performs any BGP peer oscillation damp process
> 
>               - BGP peer oscillation process [2],
> 
>               - process any bgp peer oscillation damping[2],
> 
>       Open Confirm State:
> 
>               - runs the BGP peer oscillation damping process [2]
> 
>               - performs any BGP peer oscillation damping process [2].
> 
>               - and performs any BGP peer oscillation damping, and
> 
>               - performs any BGP peer oscillation damping, and
> 
>               - performs any BGP peer oscillation damping,
> 
>        Established state.
> 
>               - performs any BGP peer oscillation damping, and
> 
>               - performs any BGP peer oscillation damping,
> 
>               - and performs any BGP peer oscillation damping,
> 
>               - performs any BGP peer oscillation damping, and
> 
> Tom Petch
> [e-mail]
> 
> 
> 



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA17417 for <[e-mail]>; Sat, 30 Nov 2002 20:37:45 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 9DBD291242; Sat, 30 Nov 2002 20:37:18 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B6BE91241; Sat, 30 Nov 2002 20:37:18 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD10F91242 for <[e-mail]>; Sat, 30 Nov 2002 20:37:16 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 90B185DE37; Sat, 30 Nov 2002 20:37:16 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id F22EC5DE1E for <[e-mail]>; Sat, 30 Nov 2002 20:37:15 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gB11bDS76509; Sat, 30 Nov 2002 17:37:13 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Tom Petch" <[e-mail]>
Cc: "idr" <[e-mail]>
Subject: Re: bgp18 WG Last Call fsm peer oscillation dampiing 
In-Reply-To: Your message of "Thu, 28 Nov 2002 15:25:47 GMT." <001401c29706$cd28db40$0301a8c0@tom3> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sat, 30 Nov 2002 17:37:13 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Tom,

> There is an action in the FSM relating to damping persistent peer
> oscillation which is referred to in several different ways (I give a
> list
> below).
> 
> I believe we should have one consistent phrase everywhere; I suggest
>    - [optionally] performs peer oscillation damping

Accepted.

> as the action (drop the BGP as that is evident from the context and
> drop the persistent as that makes the phrase overlong) with a similar
> phrase in the description in Events 6 and
> 8.  (Currently these last refer to flap which I find particularly
> misleading as this could be a reference to the mechanism of RFC2439).
> 
> And I do not believe there should be a reference, at least in the
> actions listed in the FSM - [2] appears in several places and I
> suspect is/was a reference to
> "BGP Peer Restart Backoff Mechanisms", S. Hares
> draft-skh-bgp-backoff-00.txt

You are correct - references to [2] will be removed.

Yakov.

> (And of course, any reference anywhere in the document needs to be
> handled with care because of the need for normative references to be
> Full Standard when this is to be Full Standard with the implications
> that has for implementation reports).
> 
> List of oscillation references follows
> 
>        Event6: Automatic start with bgp_stop_flap option set
> 
>   persistent peer oscillation damping
>   damping persistent peer oscillations
>   damping persistent BGP adjacency flapping
>   damping persistent BGP peer flapping.
> 
>        Event8:  Idle hold timer expires
> 
>   persistent BGP oscillation damping functions
>   persistent BGP peer oscillation damping functions
> 
> 
>       Idle
>              - persistent BGP peer oscillation
> 
>       Connect State:
>              - [optionally] performs bgp peer oscillation damping
> 
>       Active State:
> 
>              - perform the BGP peer oscillation damping process [2].
> 
>              - optionally performs BGP peer oscillation damping,
> 
>       Open Sent:
> 
>               - bgp peer oscillation damping process,
> 
>               - performs any BGP peer oscillation damp process
> 
>               - BGP peer oscillation process [2],
> 
>               - process any bgp peer oscillation damping[2],
> 
>       Open Confirm State:
> 
>               - runs the BGP peer oscillation damping process [2]
> 
>               - performs any BGP peer oscillation damping process [2].
> 
>               - and performs any BGP peer oscillation damping, and
> 
>               - performs any BGP peer oscillation damping, and
> 
>               - performs any BGP peer oscillation damping,
> 
>        Established state.
> 
>               - performs any BGP peer oscillation damping, and
> 
>               - performs any BGP peer oscillation damping,
> 
>               - and performs any BGP peer oscillation damping,
> 
>               - performs any BGP peer oscillation damping, and
> 
> Tom Petch
> [e-mail]
> 
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA16282 for <[e-mail]>; Sat, 30 Nov 2002 20:15:42 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 4AE6391240; Sat, 30 Nov 2002 20:15:12 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9B5B91241; Sat, 30 Nov 2002 20:15:11 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8755391240 for <[e-mail]>; Sat, 30 Nov 2002 20:15:09 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3B2905DE9F; Sat, 30 Nov 2002 20:15:08 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 058945DE37 for <[e-mail]>; Sat, 30 Nov 2002 20:15:07 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gB11F3S76209; Sat, 30 Nov 2002 17:15:04 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Tom Petch" <[e-mail]>
Cc: "idr" <[e-mail]>
Subject: Re: bgp18 WG Last Call fsm delete action 
In-Reply-To: Your message of "Wed, 27 Nov 2002 17:41:15 GMT." <013d01c2963c$4dbf9300$0301a8c0@tom3> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sat, 30 Nov 2002 17:15:03 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Tom,

> In several places in the FSM, under Open Sent, Open Confirm,
> Established states, there is an action relating to delete routes which
> is variously described as
> 
>       Open Sent:
> 
>         - if there are any routes associated with the BGP session,
>          delete these routes
> 
>         - if any routes are associated with te BGP session,
>           delete the routes,
> 
>       Open Confirm State:
> 
>         - if any BGP routes, dete the routes
> 
>         - If any BGP routes exist, delete the routes,
> 
>         - deletes all routes associated with connection,

As Jeff indicated in his e-mail there are no routes in either
OpenSent or OpenConfirm, so there aren't any routes to delete.
I'll fix the text to reflect this.

> 
>       Established State:
> 
>         - if any BGP routes exist, delete all BGP routes,
> 
>         - deletes all routes associated with bgp connection,
> 
>         - deletes all routes associated with connection,
> 
>         - deletes all routes associated with BGP connection,
> 
> If, as I believe, this is always the same action, then I would like
> the same description in every case.  I suggest
> 
>         - deletes all routes associated with this connection,

Accepted.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA14762 for <[e-mail]>; Sat, 30 Nov 2002 19:48:48 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6F8C39120D; Sat, 30 Nov 2002 19:47:01 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 138AF9123F; Sat, 30 Nov 2002 19:47:01 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C4A999120D for <[e-mail]>; Sat, 30 Nov 2002 19:46:59 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 9EAB85DDF5; Sat, 30 Nov 2002 19:46:59 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 404055DD92 for <[e-mail]>; Sat, 30 Nov 2002 19:46:59 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gB10kvS75662; Sat, 30 Nov 2002 16:46:57 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: -18 last call comments 
In-Reply-To: Your message of "Fri, 29 Nov 2002 20:09:44 EST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sat, 30 Nov 2002 16:46:57 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> Last comments from my most recent readthrough of -18.  Tom Petch
> catches all of the FSM comments I wanted to make:
> 
> We refer to 1772.  Do we wish to do this considering that we want to
> rev 1772?

1772 is in the non-normative section. I think we could keep it there,
and keep the references as well.

> Capitalization of magic words such as MUST and SHOULD should be done.

It should be done *as appropriate*. Therefore, if you think there
are places where it is *appropriate* to do capitalization, please
point them out.

> Update message error subcode 7 is removed.  Especially in -18,
> it looks like an editing mistake based on where it would fall
> in the editing..

>From Appendix A:

  UPDATE Message Error subcode 7 (AS Routing Loop) has been deprecated.
  
> 5.1.4: "See section 9.1.2.2 for necessary RESTRICTIONS on this"

Fixed.

> 9.1:
> The output of the Decision Process is the set of routes that will be
> advertised to (delete all) peers; the selected routes will be stored
> in the local speaker's Adj-RIB-Out according to policy.
> 
> The previous wording implied that routes in the LocRib MUST be placed
> in the adj-rib-out.

fixed.

> Reference to IDRP should be ISO10747 not IS10747.

No, it should be IS10747.

> Aside from this, things are looking very good.

Thanks !!!

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA03255 for <[e-mail]>; Fri, 29 Nov 2002 20:37:06 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B4D1C9130D; Fri, 29 Nov 2002 20:36:30 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81FED9130E; Fri, 29 Nov 2002 20:36:30 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7260E9130D for <[e-mail]>; Fri, 29 Nov 2002 20:36:29 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 5AEFF5DE9A; Fri, 29 Nov 2002 20:36:29 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id C6E2E5DE90 for <[e-mail]>; Fri, 29 Nov 2002 20:36:28 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gAU1aRR39920; Fri, 29 Nov 2002 20:36:27 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gAU1aOC39913; Fri, 29 Nov 2002 20:36:24 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gAU1aOj10190; Fri, 29 Nov 2002 20:36:24 -0500 (EST)
Date: Fri, 29 Nov 2002 20:36:24 -0500
From: Jeffrey Haas <[e-mail]>
To: Tom Petch <[e-mail]>
Cc: idr <[e-mail]>
Subject: Re: bgp18 WG Last Call fsm MIB objects
Message-ID: <[e-mail]>
References: <001501c29706$cdd0b400$0301a8c0@tom3>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <001501c29706$cdd0b400$0301a8c0@tom3>; from [e-mail] on Thu, Nov 28, 2002 at 05:43:35PM -0000
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Nov 28, 2002 at 05:43:35PM -0000, Tom Petch wrote:
> The FSM makes several references to putting values into MIB objects
> variously identified as

To make everyone's life easier, the MIB references will be removed from
the FSM and the MIB will incorporate the "do this here" references.

This way we don't have to worry about MIB object taxonomy getting out
of sync with the base specification.

> I believe this needs defining more clearly, probably with a reference
> to the relevant MIB document.  (Currently I see no MIB document in the
> list of references).

I'm taking this as a work item for the MIBv2.  The MIBv1 is basically
going up for informational/historical status. (i.e. this is what *is*
implemented, but not what we are going to use for standards purposes).

> Tom Petch
> [e-mail]

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA03056 for <[e-mail]>; Fri, 29 Nov 2002 20:34:09 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8B28E9130B; Fri, 29 Nov 2002 20:33:55 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5865C9130D; Fri, 29 Nov 2002 20:33:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B02D69130B for <[e-mail]>; Fri, 29 Nov 2002 20:33:20 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8E3F15DE9A; Fri, 29 Nov 2002 20:33:20 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 002145DE90 for <[e-mail]>; Fri, 29 Nov 2002 20:33:19 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gAU1XHd39878; Fri, 29 Nov 2002 20:33:17 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gAU1XEC39871; Fri, 29 Nov 2002 20:33:14 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gAU1XEK10179; Fri, 29 Nov 2002 20:33:14 -0500 (EST)
Date: Fri, 29 Nov 2002 20:33:14 -0500
From: Jeffrey Haas <[e-mail]>
To: Tom Petch <[e-mail]>
Cc: idr <[e-mail]>
Subject: Re: bgp18 WG Last Call fsm missing next state
Message-ID: <[e-mail]>
References: <002701c296ee$1cabd000$0301a8c0@tom3>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <002701c296ee$1cabd000$0301a8c0@tom3>; from [e-mail] on Thu, Nov 28, 2002 at 02:53:56PM -0000
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Tom,

On Thu, Nov 28, 2002 at 02:53:56PM -0000, Tom Petch wrote:
> In seven places in the FSM, the actions listed for the occurrence of
> an event do not include any indication of what the next state should
> be, nor can I be sure I can guess what it should be.
> 
> I believe the FSM should specify the new state in the cases listed
> below.
> 
>       Connect State:
> 
>         If the TCP connection succeeds [Event 15 or
>         Event 16], the local system checks the "Delay Open
>         Flag".  If the delay Open flag is set, the local system:
> **enters what state

Remains in the connect state awaiting either an open message or
for the opendelay timer to expire.

>         If the TCP connection receives an indication
>         that is invalid or unconfigured. [Event 14]:
> **enters what state

Enters the active state.
Connectretrytimer should be started.

>       Active State:
> 
>         A TCP connection succeeds [Event 15 or Event 16], the
>         local system: process the TCP connection flags
>          - If the BGP delay open flag is set:
> ** enters what state (I think this is an FSM error in TCP because it
> has not initiated a connection!)

In the active state, we are awaiting incoming tcp connections to be
completed.  Here we should:

remain in the active state
wait for an open message or the opendelay timer to expire.

>         If the local system receives a valid TCP Indication
>         [Event 13], the local system processes the TCP connection
> flags.
> ** enters what state

I'm also confused by this event.  Since we are not initiating a TCP
connection, but are awaiting one to complete, why would we get an
Indication here?  FSM error?

>         If the local system receives a TCP indication
>         that is invalid for this connection [Event 14]:
> ** enters what state

Ditto.

> 
>         If the local system receives a TCP connection
>         failed [Event 17] (timeout or receives connection
>         disconnect), the local system will:
> ** enters what state

Ditto.

>       Open Confirm State:
> 
>         If the Open messages is valid [Event 18], the collision
>         detect function is processed per section 6.8.  If this
>         connection is to be dropped due to call collision, the
>         local system:
> ** enters what state

This instance of the FSM should be discarded since it implies there is
another FSM instance running that will proceed to Established?

> Tom Petch
> [e-mail]

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA02570 for <[e-mail]>; Fri, 29 Nov 2002 20:24:10 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id AEAF49130A; Fri, 29 Nov 2002 20:23:34 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79CD79130B; Fri, 29 Nov 2002 20:23:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 682E89130A for <[e-mail]>; Fri, 29 Nov 2002 20:23:33 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 4FF6D5DEBE; Fri, 29 Nov 2002 20:23:33 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id BD2B85DEB1 for <[e-mail]>; Fri, 29 Nov 2002 20:23:32 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gAU1NUk39791; Fri, 29 Nov 2002 20:23:30 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gAU1NRC39784; Fri, 29 Nov 2002 20:23:27 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gAU1NQG10162; Fri, 29 Nov 2002 20:23:26 -0500 (EST)
Date: Fri, 29 Nov 2002 20:23:26 -0500
From: Jeffrey Haas <[e-mail]>
To: Tom Petch <[e-mail]>
Cc: [e-mail]
Subject: Re: bgp18 WG Last Call fsm delete action
Message-ID: <[e-mail]>
References: <002401c296ee$1ad5d780$0301a8c0@tom3>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <002401c296ee$1ad5d780$0301a8c0@tom3>; from [e-mail] on Thu, Nov 28, 2002 at 02:52:15PM -0000
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Tom,

On Thu, Nov 28, 2002 at 02:52:15PM -0000, Tom Petch wrote:
> I do not know either why the action is present in OpenSent and
> OpenConfirm states but that is a separate (and valid) issue.  My
> concern is that where we have one and the same action, we use the same
> description (which may then make other issues more clear).

In the OpenSent and OpenConfirm states, there should be no routes to
be deleted.  This is an error in the document.

> Tom Petch
> [e-mail]

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA01852 for <[e-mail]>; Fri, 29 Nov 2002 20:10:20 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6286591205; Fri, 29 Nov 2002 20:09:54 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 306139130A; Fri, 29 Nov 2002 20:09:54 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 13E5B91205 for <[e-mail]>; Fri, 29 Nov 2002 20:09:53 -0500 (EST)
Received: by segue.merit.edu (Postfix) id DCCCE5DE2F; Fri, 29 Nov 2002 20:09:52 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 551995DDA9 for <[e-mail]>; Fri, 29 Nov 2002 20:09:52 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gAU19mI39651 for [e-mail]; Fri, 29 Nov 2002 20:09:48 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gAU19iC39644 for <[e-mail]>; Fri, 29 Nov 2002 20:09:44 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gAU19iG10128 for [e-mail]; Fri, 29 Nov 2002 20:09:44 -0500 (EST)
Date: Fri, 29 Nov 2002 20:09:44 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: -18 last call comments
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Last comments from my most recent readthrough of -18.  Tom Petch
catches all of the FSM comments I wanted to make:

We refer to 1772.  Do we wish to do this considering that we want to
rev 1772?

Capitalization of magic words such as MUST and SHOULD should be done.

Update message error subcode 7 is removed.  Especially in -18,
it looks like an editing mistake based on where it would fall
in the editing..

5.1.4: "See section 9.1.2.2 for necessary RESTRICTIONS on this"

9.1:
The output of the Decision Process is the set of routes that will be
advertised to (delete all) peers; the selected routes will be stored
in the local speaker's Adj-RIB-Out according to policy.

The previous wording implied that routes in the LocRib MUST be placed
in the adj-rib-out.

Reference to IDRP should be ISO10747 not IS10747.

Aside from this, things are looking very good.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA12102 for <[e-mail]>; Fri, 29 Nov 2002 14:00:15 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 65E609120C; Fri, 29 Nov 2002 13:59:36 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2384B912EC; Fri, 29 Nov 2002 13:59:36 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9BC5C9120C for <[e-mail]>; Fri, 29 Nov 2002 13:59:34 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 835035DE5C; Fri, 29 Nov 2002 13:59:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by segue.merit.edu (Postfix) with ESMTP id 3985C5DE52 for <[e-mail]>; Fri, 29 Nov 2002 13:59:34 -0500 (EST)
Received: from tom3 (usermc48.uk.uudial.com [62.188.120.146]) by colossus.systems.pipex.net (Postfix) with SMTP id 128E41600058B for <[e-mail]>; Fri, 29 Nov 2002 18:59:32 +0000 (GMT)
Message-ID: <017701c297d9$731be2e0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: <[e-mail]>
Subject: bgp18 WG Last Call fsm event names
Date: Fri, 29 Nov 2002 18:45:38 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

The event name used in the FSM show much variation to the point
sometimes where I am not clear that it is always the same event (eg
where the event name is qualified by a subset of the possible causes).
Assuming that it is, I propose the following changes to make the
wording consistent, clear and concise for event names.

** denotes changed text using the convention /'old text'/'new text'/

8. BGP Finite State machine

       Event1:  Manual start
       Event2:  Manual stop
       Event3:  Automatic start
     **Event4:  Manual start with passive TCP /estabishment/flag/
     **Event5:  Automatic start with passive TCP /establishment/flag/
       Event6:  Automatic start with bgp_stop_flap option set
     **Event7:  Auto//matic/ stop
       Event8:  Idle hold timer expires
       Event9:  Connect retry timer expires
     **Event10: Hold time//r/ expires
       Event11: Keepalive timer expires
       Event12: Open Delay timer expires
     **Event13: TCP connection valid indication
     **Event14: TCP connection invalid indication
     **Event15: TCP connection request /sent received an
ACK/acknowledged/
       Event16: TCP connection confirmed
       Event17: TCP connection fails
       Event18: BGPOpen
       Event19: BGPOpen with *Open Delay timer running
       Event20: BGPHeaderErr
       Event21: BGPOpenMsgErr
       Event22: Open collision dump
       Event23: NotifMsgVerErr
       Event24: NotifMsg
       Event25: KeepAliveMsg
       Event26: UpdateMsg
       Event27: UpdateMsgErr

8.2.2 Finite State Machine

      Connect State:

        If the BGP port receives a ** valid TCP connection indication
[Event 13],

        If the TCP connection receives **an invalid indication [Event
14]:

        If the TCP connection fails **/(timeout or disconnect)//
[Event17]

      Active State:

       If the local system receives a **valid TCP //indication/ [Event
13],

       If the local system receives a TCP connection failed [Event 17]
**/(timeout or receives connection
       disconnect)//,

      Open Sent:

       If a connection in Open Sent is determined to be the
       connection that must be closed, an **/administrative collision
       detect/Open collision dump/ [Event 22] is signaled to the state
machine. If such
       an **/administrative collision detect dump [Event 22]/event/ is

       If a TCP **//connection valid/ indication [Event 13] or
       TCP **//connection/ request **//acknowledged/ [Event 15]

      Open Confirm State:

       ... or receives a TCP **/Disconnect// connection fails/ [Event
17] from the

       In the event of **/TCP establishment//TCP connection valid
indication /[Event 13]

       .... the local system will
       **/issue a call/generate an Open/ collision dump [Event 22].
When the local
       system receives a **/call/open/ collision dump event [Event
22]/such an event/, the

      Established State:

       **/disconnect from the underlying TCP/TCP connection fails/
[Event17], it:

       ... it will process **/a Call/an Open/ Collision dump
event[Event 22].


Notes:
Event 4 title brought in line with text
Event 5 title brought in line with text
Event 7 title brought in line with text
Event 13 title shortened to be closer to text, text brought in line
Event 14 title shortened to be closer to text, text brought in line
Event 15 title brought in line with text
Event 17 text brought in line with title (text often introduces
qualifying conditions that are too restrictive)
Event 22 text brought in line with title


Tom Petch
[e-mail]




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA22862 for <[e-mail]>; Thu, 28 Nov 2002 12:52:21 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E289A912CE; Thu, 28 Nov 2002 12:51:44 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 89FCE912D1; Thu, 28 Nov 2002 12:51:43 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E837F912CB for <[e-mail]>; Thu, 28 Nov 2002 12:51:40 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C61B55DDD3; Thu, 28 Nov 2002 12:51:40 -0500 (EST)
Delivered-To: [e-mail]
Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by segue.merit.edu (Postfix) with ESMTP id 7690E5DF7A for <[e-mail]>; Thu, 28 Nov 2002 12:51:40 -0500 (EST)
Received: from tom3 (userag34.uk.uudial.com [62.188.132.120]) by shockwave.systems.pipex.net (Postfix) with SMTP id 8AC451600B641 for <[e-mail]>; Thu, 28 Nov 2002 17:51:38 +0000 (GMT)
Message-ID: <001401c29706$cd28db40$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>
Subject: bgp18 WG Last Call fsm peer oscillation dampiing
Date: Thu, 28 Nov 2002 15:25:47 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

There is an action in the FSM relating to damping persistent peer
oscillation which is referred to in several different ways (I give a
list
below).

I believe we should have one consistent phrase everywhere; I suggest
   - [optionally] performs peer oscillation damping
as the action (drop the BGP as that is evident from the context and
drop the persistent as that makes the phrase overlong) with a similar
phrase in the description in Events 6 and
8.  (Currently these last refer to flap which I find particularly
misleading as this could be a reference to the mechanism of RFC2439).

And I do not believe there should be a reference, at least in the
actions listed in the FSM - [2] appears in several places and I
suspect is/was a reference to
"BGP Peer Restart Backoff Mechanisms", S. Hares
draft-skh-bgp-backoff-00.txt

(And of course, any reference anywhere in the document needs to be
handled with care because of the need for normative references to be
Full Standard when this is to be Full Standard with the implications
that has for implementation reports).

List of oscillation references follows

       Event6: Automatic start with bgp_stop_flap option set

  persistent peer oscillation damping
  damping persistent peer oscillations
  damping persistent BGP adjacency flapping
  damping persistent BGP peer flapping.

       Event8:  Idle hold timer expires

  persistent BGP oscillation damping functions
  persistent BGP peer oscillation damping functions


      Idle
             - persistent BGP peer oscillation

      Connect State:
             - [optionally] performs bgp peer oscillation damping

      Active State:

             - perform the BGP peer oscillation damping process [2].

             - optionally performs BGP peer oscillation damping,

      Open Sent:

              - bgp peer oscillation damping process,

              - performs any BGP peer oscillation damp process

              - BGP peer oscillation process [2],

              - process any bgp peer oscillation damping[2],

      Open Confirm State:

              - runs the BGP peer oscillation damping process [2]

              - performs any BGP peer oscillation damping process [2].

              - and performs any BGP peer oscillation damping, and

              - performs any BGP peer oscillation damping, and

              - performs any BGP peer oscillation damping,

       Established state.

              - performs any BGP peer oscillation damping, and

              - performs any BGP peer oscillation damping,

              - and performs any BGP peer oscillation damping,

              - performs any BGP peer oscillation damping, and

Tom Petch
[e-mail]





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA22835 for <[e-mail]>; Thu, 28 Nov 2002 12:52:04 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1D0F2912D2; Thu, 28 Nov 2002 12:51:44 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1F98912CB; Thu, 28 Nov 2002 12:51:43 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 69CE7912CE for <[e-mail]>; Thu, 28 Nov 2002 12:51:41 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 580355DF7A; Thu, 28 Nov 2002 12:51:41 -0500 (EST)
Delivered-To: [e-mail]
Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by segue.merit.edu (Postfix) with ESMTP id 271215DDD3 for <[e-mail]>; Thu, 28 Nov 2002 12:51:41 -0500 (EST)
Received: from tom3 (userag34.uk.uudial.com [62.188.132.120]) by shockwave.systems.pipex.net (Postfix) with SMTP id E74791600B673 for <[e-mail]>; Thu, 28 Nov 2002 17:51:39 +0000 (GMT)
Message-ID: <001501c29706$cdd0b400$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>
Subject: bgp18 WG Last Call fsm MIB objects
Date: Thu, 28 Nov 2002 17:43:35 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

The FSM makes several references to putting values into MIB objects
variously identified as

       Connect state

          MIB FSM error information

      Active State:

          MIB reason code
          the MIB information

      Open Sent:

           MIB state information
           MIB reason
           MIB Error reason code,

      Open Confirm State:

           the appropriate MIB information
           MIB Reason code
           the MIB entry for this peer
           the MIB reason
           the MIB reason code
           the MIB FSM variable

      Established State:

            MIB reason code,
            MIB reason code
            MIB Reason code

I can find no objects with names resembling these in either of the two
draft MIBs.  My guess would be that in most cases it is either
- bgpM2PeerLastErrorReceived/bgpM2PeerLastErrorSent from
draft-ietf-idr-bgp4-mibv2-03.txt
or
- bgpPeerLastError from draft-ietf-idr-bgp4-mib-10.txt

I believe this needs defining more clearly, probably with a reference
to the relevant MIB document.  (Currently I see no MIB document in the
list of references).

Tom Petch
[e-mail]







Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA13154 for <[e-mail]>; Thu, 28 Nov 2002 09:56:13 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 7957F912CC; Thu, 28 Nov 2002 09:55:01 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38FEF912CB; Thu, 28 Nov 2002 09:55:00 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 21387912CC for <[e-mail]>; Thu, 28 Nov 2002 09:54:56 -0500 (EST)
Received: by segue.merit.edu (Postfix) id E5DE15DEC2; Thu, 28 Nov 2002 09:54:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by segue.merit.edu (Postfix) with ESMTP id AFEB35DEB7 for <[e-mail]>; Thu, 28 Nov 2002 09:54:55 -0500 (EST)
Received: from tom3 (userbo49.uk.uudial.com [62.188.145.199]) by colossus.systems.pipex.net (Postfix) with SMTP id 9924B160009B7 for <[e-mail]>; Thu, 28 Nov 2002 14:54:54 +0000 (GMT)
Message-ID: <002701c296ee$1cabd000$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>
Subject: bgp18 WG Last Call fsm missing next state
Date: Thu, 28 Nov 2002 14:53:56 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

In seven places in the FSM, the actions listed for the occurrence of
an event do not include any indication of what the next state should
be, nor can I be sure I can guess what it should be.

I believe the FSM should specify the new state in the cases listed
below.

      Connect State:

        If the TCP connection succeeds [Event 15 or
        Event 16], the local system checks the "Delay Open
        Flag".  If the delay Open flag is set, the local system:
**enters what state

        If the TCP connection receives an indication
        that is invalid or unconfigured. [Event 14]:
**enters what state


      Active State:

        A TCP connection succeeds [Event 15 or Event 16], the
        local system: process the TCP connection flags
         - If the BGP delay open flag is set:
** enters what state (I think this is an FSM error in TCP because it
has not initiated a connection!)


        If the local system receives a valid TCP Indication
        [Event 13], the local system processes the TCP connection
flags.
** enters what state

        If the local system receives a TCP indication
        that is invalid for this connection [Event 14]:
** enters what state

        If the local system receives a TCP connection
        failed [Event 17] (timeout or receives connection
        disconnect), the local system will:
** enters what state


      Open Confirm State:

        If the Open messages is valid [Event 18], the collision
        detect function is processed per section 6.8.  If this
        connection is to be dropped due to call collision, the
        local system:
** enters what state

Tom Petch
[e-mail]





Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA13141 for <[e-mail]>; Thu, 28 Nov 2002 09:56:02 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 3F0D8912CF; Thu, 28 Nov 2002 09:54:56 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 749A0912CE; Thu, 28 Nov 2002 09:54:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 80018912CB for <[e-mail]>; Thu, 28 Nov 2002 09:54:53 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 62DF45DEC2; Thu, 28 Nov 2002 09:54:53 -0500 (EST)
Delivered-To: [e-mail]
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by segue.merit.edu (Postfix) with ESMTP id 1900F5DEB7 for <[e-mail]>; Thu, 28 Nov 2002 09:54:53 -0500 (EST)
Received: from tom3 (userbo49.uk.uudial.com [62.188.145.199]) by colossus.systems.pipex.net (Postfix) with SMTP id A168216000B74; Thu, 28 Nov 2002 14:54:50 +0000 (GMT)
Message-ID: <002401c296ee$1ad5d780$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Venu Kumar G - CTD, Chennai." <[e-mail]>, "idr" <[e-mail]>
Subject: Re: bgp18 WG Last Call fsm delete action
Date: Thu, 28 Nov 2002 14:52:15 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

I do not know either why the action is present in OpenSent and
OpenConfirm states but that is a separate (and valid) issue.  My
concern is that where we have one and the same action, we use the same
description (which may then make other issues more clear).

My guess is that it stems from the OpenDelay mechanism so that while
in OpenSent or OpenConfirm states, the exchange of Open messages
completes successfully, KeepAlive can arrive hotly followed by Update
messages.  Note that at least in some cases in OpenSent and
OpenConfirm states, the KeepAlive is sent as part of the action list
so that Updates could start arriving before the action list is
complete and so, depending on the FSM implementation view of single
threading, Updates can arrive too.  Just a guess.

Tom Petch
[e-mail]

-----Original Message-----
From: Venu Kumar G - CTD, Chennai. <[e-mail]>
To: Tom Petch <[e-mail]>; idr <[e-mail]>
Date: 28 November 2002 05:46
Subject: RE: bgp18 WG Last Call fsm delete action


>HI,
>
>         I could not understand the idea behind addding   "deleting
route
>associated with BGP sessioon...x" text in OpenSent  and  OpenConfirm
state.
>We can only receive  routes  when we in "Established" state,  and
their is
>no action or event in FSM, with that we can move to "OpenConfirm" or
"Open
>Sent " State, when we are in "Established" state.
>
>
>Venu G.
>
>
>-----Original Message-----
>From: Tom Petch [mailto:[e-mail]]
>Sent: Wednesday, November 27, 2002 11:11 PM
>To: idr
>Subject: bgp18 WG Last Call fsm delete action
>
>
>In several places in the FSM, under Open Sent, Open Confirm,
>Established states, there is an action relating to delete routes
which
>is variously described as
>
>      Open Sent:
>
>        - if there are any routes associated with the BGP session,
>         delete these routes
>
>        - if any routes are associated with te BGP session,
>          delete the routes,
>
>      Open Confirm State:
>
>        - if any BGP routes, dete the routes
>
>        - If any BGP routes exist, delete the routes,
>
>        - deletes all routes associated with connection,
>
>      Established State:
>
>        - if any BGP routes exist, delete all BGP routes,
>
>        - deletes all routes associated with bgp connection,
>
>        - deletes all routes associated with connection,
>
>        - deletes all routes associated with BGP connection,
>
>If, as I believe, this is always the same action, then I would like
>the same description in every case.  I suggest
>
>        - deletes all routes associated with this connection,
>
>Tom Petch
>[e-mail]
>
>



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA13135 for <[e-mail]>; Thu, 28 Nov 2002 09:56:01 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 4B686912CD; Thu, 28 Nov 2002 09:55:00 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EAB41912D1; Thu, 28 Nov 2002 09:54:58 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0CFCA912CD for <[e-mail]>; Thu, 28 Nov 2002 09:54:55 -0500 (EST)
Received: by segue.merit.edu (Postfix) id E94AC5DEC2; Thu, 28 Nov 2002 09:54:54 -0500 (EST)
Delivered-To: [e-mail]
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by segue.merit.edu (Postfix) with ESMTP id B94FA5DEB7 for <[e-mail]>; Thu, 28 Nov 2002 09:54:54 -0500 (EST)
Received: from tom3 (userbo49.uk.uudial.com [62.188.145.199]) by colossus.systems.pipex.net (Postfix) with SMTP id B9581160012B8 for <[e-mail]>; Thu, 28 Nov 2002 14:54:53 +0000 (GMT)
Message-ID: <002601c296ee$1c258900$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>
Subject: bgp18 WG Last Call fsm missing keepalive
Date: Thu, 28 Nov 2002 14:53:36 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

When the OpenConfirm state is entered from OpenSent with the receipt
of a valid open [Event 18], then a KeepAlive message is sent and the
timer is started.

When the OpenConfirm state is entered from Active or Connect on
receipt of a valid open [Event 19], no message is sent, no timer is
started.

I believe this inconsistency is an error and should be corrected by
adding these two actions in those two places.

Tom Petch
[e-mail]





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA13101 for <[e-mail]>; Thu, 28 Nov 2002 09:55:30 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 5FC5E912D0; Thu, 28 Nov 2002 09:54:56 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC1A8912CB; Thu, 28 Nov 2002 09:54:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 304BA912CC for <[e-mail]>; Thu, 28 Nov 2002 09:54:54 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 19AB35DEC2; Thu, 28 Nov 2002 09:54:54 -0500 (EST)
Delivered-To: [e-mail]
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by segue.merit.edu (Postfix) with ESMTP id D7A875DEB7 for <[e-mail]>; Thu, 28 Nov 2002 09:54:53 -0500 (EST)
Received: from tom3 (userbo49.uk.uudial.com [62.188.145.199]) by colossus.systems.pipex.net (Postfix) with SMTP id B6628160012AE for <[e-mail]>; Thu, 28 Nov 2002 14:54:52 +0000 (GMT)
Message-ID: <002501c296ee$1b8e7920$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>
Subject: bgp18 WG Last Call fsm incorrect next state
Date: Thu, 28 Nov 2002 14:52:59 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

I believe that there is an incorrect next state when the delay open
timer expires [event 12] in the Active state.  The next state should
be OpenSent and not OpenConfirm.

OpenConfirm is for KeepAlive processing when Open messages have been
sent and received.

OpenSent is for Open sent and not yet received.

The corresponding section in Connect state I believe is correct.

Tom Petch
[e-mail]




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA12638 for <[e-mail]>; Thu, 28 Nov 2002 00:46:54 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id C359D912C2; Thu, 28 Nov 2002 00:46:32 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C066912C3; Thu, 28 Nov 2002 00:46:32 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A8073912C2 for <[e-mail]>; Thu, 28 Nov 2002 00:46:30 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 843225E02D; Thu, 28 Nov 2002 00:46:30 -0500 (EST)
Delivered-To: [e-mail]
Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id CD0835E02C for <[e-mail]>; Thu, 28 Nov 2002 00:46:28 -0500 (EST)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <XV2HTP52>; Thu, 28 Nov 2002 11:23:04 +0530
Message-ID: <[e-mail]>
From: "Venu Kumar G - CTD, Chennai." <[e-mail]>
To: Tom Petch <[e-mail]>, idr <[e-mail]>
Subject: RE: bgp18 WG Last Call fsm delete action
Date: Thu, 28 Nov 2002 11:18:43 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

HI,    
  
         I could not understand the idea behind addding   "deleting route
associated with BGP sessioon...x" text in OpenSent  and  OpenConfirm state.
We can only receive  routes  when we in "Established" state,  and their is
no action or event in FSM, with that we can move to "OpenConfirm" or "Open
Sent " State, when we are in "Established" state.


Venu G.


-----Original Message-----
From: Tom Petch [mailto:[e-mail]]
Sent: Wednesday, November 27, 2002 11:11 PM
To: idr
Subject: bgp18 WG Last Call fsm delete action


In several places in the FSM, under Open Sent, Open Confirm,
Established states, there is an action relating to delete routes which
is variously described as

      Open Sent:

        - if there are any routes associated with the BGP session,
         delete these routes

        - if any routes are associated with te BGP session,
          delete the routes,

      Open Confirm State:

        - if any BGP routes, dete the routes

        - If any BGP routes exist, delete the routes,

        - deletes all routes associated with connection,

      Established State:

        - if any BGP routes exist, delete all BGP routes,

        - deletes all routes associated with bgp connection,

        - deletes all routes associated with connection,

        - deletes all routes associated with BGP connection,

If, as I believe, this is always the same action, then I would like
the same description in every case.  I suggest

        - deletes all routes associated with this connection,

Tom Petch
[e-mail]




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA05075 for <[e-mail]>; Wed, 27 Nov 2002 13:24:26 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BE0859129F; Wed, 27 Nov 2002 13:24:02 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B4719129E; Wed, 27 Nov 2002 13:24:02 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3C60591203 for <[e-mail]>; Wed, 27 Nov 2002 13:24:01 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 238425DFCD; Wed, 27 Nov 2002 13:24:01 -0500 (EST)
Delivered-To: [e-mail]
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by segue.merit.edu (Postfix) with ESMTP id E72FA5DDA1 for <[e-mail]>; Wed, 27 Nov 2002 13:24:00 -0500 (EST)
Received: from tom3 (userbn12.uk.uudial.com [62.188.145.63]) by colossus.systems.pipex.net (Postfix) with SMTP id 99D8516040593 for <[e-mail]>; Wed, 27 Nov 2002 18:23:56 +0000 (GMT)
Message-ID: <019d01c29642$27522ce0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>
Subject: bgp18 WG Last Call fsm mib actions
Date: Wed, 27 Nov 2002 18:18:57 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

I find the FSM inconsistent in specifying an action to place a value
in a MIB object when a NOTIFICATION is sent.

In the following six places it does not and for consistency I believe
it should.

Open Confirm State:

       If an OPEN message is received, all fields are check for
       correctness.  If the BGP message header checking [Event20]
       or OPEN message check detects an error (see Section
       6.2)[Event21], the local system:
              - sends a NOTIFICATION message with appropriate error
                code,
** MIB should be updated

       In response to any other event [Events 8-9, 12, 19, 26-27],
       the local system:
              - sends a NOTIFICATION with a code of Finite State
                Machine Error,
** MIB should be updated

Established State:

       If the local system receives an UPDATE message, and the
       Update message error handling procedure (see Section 6.3)
       detects an error [Event27], the local system:
             - sends a NOTIFICATION message with Update error,
** MIB should be updated

       If the Hold timer expires [Event10], the local system:
            - sends a NOTIFICATION message with Error Code Hold
              Timer Expired,
** MIB should be updated

       If a valid Open message [Event 18] is received, it will be
       checked to see if it collides (section 6.8) with any other
       session. If the BGP implementation determines that this
       connection needs to be terminated, it will process an Call
       Collision dump event[Event 22].  If this session needs to be
       terminated, the connection will be terminated by:
           - send a NOTIFICATION with a CEASE
** MIB should be updated

       In response to any other event [Events 8-9,12, 19-21] the
       local system:
           - sends a NOTIFICATION message with Error Code Finite
             State Machine Error,
** MIB should be updated

Tom Petch
[e-mail]





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA02856 for <[e-mail]>; Wed, 27 Nov 2002 12:42:53 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 228C59129D; Wed, 27 Nov 2002 12:42:09 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D7C3D9129A; Wed, 27 Nov 2002 12:42:08 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 156AD9129B for <[e-mail]>; Wed, 27 Nov 2002 12:42:07 -0500 (EST)
Received: by segue.merit.edu (Postfix) id F30565DEC9; Wed, 27 Nov 2002 12:42:06 -0500 (EST)
Delivered-To: [e-mail]
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by segue.merit.edu (Postfix) with ESMTP id C33B45DDEC for <[e-mail]>; Wed, 27 Nov 2002 12:42:06 -0500 (EST)
Received: from tom3 (useraq74.uk.uudial.com [62.188.136.134]) by colossus.systems.pipex.net (Postfix) with SMTP id 9BA10160398F9 for <[e-mail]>; Wed, 27 Nov 2002 17:42:05 +0000 (GMT)
Message-ID: <013d01c2963c$4dbf9300$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>
Subject: bgp18 WG Last Call fsm delete action
Date: Wed, 27 Nov 2002 17:41:15 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

In several places in the FSM, under Open Sent, Open Confirm,
Established states, there is an action relating to delete routes which
is variously described as

      Open Sent:

        - if there are any routes associated with the BGP session,
         delete these routes

        - if any routes are associated with te BGP session,
          delete the routes,

      Open Confirm State:

        - if any BGP routes, dete the routes

        - If any BGP routes exist, delete the routes,

        - deletes all routes associated with connection,

      Established State:

        - if any BGP routes exist, delete all BGP routes,

        - deletes all routes associated with bgp connection,

        - deletes all routes associated with connection,

        - deletes all routes associated with BGP connection,

If, as I believe, this is always the same action, then I would like
the same description in every case.  I suggest

        - deletes all routes associated with this connection,

Tom Petch
[e-mail]





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA02848 for <[e-mail]>; Wed, 27 Nov 2002 12:42:50 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E7FEA9129B; Wed, 27 Nov 2002 12:42:09 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90F3C9129C; Wed, 27 Nov 2002 12:42:08 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 87A7F9129A for <[e-mail]>; Wed, 27 Nov 2002 12:42:06 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 6EFB05DEC9; Wed, 27 Nov 2002 12:42:06 -0500 (EST)
Delivered-To: [e-mail]
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by segue.merit.edu (Postfix) with ESMTP id 3EA1B5DDEC for <[e-mail]>; Wed, 27 Nov 2002 12:42:06 -0500 (EST)
Received: from tom3 (useraq74.uk.uudial.com [62.188.136.134]) by colossus.systems.pipex.net (Postfix) with SMTP id 382BC16023687 for <[e-mail]>; Wed, 27 Nov 2002 17:42:04 +0000 (GMT)
Message-ID: <013c01c2963c$4d20e200$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>
Subject: bgp18  WG Last Call FSM MIB enumerations
Date: Wed, 27 Nov 2002 17:40:39 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

The FSM makes several references to putting values into MIB objects
and while some of the values are defined, eg FSM error or Hold Timer
expired, I can find no definition of the following in any of the BGP
documents, MIB or otherwise.
  connect retry expired
  TCP disconnect
  administrative down
  collision detect closure
  Call Collision cease
  collision detected and dump connection
  Administrative stop
I believe an implementation needs to be told these values somewhere
and that there should be a reference to that place in bgp18.


Tom Petch
[e-mail]






Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA12891 for <[e-mail]>; Wed, 27 Nov 2002 08:09:16 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 7A5FD9127F; Wed, 27 Nov 2002 08:08:39 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3FF1291280; Wed, 27 Nov 2002 08:08:39 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0532C9127F for <[e-mail]>; Wed, 27 Nov 2002 08:08:37 -0500 (EST)
Received: by segue.merit.edu (Postfix) id DCF9F5DEB2; Wed, 27 Nov 2002 08:08:37 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 5B1425DE4C for <[e-mail]>; Wed, 27 Nov 2002 08:08:37 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08165; Wed, 27 Nov 2002 08:05:53 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-dynamic-cap-03.txt
Date: Wed, 27 Nov 2002 08:05:52 -0500
Sender: [e-mail]
Precedence: bulk

--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		: Dynamic Capability for BGP-4
	Author(s)	: E. Chen, S. Sangli
	Filename	: draft-ietf-idr-dynamic-cap-03.txt
	Pages		: 6
	Date		: 2002-11-26
	
This document defines a new BGP capability termed 'Dynamic
Capability', which would allow the dynamic update of capabilities
over an established BGP session. This capability would facilitate
non-disruptive capability changes by BGP speakers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-dynamic-cap-03.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-dynamic-cap-03.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-dynamic-cap-03.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-dynamic-cap-03.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA21191 for <[e-mail]>; Tue, 26 Nov 2002 08:18:40 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 551369125C; Tue, 26 Nov 2002 08:18:19 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0BBA59125D; Tue, 26 Nov 2002 08:18:17 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE7509125C for <[e-mail]>; Tue, 26 Nov 2002 08:17:53 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D00025DF5B; Tue, 26 Nov 2002 08:17:53 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 538C45DF55 for <[e-mail]>; Tue, 26 Nov 2002 08:17:53 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29756; Tue, 26 Nov 2002 08:15:09 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-cease-subcode-02.txt
Date: Tue, 26 Nov 2002 08:15:09 -0500
Sender: [e-mail]
Precedence: bulk

--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		: Subcodes for BGP Cease Notification Message
	Author(s)	: E. Chen, V. Gillet
	Filename	: draft-ietf-idr-cease-subcode-02.txt
	Pages		: 4
	Date		: 2002-11-25
	
This document defines several subcodes for the BGP Cease NOTIFICATION
message that would provide more information to aid network operators
in co-relating network events and diagnosing BGP peering issues.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-cease-subcode-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-cease-subcode-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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-cease-subcode-02.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-cease-subcode-02.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA23885 for <[e-mail]>; Mon, 25 Nov 2002 16:10:13 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 700BC91248; Mon, 25 Nov 2002 16:09:54 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 45D2991249; Mon, 25 Nov 2002 16:09:54 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 04FF791248 for <[e-mail]>; Mon, 25 Nov 2002 16:09:53 -0500 (EST)
Received: by segue.merit.edu (Postfix) id E735E5DF3A; Mon, 25 Nov 2002 16:09:52 -0500 (EST)
Delivered-To: [e-mail]
Received: from cmail.packetcom.com (mr200a.caspiannetworks.com [63.108.173.139]) by segue.merit.edu (Postfix) with ESMTP id 660335DEFC for <[e-mail]>; Mon, 25 Nov 2002 16:09:52 -0500 (EST)
Received: from caspiannetworks.com ([172.17.48.103]) by cmail.packetcom.com (Mirapoint Messaging Server MOS 3.2.0-GA) with ESMTP id ABP03240; Mon, 25 Nov 2002 13:09:41 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 25 Nov 2002 16:14:49 -0800
From: jeff pickering <[e-mail]>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "John G. Scudder" <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: WG minutes
References: <[e-mail]> <p05200f3bba02f7aee015@[10.0.174.107]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Can the GR implementation report be sent to the list?

"John G. Scudder" wrote:

> At 12:43 PM -0800 11/21/02, Yakov Rekhter wrote:
> >Folks,
> >
> >Attached are the WG minutes.
> >
> >Yakov.
>
> A couple of comments below.
>
> --John
>
> >==========================================================
> >BGP Graceful Restart Implementation Report
> >John Scudder
> >
> >  o Survey sent out a few months ago, implemations from
> >    these folks (did I miss one??):
> >
> >    Cisco, IPinfusion, Redabck, Riverstone, Tenor, Juniper
>
> You got 'em all.
>
> >==========================================================
> >Secure Origin BGP
> >Alvaro Retana
> [...]
> >Jeff Haas: Because paths aren't signed, still problems exist.
> >John Scudder: Spec is better than anything, have to draw line
> >   between bullet-proof and something deployable.
>
> s/anything/nothing/
>
> It would be nice if this were true as written. :-)
>
> --John



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA27056 for <[e-mail]>; Thu, 21 Nov 2002 16:56:53 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 730669121F; Thu, 21 Nov 2002 16:56:34 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B19491225; Thu, 21 Nov 2002 16:56:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F99D9121F for <[e-mail]>; Thu, 21 Nov 2002 16:56:32 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 9E5A45E021; Thu, 21 Nov 2002 16:56:32 -0500 (EST)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id 205B85DEB9 for <[e-mail]>; Thu, 21 Nov 2002 16:56:32 -0500 (EST)
Received: from [10.0.174.107] (dhcp-64-101-214-208.cisco.com [64.101.214.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA02577; Thu, 21 Nov 2002 16:56:28 -0500 (EST)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05200f3bba02f7aee015@[10.0.174.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 21 Nov 2002 16:06:17 -0500
To: Yakov Rekhter <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: WG minutes
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 12:43 PM -0800 11/21/02, Yakov Rekhter wrote:
>Folks,
>
>Attached are the WG minutes.
>
>Yakov.

A couple of comments below.

--John

>==========================================================
>BGP Graceful Restart Implementation Report
>John Scudder
>
>  o Survey sent out a few months ago, implemations from
>    these folks (did I miss one??):
>
>    Cisco, IPinfusion, Redabck, Riverstone, Tenor, Juniper

You got 'em all.

>==========================================================
>Secure Origin BGP
>Alvaro Retana
[...]
>Jeff Haas: Because paths aren't signed, still problems exist.
>John Scudder: Spec is better than anything, have to draw line
>   between bullet-proof and something deployable.

s/anything/nothing/

It would be nice if this were true as written. :-)

--John


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA24828 for <[e-mail]>; Thu, 21 Nov 2002 15:44:19 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1508491305; Thu, 21 Nov 2002 15:43:58 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE41D9130C; Thu, 21 Nov 2002 15:43:57 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0BF5191305 for <[e-mail]>; Thu, 21 Nov 2002 15:43:56 -0500 (EST)
Received: by segue.merit.edu (Postfix) id E08C05DF4B; Thu, 21 Nov 2002 15:43:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 3F3A15DDAB for <[e-mail]>; Thu, 21 Nov 2002 15:43:55 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gALKhsS37192 for <[e-mail]>; Thu, 21 Nov 2002 12:43:54 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: WG minutes
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 21 Nov 2002 12:43:54 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

Attached are the WG minutes. 

Yakov.
------------------------------------------------------------
IDR WG Meeting Minutes 11/18/2002
Chair: Yakov Rekhter <[e-mail]>
Recorder: Danny McPherson <[e-mail]>

===================================================
Document Status Update - Yakov Rekhter

 o RFC 2842bis published as draft standard RFC 3392

 o draft-ietf-idr-md5-keys-00 WG Last Call Ended in May 2002,
   current status (as shown by the IETF ID Tracker) is DEAD

 o draft-ietf-idr-bgp4-18.txt in WG Last Call now.  
   69 comments over 2 months.  Thanks to Andrew 
   Lang for keeping track.

 o Looking for volunteers for update to 1773 & 1774,
   which is required for base spec advancement.
   
 o Need to advance BGP MIB.  Currently needs minor 
   fixes to security section.  Looking for WG last 
   call end of Nov/early Dec

  o bgp-vuln accepted as WG document.  

  o No other progress is permitted to be made in the 
    WG until base spec advances.




===================================================
 
 The BGP TTL Security Hack -- Dave Meyer
 
 
 o draft-gill-btsh-00.txt

 o Vijay Gill, John Heasley, Dave Meyer authors

 o Mechanisms proposed in draft can be used to 
   mitigate large number of DOS attacks on port 179 
   
 o TCP 4 tuple easy to discover, then just overload 
   the RP.  Don't have to own the router or anything 
   in the path to impact the routing system.

 o Is there anything short of crypto to mitigate attacks?

 o Aware of No way to spoof TTL.

 o Assumes vast majority of EBGP peerings are between 
   directly adjacent router.

 o Set TTL to 255 and if receive TTL is not 254 toss packet.

 o TTL value of 1 won't work per ttl 0 value can be 
   engineered.

 o Then use receive path ACL to only pass receive packets 
   to route processor if TTL is in this range.  If not, 
   silently discard.

 o Common practice to filter loopback IPs on the 
   network/AS edge.  Configured on per-peer basis.

 o Only works unless both peers implement

 o Protection of infrastruture beyond this requires 
   encyption-oriented mechanisms.

Dave Question to WG:  Will this break anything?

Question from floor: Why wasn't this in the very beginning?
[hahah]

John Scudder: Good idea, should be WG draft, but where (here
  or RPSEC?)?

Yakov Rekhter: How is this related to MD5 signature?

AD/Alex Zinin: BGP Specific mechanisms belong in IDR WG.
  Need consensus from WG to accept as WG item.  Should it
  wait on RPSEC to finish requirements document?  Probably
  not?

Jeff Haas:  Thinks it belongs in RPSEC per it could be 
  used generically for lots of stuff.

AD/Alex Zinin: Agree, but if we want to do it here for BGP 
  then it's OK to document it here.

Dave Meyer:  Needs to be more than BCP peer local check 
  for BEGP multi-hop has to be changed.

Yakov Rekhter:  Can WG accept now or must we wait?

AD/Alex Zinin: WG should put in updated charter queue 
  and progress thereafter.

Yakov Rekhter:  Vendors can still implement now.

Yakov R. to Dave Meyer:  Keep updated, we'll add to 
  charter after base spec is done.

==========================================================

BGP Custom Decision Process --  Alvaro Retana

 o draft-retana-bgp-custom-decision-00.txt

 o Alvaro Retana & Russ White authors

 o Need for explicit/flexible route selection 
   mechanism and not employ non-deterministic 
   ROUTER_ID and similar randomness, etc...


Draft Proposes:

 o Locally siginificant metric that can be inserted 
   anywhere in selection process.

 o non-transitive extended community, knowna as "cost 
   community", looks like this:

    Point of Insertion - value of attribute after 
      which to be inserted.
    Community ID - so that multiple communities can 
      be used.
    Cost - lowest cost preferred.

 o Must be deployed ubiquitously throughout AS.

Question:  Non-trans so it only works for IBGP side.
Alvaro Retana: Yes.

Comment: Capability support is needed to allevaite 
  IBGP deployment issue?
Alvaro Retana: Perhaps.

Question: Any issue with Route Reflector in the middle?
Alvaro Retana: No issue.  Also, talks of aggregation of 
  communities.

Questions: Non-transitive so what are route reflector issues?
Yakov Rekhter: Non-transitive community v. non-transitive 
  attribute.  Alvaro is talking of community, not attribute.

Alvaro Question to WG: Would like to progress as WG but 
  knows we have to wait on charter update.

Question:  What can this do that LOCAL_PREF can't do?
Alvaro Retana: Lots.  Need to prefer one exit but not 
  absolutely like LOCAL_PREF.

==========================================================

BGP Graceful Restart Implementation Report 
John Scudder

 o Survey sent out a few months ago, implemations from
   these folks (did I miss one??):

   Cisco, IPinfusion, Redabck, Riverstone, Tenor, Juniper

Question from John to WG/Chair: Should an implementation 
report be published and submitted to WG?  Should I do this 
under my own name per base spec hold-up?

Question:  Any feedback on needing to tweak grace period?
John Scudder: No.

Yakov Rekhter: This & Extended communities straight to IESG 
  Can we make THIS an WG document?

AD/Alex Zini: Can make WG document, can NOT progress until 
  base spec is complete.

==========================================================
Advertisement of Multiple Paths in BGP
John Scudder

 o Introduces mechanism to permit advertisement of multiple 
   paths for a single prefix.
 
 o New Capability TBD, no data

 o If capability is advertised, NLRI uses new encoding.
  
 o Adds flags (one octet) and identifier (two octets) to 
    usual NLRI

Changes versus -00 rev:

 o Path (route) is identified by (ID,prefix)

 o Flags fields added in new version:  
    
     FirstPath - implicit withdraw
     LastPath - hint to run decision process
     BestPath - moved from ID

 o ID of 65535 means explicit withdrawal of all paths
   
 o Removed dependency on MP-BGP

New Changes:  

 o Instead of LastPath use EndofRIB marker.
  (has to do with BGP update packing and 
   attribute packaging)

 o Editorial

Motivations: 

 o MED Oscillation Fix 

   - Med Oscillation Documente in RFC 3345

   - Currently proposed fixes reduce oscillation but introduce 
     deployment considerations.
  
   - Enke Chen's Best-External Advertisement solution.

   - All reduce risk but none eliminate.

   - Full-mesh IBGP doesn't oscillate.  
 
    - RRs (or confed) hide many clients and can only 
      advertise one route under current semantics.

    - Any full solution to oscillation requires advertisement 
      of multiple paths.  
      
 o Other References:

    - draft-walton--bgp-rotue-oscillation-stop
    - draft-wilfong-ibgp-oscillation

Proposal:

 o Would like to move forward and determine what 
   algorithm should be used to advertise additional 
   paths.  Probably not necessary for interoperability 
   but have to agree on path advertisement semantics.


Also Useful to enable Multi-Path IBGP

 o Add Path also introduces clean way to do 
   IBGP multi-path.

 o Could get rid of RFC 3107, which only assists 
   labeled routes.


Proposals:

 o Make add-path a WG document (taking BGP Base spec 
   hold-up into consideration)

 o Will publish-02 document

 o Need folks to implement & deploy!

Kireeti Kompella: What effect does this have on current 
  way of doing implicit withdraw?

John Scudder: None, we're not doing away with it.

Question: What are the scalability implications of 
  advertising multiple paths?
John Scudder: Depends on path advertisement algorithm.


==========================================================
Secure Origin BGP
Alvaro Retana

 o draft-ng-sobgp-bgp-extensions-00

 o Lots of discussion in RPSEC.  
 
 o James Ng - Editor of current draft

 o Document is still a work in progress.  

 o Need participation from vendors & operators.  
   Needs lots of participation from everyone 
   to implement

 o Please read the draft.

SoBGP Operation:  

 o Verify orign of advertisment
 o Verify origin of prefixes
 o Check the path

 o Flexible & very necessary to allow each AS to 
   decide what level of verification & checking.

 o Any solution MUST be incrementlly deployable.

 o This solution Does NOT protect:  peering sessions
   between routers.

 o BGP Attribute authentication
 
 o Does NOT Thanism to verify full validity of the AS_PATH.  
   Can be checked to see if it is possible.  
   
 o Introduces Topology Map concept to address who 
   neighbor are.

 o Scalability concerns per Added extra protocol information, 
   increases overhead, obviously.

Defines New BGP Message - Type 6(?)

 o Used to carry security information within the protocol.
   can also be carried outside of bgp.

*** bunch more details in the draft, need to read it!


Propose:

 o Add to the new WG charter to include BGP Security 
   work as work item

 o First step should be requirements document.  Should 
   probably come from RPSEC.

Question:  Helpful if you would address motivation
Alvaro Retana:  To verify that originator is authorized 
  to announce the route.

Comments: Sigcomm2002 papers talks about route advertisements 
  in error, etc...  Good reference.

Jeff Haas:  Problem is that this proposal doesn't provide 
  protection against active attack.  This provides protection 
  against things that COULD show up.
Russ White: If you read draft operation you can only spoof
  with a valid path.  
Jeff Haas: Because paths aren't signed, still problems exist.
John Scudder: Spec is better than anything, have to draw line 
  between bullet-proof and something deployable.

Alvaro Retana: Need to work on requirements first!

Comment:  Scalability issue.  Need to build chain of trust
  perhaps instead.
Alvaro Retana:  Don't need path keys, need origin keys.

Vince Fuller: How is this going to be any more acceptable
  than past work that providers shot down?  What makes this 
  more interesting?
Alvaro Retana:  Not a provider, none cared to comment...
Vince Fuller: Should look to IOPS work requirements from a 
  few years back.

Alvaro Retana:  Everyone is more paranoid abnout secutiy
  now, good motivater!

Comment:  Backfitting security is a problem, it always
    is.  What do you put in a router?  Should this be there?
    How much can a router do?  Less security and better other
    stuff may become a choice.  Lots of coinflicts.

John Scudder: Appealing because it can be deployed 
     incrementally.

Comment:  Has another proposal but will take it to RPSEC.

Russ White: Note that you CAN offload security processing 
  on other boxes with this proposal.


===============================================================
Open Discussion...


John Scudder: Question on Base Spec holding up all other
  work.  When will Last Last call happen?

Yakov Rekhter: Don't know.  This is just WG Last Call and 
  then IESG comments, then IETF Last Call.  Can't give 
  ANY current date.

AD/Alex Zinin: Can't give hard dates.  The process will be 
  finished when the process is finished.  Not that IESG is 
  holding up work, just part of normal draft review process.  
  Comments will be sent back to WG and it's up to WG to 
  decide how fast we can address.

Yakov Rekhter: How long will it take IESG to look at 
  document?

AD/Alex Zinin:  Three parts to process: 

  1 AD review
  2 To IESG, IETF Last Call issued.
    if comments back to WG.
  3 No comments, to IESG telechat within two weeks.
    Someone on IESG may defer but can only happen for 
    two weeks.  With consent of chair can be deferred 
    for two more but that's max.  Comments need to be 
    addressed by authors/wg and resubmit to IETF last 
    call.

    When comments are provided back to WG and Addressed 
    and document goes back to IESG it is normally not the 
    case that new comments will arise from IESG.  They try 
    to be consistent and only supply one set of comments.

Yakov Rekhter:  Lack of progress in IETF Standards Track 
   doesn't mean you can't still discuss, implement, deploy, etc..

Meeting Adjourned


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA23430 for <[e-mail]>; Thu, 21 Nov 2002 14:59:20 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 545AF91303; Thu, 21 Nov 2002 14:56:41 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B92A912FF; Thu, 21 Nov 2002 14:56:41 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 03E11912FD for <[e-mail]>; Thu, 21 Nov 2002 14:56:35 -0500 (EST)
Received: by segue.merit.edu (Postfix) id E4F705E653; Thu, 21 Nov 2002 14:56:35 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id BB44A5E651 for <[e-mail]>; Thu, 21 Nov 2002 14:56:35 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18ExR6-000GBM-00; Thu, 21 Nov 2002 11:56:28 -0800
Date: Thu, 21 Nov 2002 14:55:10 -0500
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: "John G. Scudder" <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>, [e-mail]
Subject: Re: Authentication in draft-ietf-idr-bgp4-18.txt - resend
In-Reply-To: <p05200f2aba02ace4edac@[10\.0\.174\.107]>
References:  <[e-mail] > <[e-mail]> <[e-mail]> <p05200f2aba02ace4edac@[10.0.174.107]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

I agree with John here.
I don't think there will be problems in the IESG
with TCP MD5 as the authentication mechanism.

Alex.

Thursday, November 21, 2002, 11:20:30 AM, John G. Scudder wrote:
> At 10:20 AM -0500 11/21/02, Jeffrey Haas wrote:
>>On Thu, Nov 21, 2002 at 10:01:21AM -0500, Alex Zinin wrote:
>>  >  What I was trying to say is that 1264 requires an
>>>   authentication scheme (also expected during the IESG
>>>   review, btw) for a routing proto spec to be advanced,
>>
>>The point I was trying to ask - perhaps too obtusely - is that
>>TCP MD5 is not a bgp authentication mechanism.  Is it sufficient
>>to secure the transport stream to satisfy this requirement?

> I certainly see the reason for your concern.  My take on it is that 
> not only is there no technical reason to reject TCP MD5 as an 
> authentication mechanism, but as Curtis recently pointed out, there 
> is a technical _requirement_ that BGP's security mechanism be 
> transport-based.  Call me a Pollyanna, but I think that this should 
> be sufficient to satisfy the standards process and that it would make 
> no sense to reject it because of artificial layering concerns.

> So based on common sense, it seems to me that we are borrowing 
> trouble if we get preemptively worried about this point.

> --John




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA23296 for <[e-mail]>; Thu, 21 Nov 2002 14:54:50 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id C2F3F91300; Thu, 21 Nov 2002 14:53:53 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7520A9130A; Thu, 21 Nov 2002 14:53:50 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CBBC891303 for <[e-mail]>; Thu, 21 Nov 2002 14:53:05 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A98025E64D; Thu, 21 Nov 2002 14:53:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by segue.merit.edu (Postfix) with ESMTP id 440AC5E054 for <[e-mail]>; Thu, 21 Nov 2002 14:53:05 -0500 (EST)
Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id gALJpq0p022691; Thu, 21 Nov 2002 14:51:52 -0500 (EST)
Date: Thu, 21 Nov 2002 14:51:52 -0500 (EST)
From: Scott Bradner <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: revised Security Consideration section
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> You can't progress an RFC with a reference to a draft in it.

nit 

You can't progress an RFC with a normative reference to a draft in it.

Scott


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA23186 for <[e-mail]>; Thu, 21 Nov 2002 14:50:33 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E3C0C91319; Thu, 21 Nov 2002 14:49:01 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2EED391357; Thu, 21 Nov 2002 14:48:54 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9FCD491351 for <[e-mail]>; Thu, 21 Nov 2002 14:48:48 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 96EE95DE08; Thu, 21 Nov 2002 14:48:32 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 0C3D65E664 for <[e-mail]>; Thu, 21 Nov 2002 14:47:55 -0500 (EST)
Received: by sentry.gw.tislabs.com; id OAA09362; Thu, 21 Nov 2002 14:48:03 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma009334; Thu, 21 Nov 02 14:47:34 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id gALJlOF20874; Thu, 21 Nov 2002 14:47:24 -0500 (EST)
Date: Thu, 21 Nov 2002 14:47:24 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail]
Subject: RE: revised Security Consideration section
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

>however valuable this WIP is.

valuable, schmaluable.  It's required.  

How would a complete cut-and-paste help?  We'd have to re-last-call the
bgp spec.  (!)

--Sandy



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA23171 for <[e-mail]>; Thu, 21 Nov 2002 14:50:09 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 2E12791344; Thu, 21 Nov 2002 14:47:10 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9584B9133E; Thu, 21 Nov 2002 14:46:51 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BAF4A9134B for <[e-mail]>; Thu, 21 Nov 2002 14:45:04 -0500 (EST)
Received: by segue.merit.edu (Postfix) id BB1585DE13; Thu, 21 Nov 2002 14:45:04 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 06B965DEEB for <[e-mail]>; Thu, 21 Nov 2002 14:45:03 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18ExG1-000F8B-00 for [e-mail]; Thu, 21 Nov 2002 11:45:02 -0800
Date: Thu, 21 Nov 2002 14:43:39 -0500
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: Re: revised Security Consideration section
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

In fact, I just realized that since the sec doc will
be published as INFO (it does not specify any proto
changes), the spec cannot refer to it normatively,
as this would prevent it from going to the STD track.
So, it has to be informative.

-- 
Alex

Thursday, November 21, 2002, 2:37:42 PM, Alex Zinin wrote:
> Yakov,

>> Perhaps Alex could comment on whether the IESG would insist
>> on making Sandy's draft a normative reference, or whether
>> it would be ok with the IESG to make it non-normative.

> I'll check with the IESG. My personal opinion is that
> informational is fine here. However, I don't think this
> changes much, as the real IESG requirement is for both
> docs to be progressed together... Logically they both
> will be considered as a single doc anyways, i.e., if
> there are any problems with the security doc, the spec
> itself will need to wait until those are fixed.

> Alex




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA23156 for <[e-mail]>; Thu, 21 Nov 2002 14:49:48 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8F6AF9133F; Thu, 21 Nov 2002 14:46:36 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A23D191344; Thu, 21 Nov 2002 14:43:45 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B3D579133E for <[e-mail]>; Thu, 21 Nov 2002 14:42:46 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A3FB95DEEB; Thu, 21 Nov 2002 14:42:46 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 30F225DE13 for <[e-mail]>; Thu, 21 Nov 2002 14:42:46 -0500 (EST)
Received: by sentry.gw.tislabs.com; id OAA09005; Thu, 21 Nov 2002 14:42:55 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma008976; Thu, 21 Nov 02 14:42:18 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id gALJg8S20359; Thu, 21 Nov 2002 14:42:08 -0500 (EST)
Date: Thu, 21 Nov 2002 14:42:08 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail]
Subject: RE: revised Security Consideration section
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

>        As I understand it, Sandy's draft is intended to
>be informational.  Therefore, it is not clear to me that
>the reference needs to be normative.  As a non normative
>(as it is in your proposal).

The problem is procedural, I think.

You can't progress an RFC with a reference to a draft in it.
And your RFC must include a security considerations section, so
you can't leave it out entirely.

And, as John pointed out, the whole draft is about BGP, so there's
no taking out just the BGP portions.

--Sandy


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA23058 for <[e-mail]>; Thu, 21 Nov 2002 14:48:29 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 617159132C; Thu, 21 Nov 2002 14:40:43 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CA0C91334; Thu, 21 Nov 2002 14:40:42 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0196091327 for <[e-mail]>; Thu, 21 Nov 2002 14:39:05 -0500 (EST)
Received: by segue.merit.edu (Postfix) id DDD4A5DEEB; Thu, 21 Nov 2002 14:39:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id B4B8E5DE61 for <[e-mail]>; Thu, 21 Nov 2002 14:39:05 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18ExAC-000Ef9-00; Thu, 21 Nov 2002 11:39:00 -0800
Date: Thu, 21 Nov 2002 14:37:42 -0500
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: "Gray, Eric" <[e-mail]>, "'John G. Scudder'" <[e-mail]>, <[e-mail]>
Subject: Re: revised Security Consideration section
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Yakov,

> Perhaps Alex could comment on whether the IESG would insist
> on making Sandy's draft a normative reference, or whether
> it would be ok with the IESG to make it non-normative.

I'll check with the IESG. My personal opinion is that
informational is fine here. However, I don't think this
changes much, as the real IESG requirement is for both
docs to be progressed together... Logically they both
will be considered as a single doc anyways, i.e., if
there are any problems with the security doc, the spec
itself will need to wait until those are fixed.

Alex




Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA22992 for <[e-mail]>; Thu, 21 Nov 2002 14:46:00 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 4960A9130E; Thu, 21 Nov 2002 14:37:49 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1345691314; Thu, 21 Nov 2002 14:37:43 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6DCE59130E for <[e-mail]>; Thu, 21 Nov 2002 14:37:34 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 53DAF5DE61; Thu, 21 Nov 2002 14:37:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 0CC255DE13 for <[e-mail]>; Thu, 21 Nov 2002 14:37:34 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <WYS12FZL>; Thu, 21 Nov 2002 14:37:33 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Alex Zinin'" <[e-mail]>, "Gray, Eric" <[e-mail]>
Cc: "'John G. Scudder'" <[e-mail]>, [e-mail]
Subject: RE: revised Security Consideration section
Date: Thu, 21 Nov 2002 14:37:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Okay.

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Alex Zinin [mailto:[e-mail]]
> Sent: Thursday, November 21, 2002 2:32 PM
> To: Gray, Eric
> Cc: 'John G. Scudder'; [e-mail]
> Subject: Re: revised Security Consideration section
> 
> Eric,
> 
>   Some thoughts on this:
> 
>   1. The BGP spec will need a security analysis as well
>      as the authentication mechanism in order to go through
>      the IESG.
> 
>   2. Security analysis needs to be specified either in
>      the spec itself or in a separate document. If in a
>      separate document, both docs will need to go to
>      the IESG at the same time (otherwise there is no
>      way to ensure that the requirement for a useful
>      Security Considerations section is ever satisfied).
> 
>   3. Sandy's doc seems to have a quite thorough BGP security
>      analysis. If the WG believes that more work needs
>      to be done on it, then it does not matter whether
>      the text is cut-n-pasted or stays in a separate doc.
>      If the WG believes that the security text is good
>      enough, then again it doesn't matter and we go back
>      to point 2 above.
> 
>   Thanks.
> 
> --
> Alex
> 
> Thursday, November 21, 2002, 2:16:41 PM, Gray, Eric wrote:
> > Yeah, John, as indicated in crossed-mail, I am suggesting
> > either a complete cut-and-paste or a non-normative reference.
> > Sandy's draft seems only just now to have become a WG draft
> > (the reference given by Yakov does not yet exist).  I see
> > no reason why the BGP draft needs to be held up pending
> > WG, IESG and IETF processing of Sandy's informational WIP,
> > however valuable this WIP is.
> 
> > Obviously, it would be easier to make it a non-normative
> > reference.
> 
> > An analysis of protocol vulnerability is inherently an
> > open-ended task.  I believe the key reason for rev'ing
> > the BGP specification was to update it according to what
> > implementations really do and to push it forward to
> > Draft Standard status - not solve the world's problems.  :-)
> 
> > BGP exists and is massively deployed. Clearly understanding
> > BGP security risks is important, and this information is
> > increasingly useful as it is made available.  But let's not
> > block other important work in the process...
> 
> > Eric W. Gray
> > Systems Architect
> > Celox Networks, Inc.
> > [e-mail]
> > 508 305 7214
> 
> 
> >> -----Original Message-----
> >> From: John G. Scudder [mailto:[e-mail]]
> >> Sent: Thursday, November 21, 2002 1:09 PM
> >> To: Gray, Eric
> >> Cc: 'Yakov Rekhter'; [e-mail]
> >> Subject: RE: revised Security Consideration section
> >>
> >> Eric,
> >>
> >> At 11:42 AM -0500 11/21/02, Gray, Eric wrote:
> >> >     This change is okay with me only if the reference to
> >> >XXX is non normative.  Otherwise, I would suggest literally
> >> >including those aspects of Sandy's draft that you think
> >> >apply to BGP as part of the BGP RFC-to-be.
> >>
> >> The title of Sandy's draft is "BGP Security Vulnerabilities
> >> Analysis", and the Security Considerations sections says in part:
> >>
> >>    This entire memo is about security, describing an analysis of the
> >>    vulnerabilities that exist in the BGP protocol.
> >>
> >> Clearly the entire thing applies to BGP.  Are you suggesting a
> >> complete cut-n-paste of the draft into the main spec?  If not, what
> >> are you suggesting?
> >>
> >> FWIW, the proposal as written is OK by me.
> >>
> >> Regards,
> >>
> >> --John



Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA22797 for <[e-mail]>; Thu, 21 Nov 2002 14:39:18 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 7DDCC912FE; Thu, 21 Nov 2002 14:34:35 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 887DC912FC; Thu, 21 Nov 2002 14:34:33 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 69663912FE for <[e-mail]>; Thu, 21 Nov 2002 14:33:43 -0500 (EST)
Received: by segue.merit.edu (Postfix) id BA3735E65D; Thu, 21 Nov 2002 14:33:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id A9B795E65F for <[e-mail]>; Thu, 21 Nov 2002 14:33:07 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18Ex4Q-000EDb-00; Thu, 21 Nov 2002 11:33:03 -0800
Date: Thu, 21 Nov 2002 14:31:30 -0500
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Cc: "'John G. Scudder'" <[e-mail]>, [e-mail]
Subject: Re: revised Security Consideration section
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Eric,

  Some thoughts on this:

  1. The BGP spec will need a security analysis as well
     as the authentication mechanism in order to go through
     the IESG.

  2. Security analysis needs to be specified either in
     the spec itself or in a separate document. If in a
     separate document, both docs will need to go to
     the IESG at the same time (otherwise there is no
     way to ensure that the requirement for a useful
     Security Considerations section is ever satisfied).

  3. Sandy's doc seems to have a quite thorough BGP security
     analysis. If the WG believes that more work needs
     to be done on it, then it does not matter whether
     the text is cut-n-pasted or stays in a separate doc.
     If the WG believes that the security text is good
     enough, then again it doesn't matter and we go back
     to point 2 above.

  Thanks.

-- 
Alex

Thursday, November 21, 2002, 2:16:41 PM, Gray, Eric wrote:
> Yeah, John, as indicated in crossed-mail, I am suggesting
> either a complete cut-and-paste or a non-normative reference.
> Sandy's draft seems only just now to have become a WG draft
> (the reference given by Yakov does not yet exist).  I see
> no reason why the BGP draft needs to be held up pending
> WG, IESG and IETF processing of Sandy's informational WIP,
> however valuable this WIP is.

> Obviously, it would be easier to make it a non-normative 
> reference.

> An analysis of protocol vulnerability is inherently an
> open-ended task.  I believe the key reason for rev'ing 
> the BGP specification was to update it according to what
> implementations really do and to push it forward to
> Draft Standard status - not solve the world's problems.  :-)

> BGP exists and is massively deployed. Clearly understanding
> BGP security risks is important, and this information is
> increasingly useful as it is made available.  But let's not
> block other important work in the process...

> Eric W. Gray
> Systems Architect
> Celox Networks, Inc.
> [e-mail]
> 508 305 7214


>> -----Original Message-----
>> From: John G. Scudder [mailto:[e-mail]]
>> Sent: Thursday, November 21, 2002 1:09 PM
>> To: Gray, Eric
>> Cc: 'Yakov Rekhter'; [e-mail]
>> Subject: RE: revised Security Consideration section
>> 
>> Eric,
>> 
>> At 11:42 AM -0500 11/21/02, Gray, Eric wrote:
>> >     This change is okay with me only if the reference to
>> >XXX is non normative.  Otherwise, I would suggest literally
>> >including those aspects of Sandy's draft that you think
>> >apply to BGP as part of the BGP RFC-to-be.
>> 
>> The title of Sandy's draft is "BGP Security Vulnerabilities
>> Analysis", and the Security Considerations sections says in part:
>> 
>>    This entire memo is about security, describing an analysis of the
>>    vulnerabilities that exist in the BGP protocol.
>> 
>> Clearly the entire thing applies to BGP.  Are you suggesting a
>> complete cut-n-paste of the draft into the main spec?  If not, what
>> are you suggesting?
>> 
>> FWIW, the proposal as written is OK by me.
>> 
>> Regards,
>> 
>> --John




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA22414 for <[e-mail]>; Thu, 21 Nov 2002 14:26:29 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id F33D6912F8; Thu, 21 Nov 2002 14:26:14 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8A78912FA; Thu, 21 Nov 2002 14:26:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A2928912F8 for <[e-mail]>; Thu, 21 Nov 2002 14:26:12 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 841C75E057; Thu, 21 Nov 2002 14:26:12 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 23CDF5DE61 for <[e-mail]>; Thu, 21 Nov 2002 14:26:12 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gALJQ3S28171; Thu, 21 Nov 2002 11:26:03 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Cc: "'John G. Scudder'" <[e-mail]>, [e-mail]
Subject: Re: revised Security Consideration section 
In-Reply-To: Your message of "Thu, 21 Nov 2002 14:16:41 EST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 21 Nov 2002 11:26:03 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Eric,

> Yeah, John, as indicated in crossed-mail, I am suggesting
> either a complete cut-and-paste or a non-normative reference.
> Sandy's draft seems only just now to have become a WG draft
> (the reference given by Yakov does not yet exist).  I see
> no reason why the BGP draft needs to be held up pending
> WG, IESG and IETF processing of Sandy's informational WIP,
> however valuable this WIP is.
> 
> Obviously, it would be easier to make it a non-normative 
> reference.
> 
> An analysis of protocol vulnerability is inherently an
> open-ended task.  I believe the key reason for rev'ing 
> the BGP specification was to update it according to what
> implementations really do and to push it forward to
> Draft Standard status - not solve the world's problems.  :-)
> 
> BGP exists and is massively deployed. Clearly understanding
> BGP security risks is important, and this information is
> increasingly useful as it is made available.  But let's not
> block other important work in the process...

Perhaps Alex could comment on whether the IESG would insist
on making Sandy's draft a normative reference, or whether
it would be ok with the IESG to make it non-normative.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA22251 for <[e-mail]>; Thu, 21 Nov 2002 14:20:20 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B526791304; Thu, 21 Nov 2002 14:18:38 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 330C1912FB; Thu, 21 Nov 2002 14:18:38 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3517191304 for <[e-mail]>; Thu, 21 Nov 2002 14:18:27 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8D2B95E04E; Thu, 21 Nov 2002 14:18:22 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id F1FD45E64D for <[e-mail]>; Thu, 21 Nov 2002 14:16:42 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <WYS12F4V>; Thu, 21 Nov 2002 14:16:42 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'John G. Scudder'" <[e-mail]>
Cc: [e-mail]
Subject: RE: revised Security Consideration section
Date: Thu, 21 Nov 2002 14:16:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Yeah, John, as indicated in crossed-mail, I am suggesting
either a complete cut-and-paste or a non-normative reference.
Sandy's draft seems only just now to have become a WG draft
(the reference given by Yakov does not yet exist).  I see
no reason why the BGP draft needs to be held up pending
WG, IESG and IETF processing of Sandy's informational WIP,
however valuable this WIP is.

Obviously, it would be easier to make it a non-normative 
reference.

An analysis of protocol vulnerability is inherently an
open-ended task.  I believe the key reason for rev'ing 
the BGP specification was to update it according to what
implementations really do and to push it forward to
Draft Standard status - not solve the world's problems.  :-)

BGP exists and is massively deployed. Clearly understanding
BGP security risks is important, and this information is
increasingly useful as it is made available.  But let's not
block other important work in the process...

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: John G. Scudder [mailto:[e-mail]]
> Sent: Thursday, November 21, 2002 1:09 PM
> To: Gray, Eric
> Cc: 'Yakov Rekhter'; [e-mail]
> Subject: RE: revised Security Consideration section
> 
> Eric,
> 
> At 11:42 AM -0500 11/21/02, Gray, Eric wrote:
> >	This change is okay with me only if the reference to
> >XXX is non normative.  Otherwise, I would suggest literally
> >including those aspects of Sandy's draft that you think
> >apply to BGP as part of the BGP RFC-to-be.
> 
> The title of Sandy's draft is "BGP Security Vulnerabilities
> Analysis", and the Security Considerations sections says in part:
> 
>    This entire memo is about security, describing an analysis of the
>    vulnerabilities that exist in the BGP protocol.
> 
> Clearly the entire thing applies to BGP.  Are you suggesting a
> complete cut-n-paste of the draft into the main spec?  If not, what
> are you suggesting?
> 
> FWIW, the proposal as written is OK by me.
> 
> Regards,
> 
> --John


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA20090 for <[e-mail]>; Thu, 21 Nov 2002 13:09:58 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1CBE9912F0; Thu, 21 Nov 2002 13:09:30 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D62E5912F1; Thu, 21 Nov 2002 13:09:29 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CE714912F0 for <[e-mail]>; Thu, 21 Nov 2002 13:09:28 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B24215DE47; Thu, 21 Nov 2002 13:09:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id 39B8A5DE30 for <[e-mail]>; Thu, 21 Nov 2002 13:09:28 -0500 (EST)
Received: from [10.0.174.107] (dhcp-64-101-214-208.cisco.com [64.101.214.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA18809; Thu, 21 Nov 2002 13:09:23 -0500 (EST)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05200f2cba02bdc94e38@[10.0.174.107]>
In-Reply-To:  <[e-mail] >
References:  <[e-mail] >
Date: Thu, 21 Nov 2002 13:08:46 -0500
To: "Gray, Eric" <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: RE: revised Security Consideration section
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Eric,

At 11:42 AM -0500 11/21/02, Gray, Eric wrote:
>	This change is okay with me only if the reference to
>XXX is non normative.  Otherwise, I would suggest literally
>including those aspects of Sandy's draft that you think
>apply to BGP as part of the BGP RFC-to-be.

The title of Sandy's draft is "BGP Security Vulnerabilities 
Analysis", and the Security Considerations sections says in part:

   This entire memo is about security, describing an analysis of the
   vulnerabilities that exist in the BGP protocol.

Clearly the entire thing applies to BGP.  Are you suggesting a 
complete cut-n-paste of the draft into the main spec?  If not, what 
are you suggesting?

FWIW, the proposal as written is OK by me.

Regards,

--John


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA19115 for <[e-mail]>; Thu, 21 Nov 2002 12:36:23 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 753C291224; Thu, 21 Nov 2002 12:36:07 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B46D912EF; Thu, 21 Nov 2002 12:36:07 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 165E091224 for <[e-mail]>; Thu, 21 Nov 2002 12:36:06 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0225D5DDD8; Thu, 21 Nov 2002 12:36:06 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id B41695DDB7 for <[e-mail]>; Thu, 21 Nov 2002 12:36:05 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <WYS12FHA>; Thu, 21 Nov 2002 12:36:05 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: RE: revised Security Consideration section 
Date: Thu, 21 Nov 2002 12:36:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Yakov,

	This is exactly what I am concerned about.  Given
the delta in processing state between the current BGP
draft and Sandy's draft, this means potentially sitting
on the BGP draft for some time to come.

	As I understand it, Sandy's draft is intended to
be informational.  Therefore, it is not clear to me that
the reference needs to be normative.  As a non normative
reference, it could be referred to as a work in progress
(as it is in your proposal).

	If the reference must be normative for some reason,
it should be sufficient to include a snap-shot of Sandy's 
draft as an additional appendix and refer to that appendix 
in the security considerations section.


Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Thursday, November 21, 2002 11:47 AM
> To: Gray, Eric
> Cc: [e-mail]
> Subject: Re: revised Security Consideration section
> 
> Eric,
> 
> >
> > 	This change is okay with me only if the reference to
> > XXX is non normative.  Otherwise, I would suggest literally
> > including those aspects of Sandy's draft that you think
> > apply to BGP as part of the BGP RFC-to-be.  Otherwise, we
> > are back into the mode where advancing the BGP effort is an
> > open-ended proposition.
> 
> Sandy's draft (with appropriate revisions, if necessary) will be
> advanced together with the base BGP spec.
> 
> Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA17683 for <[e-mail]>; Thu, 21 Nov 2002 11:50:00 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 97981912ED; Thu, 21 Nov 2002 11:49:36 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60F209121E; Thu, 21 Nov 2002 11:49:36 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B65C0912ED for <[e-mail]>; Thu, 21 Nov 2002 11:48:26 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 06B2E5E058; Thu, 21 Nov 2002 11:48:24 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 9DB8B5E5E6 for <[e-mail]>; Thu, 21 Nov 2002 11:47:26 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gALGlPS11200; Thu, 21 Nov 2002 08:47:25 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Cc: [e-mail]
Subject: Re: revised Security Consideration section 
In-Reply-To: Your message of "Thu, 21 Nov 2002 11:42:25 EST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 21 Nov 2002 08:47:25 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Eric,

> 
> 	This change is okay with me only if the reference to
> XXX is non normative.  Otherwise, I would suggest literally
> including those aspects of Sandy's draft that you think 
> apply to BGP as part of the BGP RFC-to-be.  Otherwise, we
> are back into the mode where advancing the BGP effort is an
> open-ended proposition.

Sandy's draft (with appropriate revisions, if necessary) will be 
advanced together with the base BGP spec.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA17459 for <[e-mail]>; Thu, 21 Nov 2002 11:43:06 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BB74F91297; Thu, 21 Nov 2002 11:42:28 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 87087912ED; Thu, 21 Nov 2002 11:42:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4889E91297 for <[e-mail]>; Thu, 21 Nov 2002 11:42:27 -0500 (EST)
Received: by segue.merit.edu (Postfix) id DE7355DFF1; Thu, 21 Nov 2002 11:42:26 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 936EB5DE08 for <[e-mail]>; Thu, 21 Nov 2002 11:42:26 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <WYS1210H>; Thu, 21 Nov 2002 11:42:26 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: revised Security Consideration section
Date: Thu, 21 Nov 2002 11:42:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Yakov,

	This change is okay with me only if the reference to
XXX is non normative.  Otherwise, I would suggest literally
including those aspects of Sandy's draft that you think 
apply to BGP as part of the BGP RFC-to-be.  Otherwise, we
are back into the mode where advancing the BGP effort is an
open-ended proposition.

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Thursday, November 21, 2002 11:14 AM
> To: [e-mail]
> Subject: revised Security Consideration section
> 
> Folks,
> 
> Here is a proposed revision for the Security Consideration section.
> This revision reflects the discussion on making TCP MD5 a "MUST", and
> also on including by reference the BGP vulnerabilities analysis in the
> base spec.
> 
>    The authentication mechanism that an implementation of BGP MUST
>    support is specified in [RFC2385]. The authentication provided by
>    this mechanism could be done on a per peer basis.
> 
>    Security issues with BGP routing information dissemination are
>    discussed in [XXX].
> 
> 
>    [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
>    Signature Option", RFC2385, August 1998.
> 
>    [XXX] Murphy, S., "BGP Security Vulnerabilities Analysis",
>    draft-ietf-idr-bgp-vuln-00.txt, work in progress
> 
> 
> Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA17322 for <[e-mail]>; Thu, 21 Nov 2002 11:37:08 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 7259A9121D; Thu, 21 Nov 2002 11:36:41 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3610491297; Thu, 21 Nov 2002 11:36:41 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E929E9121D for <[e-mail]>; Thu, 21 Nov 2002 11:36:39 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D5C715DFF1; Thu, 21 Nov 2002 11:36:39 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 8E8CD5DE95 for <[e-mail]>; Thu, 21 Nov 2002 11:36:39 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <WYS1219T>; Thu, 21 Nov 2002 11:36:39 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>
Cc: [e-mail], Alex Zinin <[e-mail]>
Subject: RE: Authentication in draft-ietf-idr-bgp4-18.txt - resend
Date: Thu, 21 Nov 2002 11:36:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Jeffrey,

	The big sticking point is over whether or not RFC
1264 actually states that a routing protocol must explicitly
require support of some authentication mechanism.  Completely
independent of the precise wording of RFC 1264, don't you
agree that any authentication mechanism we might talk about
will only work if it is implemented by cooperating systems?

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Thursday, November 21, 2002 10:20 AM
> To: Alex Zinin
> Cc: [e-mail]
> Subject: Re: Authentication in draft-ietf-idr-bgp4-18.txt - resend
> 
> On Thu, Nov 21, 2002 at 10:01:21AM -0500, Alex Zinin wrote:
> >  What I was trying to say is that 1264 requires an
> >  authentication scheme (also expected during the IESG
> >  review, btw) for a routing proto spec to be advanced,
> 
> The point I was trying to ask - perhaps too obtusely - is that
> TCP MD5 is not a bgp authentication mechanism.  Is it sufficient
> to secure the transport stream to satisfy this requirement?
> 
> The requirement states:
> "The security architecture must include mechanisms for authenticating
>  routing messages and may include other forms of protection."
> 
> I don't know how this has been traditionally interpreted.
> 
> > Alex
> 
> --
> Jeff Haas
> NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA16884 for <[e-mail]>; Thu, 21 Nov 2002 11:22:27 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D76E4912EE; Thu, 21 Nov 2002 11:21:58 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F8E0912ED; Thu, 21 Nov 2002 11:21:58 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 69525912EC for <[e-mail]>; Thu, 21 Nov 2002 11:21:54 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 24F755E02E; Thu, 21 Nov 2002 11:21:54 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 7D0C75DEDC for <[e-mail]>; Thu, 21 Nov 2002 11:21:53 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gALGLoS09127; Thu, 21 Nov 2002 08:21:50 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Tom Petch" <[e-mail]>
Cc: "idr" <[e-mail]>
Subject: Re: BGP18-FSM-terminology 
In-Reply-To: Your message of "Thu, 14 Nov 2002 18:29:16 GMT." <002101c28c0b$d8f10c00$0301a8c0@tom3> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 21 Nov 2002 08:21:50 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Tom,

> I think a standard description would serve us better instead of using
> the  following different ways (which I take all to refer to the same
> entity):
> 
> delayBGP open timer
> BGP delay open timer
> BGP open delay timer
> delay open timer
> BGP delay timer
> 
> I suggest Open Delay timer (with those capitals)

Your suggestion is accepted.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA16871 for <[e-mail]>; Thu, 21 Nov 2002 11:22:07 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1E65F912EB; Thu, 21 Nov 2002 11:21:39 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF753912EC; Thu, 21 Nov 2002 11:21:38 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C9C1D912EB for <[e-mail]>; Thu, 21 Nov 2002 11:21:37 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 9D6005E056; Thu, 21 Nov 2002 11:21:37 -0500 (EST)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id EA4AF5E02E for <[e-mail]>; Thu, 21 Nov 2002 11:21:36 -0500 (EST)
Received: from [10.0.174.107] (dhcp-64-101-214-208.cisco.com [64.101.214.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA13431; Thu, 21 Nov 2002 11:21:01 -0500 (EST)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05200f2aba02ace4edac@[10.0.174.107]>
In-Reply-To: <[e-mail]>
References:  <[e-mail] > <[e-mail]> <[e-mail]>
Date: Thu, 21 Nov 2002 11:20:30 -0500
To: Jeffrey Haas <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: Authentication in draft-ietf-idr-bgp4-18.txt - resend
Cc: Alex Zinin <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 10:20 AM -0500 11/21/02, Jeffrey Haas wrote:
>On Thu, Nov 21, 2002 at 10:01:21AM -0500, Alex Zinin wrote:
>  >  What I was trying to say is that 1264 requires an
>>   authentication scheme (also expected during the IESG
>>   review, btw) for a routing proto spec to be advanced,
>
>The point I was trying to ask - perhaps too obtusely - is that
>TCP MD5 is not a bgp authentication mechanism.  Is it sufficient
>to secure the transport stream to satisfy this requirement?

I certainly see the reason for your concern.  My take on it is that 
not only is there no technical reason to reject TCP MD5 as an 
authentication mechanism, but as Curtis recently pointed out, there 
is a technical _requirement_ that BGP's security mechanism be 
transport-based.  Call me a Pollyanna, but I think that this should 
be sufficient to satisfy the standards process and that it would make 
no sense to reject it because of artificial layering concerns.

So based on common sense, it seems to me that we are borrowing 
trouble if we get preemptively worried about this point.

--John


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA16638 for <[e-mail]>; Thu, 21 Nov 2002 11:15:08 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 0339F9129A; Thu, 21 Nov 2002 11:14:12 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABC3F912EB; Thu, 21 Nov 2002 11:14:11 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 56DE89129A for <[e-mail]>; Thu, 21 Nov 2002 11:14:10 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3E6425E056; Thu, 21 Nov 2002 11:14:10 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id A1A235DE32 for <[e-mail]>; Thu, 21 Nov 2002 11:14:09 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gALGE9S08351 for <[e-mail]>; Thu, 21 Nov 2002 08:14:09 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: revised Security Consideration section
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 21 Nov 2002 08:14:09 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

Here is a proposed revision for the Security Consideration section.
This revision reflects the discussion on making TCP MD5 a "MUST", and 
also on including by reference the BGP vulnerabilities analysis in the
base spec.

   The authentication mechanism that an implementation of BGP MUST
   support is specified in [RFC2385]. The authentication provided by
   this mechanism could be done on a per peer basis.

   Security issues with BGP routing information dissemination are 
   discussed in [XXX].


   [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 
   Signature Option", RFC2385, August 1998.

   [XXX] Murphy, S., "BGP Security Vulnerabilities Analysis",
   draft-ietf-idr-bgp-vuln-00.txt, work in progress


Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA16614 for <[e-mail]>; Thu, 21 Nov 2002 11:14:31 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id C388491295; Thu, 21 Nov 2002 11:14:08 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8AFC29129A; Thu, 21 Nov 2002 11:14:08 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D153E91295 for <[e-mail]>; Thu, 21 Nov 2002 11:14:05 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 9F23A5E04E; Thu, 21 Nov 2002 11:14:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 9630D5DE32 for <[e-mail]>; Thu, 21 Nov 2002 11:14:04 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <WYS1215P>; Thu, 21 Nov 2002 11:14:04 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, Justin Fletcher <[e-mail]>
Cc: Alex Zinin <[e-mail]>, [e-mail]
Subject: RE: Authentication in draft-ietf-idr-bgp4-18.txt 
Date: Thu, 21 Nov 2002 11:14:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

What RFC actually states as a requirement - as far as I can
tell - is the following:

"The security architecture must include mechanisms for
 authenticating routing messages and may include other 
 forms of protection."

This statement occurs twice (page 2 and page 4) and there is
additional statements to the effect that a statement must be
provided to the IESG - via the Routing AD(s) - as to the 
authentication mechanisms used by the protocol.

While it is almost certain that the intention was that some
mechanism MUST be supported in implementations of a routing
protocol, there is ample opportunity for misunderstanding.
Stating that the "security architecture" must have some form
of authentication is not the same thing as saying that an
implementation must implement this mechanism.  Indeed, given
that the BGP authentication mechanism that seemd previously
to fulfill the RFC 1264 requirement was not implemented, it
seems reasonably clear that most people did not view it as 
an implementation requirement.

However, such a mechanism is needed.  Removing the text that
described BGP authentication removed some degree of ambiguity
since most (if not all) implementations did not implement it.
Many (if not most) actually implemented the TCP MD5 signature
option.

Suddenly declaring existing implementations as non-compliant
is not an issue.  This is a respin of the previous RFC and an
interoperability mode is obvious.  In fact, given that very
many implementations already support TCP MD5 signature option,
it seems likely that use of this interoperability mode has 
already been demonstrated between implementations that do and
do not support this option.


Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, November 20, 2002 7:35 PM
> To: Justin Fletcher
> Cc: Alex Zinin; [e-mail]
> Subject: Re: Authentication in draft-ietf-idr-bgp4-18.txt
> 
> Justin,
> 
> > On Wed, 20 Nov 2002, Alex Zinin wrote:
> >
> > > Folks,
> > >
> > >  Now that the BGP-internal authentication has been removed
> > >  from the spec due to lack of implementations, we're left
> > >  with no mandatory authentication mechanism (required by
> > >  RFC1264).
> > >
> > >  It's up to the WG to decide what should be done, but seems
> > >  that saying that implementations MUST implement TCP MD5 would
> > >  be a good solution.
> >
> > I strongly disagree.
> >
> > This would indicate a change in the base specification; any vendor
> > implementation which had been previously compliant would suddenly be
> > non-compliant if TCP MD5 authentication is not supported.
> >
> > In addition, RFC1264 is an informational; I don't believe conformance
> > should be considered as a requirement for a standards-track document.
> >
> > We could recommend implementation of TCP MD5 for authentication,
> > but it certainly shouldn't be mandatory.
> 
> As Alex mentioned in his e-mail RFC1264 *requires* a mandatory
> authentication mechanism. That is, to have a Draft Standard spec
> that doesn't have a mandatory authentication mechanism is *not* an
> option.
> 
> The BGP-internal authentication has been removed because it wasn't
> implemented. So, the only possible mechanism known to me that could
> be used to satisfy the rfc1264 requirement is TCP MD5 (as it provides
> authentication, and has deployed multi-vendor interoperable
> implementations).
> 
> If you are aware of any other possible mechanism that satisfies
> the rfc1264 requirement *and* has deployed multi-vendor interoperable
> implementatations, please mention it, so that we could consider
> it as an alternative to TCP MD5. In the absence of such an
> alternative we have no choice, but to make TCP MD5 mandatory.
> 
> Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15087 for <[e-mail]>; Thu, 21 Nov 2002 10:21:11 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DF58C9128C; Thu, 21 Nov 2002 10:20:44 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8EBF91295; Thu, 21 Nov 2002 10:20:44 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 94C539128C for <[e-mail]>; Thu, 21 Nov 2002 10:20:43 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 82A215E04E; Thu, 21 Nov 2002 10:20:43 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id DFAE35DFA6 for <[e-mail]>; Thu, 21 Nov 2002 10:20:42 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gALFKAn64684; Thu, 21 Nov 2002 10:20:10 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gALFK7C64677; Thu, 21 Nov 2002 10:20:07 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gALFK7q16728; Thu, 21 Nov 2002 10:20:07 -0500 (EST)
Date: Thu, 21 Nov 2002 10:20:07 -0500
From: Jeffrey Haas <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: [e-mail]
Subject: Re: Authentication in draft-ietf-idr-bgp4-18.txt - resend
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Nov 21, 2002 at 10:01:21AM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Nov 21, 2002 at 10:01:21AM -0500, Alex Zinin wrote:
>  What I was trying to say is that 1264 requires an
>  authentication scheme (also expected during the IESG
>  review, btw) for a routing proto spec to be advanced,

The point I was trying to ask - perhaps too obtusely - is that
TCP MD5 is not a bgp authentication mechanism.  Is it sufficient
to secure the transport stream to satisfy this requirement?

The requirement states:
"The security architecture must include mechanisms for authenticating
 routing messages and may include other forms of protection."

I don't know how this has been traditionally interpreted.

> Alex

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA14451 for <[e-mail]>; Thu, 21 Nov 2002 10:05:16 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 217F491296; Thu, 21 Nov 2002 10:04:38 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C62E29128C; Thu, 21 Nov 2002 10:04:37 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B32A9128C for <[e-mail]>; Thu, 21 Nov 2002 10:03:31 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 14E1D5DE6F; Thu, 21 Nov 2002 10:03:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 5CF555E658 for <[e-mail]>; Thu, 21 Nov 2002 10:02:00 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18Esq7-000KqG-00; Thu, 21 Nov 2002 07:01:59 -0800
Date: Thu, 21 Nov 2002 10:01:28 -0500
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Justin Fletcher <[e-mail]>
Cc: [e-mail]
Subject: Re: Authentication in draft-ietf-idr-bgp4-18.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Justin,

 Curtis answered your questions quite well.
 One thing that I wanted to add regarding being compliant:
 since people didn't implement the authentication mechanism
 described in 1771, and TCP MD5 is widely used today, making
 this change in the document will actually increase the level
 of compliancy for the current implementations.

-- 
Alex

Wednesday, November 20, 2002, 9:06:19 PM, Curtis Villamizar wrote:

> In message <Pine.LNX.4.44.0211201604570.5337-100000@riga>, Justin Fletcher writ
> es:
>> On Wed, 20 Nov 2002, Alex Zinin wrote:
>> 
>> > Folks,
>> > 
>> >  Now that the BGP-internal authentication has been removed
>> >  from the spec due to lack of implementations, we're left
>> >  with no mandatory authentication mechanism (required by
>> >  RFC1264).
>> > 
>> >  It's up to the WG to decide what should be done, but seems
>> >  that saying that implementations MUST implement TCP MD5 would
>> >  be a good solution.
>> 
>> I strongly disagree.
>> 
>> This would indicate a change in the base specification; any vendor
>> implementation which had been previously compliant would suddenly be
>> non-compliant if TCP MD5 authentication is not supported.

> Advancing a spec to Draft Standard does not require a unanimous
> decision nor does it require that the spec be limited to features that
> *every* known implementation conforms to.

>> In addition, RFC1264 is an informational; I don't believe conformance
>> should be considered as a requirement for a standards-track document.

> Informational doesn't mean "ignore this document".  The IESG is
> "informing" us of the rules by which we have to play to have any
> chance of advancing a document.

>> We could recommend implementation of TCP MD5 for authentication,
>> but it certainly shouldn't be mandatory.
>> -- 
>> Justin Fletcher
>> Proficient Networks, Inc.

> We have to make it manditory or the IESG will toss the document back
> at the WG.  The vast majority of router implementations of BGP have
> TCP MD5.  I'm not sure if there is a BSD implementation of TCP MD5
> floating around.

> Curtis




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA14439 for <[e-mail]>; Thu, 21 Nov 2002 10:04:59 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D6BC691292; Thu, 21 Nov 2002 10:04:37 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 851E891295; Thu, 21 Nov 2002 10:04:37 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9DF2091292 for <[e-mail]>; Thu, 21 Nov 2002 10:03:31 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 2E6B75E64E; Thu, 21 Nov 2002 10:03:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 889E65E655 for <[e-mail]>; Thu, 21 Nov 2002 10:01:53 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18Espz-000KqB-00; Thu, 21 Nov 2002 07:01:52 -0800
Date: Thu, 21 Nov 2002 10:01:21 -0500
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Cc: [e-mail]
Subject: Re: Authentication in draft-ietf-idr-bgp4-18.txt - resend
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Eric,

 What I was trying to say is that 1264 requires an
 authentication scheme (also expected during the IESG
 review, btw) for a routing proto spec to be advanced,
 and the new spec does not have one. TCP MD5 seemed
 like a logical way to fix this, since this is a de
 facto the most widely deployed authentication scheme.

-- 
Alex

Wednesday, November 20, 2002, 4:57:39 PM, Gray, Eric wrote:
> Alex,

>         I think mandating TCP MD5 is a good thing, but 
> I am somewhat surprised at the logic of this assertion.  
> Given that the BGP specification's previously proposed 
> authentication (the one being removed) must not have 
> been exactly mandatory (given that nobody seems to have
> implemented it), I am not sure that the need to mandate
> TCP MD5 follows from the removal of BGP authentication.

>         I believe what you are specifically suggesting is
> that the specification should explicitly state that TCP
> MD5 authentication must be supported by implementations 
> (IAW RFC 1264).

>         I suggest changing the following (Appendix E, 3rd
> paragraph):

>    A local system may protect its BGP connections by using the TCP MD5
>    Signature Option [RFC2385].

> to read:

>    A local system may need to protect its BGP connections by using 
>    the TCP MD5 Signature Option [RFC2385].  For this reason, a BGP
>    implementation MUST support this option.

> Eric W. Gray
> Systems Architect
> Celox Networks, Inc.
> [e-mail]
> 508 305 7214


>> -----Original Message-----
>> From: Alex Zinin [mailto:[e-mail]]
>> Sent: Wednesday, November 20, 2002 3:52 PM
>> To: [e-mail]
>> Subject: Authentication in draft-ietf-idr-bgp4-18.txt
>> 
>> Folks,
>> 
>>  Now that the BGP-internal authentication has been removed
>>  from the spec due to lack of implementations, we're left
>>  with no mandatory authentication mechanism (required by
>>  RFC1264).
>> 
>>  It's up to the WG to decide what should be done, but seems
>>  that saying that implementations MUST implement TCP MD5 would
>>  be a good solution.
>> 
>> --
>> Alex




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA13606 for <[e-mail]>; Thu, 21 Nov 2002 09:37:55 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BCA859123A; Thu, 21 Nov 2002 09:37:18 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90ABD9128C; Thu, 21 Nov 2002 09:37:18 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 84E699123A for <[e-mail]>; Thu, 21 Nov 2002 09:37:16 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 53EC05DE32; Thu, 21 Nov 2002 09:37:16 -0500 (EST)
Delivered-To: [e-mail]
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by segue.merit.edu (Postfix) with ESMTP id AC3FB5DE03 for <[e-mail]>; Thu, 21 Nov 2002 09:37:15 -0500 (EST)
Received: (from heas@localhost) by guelah.shrubbery.net (8.11.6/8.11.1) id gALEbCg20179; Thu, 21 Nov 2002 14:37:12 GMT
Date: Thu, 21 Nov 2002 14:37:11 +0000
From: john heasley <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Authentication in draft-ietf-idr-bgp4-18.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Nov 21, 2002 at 09:29:44AM -0500
X-note: live free, or die!
X-homer: mmmm, forbidden doughnut.
Sender: [e-mail]
Precedence: bulk

Thu, Nov 21, 2002 at 09:29:44AM -0500, [e-mail]:
> >This is problematic since we're relying on a transport mechanism
> >and not something within the protocol.
> 
> and 
> 
> >IMHO It makes perfect sense to mandate TCP MD5.

in case its not obvious, we (operations folk) demand md5.

> Procedurally, does it make sense or look better if that mandate appears
> in the applicability statement?

please stick to documenting existing.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA13428 for <[e-mail]>; Thu, 21 Nov 2002 09:30:55 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6A82391208; Thu, 21 Nov 2002 09:30:07 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB6DE9123A; Thu, 21 Nov 2002 09:30:06 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B774291208 for <[e-mail]>; Thu, 21 Nov 2002 09:30:04 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 230275E054; Thu, 21 Nov 2002 09:30:03 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 507755E056 for <[e-mail]>; Thu, 21 Nov 2002 09:30:01 -0500 (EST)
Received: by sentry.gw.tislabs.com; id JAA25183; Thu, 21 Nov 2002 09:30:09 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma025142; Thu, 21 Nov 02 09:29:54 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id gALETit00132; Thu, 21 Nov 2002 09:29:44 -0500 (EST)
Date: Thu, 21 Nov 2002 09:29:44 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail]
Subject: Re: Authentication in draft-ietf-idr-bgp4-18.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

>This is problematic since we're relying on a transport mechanism
>and not something within the protocol.

and 

>IMHO It makes perfect sense to mandate TCP MD5.

Procedurally, does it make sense or look better if that mandate appears
in the applicability statement?

--Sandy


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA10154 for <[e-mail]>; Wed, 20 Nov 2002 21:11:00 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 4445B912E8; Wed, 20 Nov 2002 21:09:03 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF7CC912EF; Wed, 20 Nov 2002 21:09:02 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 22F4F912E8 for <[e-mail]>; Wed, 20 Nov 2002 21:08:57 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 10ADF5DDB6; Wed, 20 Nov 2002 21:08:57 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 3E9A75DE96 for <[e-mail]>; Wed, 20 Nov 2002 21:08:56 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id VAA05526; Wed, 20 Nov 2002 21:06:19 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Justin Fletcher <[e-mail]>
Cc: Alex Zinin <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Authentication in draft-ietf-idr-bgp4-18.txt 
In-reply-to: Your message of "Wed, 20 Nov 2002 16:20:02 PST." <Pine.LNX.4.44.0211201604570.5337-100000@riga> 
Date: Wed, 20 Nov 2002 21:06:19 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <Pine.LNX.4.44.0211201604570.5337-100000@riga>, Justin Fletcher writ
es:
> On Wed, 20 Nov 2002, Alex Zinin wrote:
> 
> > Folks,
> > 
> >  Now that the BGP-internal authentication has been removed
> >  from the spec due to lack of implementations, we're left
> >  with no mandatory authentication mechanism (required by
> >  RFC1264).
> > 
> >  It's up to the WG to decide what should be done, but seems
> >  that saying that implementations MUST implement TCP MD5 would
> >  be a good solution.
> 
> I strongly disagree.
> 
> This would indicate a change in the base specification; any vendor
> implementation which had been previously compliant would suddenly be
> non-compliant if TCP MD5 authentication is not supported.

Advancing a spec to Draft Standard does not require a unanimous
decision nor does it require that the spec be limited to features that
*every* known implementation conforms to.

> In addition, RFC1264 is an informational; I don't believe conformance
> should be considered as a requirement for a standards-track document.

Informational doesn't mean "ignore this document".  The IESG is
"informing" us of the rules by which we have to play to have any
chance of advancing a document.

> We could recommend implementation of TCP MD5 for authentication,
> but it certainly shouldn't be mandatory.
> -- 
> Justin Fletcher
> Proficient Networks, Inc.

We have to make it manditory or the IESG will toss the document back
at the WG.  The vast majority of router implementations of BGP have
TCP MD5.  I'm not sure if there is a BSD implementation of TCP MD5
floating around.

Curtis


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA08244 for <[e-mail]>; Wed, 20 Nov 2002 20:35:24 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 13F10912E6; Wed, 20 Nov 2002 20:34:51 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D57ED912E7; Wed, 20 Nov 2002 20:34:50 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B013912E6 for <[e-mail]>; Wed, 20 Nov 2002 20:34:49 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 86E2C5DDED; Wed, 20 Nov 2002 20:34:49 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id B211B5DDB6 for <[e-mail]>; Wed, 20 Nov 2002 20:34:48 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id UAA05307; Wed, 20 Nov 2002 20:32:10 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: Alex Zinin <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Authentication in draft-ietf-idr-bgp4-18.txt 
In-reply-to: Your message of "Wed, 20 Nov 2002 16:04:35 EST." <[e-mail]> 
Date: Wed, 20 Nov 2002 20:32:10 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Jeffrey Haas writes:
> On Wed, Nov 20, 2002 at 03:52:26PM -0500, Alex Zinin wrote:
> >  It's up to the WG to decide what should be done, but seems
> >  that saying that implementations MUST implement TCP MD5 would
> >  be a good solution.
> 
> This is problematic since we're relying on a transport mechanism
> and not something within the protocol.
> 
> > Alex
> 
> -- 
> Jeff Haas 
> NextHop Technologies


You can't protect against a TCP RST error (denial of service attack)
with something within the protocol (solely within the TCP data
stream).  So if you want it to work (assumed requirement) it has to be
in the transport mechanism.

We already clearly indicate that TCP is required.

Curtis



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA05186 for <[e-mail]>; Wed, 20 Nov 2002 19:36:21 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8EE71912E4; Wed, 20 Nov 2002 19:35:55 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4FE1C912E5; Wed, 20 Nov 2002 19:35:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 135E4912E4 for <[e-mail]>; Wed, 20 Nov 2002 19:35:54 -0500 (EST)
Received: by segue.merit.edu (Postfix) id DFDC85E02F; Wed, 20 Nov 2002 19:35:53 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 810E25DFD2 for <[e-mail]>; Wed, 20 Nov 2002 19:35:53 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gAL0ZBS58346; Wed, 20 Nov 2002 16:35:11 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Justin Fletcher <[e-mail]>
Cc: Alex Zinin <[e-mail]>, [e-mail]
Subject: Re: Authentication in draft-ietf-idr-bgp4-18.txt 
In-Reply-To: Your message of "Wed, 20 Nov 2002 16:20:02 PST." <Pine.LNX.4.44.0211201604570.5337-100000@riga> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 20 Nov 2002 16:35:11 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Justin,

> On Wed, 20 Nov 2002, Alex Zinin wrote:
> 
> > Folks,
> > 
> >  Now that the BGP-internal authentication has been removed
> >  from the spec due to lack of implementations, we're left
> >  with no mandatory authentication mechanism (required by
> >  RFC1264).
> > 
> >  It's up to the WG to decide what should be done, but seems
> >  that saying that implementations MUST implement TCP MD5 would
> >  be a good solution.
> 
> I strongly disagree.
> 
> This would indicate a change in the base specification; any vendor
> implementation which had been previously compliant would suddenly be
> non-compliant if TCP MD5 authentication is not supported.
> 
> In addition, RFC1264 is an informational; I don't believe conformance
> should be considered as a requirement for a standards-track document.
> 
> We could recommend implementation of TCP MD5 for authentication,
> but it certainly shouldn't be mandatory.

As Alex mentioned in his e-mail RFC1264 *requires* a mandatory
authentication mechanism. That is, to have a Draft Standard spec
that doesn't have a mandatory authentication mechanism is *not* an
option.

The BGP-internal authentication has been removed because it wasn't
implemented. So, the only possible mechanism known to me that could
be used to satisfy the rfc1264 requirement is TCP MD5 (as it provides
authentication, and has deployed multi-vendor interoperable
implementations).

If you are aware of any other possible mechanism that satisfies
the rfc1264 requirement *and* has deployed multi-vendor interoperable
implementatations, please mention it, so that we could consider
it as an alternative to TCP MD5. In the absence of such an
alternative we have no choice, but to make TCP MD5 mandatory.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA04378 for <[e-mail]>; Wed, 20 Nov 2002 19:20:48 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B78BB912E3; Wed, 20 Nov 2002 19:20:23 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86FD9912E4; Wed, 20 Nov 2002 19:20:23 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8556E912E3 for <[e-mail]>; Wed, 20 Nov 2002 19:20:22 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 7250C5E029; Wed, 20 Nov 2002 19:20:22 -0500 (EST)
Delivered-To: [e-mail]
Received: from earthquake.proficient.net (fe0-0-access-1-sfo.proficient.net [65.209.247.5]) by segue.merit.edu (Postfix) with ESMTP id 073515DF61 for <[e-mail]>; Wed, 20 Nov 2002 19:20:22 -0500 (EST)
Received: from riga ([10.0.0.25]) by earthquake.proficient.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.4905); Wed, 20 Nov 2002 16:20:20 -0800
Date: Wed, 20 Nov 2002 16:20:02 -0800 (PST)
From: Justin Fletcher <[e-mail]>
X-X-Sender: jfletcher@riga
To: Alex Zinin <[e-mail]>
Cc: [e-mail]
Subject: Re: Authentication in draft-ietf-idr-bgp4-18.txt
In-Reply-To: <[e-mail]>
Message-ID: <Pine.LNX.4.44.0211201604570.5337-100000@riga>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-OriginalArrivalTime: 21 Nov 2002 00:20:20.0818 (UTC) FILETIME=[C6E58B20:01C290F3]
Sender: [e-mail]
Precedence: bulk

On Wed, 20 Nov 2002, Alex Zinin wrote:

> Folks,
> 
>  Now that the BGP-internal authentication has been removed
>  from the spec due to lack of implementations, we're left
>  with no mandatory authentication mechanism (required by
>  RFC1264).
> 
>  It's up to the WG to decide what should be done, but seems
>  that saying that implementations MUST implement TCP MD5 would
>  be a good solution.

I strongly disagree.

This would indicate a change in the base specification; any vendor
implementation which had been previously compliant would suddenly be
non-compliant if TCP MD5 authentication is not supported.

In addition, RFC1264 is an informational; I don't believe conformance
should be considered as a requirement for a standards-track document.

We could recommend implementation of TCP MD5 for authentication,
but it certainly shouldn't be mandatory.
-- 
Justin Fletcher
Proficient Networks, Inc.



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA28017 for <[e-mail]>; Wed, 20 Nov 2002 17:20:22 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 5AE4B912E0; Wed, 20 Nov 2002 17:20:00 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2CF2F912DE; Wed, 20 Nov 2002 17:19:59 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AB456912E1 for <[e-mail]>; Wed, 20 Nov 2002 17:19:54 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 876AF5DE80; Wed, 20 Nov 2002 17:19:54 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 3EF5B5DE9E for <[e-mail]>; Wed, 20 Nov 2002 17:19:54 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <WYS12BMZ>; Wed, 20 Nov 2002 17:19:53 -0500
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail], [e-mail]
Subject: set origin egp <asNum>
Date: Wed, 20 Nov 2002 17:19:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

does anybody know what the <asNum> does in "set origin egp <asNum>" ???  it
seems to do nothing

thnx


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA26728 for <[e-mail]>; Wed, 20 Nov 2002 16:58:03 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 0A6B2912DD; Wed, 20 Nov 2002 16:57:45 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C9EA5912DE; Wed, 20 Nov 2002 16:57:44 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8754D912DD for <[e-mail]>; Wed, 20 Nov 2002 16:57:43 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 712175DF56; Wed, 20 Nov 2002 16:57:43 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 3153C5DF43 for <[e-mail]>; Wed, 20 Nov 2002 16:57:43 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <WYS12BJP>; Wed, 20 Nov 2002 16:57:42 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: [e-mail], "'Alex Zinin'" <[e-mail]>
Subject: RE: Authentication in draft-ietf-idr-bgp4-18.txt - resend
Date: Wed, 20 Nov 2002 16:57:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Alex,

	I think mandating TCP MD5 is a good thing, but 
I am somewhat surprised at the logic of this assertion.  
Given that the BGP specification's previously proposed 
authentication (the one being removed) must not have 
been exactly mandatory (given that nobody seems to have
implemented it), I am not sure that the need to mandate
TCP MD5 follows from the removal of BGP authentication.

	I believe what you are specifically suggesting is
that the specification should explicitly state that TCP
MD5 authentication must be supported by implementations 
(IAW RFC 1264).

	I suggest changing the following (Appendix E, 3rd
paragraph):

   A local system may protect its BGP connections by using the TCP MD5
   Signature Option [RFC2385].

to read:

   A local system may need to protect its BGP connections by using 
   the TCP MD5 Signature Option [RFC2385].  For this reason, a BGP
   implementation MUST support this option.

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Alex Zinin [mailto:[e-mail]]
> Sent: Wednesday, November 20, 2002 3:52 PM
> To: [e-mail]
> Subject: Authentication in draft-ietf-idr-bgp4-18.txt
> 
> Folks,
> 
>  Now that the BGP-internal authentication has been removed
>  from the spec due to lack of implementations, we're left
>  with no mandatory authentication mechanism (required by
>  RFC1264).
> 
>  It's up to the WG to decide what should be done, but seems
>  that saying that implementations MUST implement TCP MD5 would
>  be a good solution.
> 
> --
> Alex



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA25968 for <[e-mail]>; Wed, 20 Nov 2002 16:43:32 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 39604912DB; Wed, 20 Nov 2002 16:43:05 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 00BAD912DC; Wed, 20 Nov 2002 16:43:04 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A815C912DB for <[e-mail]>; Wed, 20 Nov 2002 16:43:03 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 84D5C5DFDF; Wed, 20 Nov 2002 16:43:03 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 40B335DFE1 for <[e-mail]>; Wed, 20 Nov 2002 16:43:03 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <WYS12BHM>; Wed, 20 Nov 2002 16:43:02 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Alex Zinin'" <[e-mail]>, [e-mail]
Subject: RE: Authentication in draft-ietf-idr-bgp4-18.txt
Date: Wed, 20 Nov 2002 16:42:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Alex,

	I think mandating TCP MD5 is a good thing, but 
I am somewhat surprised at the logic of this assertion.  
Given that the BGP specification's previously proposed 
authentication (the one being removed) must not have 
been exactly mandatory (given that nobody seems to have
implemented it), I am not sure that the need to mandate
TCP MD5 follows from the removal of BGP authentication.

	I believe what you are specifically suggesting is
that the specification should explicitly state that TCP
MD5 authentication must be supported by implementation 
(IAW RFC 1264).

	I suggest changing the following (Appendix E, 3rd
paragraph):

   A local system may protect its BGP connections by using the TCP MD5
   Signature Option [RFC2385].

to read:

   A local system may need top protect its BGP connections by using 
   the TCP MD5 Signature Option [RFC2385].  For this reason, a BGP
   implementation MUST support this option.

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Alex Zinin [mailto:[e-mail]]
> Sent: Wednesday, November 20, 2002 3:52 PM
> To: [e-mail]
> Subject: Authentication in draft-ietf-idr-bgp4-18.txt
> 
> Folks,
> 
>  Now that the BGP-internal authentication has been removed
>  from the spec due to lack of implementations, we're left
>  with no mandatory authentication mechanism (required by
>  RFC1264).
> 
>  It's up to the WG to decide what should be done, but seems
>  that saying that implementations MUST implement TCP MD5 would
>  be a good solution.
> 
> --
> Alex



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA24408 for <[e-mail]>; Wed, 20 Nov 2002 16:13:47 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id AA6E0912D7; Wed, 20 Nov 2002 16:13:29 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7BE02912D8; Wed, 20 Nov 2002 16:13:29 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 068A2912D7 for <[e-mail]>; Wed, 20 Nov 2002 16:13:27 -0500 (EST)
Received: by segue.merit.edu (Postfix) id DD3235DFFE; Wed, 20 Nov 2002 16:13:27 -0500 (EST)
Delivered-To: [e-mail]
Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 6595E5DFFA for <[e-mail]>; Wed, 20 Nov 2002 16:13:27 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA16565; Wed, 20 Nov 2002 16:12:48 -0500 (EST)
Date: Wed, 20 Nov 2002 16:12:48 -0500 (EST)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: Curtis Villamizar <[e-mail]>
Cc: Alex Zinin <[e-mail]>, [e-mail]
Subject: Re: Authentication in draft-ietf-idr-bgp4-18.txt 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> IMHO It makes perfect sense to mandate TCP MD5.

Agreed.

Russ


__________________________________
[e-mail] CCIE <>< Grace Alone




Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA24006 for <[e-mail]>; Wed, 20 Nov 2002 16:05:53 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 07CB99120A; Wed, 20 Nov 2002 16:05:14 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3F77912D6; Wed, 20 Nov 2002 16:05:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D05909120A for <[e-mail]>; Wed, 20 Nov 2002 16:05:11 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B5F265DFF2; Wed, 20 Nov 2002 16:05:11 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 2CF825DF5E for <[e-mail]>; Wed, 20 Nov 2002 16:05:11 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gAKL4c546789; Wed, 20 Nov 2002 16:04:38 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gAKL4ZC46782; Wed, 20 Nov 2002 16:04:35 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gAKL4Zo07632; Wed, 20 Nov 2002 16:04:35 -0500 (EST)
Date: Wed, 20 Nov 2002 16:04:35 -0500
From: Jeffrey Haas <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: [e-mail]
Subject: Re: Authentication in draft-ietf-idr-bgp4-18.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Nov 20, 2002 at 03:52:26PM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Nov 20, 2002 at 03:52:26PM -0500, Alex Zinin wrote:
>  It's up to the WG to decide what should be done, but seems
>  that saying that implementations MUST implement TCP MD5 would
>  be a good solution.

This is problematic since we're relying on a transport mechanism
and not something within the protocol.

> Alex

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA23992 for <[e-mail]>; Wed, 20 Nov 2002 16:05:43 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 2AA4A912D6; Wed, 20 Nov 2002 16:05:37 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DDD39912D7; Wed, 20 Nov 2002 16:05:36 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A0E35912D6 for <[e-mail]>; Wed, 20 Nov 2002 16:05:33 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3A2CE5DFF4; Wed, 20 Nov 2002 16:05:33 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 6D2DF5DFF2 for <[e-mail]>; Wed, 20 Nov 2002 16:05:32 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA03555; Wed, 20 Nov 2002 16:02:54 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: [e-mail]
Reply-To: [e-mail]
Subject: Re: Authentication in draft-ietf-idr-bgp4-18.txt 
In-reply-to: Your message of "Wed, 20 Nov 2002 15:52:26 EST." <[e-mail]> 
Date: Wed, 20 Nov 2002 16:02:53 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Alex Zinin writes:
> Folks,
> 
>  Now that the BGP-internal authentication has been removed
>  from the spec due to lack of implementations, we're left
>  with no mandatory authentication mechanism (required by
>  RFC1264).
> 
>  It's up to the WG to decide what should be done, but seems
>  that saying that implementations MUST implement TCP MD5 would
>  be a good solution.
> 
> -- 
> Alex


If the IETF doesn't say so enough customers certainly do that all
implementations seem to have it.  At least I don't know of any
exceptions.

IMHO It makes perfect sense to mandate TCP MD5.

Curtis


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA23301 for <[e-mail]>; Wed, 20 Nov 2002 15:53:15 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 03C1A912D4; Wed, 20 Nov 2002 15:52:48 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD30C912D6; Wed, 20 Nov 2002 15:52:47 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 88CCE912D4 for <[e-mail]>; Wed, 20 Nov 2002 15:52:46 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 6EF1F5DFE9; Wed, 20 Nov 2002 15:52:46 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 47F715DFE7 for <[e-mail]>; Wed, 20 Nov 2002 15:52:46 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18Ebq1-0006Dm-00 for [e-mail]; Wed, 20 Nov 2002 12:52:45 -0800
Date: Wed, 20 Nov 2002 15:52:26 -0500
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: Authentication in draft-ietf-idr-bgp4-18.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Folks,

 Now that the BGP-internal authentication has been removed
 from the spec due to lack of implementations, we're left
 with no mandatory authentication mechanism (required by
 RFC1264).

 It's up to the WG to decide what should be done, but seems
 that saying that implementations MUST implement TCP MD5 would
 be a good solution.

-- 
Alex




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA04867 for <[e-mail]>; Wed, 20 Nov 2002 10:11:58 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 163D6912C2; Wed, 20 Nov 2002 10:11:40 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1B84912C3; Wed, 20 Nov 2002 10:11:39 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C1DA3912C2 for <[e-mail]>; Wed, 20 Nov 2002 10:11:38 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B352C5DFDE; Wed, 20 Nov 2002 10:11:38 -0500 (EST)
Delivered-To: [e-mail]
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by segue.merit.edu (Postfix) with ESMTP id 4CF445DFDD for <[e-mail]>; Wed, 20 Nov 2002 10:11:38 -0500 (EST)
Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id gAKFAOlu017623 for [e-mail]; Wed, 20 Nov 2002 10:10:24 -0500 (EST)
Date: Wed, 20 Nov 2002 10:10:24 -0500 (EST)
From: Scott Bradner <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: IANA considerations in draft-ietf-idr-bgp4-18.txt
Sender: [e-mail]
Precedence: bulk

I think this document should have an IANA Considerations section along the
following lines:

IANA Considerations:
	All extensions to this protocol, including new message types and
Path Attributes MUST only be made using the Standards Action process
defined in [rfc2434].


and add a normative reference to 

[rfc2434] Narten, T., and H. Alvestrand "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998


Scott


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA00781 for <[e-mail]>; Tue, 19 Nov 2002 14:11:57 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D61C69124D; Tue, 19 Nov 2002 14:11:39 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3DAD912A1; Tue, 19 Nov 2002 14:11:39 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9DD189124D for <[e-mail]>; Tue, 19 Nov 2002 14:11:38 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 7EAAD5E33C; Tue, 19 Nov 2002 14:11:38 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id EB31B5E334 for <[e-mail]>; Tue, 19 Nov 2002 14:11:37 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gAJJBaK14918; Tue, 19 Nov 2002 14:11:36 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gAJJBXC14911; Tue, 19 Nov 2002 14:11:33 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gAJJBXO17635; Tue, 19 Nov 2002 14:11:33 -0500 (EST)
Date: Tue, 19 Nov 2002 14:11:33 -0500
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: draft-ietf-idr-bgp4-mibv2-03.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Nov 19, 2002 at 12:37:06PM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Nov 19, 2002 at 12:37:06PM -0500, Natale, Jonathan wrote:
> what about having a standard set: ~= "largest local_pref", "lowest ID",
> etc., and also have some vendor defined ones:
> <vendor-ID><vendor-code><vendor defined description> ???

The issue is that one really wants to know relative ordering.
Strings aren't the best sort of thing for that.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA25735 for <[e-mail]>; Tue, 19 Nov 2002 12:37:26 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 743C69129A; Tue, 19 Nov 2002 12:37:13 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 45E759129B; Tue, 19 Nov 2002 12:37:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D3D09129A for <[e-mail]>; Tue, 19 Nov 2002 12:37:12 -0500 (EST)
Received: by segue.merit.edu (Postfix) id E77FD5DDF6; Tue, 19 Nov 2002 12:37:11 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 9B91A5DF6F for <[e-mail]>; Tue, 19 Nov 2002 12:37:11 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <WYS1H58M>; Tue, 19 Nov 2002 12:37:11 -0500
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: draft-ietf-idr-bgp4-mibv2-03.txt
Date: Tue, 19 Nov 2002 12:37:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

i would recommend against trying to automate something like this

but if someone were to do it, matching the strings would be the least of the
problems

i am assuming the possible strings would be in the MIB(s) ???

what about having a standard set: ~= "largest local_pref", "lowest ID",
etc., and also have some vendor defined ones:
<vendor-ID><vendor-code><vendor defined description> ???



> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]] 
> Sent: Tuesday, November 19, 2002 12:25 PM
> To: Natale, Jonathan
> Cc: '[e-mail]'
> Subject: Re: draft-ietf-idr-bgp4-mibv2-03.txt
> 
> 
> On Tue, Nov 19, 2002 at 12:22:04PM -0500, Natale, Jonathan wrote:
> > thanks, jeff
> > 
> > i think vendor defined text would suffice and be the most extensible
> 
> But its also the hardest to use for automation.
> 
> -- 
> Jeff Haas 
> NextHop Technologies
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA25520 for <[e-mail]>; Tue, 19 Nov 2002 12:33:14 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E18EB91296; Tue, 19 Nov 2002 12:32:37 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 271DE9129A; Tue, 19 Nov 2002 12:32:36 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 53CBA91296 for <[e-mail]>; Tue, 19 Nov 2002 12:32:33 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 394A15DEC0; Tue, 19 Nov 2002 12:32:33 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id A21CF5DDF8 for <[e-mail]>; Tue, 19 Nov 2002 12:32:32 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gAJHWW811908 for [e-mail]; Tue, 19 Nov 2002 12:32:32 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gAJHWSC11901 for <[e-mail]>; Tue, 19 Nov 2002 12:32:28 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gAJHWSV17508 for [e-mail]; Tue, 19 Nov 2002 12:32:28 -0500 (EST)
Date: Tue, 19 Nov 2002 12:32:28 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: suggestion to authors of new extensions
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

We now have two drafts out suggesting that their message type is
going to be 6 - dynamic caps and the sobgp security message.

While rfc 2042 specifically addresses path attributes, I'd suggest
that we should also take the stance that we should use message
code 255 for "not done yet" or "to be assigned by iana/ietf"
extensions.

Its irritating enough to have extensions with unusual gaps in the
numbering schemes.  Lets not do this to the base protocol. :-)

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA25072 for <[e-mail]>; Tue, 19 Nov 2002 12:25:22 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DB81491297; Tue, 19 Nov 2002 12:25:01 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AAE3B91298; Tue, 19 Nov 2002 12:25:01 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A746D91297 for <[e-mail]>; Tue, 19 Nov 2002 12:25:00 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8604C5DF6F; Tue, 19 Nov 2002 12:25:00 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id E86975DEB1 for <[e-mail]>; Tue, 19 Nov 2002 12:24:59 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gAJHOwV11596; Tue, 19 Nov 2002 12:24:58 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gAJHOtC11588; Tue, 19 Nov 2002 12:24:55 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gAJHOtW17479; Tue, 19 Nov 2002 12:24:55 -0500 (EST)
Date: Tue, 19 Nov 2002 12:24:55 -0500
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: draft-ietf-idr-bgp4-mibv2-03.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Nov 19, 2002 at 12:22:04PM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Nov 19, 2002 at 12:22:04PM -0500, Natale, Jonathan wrote:
> thanks, jeff
> 
> i think vendor defined text would suffice and be the most extensible

But its also the hardest to use for automation.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA24918 for <[e-mail]>; Tue, 19 Nov 2002 12:22:33 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 7AA8691295; Tue, 19 Nov 2002 12:22:13 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4216891297; Tue, 19 Nov 2002 12:22:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0164291295 for <[e-mail]>; Tue, 19 Nov 2002 12:22:11 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D95AC5DEDE; Tue, 19 Nov 2002 12:22:11 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 98F7E5DEB1 for <[e-mail]>; Tue, 19 Nov 2002 12:22:11 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <WYS1H563>; Tue, 19 Nov 2002 12:22:11 -0500
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: draft-ietf-idr-bgp4-mibv2-03.txt
Date: Tue, 19 Nov 2002 12:22:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

thanks, jeff

i think vendor defined text would suffice and be the most extensible


> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]] 
> Sent: Tuesday, November 19, 2002 12:09 PM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: draft-ietf-idr-bgp4-mibv2-03.txt
> 
> 
> Jonathon,
> 
> On Tue, Nov 19, 2002 at 10:19:24AM -0500, Natale, Jonathan wrote:
> > I think you had suggested an object to indicate which 
> step/attribute was
> > used to select/not select the route as best.  I think this 
> is a good idea.
> 
> I think operators would find this particularly useful. :-)
> 
> > Has this been formally drafted anywhere?
> 
> Not at the moment.  However, the recent draft:
>     BGP Custom Decision Process 
> (draft-retana-bgp-custom-decision-00.txt)o
> 
> gives a start to this by enumerating route selection steps.
> 
> The biggest obstacle to doing this is formally enumerating the
> route selection steps and permitting them to vary from vendor to
> vendor since no one seems to be interested in getting things to the
> level of 100% consistancy.
> 
> Then again, something kinky (at least in the MIB) could be done
> such that the object contains an index into a table that contains
> the vendor's implementation of route selection.  A dump of that
> table would show what all the steps are.
> 
> Given that vendors allow tweaking of the process via knob in many
> cases, even that is probably not 100% feasible. 
> 
> The best we could probably hope for is a text description of where
> we stopped.
> 
> > I did not see it in
> > draft-ietf-idr-bgp4-mibv2-03.txt, but I may have missed it.
> 
> At this point, I'm not arbitrarily putting stuff in the v2MIB without
> group consensus.  However, given some of the recommendations made at
> the IDR session (e.g. injecting multiple route instances), the
> MIB may require serious tweaking.
> 
> -- 
> Jeff Haas 
> NextHop Technologies
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA24183 for <[e-mail]>; Tue, 19 Nov 2002 12:10:11 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 0B95691292; Tue, 19 Nov 2002 12:09:35 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C52E191294; Tue, 19 Nov 2002 12:09:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AF10991292 for <[e-mail]>; Tue, 19 Nov 2002 12:09:33 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8F84F5DEDE; Tue, 19 Nov 2002 12:09:33 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 3180F5DEB1 for <[e-mail]>; Tue, 19 Nov 2002 12:09:33 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gAJH9VN11121; Tue, 19 Nov 2002 12:09:31 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gAJH9SC11114; Tue, 19 Nov 2002 12:09:28 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gAJH9S917431; Tue, 19 Nov 2002 12:09:28 -0500 (EST)
Date: Tue, 19 Nov 2002 12:09:28 -0500
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-ietf-idr-bgp4-mibv2-03.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Nov 19, 2002 at 10:19:24AM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Jonathon,

On Tue, Nov 19, 2002 at 10:19:24AM -0500, Natale, Jonathan wrote:
> I think you had suggested an object to indicate which step/attribute was
> used to select/not select the route as best.  I think this is a good idea.

I think operators would find this particularly useful. :-)

> Has this been formally drafted anywhere?

Not at the moment.  However, the recent draft:
    BGP Custom Decision Process (draft-retana-bgp-custom-decision-00.txt)o

gives a start to this by enumerating route selection steps.

The biggest obstacle to doing this is formally enumerating the
route selection steps and permitting them to vary from vendor to
vendor since no one seems to be interested in getting things to the
level of 100% consistancy.

Then again, something kinky (at least in the MIB) could be done
such that the object contains an index into a table that contains
the vendor's implementation of route selection.  A dump of that
table would show what all the steps are.

Given that vendors allow tweaking of the process via knob in many
cases, even that is probably not 100% feasible. 

The best we could probably hope for is a text description of where
we stopped.

> I did not see it in
> draft-ietf-idr-bgp4-mibv2-03.txt, but I may have missed it.

At this point, I'm not arbitrarily putting stuff in the v2MIB without
group consensus.  However, given some of the recommendations made at
the IDR session (e.g. injecting multiple route instances), the
MIB may require serious tweaking.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA18394 for <[e-mail]>; Tue, 19 Nov 2002 10:20:16 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 716599128C; Tue, 19 Nov 2002 10:19:47 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C0DC9128E; Tue, 19 Nov 2002 10:19:45 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EC77C9128C for <[e-mail]>; Tue, 19 Nov 2002 10:19:27 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C37445DEC5; Tue, 19 Nov 2002 10:19:27 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 7CDEE5DD94 for <[e-mail]>; Tue, 19 Nov 2002 10:19:27 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <WYS1H5GL>; Tue, 19 Nov 2002 10:19:27 -0500
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>
Cc: [e-mail]
Subject: RE: draft-ietf-idr-bgp4-mibv2-03.txt
Date: Tue, 19 Nov 2002 10:19:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Jeff,

I think you had suggested an object to indicate which step/attribute was
used to select/not select the route as best.  I think this is a good idea.
Has this been formally drafted anywhere?  I did not see it in
draft-ietf-idr-bgp4-mibv2-03.txt, but I may have missed it.

Thanks,
Jonathan

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]] 
> Sent: Thursday, November 07, 2002 10:21 AM
> To: Gray, Eric
> Cc: [e-mail]
> Subject: Re: draft-ietf-idr-bgp4-mibv2-03.txt
> 
> 
> Eric,
> 
> On Thu, Nov 07, 2002 at 09:58:56AM -0500, Gray, Eric wrote:
> >   
> http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-03.txt
> > 
> > Apparently, about 3/4 of page 98 was vaporized in production,
> 
> Weird.  Looks like my "roff fixup" script has an error.  My apologies.
> 
> The missing two sections are "intellectual property" which is generic
> IETF boilerplate and the acknowledgements section.
> 
> > including all of sections 3 and 4.  Also, I think it would be
> > helpful to move the table of contents to the beginning of the
> > draft... 
> 
> Will do this for the next rev of the MIB.  This is largely 
> the raw output
> of the roff.
> 
> > Eric W. Gray
> 
> -- 
> Jeff Haas 
> NextHop Technologies
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA13310 for <[e-mail]>; Mon, 18 Nov 2002 15:00:12 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1B7B691201; Mon, 18 Nov 2002 14:59:50 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB84A91262; Mon, 18 Nov 2002 14:59:49 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D79CD91201 for <[e-mail]>; Mon, 18 Nov 2002 14:59:48 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C3E1D5E0E1; Mon, 18 Nov 2002 14:59:48 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 304045E0D1 for <[e-mail]>; Mon, 18 Nov 2002 14:59:48 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gAIJxlM87249; Mon, 18 Nov 2002 14:59:47 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gAIJxhC87242; Mon, 18 Nov 2002 14:59:43 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gAIJxho15254; Mon, 18 Nov 2002 14:59:43 -0500 (EST)
Date: Mon, 18 Nov 2002 14:59:43 -0500
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-idr-bgp4-mib-10.txt -- optional attribu tes
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Nov 18, 2002 at 02:42:50PM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Nov 18, 2002 at 02:42:50PM -0500, Natale, Jonathan wrote:
> A good example is the MED.  A route does not always have a MED, it can be
> advertised with no med at all.  But the MED is an object in the MIB table.
> Community is another example.

Unfortunately, in the first MIB, there isn't a good mechanism to
represent the absence of a MED or a LOCAL_PREF.  -1 is used
to represent the absence of these values which artificially
restricts the valid range in the MIB, but practically its a non-issue.

(note the comments for those objects)

In the v2 mib, a TruthValue is used to specifically represent the absence
of these values.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA11722 for <[e-mail]>; Mon, 18 Nov 2002 14:33:02 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 57D9691270; Mon, 18 Nov 2002 14:31:58 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E97B391271; Mon, 18 Nov 2002 14:31:56 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9BA2B91270 for <[e-mail]>; Mon, 18 Nov 2002 14:31:49 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 875985E0D7; Mon, 18 Nov 2002 14:31:49 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id E95FA5E0D3 for <[e-mail]>; Mon, 18 Nov 2002 14:31:48 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gAIJVkA85773; Mon, 18 Nov 2002 14:31:46 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gAIJVgC85766; Mon, 18 Nov 2002 14:31:42 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gAIJVgN15203; Mon, 18 Nov 2002 14:31:42 -0500 (EST)
Date: Mon, 18 Nov 2002 14:31:42 -0500
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-idr-bgp4-mib-10.txt -- optional attribu tes
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Nov 18, 2002 at 10:35:59AM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Jonathon,

On Mon, Nov 18, 2002 at 10:35:59AM -0500, Natale, Jonathan wrote:
> There seems to be no graceful method of dealing with the fact 
> that some attributes are optional, other than just defining a 
> value of the attribute to mean that the attribute is not 
> present.

I am missing some context here.  Could you give a more specific example?

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA28369 for <[e-mail]>; Mon, 18 Nov 2002 10:36:40 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 88B0891210; Mon, 18 Nov 2002 10:36:02 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 507D391240; Mon, 18 Nov 2002 10:36:02 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 21FC091210 for <[e-mail]>; Mon, 18 Nov 2002 10:36:01 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0CEB55E00A; Mon, 18 Nov 2002 10:36:01 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id BE9CA5DE68 for <[e-mail]>; Mon, 18 Nov 2002 10:36:00 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <WYS1HVWM>; Mon, 18 Nov 2002 10:36:00 -0500
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-idr-bgp4-mib-10.txt -- optional attribu tes
Date: Mon, 18 Nov 2002 10:35:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

There seems to be no graceful method of dealing with the fact 
that some attributes are optional, other than just defining a 
value of the attribute to mean that the attribute is not 
present.  But this method obviously has problems.  Did I miss 
something?  Or if this is to be "the method", I suggest that 
the specific value, to mean that the attribute is not 
present, be defined for all optional attributes.

Thank you.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA26678 for <[e-mail]>; Mon, 18 Nov 2002 10:08:59 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 727C99123A; Mon, 18 Nov 2002 10:08:31 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 323309123F; Mon, 18 Nov 2002 10:08:31 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB55D9123A for <[e-mail]>; Mon, 18 Nov 2002 10:08:29 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D4E8D5DE50; Mon, 18 Nov 2002 10:08:29 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id ED1CA5E0C9 for <[e-mail]>; Mon, 18 Nov 2002 10:08:28 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <WYS1HVS4>; Mon, 18 Nov 2002 10:08:28 -0500
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: Community = 0
Date: Mon, 18 Nov 2002 10:08:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

A major vendor sets the community to 0 for "internet" and will match on 0,
on any, and on none for "internet".  RFC1997, just says that all routes, by
default, are in "internet", is there another RFC/draft that describes this
'0 for "internet"' behavior?  Also, why does the RFC say "by default"--are
there implementations that can reconfigure this?

Thank you.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA08891 for <[e-mail]>; Fri, 15 Nov 2002 11:25:23 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 78A00912D6; Fri, 15 Nov 2002 11:25:12 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3FE46912DA; Fri, 15 Nov 2002 11:25:12 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 46695912D6 for <[e-mail]>; Fri, 15 Nov 2002 11:25:11 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 2E0B55DF7F; Fri, 15 Nov 2002 11:25:11 -0500 (EST)
Delivered-To: [e-mail]
Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id A3E165DDF5 for <[e-mail]>; Fri, 15 Nov 2002 11:25:10 -0500 (EST)
Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id gAFHK6M15150 for <[e-mail]>; Fri, 15 Nov 2002 10:20:06 -0700
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
To: "'[e-mail]'" <[e-mail]>
From: Danny McPherson <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Attribute manipulation on routes announced to a RR client 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 15 Nov 2002 10:20:06 -0700
Sender: [e-mail]
Precedence: bulk

> But they're NOT deployed in consistent manners.  Often Member-ASs of a 
> confederation are under different administrative control, run separate
> IGPs, employ RR for inter-Member-AS hierarchy, etc..  Much of the 

s/inter-Member-AS/intra-Member-AS/

-danny



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA08830 for <[e-mail]>; Fri, 15 Nov 2002 11:23:40 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 31C23912DE; Fri, 15 Nov 2002 11:23:00 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 01236912EC; Fri, 15 Nov 2002 11:22:59 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7B851912DE for <[e-mail]>; Fri, 15 Nov 2002 11:22:55 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 6B1815DF7F; Fri, 15 Nov 2002 11:22:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id DE80E5DEB4 for <[e-mail]>; Fri, 15 Nov 2002 11:22:54 -0500 (EST)
Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id gAFHHop15075 for <[e-mail]>; Fri, 15 Nov 2002 10:17:50 -0700
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
To: "'[e-mail]'" <[e-mail]>
From: Danny McPherson <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Attribute manipulation on routes announced to a RR client 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 15 Nov 2002 10:17:50 -0700
Sender: [e-mail]
Precedence: bulk

> In fact, my concerns is: Is an implementation allowed to provide
> configuration tools to the user to manipulate attributes on routes reflected
> to a RRclient or on routes announced to an internal peer in the confed?

In reality, an implementation can provide whatever configuration 
capabilities they wish, though they should be cautious not to break 
anything and that what they're doing works for the folks that are 
intending to deploy it.

> I noticed that Cisco's route map attribute manipulation has no effect on
> reflected routes. Is that an implementation detail or is that based on RFC?

Uhhmm.., an implementation detail based on the RFC and deployment....?
For example, an RR would likely want to set the NEXT_HOP attribute 
value to 'itself' for EBGP learned and advertised routes but probably 
not for routes that are 'reflected'.  How else would this be 
accomplished? 

On the other hand, an EIBGP Member-AS border router would likely want 
to modify the NEXT_HOP value for routes advertised to other Member-ASs.

> However I did not see any equivalent behavior in the context of confed. Why
> not? Both mechanisms are used to reduced the full mesh. Therefore they
> should be implemented in consistent manners.

But they're NOT deployed in consistent manners.  Often Member-ASs of a 
confederation are under different administrative control, run separate
IGPs, employ RR for inter-Member-AS hierarchy, etc..  Much of the control 
over attribute manipulation you're seeing in existing implementations 
has been implemented as such as a result.

-danny



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA08252 for <[e-mail]>; Fri, 15 Nov 2002 11:06:17 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1DFE6912DD; Fri, 15 Nov 2002 11:04:11 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 964C3912E0; Fri, 15 Nov 2002 11:04:10 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 38D64912DD for <[e-mail]>; Fri, 15 Nov 2002 11:03:17 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1FDA85DF9E; Fri, 15 Nov 2002 11:03:17 -0500 (EST)
Delivered-To: [e-mail]
Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 96F555DF61 for <[e-mail]>; Fri, 15 Nov 2002 11:03:16 -0500 (EST)
Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id gAFGwBr14816 for <[e-mail]>; Fri, 15 Nov 2002 09:58:11 -0700
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
To: idr <[e-mail]>
From: Danny McPherson <[e-mail]>
Reply-To: [e-mail]
Subject: Re: aggregation in AS confed 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 15 Nov 2002 09:58:11 -0700
Sender: [e-mail]
Precedence: bulk

OK, I'll address this in the next rev of 3065, which should 
be within a few months as draft-mcpherson-rfc3065bis-00.txt
is already published and in the "awaiting WG acceptance" 
queue.

-danny

> 
> 
> -----Original Message-----
> From: naresh paliwal [mailto:[e-mail]]
> Sent: Friday, November 15, 2002 3:57 PM
> To: Venu Kumar G - CTD,Chennai.
> Cc: Sivananda Ramnath - CTD,Chennai.; [e-mail]; idr
> Subject: Re: RE: aggregation in AS confed
> 
> 
> naresh>>Should the aggregator attr contains Confed-Id in case of 
> naresh>>advertisement to internal or confed-peer also.
>    
>   I guess the idea of having AS no in AGGREGATOR attribute  could be
>           1.  Network operators to track last aggregation (debugging
> purpose)
>           2.  To take some policy decisions.
>        So while sending/receiving routes to/from other  BGP speakers,  In
> general we take policy decisions only at AS level, not with-in AS.  So I
> think Sending "Confed-ID" is the only correct option in the AGGREGATOR. All
> internal BGP routers can ignore this AS no, if it contains it's own
> "Confederation ID".
> 
> naresh>>If "yes", Its not as per the rfc 3065, which quotes in section 
> naresh>>
> 6:
> " A member of a BGP confederation will use its Member-AS Number in 
> all the transactions with peers that are memebers of the same 
> confederation as the given router."
> 
>        We can  add an exceptional case for this.
> 



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA01571 for <[e-mail]>; Fri, 15 Nov 2002 08:54:26 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B9111912CD; Fri, 15 Nov 2002 08:54:07 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75ED6912CE; Fri, 15 Nov 2002 08:54:07 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E485D912CD for <[e-mail]>; Fri, 15 Nov 2002 08:54:05 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C90795DFFE; Fri, 15 Nov 2002 08:54:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from mail1.hyperchip.com (mail1.hyperchip.com [216.94.112.3]) by segue.merit.edu (Postfix) with ESMTP id 5C78D5DFFC for <[e-mail]>; Fri, 15 Nov 2002 08:54:05 -0500 (EST)
Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail1.hyperchip.com with esmtp (Exim 3.22 #1) id 18Cgv5-0005lB-00; Fri, 15 Nov 2002 08:54:03 -0500
Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id <W520926M>; Fri, 15 Nov 2002 08:50:19 -0500
Message-ID: <[e-mail]>
From: Martin Clouatre <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Attribute manipulation on routes announced to a RR client
Date: Fri, 15 Nov 2002 08:50:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28CAD.EF4DA830"
Sender: [e-mail]
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C28CAD.EF4DA830
Content-Type: text/plain;
	charset="iso-8859-1"

OK here is more details about my concerns.

>From section 8 of RFC 2796 (RR), I understand that a router should not allow
a user to perform attribute manipulation (via an outbound route map for
instance) on reflected routes.
   "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."

>From section 7 of RFC3065 (confed), I understand that some EBGP rules can be
broken when doing EIBGP. For instance, LOCAL_PREF can be used and MED must
be preserved. However, there is not a statement similar to the one above
specifying if user could manipulate those attributes anyway through
configuration. 

In fact, my concerns is: Is an implementation allowed to provide
configuration tools to the user to manipulate attributes on routes reflected
to a RRclient or on routes announced to an internal peer in the confed? I
noticed that Cisco's route map attribute manipulation has no effect on
reflected routes. Is that an implementation detail or is that based on RFC?
However I did not see any equivalent behavior in the context of confed. Why
not? Both mechanisms are used to reduced the full mesh. Therefore they
should be implemented in consistent manners.

In my previous message, by "AS-PATH attributes", I meant "path attributes",
i.e. MED, LOCAL_PREF, ORIGIN, etc., that can have an impact on the BGP
decision process. Sorry for the ambiguity.

Thanks in advance you for your valuable inputs...

Martin Clouatre


-----Original Message-----
From: Danny McPherson [mailto:[e-mail]]
Sent: Thursday, November 14, 2002 6:59 PM
To: '[e-mail]'
Subject: Re: Attribute manipulation on routes announced to a RR client



> I have two questions about that statement:
> 
> FIRST QUESTION
> I think this statement should also specify that a RR should not perform
> outbound route filtering on reflected IBGP routes. Do you agree?

No.  Route filtering is considered an implementation and/or 
deployment issue.
 
> SECOND QUESTION
> I did not find any equivalent statement in the BGP confederation RFC.
> Why is that?

Section 7 of RFC 3065 does provide some discussion of this.

> Bad attribute manipulation when advertising IBGP routes to an EIBGP
> peer can also result in loops.

With consideration of RFC 2065, can you provide an example?

> My understanding is that, when a BGP router advertises an IBGP route to 
> an EIBGP peer, it should not be allowed to modify any AS-PATH attributes
> that could change consistent route selection.

Did you mean "AS-PATH attributes" or "path attributes"?  Either way, 
I believe the current text suffices.  However, if you'd care to provide 
specific examples with which you're concerned we'll certainly considering 
addressing them in the next revision, if need be.

-danny


------_=_NextPart_001_01C28CAD.EF4DA830
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Attribute manipulation on routes announced to a RR =
client</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>OK here is more details about my concerns.</FONT>
</P>

<P><FONT SIZE=3D2>From section 8 of RFC 2796 (RR), I understand that a =
router should not allow a user to perform attribute manipulation (via =
an outbound route map for instance) on reflected routes.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; &quot;Care should be taken to make sure =
that none of the BGP path</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; attributes defined above can be =
modified through configuration when</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; exchanging internal routing information =
between RRs and Clients and</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Non-Clients.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>From section 7 of RFC3065 (confed), I understand that =
some EBGP rules can be broken when doing EIBGP. For instance, =
LOCAL_PREF can be used and MED must be preserved. However, there is not =
a statement similar to the one above specifying if user could =
manipulate those attributes anyway through configuration. </FONT></P>

<P><FONT SIZE=3D2>In fact, my concerns is: Is an implementation allowed =
to provide configuration tools to the user to manipulate attributes on =
routes reflected to a RRclient or on routes announced to an internal =
peer in the confed? I noticed that Cisco's route map attribute =
manipulation has no effect on reflected routes. Is that an =
implementation detail or is that based on RFC? However I did not see =
any equivalent behavior in the context of confed. Why not? Both =
mechanisms are used to reduced the full mesh. Therefore they should be =
implemented in consistent manners.</FONT></P>

<P><FONT SIZE=3D2>In my previous message, by &quot;AS-PATH =
attributes&quot;, I meant &quot;path attributes&quot;, i.e. MED, =
LOCAL_PREF, ORIGIN, etc., that can have an impact on the BGP decision =
process. Sorry for the ambiguity.</FONT></P>

<P><FONT SIZE=3D2>Thanks in advance you for your valuable =
inputs...</FONT>
</P>

<P><FONT SIZE=3D2>Martin Clouatre</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Danny McPherson [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, November 14, 2002 6:59 PM</FONT>
<BR><FONT SIZE=3D2>To: '[e-mail]'</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Attribute manipulation on routes =
announced to a RR client</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; I have two questions about that =
statement:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; FIRST QUESTION</FONT>
<BR><FONT SIZE=3D2>&gt; I think this statement should also specify that =
a RR should not perform</FONT>
<BR><FONT SIZE=3D2>&gt; outbound route filtering on reflected IBGP =
routes. Do you agree?</FONT>
</P>

<P><FONT SIZE=3D2>No.&nbsp; Route filtering is considered an =
implementation and/or </FONT>
<BR><FONT SIZE=3D2>deployment issue.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; SECOND QUESTION</FONT>
<BR><FONT SIZE=3D2>&gt; I did not find any equivalent statement in the =
BGP confederation RFC.</FONT>
<BR><FONT SIZE=3D2>&gt; Why is that?</FONT>
</P>

<P><FONT SIZE=3D2>Section 7 of RFC 3065 does provide some discussion of =
this.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Bad attribute manipulation when advertising IBGP =
routes to an EIBGP</FONT>
<BR><FONT SIZE=3D2>&gt; peer can also result in loops.</FONT>
</P>

<P><FONT SIZE=3D2>With consideration of RFC 2065, can you provide an =
example?</FONT>
</P>

<P><FONT SIZE=3D2>&gt; My understanding is that, when a BGP router =
advertises an IBGP route to </FONT>
<BR><FONT SIZE=3D2>&gt; an EIBGP peer, it should not be allowed to =
modify any AS-PATH attributes</FONT>
<BR><FONT SIZE=3D2>&gt; that could change consistent route =
selection.</FONT>
</P>

<P><FONT SIZE=3D2>Did you mean &quot;AS-PATH attributes&quot; or =
&quot;path attributes&quot;?&nbsp; Either way, </FONT>
<BR><FONT SIZE=3D2>I believe the current text suffices.&nbsp; However, =
if you'd care to provide </FONT>
<BR><FONT SIZE=3D2>specific examples with which you're concerned we'll =
certainly considering </FONT>
<BR><FONT SIZE=3D2>addressing them in the next revision, if need =
be.</FONT>
</P>

<P><FONT SIZE=3D2>-danny</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C28CAD.EF4DA830--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA27648 for <[e-mail]>; Fri, 15 Nov 2002 07:36:16 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DFC7B91221; Fri, 15 Nov 2002 07:35:49 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AFAC7912CD; Fri, 15 Nov 2002 07:35:49 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5A56F91221 for <[e-mail]>; Fri, 15 Nov 2002 07:35:48 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3FEE05DFEC; Fri, 15 Nov 2002 07:35:48 -0500 (EST)
Delivered-To: [e-mail]
Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id DA2765DFEB for <[e-mail]>; Fri, 15 Nov 2002 07:35:43 -0500 (EST)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <W9BX7BDW>; Fri, 15 Nov 2002 18:11:00 +0530
Message-ID: <[e-mail]>
From: "Venu Kumar G - CTD, Chennai." <[e-mail]>
To: naresh paliwal <[e-mail]>, "Venu Kumar G - CTD,Chennai." <[e-mail]>
Cc: "Sivananda Ramnath - CTD,Chennai." <[e-mail]>, [e-mail], idr <[e-mail]>
Subject: RE: RE: aggregation in AS confed
Date: Fri, 15 Nov 2002 18:07:51 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

-----Original Message-----
From: naresh paliwal [mailto:[e-mail]]
Sent: Friday, November 15, 2002 3:57 PM
To: Venu Kumar G - CTD,Chennai.
Cc: Sivananda Ramnath - CTD,Chennai.; [e-mail]; idr
Subject: Re: RE: aggregation in AS confed


naresh>>Should the aggregator attr contains Confed-Id in case of 
naresh>>advertisement to internal or confed-peer also.
   
  I guess the idea of having AS no in AGGREGATOR attribute  could be
          1.  Network operators to track last aggregation (debugging
purpose)
          2.  To take some policy decisions.
       So while sending/receiving routes to/from other  BGP speakers,  In
general we take policy decisions only at AS level, not with-in AS.  So I
think Sending "Confed-ID" is the only correct option in the AGGREGATOR. All
internal BGP routers can ignore this AS no, if it contains it's own
"Confederation ID".

naresh>>If "yes", Its not as per the rfc 3065, which quotes in section 
naresh>>
6:
" A member of a BGP confederation will use its Member-AS Number in 
all the transactions with peers that are memebers of the same 
confederation as the given router."

       We can  add an exceptional case for this.

naresh>>


Regards
Venu G.


-naresh

On Fri, 15 Nov 2002 Venu Kumar G - CTD, Chennai. wrote :

>
>Danny >> What specifically are you referring to?  It should be 
>performed
>Danny >> no differently than it is without confederations.
>
>        Yes I too aggree, But the only missing point in the 
>current spec,
>When you do the aggregation on "confederation" feature enabled 
>router, and
>if they are intrested to add the "AGGREGATOR" attribute, In that 
>case
>AGGREGATOR attribute AS number SHOULD be the "Confederation 
>Identifier"
>instead of local "AS Number".
>
>       Can we  document this point in the next version, and if 
>possible can
>we mention the same, what you mention above by using words
>"AS_CONFED_SEQUENCE " /"AS_CONFED_SET" and comparing this with 
>"AS_SEQUENCE"
>/"AS_SET" segment types.
>
>Regards
>Venu G.
>
>
>
>-danny
>
> > How is route aggregation performed within the AS 
>confederation,
> > especially when aggregated route is be advertised to a
> > Confederation peer(Peer, belongs to the same confed).


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA20315 for <[e-mail]>; Fri, 15 Nov 2002 05:28:28 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id CF31E912CA; Fri, 15 Nov 2002 05:28:02 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 965DC912CB; Fri, 15 Nov 2002 05:28:02 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 55F22912CA for <[e-mail]>; Fri, 15 Nov 2002 05:28:01 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3A5165DFC3; Fri, 15 Nov 2002 05:28:01 -0500 (EST)
Delivered-To: [e-mail]
Received: from webmail10.rediffmail.com (unknown [202.54.124.179]) by segue.merit.edu (Postfix) with SMTP id 9DE5C5DFC2 for <[e-mail]>; Fri, 15 Nov 2002 05:27:59 -0500 (EST)
Received: (qmail 26568 invoked by uid 510); 15 Nov 2002 10:27:00 -0000
Date: 15 Nov 2002 10:27:00 -0000
Message-ID: <[e-mail]>
Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 15 nov 2002 10:27:00 -0000
MIME-Version: 1.0
From: "naresh  paliwal" <[e-mail]>
Reply-To: "naresh  paliwal" <[e-mail]>
To: "Venu Kumar G - CTD,Chennai." <[e-mail]>
Cc: "Sivananda Ramnath - CTD,Chennai." <[e-mail]>, [e-mail], "idr" <[e-mail]>
Subject: Re: RE: aggregation in AS confed
Content-type: text/plain; format=flowed
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

Should the aggregator attr contains Confed-Id in case of 
advertisement to internal or confed-peer also.

If "yes", Its not as per the rfc 3065, which quotes in section 
6:
" A member of a BGP confederation will use its Member-AS Number in 
all the transactions with peers that are memebers of the same 
confederation as the given router."

-naresh

On Fri, 15 Nov 2002 Venu Kumar G - CTD, Chennai. wrote :

>
>Danny >> What specifically are you referring to?  It should be 
>performed
>Danny >> no differently than it is without confederations.
>
>        Yes I too aggree, But the only missing point in the 
>current spec,
>When you do the aggregation on "confederation" feature enabled 
>router, and
>if they are intrested to add the "AGGREGATOR" attribute, In that 
>case
>AGGREGATOR attribute AS number SHOULD be the "Confederation 
>Identifier"
>instead of local "AS Number".
>
>       Can we  document this point in the next version, and if 
>possible can
>we mention the same, what you mention above by using words
>"AS_CONFED_SEQUENCE " /"AS_CONFED_SET" and comparing this with 
>"AS_SEQUENCE"
>/"AS_SET" segment types.
>
>Regards
>Venu G.
>
>
>
>-danny
>
> > How is route aggregation performed within the AS 
>confederation,
> > especially when aggregated route is be advertised to a
> > Confederation peer(Peer, belongs to the same confed).



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA18074 for <[e-mail]>; Fri, 15 Nov 2002 04:45:10 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E76E89124F; Fri, 15 Nov 2002 04:44:42 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A6E73912CA; Fri, 15 Nov 2002 04:44:41 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 661079124F for <[e-mail]>; Fri, 15 Nov 2002 04:44:40 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 479825DF97; Fri, 15 Nov 2002 04:44:40 -0500 (EST)
Delivered-To: [e-mail]
Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id B98C05DF82 for <[e-mail]>; Fri, 15 Nov 2002 04:44:38 -0500 (EST)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <W9BX672C>; Fri, 15 Nov 2002 15:19:56 +0530
Message-ID: <[e-mail]>
From: "Venu Kumar G - CTD, Chennai." <[e-mail]>
To: [e-mail], idr <[e-mail]>
Cc: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
Subject: RE: aggregation in AS confed 
Date: Fri, 15 Nov 2002 15:16:48 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hi danny,


-----Original Message-----
From: Danny McPherson [mailto:[e-mail]]
Sent: Friday, November 15, 2002 5:30 AM
To: idr
Subject: Re: aggregation in AS confed 



Danny >> What specifically are you referring to?  It should be performed 
Danny >> no differently than it is without confederations.

       Yes I too aggree, But the only missing point in the current spec,
When you do the aggregation on "confederation" feature enabled router, and
if they are intrested to add the "AGGREGATOR" attribute, In that case
AGGREGATOR attribute AS number SHOULD be the "Confederation Identifier"
instead of local "AS Number".

      Can we  document this point in the next version, and if possible can
we mention the same, what you mention above by using words
"AS_CONFED_SEQUENCE " /"AS_CONFED_SET" and comparing this with "AS_SEQUENCE"
/"AS_SET" segment types. 

Regards
Venu G.



-danny

> How is route aggregation performed within the AS confederation, 
> especially when aggregated route is be advertised to a 
> Confederation peer(Peer, belongs to the same confed).


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA13706 for <[e-mail]>; Thu, 14 Nov 2002 18:12:03 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 2EB1D912BB; Thu, 14 Nov 2002 18:11:41 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA121912BD; Thu, 14 Nov 2002 18:11:40 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8385B912BB for <[e-mail]>; Thu, 14 Nov 2002 18:11:38 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 6D3A15DEFE; Thu, 14 Nov 2002 18:11:38 -0500 (EST)
Delivered-To: [e-mail]
Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id E47825DEFB for <[e-mail]>; Thu, 14 Nov 2002 18:11:37 -0500 (EST)
Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id gAF06XO04195 for <[e-mail]>; Thu, 14 Nov 2002 17:06:33 -0700
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
To: "'[e-mail]'" <[e-mail]>
From: Danny McPherson <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Attribute manipulation on routes announced to a RR client 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 14 Nov 2002 17:06:33 -0700
Sender: [e-mail]
Precedence: bulk

> > Bad attribute manipulation when advertising IBGP routes to an EIBGP
> > peer can also result in loops.
> 
> With consideration of RFC 2065, can you provide an example?
                            ^^^^
This was obviously supposed to be 3065.

-danny 



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA13409 for <[e-mail]>; Thu, 14 Nov 2002 18:06:17 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 29A7F912C9; Thu, 14 Nov 2002 18:05:12 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DEFB0912CB; Thu, 14 Nov 2002 18:05:11 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 11C92912C9 for <[e-mail]>; Thu, 14 Nov 2002 18:05:08 -0500 (EST)
Received: by segue.merit.edu (Postfix) id EE3475DEA0; Thu, 14 Nov 2002 18:05:07 -0500 (EST)
Delivered-To: [e-mail]
Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 54CF65DDE4 for <[e-mail]>; Thu, 14 Nov 2002 18:05:07 -0500 (EST)
Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id gAF002N04043 for <[e-mail]>; Thu, 14 Nov 2002 17:00:02 -0700
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
To: "idr" <[e-mail]>
From: Danny McPherson <[e-mail]>
Reply-To: [e-mail]
Subject: Re: aggregation in AS confed 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 14 Nov 2002 17:00:02 -0700
Sender: [e-mail]
Precedence: bulk

What specifically are you referring to?  It should be performed 
no differently than it is without confederations.

-danny

> How is route aggregation performed within the AS confederation, 
> especially when aggregated route is be advertised to a 
> Confederation peer(Peer, belongs to the same confed).



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA13391 for <[e-mail]>; Thu, 14 Nov 2002 18:05:59 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D4CB5912B9; Thu, 14 Nov 2002 18:03:44 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92267912B8; Thu, 14 Nov 2002 18:03:44 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1E848912BB for <[e-mail]>; Thu, 14 Nov 2002 18:03:36 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 034515DEFB; Thu, 14 Nov 2002 18:03:36 -0500 (EST)
Delivered-To: [e-mail]
Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 72E795DEE9 for <[e-mail]>; Thu, 14 Nov 2002 18:03:35 -0500 (EST)
Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id gAENwUp04017 for <[e-mail]>; Thu, 14 Nov 2002 16:58:30 -0700
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
To: "'[e-mail]'" <[e-mail]>
From: Danny McPherson <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Attribute manipulation on routes announced to a RR client 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Thu, 14 Nov 2002 16:58:30 -0700
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id SAA13391

> I have two questions about that statement:
> 
> FIRST QUESTION
> I think this statement should also specify that a RR should not perform
> outbound route filtering on reflected IBGP routes. Do you agree?

No.  Route filtering is considered an implementation and/or 
deployment issue.
 
> SECOND QUESTION
> I did not find any equivalent statement in the BGP confederation RFC.
> Why is that?

Section 7 of RFC 3065 does provide some discussion of this.

> Bad attribute manipulation when advertising IBGP routes to an EIBGP
> peer can also result in loops.

With consideration of RFC 2065, can you provide an example?

> My understanding is that, when a BGP router advertises an IBGP route to 
> an EIBGP peer, it should not be allowed to modify any AS-PATH attributes
> that could change consistent route selection.

Did you mean "AS-PATH attributes" or "path attributes"?  Either way, 
I believe the current text suffices.  However, if you'd care to provide 
specific examples with which you're concerned we'll certainly considering 
addressing them in the next revision, if need be.

-danny



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA01626 for <[e-mail]>; Thu, 14 Nov 2002 14:21:53 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B3A91912A6; Thu, 14 Nov 2002 14:21:26 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F2E9912A7; Thu, 14 Nov 2002 14:21:26 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1BF46912A6 for <[e-mail]>; Thu, 14 Nov 2002 14:21:25 -0500 (EST)
Received: by segue.merit.edu (Postfix) id ED72A5DEDD; Thu, 14 Nov 2002 14:21:24 -0500 (EST)
Delivered-To: [e-mail]
Received: from mail1.hyperchip.com (mail1.hyperchip.com [216.94.112.3]) by segue.merit.edu (Postfix) with ESMTP id 750BC5DD98 for <[e-mail]>; Thu, 14 Nov 2002 14:21:24 -0500 (EST)
Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail1.hyperchip.com with esmtp (Exim 3.22 #1) id 18CPYK-0004cU-00 for [e-mail]; Thu, 14 Nov 2002 14:21:24 -0500
Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id <W5209FFA>; Thu, 14 Nov 2002 14:17:42 -0500
Message-ID: <[e-mail]>
From: Martin Clouatre <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Attribute manipulation on routes announced to a RR client
Date: Thu, 14 Nov 2002 14:17:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28C12.80D5CB30"
Sender: [e-mail]
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C28C12.80D5CB30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The BGP Route Reflection RFC specifies the following:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
8. Implementation and Configuration Considerations=20
[...] 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.=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


I have two questions about that statement:

FIRST QUESTION
I think this statement should also specify that a RR should not perform
outbound route filtering on reflected IBGP routes. Do you agree?

SECOND QUESTION
I did not find any equivalent statement in the BGP confederation RFC. =
Why is
that?
Bad attribute manipulation when advertising IBGP routes to an EIBGP =
peer can
also result in loops.=20
My understanding is that, when a BGP router advertises an IBGP route to =
an
EIBGP peer, it should not be allowed to modify any AS-PATH attributes =
that
could change consistent route selection.







Martin Clou=E2tre, ing=20
d=E9veloppement logiciel - =E9quipe BGP=20
[e-mail] < <mailto:[e-mail]>>=20
www.hyperchip.com < <http://www.hyperchip.com/>>=20
t=E9l : 514.906.4922=20
fax: [phone]=20

Venez rencontrer Hyperchip =E0 :
Lightspeed Europe 02 - London, UK - Tues, Dec 3rd @ 2:15pm - Richard =
Norman,
panelist, "Future Network Architectures"

Prenez connaissance de nos pr=E9sentations =E0 SUPERCOMM  disponible en =
ligne =E0
www.hyperchip.com/supercomm <http://www.hyperchip.com/supercomm>



------_=_NextPart_001_01C28C12.80D5CB30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Attribute manipulation on routes announced to a RR =
client</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">The BGP Route Reflection RFC specifies =
the following:</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT FACE=3D"Times New Roman">8. Implementation and Configuration =
Considerations </FONT>
<BR><FONT FACE=3D"Times New Roman">[...] 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. </FONT></P>

<P><FONT FACE=3D"Times New =
Roman">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">I have two questions about that =
statement:</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">FIRST QUESTION</FONT>
<BR><FONT FACE=3D"Times New Roman">I think this statement should also =
specify that a RR should not perform outbound route filtering on =
reflected IBGP routes. Do you agree?</FONT></P>

<P><FONT FACE=3D"Times New Roman">SECOND QUESTION</FONT>
<BR><FONT FACE=3D"Times New Roman">I did not find any equivalent =
statement in the BGP confederation RFC. Why is that?</FONT>
<BR><FONT FACE=3D"Times New Roman">Bad attribute manipulation when =
advertising IBGP routes to an EIBGP peer can also result in loops. =
</FONT>
<BR><FONT FACE=3D"Times New Roman">My understanding is that, when a BGP =
router advertises an IBGP route to an EIBGP peer, it should not be =
allowed to modify any AS-PATH attributes that could change consistent =
route selection.</FONT></P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Dax-Regular">Martin Clou=E2tre, ing<BR>
d=E9veloppement logiciel - =E9quipe BGP<BR>
<U>[e-mail] &lt; </U></FONT><U><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Dax-Regular">&lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</=
A>&gt;</FONT><FONT SIZE=3D2 FACE=3D"Dax-Regular">&gt;</FONT></U><FONT =
SIZE=3D2 FACE=3D"Dax-Regular"><BR>
</FONT><U><FONT SIZE=3D2 FACE=3D"Dax-Regular">www.hyperchip.com &lt; =
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Dax-Regular">&lt;<A =
HREF=3D"http://www.hyperchip.com/" =
TARGET=3D"_blank">http://www.hyperchip.com/</A>&gt;</FONT><FONT =
SIZE=3D2 FACE=3D"Dax-Regular">&gt;</FONT></U><FONT SIZE=3D2 =
FACE=3D"Dax-Regular"><BR>
t=E9l : 514.906.4922<BR>
fax: [phone] </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Dax-Regular">Venez rencontrer Hyperchip =E0 =
:</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Dax-Regular">Lightspeed =
Europe 02 - London, UK - Tues, Dec 3rd @ 2:15pm - Richard Norman, =
panelist, "Future Network Architectures"</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Dax-Regular">Prenez =
connaissance de nos pr=E9sentations =E0 SUPERCOMM&nbsp; disponible en =
ligne =E0</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Dax-Regular">www.hyperchip.com/supercomm &lt;<A =
HREF=3D"http://www.hyperchip.com/supercomm" =
TARGET=3D"_blank">http://www.hyperchip.com/supercomm</A>&gt;</FONT></U><=
/P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C28C12.80D5CB30--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA28914 for <[e-mail]>; Thu, 14 Nov 2002 13:30:20 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 68375912A2; Thu, 14 Nov 2002 13:29:56 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3BD9A912A4; Thu, 14 Nov 2002 13:29:56 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1587B912A2 for <[e-mail]>; Thu, 14 Nov 2002 13:29:55 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0242A5DF31; Thu, 14 Nov 2002 13:29:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by segue.merit.edu (Postfix) with ESMTP id C28715DF12 for <[e-mail]>; Thu, 14 Nov 2002 13:29:54 -0500 (EST)
Received: from tom3 (usermd43.uk.uudial.com [62.188.120.240]) by shockwave.systems.pipex.net (Postfix) with SMTP id 4C03116000C62; Thu, 14 Nov 2002 18:29:52 +0000 (GMT)
Message-ID: <002101c28c0b$d8f10c00$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>, "Yakov Rekhter" <[e-mail]>
Subject: BGP18-FSM-terminology
Date: Thu, 14 Nov 2002 18:29:16 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

I think a standard description would serve us better instead of using
the  following different ways (which I take all to refer to the same
entity):

delayBGP open timer
BGP delay open timer
BGP open delay timer
delay open timer
BGP delay timer

I suggest Open Delay timer (with those capitals)

I believe that the corresponding flag is consistently referred to
(apart from the capitalisation) as Delay Open flag

Tom Petch
[e-mail]






Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA00414 for <[e-mail]>; Thu, 14 Nov 2002 05:03:58 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 2CD1B9128B; Thu, 14 Nov 2002 05:03:44 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA6AB91289; Thu, 14 Nov 2002 05:03:43 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 45E5B9128C for <[e-mail]>; Thu, 14 Nov 2002 05:03:37 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 65A8D5DE20; Thu, 14 Nov 2002 05:03:37 -0500 (EST)
Delivered-To: [e-mail]
Received: from webmail8.rediffmail.com (unknown [202.54.124.153]) by segue.merit.edu (Postfix) with SMTP id 922C65DD92 for <[e-mail]>; Thu, 14 Nov 2002 05:03:36 -0500 (EST)
Received: (qmail 17320 invoked by uid 510); 14 Nov 2002 09:50:08 -0000
Date: 14 Nov 2002 09:50:08 -0000
Message-ID: <[e-mail]>
Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 14 nov 2002 09:50:08 -0000
MIME-Version: 1.0
From: "naresh  paliwal" <[e-mail]>
Reply-To: "naresh  paliwal" <[e-mail]>
To: "idr" <[e-mail]>
Cc: [e-mail]
Subject: aggregation in AS confed
Content-type: text/plain; format=flowed
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

How is route aggregation performed within the AS confederation, 
especially when aggregated route is be advertised to a 
Confederation peer(Peer, belongs to the same confed).

Regards
-naresh paliwal


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA08540 for <[e-mail]>; Wed, 13 Nov 2002 12:49:38 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8CF8F9126A; Wed, 13 Nov 2002 12:49:19 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 589159126C; Wed, 13 Nov 2002 12:49:19 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 21ECB9126A for <[e-mail]>; Wed, 13 Nov 2002 12:49:18 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1007C5DF9E; Wed, 13 Nov 2002 12:49:18 -0500 (EST)
Delivered-To: [e-mail]
Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by segue.merit.edu (Postfix) with ESMTP id B47175DEA0 for <[e-mail]>; Wed, 13 Nov 2002 12:49:17 -0500 (EST)
Received: from tom3 (userbf25.uk.uudial.com [62.188.142.46]) by shockwave.systems.pipex.net (Postfix) with SMTP id 4599816001096; Wed, 13 Nov 2002 17:49:15 +0000 (GMT)
Message-ID: <006301c28b3d$0347d3a0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>, "Yakov Rekhter" <[e-mail]>
Subject: bgp-18 FSM OpenDelay
Date: Wed, 13 Nov 2002 17:48:39 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

I (still) do find the Active and Connect states complicated, made so
by the fact that they are each two states, with the second of each
relating to open delay and its timer, entered once the transport
connection is complete.  The FSM will be simpler if that OpenDelay
state is made explicit since this will eliminate the current
duplication between Active and Connect states and tie up some loose
ends in those states that will otherwise need fixing.  This proposal
does not make any semantic change.

OPENDELAY State:

In this state, BGP has completed a transport connection,
the DelayOpen flag is set,
no Open message has been sent or received and
the OpenDelay timer is running.
The KeepAlive and Hold timers should not be running.

If the OpenDelay timer expires [Event 12] in the OpenDelay state,
the local system
     - completes the BGP initialization,
     - sends an Open message to its peer,
     - starts the Hold timer with a large value,
     - changes the state to OpenSent

     A hold timer value of 4 minutes is suggested.

If a Transport Failure [Event17] is received from the
underlying transport protocol, the local system:
       - closes the BGP connection,
       - starts the Connect Retry timer with initial value,
       - listens for a connection that may be
         initiated by the remote BGP peer,
       - stops the OpenDelay timer
       - changes the state to Active

If an Open message is received [Event 19], the local system:
- completes the BGP initialization,
- stops the OpenDelay timer
- sends an Open message
- sends KeepAlive message
      - starts KeepAlive timer
      - changes the state to OpenConfirm

The start events [Event 1, 3-6] are ignored in OpenDelay
state.

For a manual stop event[Event2], the local system:
       - drops the transport connection,
       - releases all BGP resources,
       - sets ConnectRetryCnt to zero
       - stops OpenDelay timer
       - goes to Idle state.

In response to any other events [Events 7-9, 10-11, 13-16, 18, 20-
27] the local system:

     - drops the Transport connection,
     - release all BGP resources,
     - increments the ConnectRetryCnt by 1,
     - [optionally] performs bgp peer oscillation damping, and
     [Action D in the FSM table],
     - stops the OpenDelay timer
     - goes to Idle state.

I can give you the simplifications to the Active and Connect states if
required.

Tom Petch
[e-mail]





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA05015 for <[e-mail]>; Wed, 13 Nov 2002 11:42:56 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DA26591263; Wed, 13 Nov 2002 11:42:28 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B120691265; Wed, 13 Nov 2002 11:42:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 384B591263 for <[e-mail]>; Wed, 13 Nov 2002 11:42:27 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 2929B5DF98; Wed, 13 Nov 2002 11:42:27 -0500 (EST)
Delivered-To: [e-mail]
Received: from smail2.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by segue.merit.edu (Postfix) with ESMTP id 831545DF66 for <[e-mail]>; Wed, 13 Nov 2002 11:42:26 -0500 (EST)
Received: from nmu.alcatel.fr (tcmh80.nmu.alcatel.fr [139.54.143.3]) by smail2.alcatel.fr (ALCANET/NETFR) with ESMTP id gADGf3nC019728 for <[e-mail]>; Wed, 13 Nov 2002 17:41:03 +0100
Received: from nmu.alcatel.fr (houat [192.200.245.153]) by nmu.alcatel.fr (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id RAA14084 for <[e-mail]>; Wed, 13 Nov 2002 17:40:57 +0100 (MET)
Message-ID: <[e-mail]>
Date: Wed, 13 Nov 2002 17:40:58 +0100
From: christophe preguica <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: TCP MD5 signature option for IPv6 ?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: [e-mail]
Precedence: bulk

Hi,

Does TCP MD5 signature option (RFC 2385) applicable for IPv6 ? In case
of IPv6 the pseudo-header is different.
Or should BGP rely only on IPsec in case of IPv6 ?

Kind regards,

Christophe.




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA25092 for <[e-mail]>; Tue, 12 Nov 2002 07:03:18 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 35A139123B; Tue, 12 Nov 2002 07:02:58 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F18329123C; Tue, 12 Nov 2002 07:02:57 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15BB69123B for <[e-mail]>; Tue, 12 Nov 2002 07:02:53 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D550E5DF32; Tue, 12 Nov 2002 07:02:53 -0500 (EST)
Delivered-To: [e-mail]
Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 5A25C5DDAA for <[e-mail]>; Tue, 12 Nov 2002 07:02:53 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA18779; Tue, 12 Nov 2002 07:02:52 -0500 (EST)
Date: Tue, 12 Nov 2002 07:02:52 -0500 (EST)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: [e-mail], [e-mail]
Subject: soBGP Drafts Updated....
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

It's too late for the Secretariat to handle these, so we've
posted them on a publicly accesible ftp server for perusal. Minor
changes, mostly, to deal with initial comments, are included, and
the formatting is cleaned up somewhat.

ftp://www.riw.us/draft-ng-sobgp-bgp-extensions-01.txt
ftp://www.riw.us/draft-white-sobgp-deployment-01.txt

Russ

__________________________________
[e-mail] CCIE <>< Grace Alone




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA13541 for <[e-mail]>; Fri, 8 Nov 2002 17:54:42 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1BB3B912D6; Fri,  8 Nov 2002 17:54:15 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCED5912D8; Fri,  8 Nov 2002 17:54:14 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C54A3912D6 for <[e-mail]>; Fri,  8 Nov 2002 17:54:13 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A78FA5DEAC; Fri,  8 Nov 2002 17:54:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from earthquake.proficient.net (fe0-0-access-1-sfo.proficient.net [65.209.247.5]) by segue.merit.edu (Postfix) with ESMTP id 5DC845DEA3 for <[e-mail]>; Fri,  8 Nov 2002 17:54:13 -0500 (EST)
Received: from riga ([10.0.0.25]) by earthquake.proficient.net with Microsoft SMTPSVC(5.0.2195.4905); Fri, 8 Nov 2002 14:54:08 -0800
Subject: Re: Last Call: NOPEER community for BGP route scope control to BCP
From: Justin Fletcher <[e-mail]>
To: Pekka Savola <[e-mail]>
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) 
Date: 08 Nov 2002 14:54:04 -0800
Message-Id: <1036796044.2228.194.camel@riga>
Mime-Version: 1.0
X-OriginalArrivalTime: 08 Nov 2002 22:54:08.0765 (UTC) FILETIME=[BF27E2D0:01C28779]
Sender: [e-mail]
Precedence: bulk

> > 
> > There's a large motivation section, but no implementation
> > section (what do I do with NOPEER if receive it?)
> 
> Do you think example route-map statements are necessary?

I believe examples of how this would be applied and what the affect
on advertisements would be very helpful; I'd suggest they be as generic
as possible rather than a vendor-specific implementation.

Justin Fletcher
Proficient Networks, Inc.



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA08015 for <[e-mail]>; Fri, 8 Nov 2002 07:34:42 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 982F49129E; Fri,  8 Nov 2002 07:34:10 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F6E8912A7; Fri,  8 Nov 2002 07:34:10 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B5A919129E for <[e-mail]>; Fri,  8 Nov 2002 07:34:02 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8064B5DFA4; Fri,  8 Nov 2002 07:34:02 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id A1A155DF9C for <[e-mail]>; Fri,  8 Nov 2002 07:34:01 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14790; Fri, 8 Nov 2002 07:31:30 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-walton-bgp-add-paths-01.txt
Date: Fri, 08 Nov 2002 07:31:29 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Advertisement of Multiple Paths in BGP
	Author(s)	: D. Walton, D. Cook, A. Retana, J. Scudder
	Filename	: draft-walton-bgp-add-paths-01.txt
	Pages		: 11
	Date		: 2002-11-7
	
The BGP specification [1,2] defines an 'Update-Send Process' to
advertise the routes chosen by the Decision Process to other BGP
speakers.  No provisions are made to facilitate the advertisement of
multiple paths to the same destination.  In fact, a route with the
same NLRI as a previously advertised route implicitly replaces the
original advertisement.
This document proposes a mechanism that will allow the advertisement
of multiple paths for the same prefix without the new paths
implicitly replacing any previous ones.  The essence of the mechanism
is that each path is identified by an arbitrary identifier in
addition to its prefix.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-walton-bgp-add-paths-01.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-walton-bgp-add-paths-01.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-walton-bgp-add-paths-01.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-walton-bgp-add-paths-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-walton-bgp-add-paths-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA22080 for <[e-mail]>; Thu, 7 Nov 2002 18:04:15 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 5FF17912D0; Thu,  7 Nov 2002 18:01:54 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3363E912D2; Thu,  7 Nov 2002 18:01:54 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D2B34912D0 for <[e-mail]>; Thu,  7 Nov 2002 18:01:52 -0500 (EST)
Received: by segue.merit.edu (Postfix) id BD4DE5DE07; Thu,  7 Nov 2002 18:01:52 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id AB2A25DDD5 for <[e-mail]>; Thu,  7 Nov 2002 18:01:51 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA25608; Thu, 7 Nov 2002 17:59:14 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Justin Fletcher <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], Alex Zinin <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Last Call: NOPEER community for BGP route scope control to BCP 
In-reply-to: Your message of "07 Nov 2002 10:13:03 PST." <1036692784.2228.123.camel@riga> 
Date: Thu, 07 Nov 2002 17:59:14 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <1036692784.2228.123.camel@riga>, Justin Fletcher writes:
> > The IESG has received a request from the Prefix Taxonomy Ongoing
> > Measurement & Inter Network Experiment Working Group to consider NOPEER
> > community for BGP route scope control
> > <draft-ietf-ptomaine-nopeer-00.txt> as a BCP.
> > 
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action.  Please send any comments to the
> > [e-mail] or [e-mail] mailing lists by 2002-11-17.
> 
> I believe this should be considered as an experimental rather than a
> BCP.  It does not document current practice and requires implementation
> by router vendors before it can be adopted into practice.
> 
> Other issues:
> 
> The community field should be previously assigned by IANA and defined in
> the document.
> 
> There's a large motivation section, but no implementation
> section (what do I do with NOPEER if receive it?)

The ISP configures policy (a single statement) based on the NOPEER BGP
community.

What the policy does is not sufficiently specified.

> The paragraph
> 
>   This approach allows an originator of a prefix to attach a commonly
>   defined policy to a route prefix, indicate that a route should be
>   re-advertised conditionally, based on the characteristics of the
>   inter-AS connection.
> 
> does not define the conditions under which a route should be
> re-advertised.  Without such, I don't see a difference between
> NOPEER and NO-ADVERTISE.

The semantics are not defined.

A customer sends NO-ADVERTISE.  A peer sends NOPEER.  I would imagine
that a customer sending NOPEER would go out of the immediate AS
(NOPEER and current AS as the only AS in the path is exported) but no
further.  If this is what is intended the draft doesn't say so.

> There should at least be references to RFC1771 and RFC1997.
> 
> I'd like a clear definition of "bilateral inter-AS peering"
> early in the document.
> 
> Best,
> Justin Fletcher
> Proficient Networks, Inc.

I agree with your comments regarding inadequate specification of
implementation.  This draft has a good motivation but semantics need
to be clearly defined.

It is also not a BCP since it is not a current practice (unless Geoff
is already doing this with his peers, which I doubt).

Curtis


Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA13173 for <[e-mail]>; Thu, 7 Nov 2002 15:15:21 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8EF88912CC; Thu,  7 Nov 2002 15:14:33 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 332D7912D2; Thu,  7 Nov 2002 15:14:33 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 034A2912CE for <[e-mail]>; Thu,  7 Nov 2002 15:14:28 -0500 (EST)
Received: by segue.merit.edu (Postfix) id CC0B25DEDE; Thu,  7 Nov 2002 15:14:27 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 880235DE12; Thu,  7 Nov 2002 15:14:26 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST)
Message-Id: <[e-mail]>
From: The IESG <[e-mail]>
To: All IETF Working Groups: ;
Subject: Note Well Statement
x-msg: NoteWell
Date: Thu, 07 Nov 2002 15:11:40 -0500
Sender: [e-mail]
Precedence: bulk

>From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================

				NOTE WELL

All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA06821 for <[e-mail]>; Thu, 7 Nov 2002 13:13:50 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 167D6912C2; Thu,  7 Nov 2002 13:13:15 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC043912C3; Thu,  7 Nov 2002 13:13:14 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CE445912C2 for <[e-mail]>; Thu,  7 Nov 2002 13:13:13 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B709C5DDF6; Thu,  7 Nov 2002 13:13:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from earthquake.proficient.net (fe0-0-access-1-sfo.proficient.net [65.209.247.5]) by segue.merit.edu (Postfix) with ESMTP id 6C8815DDA6 for <[e-mail]>; Thu,  7 Nov 2002 13:13:13 -0500 (EST)
Received: from riga ([10.0.0.25]) by earthquake.proficient.net with Microsoft SMTPSVC(5.0.2195.4905); Thu, 7 Nov 2002 10:13:07 -0800
Subject: Re: Last Call: NOPEER community for BGP route scope control to BCP
From: Justin Fletcher <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], Alex Zinin <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) 
Date: 07 Nov 2002 10:13:03 -0800
Message-Id: <1036692784.2228.123.camel@riga>
Mime-Version: 1.0
X-OriginalArrivalTime: 07 Nov 2002 18:13:07.0452 (UTC) FILETIME=[529DF3C0:01C28689]
Sender: [e-mail]
Precedence: bulk

> The IESG has received a request from the Prefix Taxonomy Ongoing
> Measurement & Inter Network Experiment Working Group to consider NOPEER
> community for BGP route scope control
> <draft-ietf-ptomaine-nopeer-00.txt> as a BCP.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [e-mail] or [e-mail] mailing lists by 2002-11-17.

I believe this should be considered as an experimental rather than a
BCP.  It does not document current practice and requires implementation
by router vendors before it can be adopted into practice.

Other issues:

The community field should be previously assigned by IANA and defined in
the document.

There's a large motivation section, but no implementation
section (what do I do with NOPEER if receive it?)

The paragraph

  This approach allows an originator of a prefix to attach a commonly
  defined policy to a route prefix, indicate that a route should be
  re-advertised conditionally, based on the characteristics of the
  inter-AS connection.

does not define the conditions under which a route should be
re-advertised.  Without such, I don't see a difference between
NOPEER and NO-ADVERTISE.

There should at least be references to RFC1771 and RFC1997.

I'd like a clear definition of "bilateral inter-AS peering"
early in the document.

Best,
Justin Fletcher
Proficient Networks, Inc.



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA27343 for <[e-mail]>; Thu, 7 Nov 2002 10:21:28 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D48BE912B0; Thu,  7 Nov 2002 10:21:14 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8116E912B2; Thu,  7 Nov 2002 10:21:14 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 01E41912A4 for <[e-mail]>; Thu,  7 Nov 2002 10:21:04 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D26FF5DDD4; Thu,  7 Nov 2002 10:21:04 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 47F3A5DDA7 for <[e-mail]>; Thu,  7 Nov 2002 10:21:04 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gA7FKwC38925; Thu, 7 Nov 2002 10:20:58 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA7FKtC38918; Thu, 7 Nov 2002 10:20:55 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA7FKs105264; Thu, 7 Nov 2002 10:20:54 -0500 (EST)
Date: Thu, 7 Nov 2002 10:20:54 -0500
From: Jeffrey Haas <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-ietf-idr-bgp4-mibv2-03.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Nov 07, 2002 at 09:58:56AM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Eric,

On Thu, Nov 07, 2002 at 09:58:56AM -0500, Gray, Eric wrote:
>   http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-03.txt
> 
> Apparently, about 3/4 of page 98 was vaporized in production,

Weird.  Looks like my "roff fixup" script has an error.  My apologies.

The missing two sections are "intellectual property" which is generic
IETF boilerplate and the acknowledgements section.

> including all of sections 3 and 4.  Also, I think it would be
> helpful to move the table of contents to the beginning of the
> draft... 

Will do this for the next rev of the MIB.  This is largely the raw output
of the roff.

> Eric W. Gray

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA26055 for <[e-mail]>; Thu, 7 Nov 2002 10:01:41 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 767A1912B7; Thu,  7 Nov 2002 09:59:11 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3006912B6; Thu,  7 Nov 2002 09:59:10 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1FF96912B0 for <[e-mail]>; Thu,  7 Nov 2002 09:59:04 -0500 (EST)
Received: by segue.merit.edu (Postfix) id F22AB5DDE5; Thu,  7 Nov 2002 09:59:03 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id AA5995DDD4 for <[e-mail]>; Thu,  7 Nov 2002 09:59:03 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LB4AM10>; Thu, 7 Nov 2002 09:59:03 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Jeffrey Haas <[e-mail]>, "'Sue Hares'" <[e-mail]>, "'Wayne Tackabury'" <[e-mail]>
Cc: "'Inter Domain Routing Working Group'" <[e-mail]>
Subject: draft-ietf-idr-bgp4-mibv2-03.txt
Date: Thu, 7 Nov 2002 09:58:56 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Jeff/Sue/Wayne,

	Editorial comments on "Definitions of Managed Objects
for the Fourth Version of Border Gateway Protocol (BGP-4),
Second Version" - at least as it currently appears at:

  http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-03.txt

Apparently, about 3/4 of page 98 was vaporized in production,
including all of sections 3 and 4.  Also, I think it would be
helpful to move the table of contents to the beginning of the
draft... 

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA10873 for <[e-mail]>; Thu, 7 Nov 2002 06:27:55 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 5F609912A8; Thu,  7 Nov 2002 06:27:22 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22D63912A9; Thu,  7 Nov 2002 06:27:22 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 34E04912A8 for <[e-mail]>; Thu,  7 Nov 2002 06:27:18 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 24D1B5DE43; Thu,  7 Nov 2002 06:27:18 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 9AD655DDC2 for <[e-mail]>; Thu,  7 Nov 2002 06:27:17 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10736; Thu, 7 Nov 2002 06:24:47 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-bgp4-mibv2-03.txt
Date: Thu, 07 Nov 2002 06:24:46 -0500
Sender: [e-mail]
Precedence: bulk

--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		: Definitions of Managed Objects for the Fourth Version 
                          of Border Gateway Protocol (BGP-4),Second Version
	Author(s)	: J. Haas, W. Tackabury, S. Hares
	Filename	: draft-ietf-idr-bgp4-mibv2-03.txt
	Pages		: 103
	Date		: 2002-11-6
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, this MIB defines objects that facilitate the
management of the Border Gateway Protocol Version 4 (BGP4).
Distribution of this memo is unlimited.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-03.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-mibv2-03.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-mibv2-03.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-mibv2-03.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA10853 for <[e-mail]>; Thu, 7 Nov 2002 06:27:46 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1CA4D912A7; Thu,  7 Nov 2002 06:27:14 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2276912A8; Thu,  7 Nov 2002 06:27:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6CE54912A7 for <[e-mail]>; Thu,  7 Nov 2002 06:27:12 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 558D55DF50; Thu,  7 Nov 2002 06:27:12 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id CAE8B5DE43 for <[e-mail]>; Thu,  7 Nov 2002 06:27:11 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10724; Thu, 7 Nov 2002 06:24:41 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-bgp4-mib-10.txt
Date: Thu, 07 Nov 2002 06:24:40 -0500
Sender: [e-mail]
Precedence: bulk

--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		: Definitions of Managed Objects for the Fourth Version 
                          of Border Gateway Protocol (BGP-4)
	Author(s)	: J. Haas, S. Hares
	Filename	: draft-ietf-idr-bgp4-mib-10.txt
	Pages		: 35
	Date		: 2002-11-6
	
This memo is an extension to the SNMP MIB.  The origin of this memo
is from RFC 1269 'Definitions of Managed Objects for the Border
Gateway Protocol (Version 3)', 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
current SNMP framework documents.
This memo is intended to document deployed implementations of this
MIB in a historical context, provide clarifications of some items and
also note errors where the MIB fails to fully represent the BGP
protocol.  Work is currently in progress to replace this MIB with a
new one representing the current state of the BGP protocol and its
extensions.
Distribution of this memo is unlimited.  Please forward comments to
[e-mail].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-10.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-mib-10.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-mib-10.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-mib-10.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA17461 for <[e-mail]>; Wed, 6 Nov 2002 12:49:28 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 791929129E; Wed,  6 Nov 2002 12:49:12 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3472C9129D; Wed,  6 Nov 2002 12:49:12 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E5E24912AD for <[e-mail]>; Wed,  6 Nov 2002 12:49:02 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B7DFA5DDD0; Wed,  6 Nov 2002 12:49:02 -0500 (EST)
Delivered-To: [e-mail]
Received: from mpls-qmqp-02.inet.qwest.net (mpls-qmqp-02.inet.qwest.net [63.231.195.113]) by segue.merit.edu (Postfix) with SMTP id 54D9B5DDA5 for <[e-mail]>; Wed,  6 Nov 2002 12:49:02 -0500 (EST)
Received: (qmail 84808 invoked by uid 0); 6 Nov 2002 17:41:15 -0000
Received: from unknown (63.231.195.14) by mpls-qmqp-02.inet.qwest.net with QMQP; 6 Nov 2002 17:41:15 -0000
Received: from mplsapanas03poolc206.mpls.uswest.net (HELO charita) (65.103.5.206) by mpls-pop-14.inet.qwest.net with SMTP; 6 Nov 2002 17:49:01 -0000
Date: Wed, 6 Nov 2002 11:55:56 -0600
Message-ID: <004301c285bd$c22c6e00$[e-mail]>
From: "Parag Deshpande" <[e-mail]>
To: [e-mail]
Subject: ConnectRetryCnt
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01C2858B.775FA360"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0040_01C2858B.775FA360
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I had a question on ConnectRetryCnt.=20

According to the new draft it seems that this variable=20
is now limited to keeping statistical information.=20

However, the Event6/8 and the statement "- [optionally] performs bgp =
peer oscillation damping"=20
indicate damping mechanisms which MAY be a function of this variable.

Since the current draft does not specify in particular any damping =
mechanisms (that use this variable),
I was wondering, whether the draft should mention it(ConnectRetryCnt) or =
not.

Thanks
Parag




------=_NextPart_000_0040_01C2858B.775FA360
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hi,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>I had a question on ConnectRetryCnt. </FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>According to the new draft it seems that this =
</FONT><FONT=20
size=3D2>variable </FONT></DIV>
<DIV><FONT size=3D2>is now limited to keeping </FONT><FONT =
size=3D2>statistical=20
information. </FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>However, the Event6/8 and the statement <FONT =
size=3D2>"-=20
[optionally] performs bgp peer oscillation damping" </FONT></FONT></DIV>
<DIV><FONT size=3D2>indicate damping mechanisms </FONT><FONT =
size=3D2>which&nbsp;MAY=20
be a function of this variable.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Since the current draft does not specify in =
particular any=20
damping mechanisms (that use this variable),</FONT></DIV>
<DIV><FONT size=3D2>I was wondering,&nbsp;whether th</FONT><FONT =
size=3D2>e draft=20
should mention it(ConnectRetryCnt) or not.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Thanks</FONT></DIV>
<DIV><FONT size=3D2>Parag</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0040_01C2858B.775FA360--



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA06950 for <[e-mail]>; Tue, 5 Nov 2002 20:21:34 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 193BE91213; Tue,  5 Nov 2002 20:21:15 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB3D39121D; Tue,  5 Nov 2002 20:21:14 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4B84791213 for <[e-mail]>; Tue,  5 Nov 2002 20:21:12 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 246C75DD97; Tue,  5 Nov 2002 20:21:12 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 83C095DD8E for <[e-mail]>; Tue,  5 Nov 2002 20:21:11 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gA61LBS83626 for <[e-mail]>; Tue, 5 Nov 2002 17:21:11 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: WG Last Call
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 05 Nov 2002 17:21:11 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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:    [e-mail]
To:      IETF-Announce: ;
cc:      [e-mail]
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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

- --OtherAccess--

- --NextPart--



------- End of Forwarded Message



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA02659 for <[e-mail]>; Tue, 5 Nov 2002 10:05:59 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 3BF8D91213; Tue,  5 Nov 2002 10:05:33 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0DD8791216; Tue,  5 Nov 2002 10:05:32 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F3C4191213 for <[e-mail]>; Tue,  5 Nov 2002 10:05:31 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D5DAC5DDD3; Tue,  5 Nov 2002 10:05:31 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 77E695DDC8 for <[e-mail]>; Tue,  5 Nov 2002 10:05:31 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gA5F4qH62215; Tue, 5 Nov 2002 10:04:52 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA5F4nC62208; Tue, 5 Nov 2002 10:04:49 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA5F4nj12174; Tue, 5 Nov 2002 10:04:49 -0500 (EST)
Date: Tue, 5 Nov 2002 10:04:49 -0500
From: Jeffrey Haas <[e-mail]>
To: Alexei Roudnev <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP security in practice
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <00b401c284a1$c93526a0$6401a8c0@oemcomputer>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <00b401c284a1$c93526a0$6401a8c0@oemcomputer>; from [e-mail] on Tue, Nov 05, 2002 at 12:03:11AM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Nov 05, 2002 at 12:03:11AM -0800, Alexei Roudnev wrote:
> As filters do not help against anything. I know  ISP who did not used AS filtering
> at all 3 years ago - you should filter prefixes anyway, so why bother about AS
> passes? We removed _all_ AS fileters and keep only prefix filters (for both
> inbound and outbound bgp) - of course, it allowed customer to announce ANY AS, but
> _so what?_

Prefix filters protect you against *what*.  I.e. *what* reachability
are you getting?
As path filters protect you against *who*.  I.e. is this person allowed
(or even expected) to propagate this route.

Protecting against bad prefixes provides general protection against
bad routes getting into the Internet.  Pair this with originating
AS correlation and you stop most of what our previous "oops"s have
been.

But you need to filter against the path in order to provide a full
policy check if you're more than one hop away from a given party.
If you're only one hop, you can do this with your prefix filters.

I'll admit that people will settle for sub-optimal routing due to
route leaks - you can notice and fix that.

People don't want to deal with bad prefixes.

> Alexei Roudnev.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA19494 for <[e-mail]>; Tue, 5 Nov 2002 06:11:47 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6207491223; Tue,  5 Nov 2002 06:11:28 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29D869122F; Tue,  5 Nov 2002 06:11:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C289991223 for <[e-mail]>; Tue,  5 Nov 2002 06:11:26 -0500 (EST)
Received: by segue.merit.edu (Postfix) id AEEA35DF2A; Tue,  5 Nov 2002 06:11:26 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 1C7B35DE80 for <[e-mail]>; Tue,  5 Nov 2002 06:11:26 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10838; Tue, 5 Nov 2002 06:08:56 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-bgp4-18.txt
Date: Tue, 05 Nov 2002 06:08:56 -0500
Sender: [e-mail]
Precedence: bulk

--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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA27183 for <[e-mail]>; Mon, 4 Nov 2002 14:58:49 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 13DD091268; Mon,  4 Nov 2002 14:58:30 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFD7091269; Mon,  4 Nov 2002 14:58:29 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 125FC91268 for <[e-mail]>; Mon,  4 Nov 2002 14:58:29 -0500 (EST)
Received: by segue.merit.edu (Postfix) id EB15F5DE83; Mon,  4 Nov 2002 14:58:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from www.aoygroup.com (s1.YURIEV.COM [207.106.66.145]) by segue.merit.edu (Postfix) with SMTP id A72715DE65 for <[e-mail]>; Mon,  4 Nov 2002 14:58:28 -0500 (EST)
Received: (qmail 26515 invoked by uid 500); 4 Nov 2002 20:07:01 -0000
Date: Mon, 4 Nov 2002 15:07:01 -0500 (EST)
From: [e-mail]
To: [e-mail]
Subject: RE: BGP security in practice
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> 
> but you will find it in draft-ng-sobgp-bgp-extensions-00.txt

Whenever one is building a system that uses PKI ("o the 'pki' is pgp-like or
even real pgp") one must deal with key management on the principal. If one
does not deal with the key management on the principal, the entire
authentication/authorization functionality that relies on PKI cannot be
trusted. Saying that PKI key management is beyond the scope of the protocol
is passing a bucket, which does not work. Hence, the protocol added another
layer of complexity and gained nothing. That, in turn, violates KISS
principal.

Alex




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA22652 for <[e-mail]>; Mon, 4 Nov 2002 13:37:16 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 566979120D; Mon,  4 Nov 2002 13:36:39 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E2E791265; Mon,  4 Nov 2002 13:36:39 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 44AE79120D for <[e-mail]>; Mon,  4 Nov 2002 13:36:38 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 2B83A5DEF9; Mon,  4 Nov 2002 13:36:38 -0500 (EST)
Delivered-To: [e-mail]
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id F34B25DEF3 for <[e-mail]>; Mon,  4 Nov 2002 13:36:37 -0500 (EST)
Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 188m5V-000Grw-00; Mon, 04 Nov 2002 10:36:37 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Mark Handley <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP security in practice 
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 04 Nov 2002 10:36:37 -0800
Sender: [e-mail]
Precedence: bulk

> Don't we need to be hardening all the software for a longer-term
> solution, rather than just the current snapshot?

bingo!



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA22399 for <[e-mail]>; Mon, 4 Nov 2002 13:32:24 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E908D91263; Mon,  4 Nov 2002 13:31:20 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 922D291265; Mon,  4 Nov 2002 13:31:20 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 71D0491263 for <[e-mail]>; Mon,  4 Nov 2002 13:31:19 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8857D5DDEA; Mon,  4 Nov 2002 13:30:38 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id AFAC85DDE4 for <[e-mail]>; Mon,  4 Nov 2002 13:30:37 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gA4IU6036432; Mon, 4 Nov 2002 13:30:06 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA4IU2C36425; Mon, 4 Nov 2002 13:30:02 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA4IU2707962; Mon, 4 Nov 2002 13:30:02 -0500 (EST)
Date: Mon, 4 Nov 2002 13:30:02 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: BGP security in practice
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Nov 04, 2002 at 01:29:15PM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Alex,

I think you meant to respond to Randy.

On Mon, Nov 04, 2002 at 01:29:15PM -0500, [e-mail] wrote:
> > I'd argue though that the filter model *may* be implementable
> > on current (bigger) hardware without the need for crypto
> > accelerators.  Thats where some analysis might be handy.
> 
> How are you going to manage the keys?

What keys?  They're just acl's.

> Alex

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA21777 for <[e-mail]>; Mon, 4 Nov 2002 13:21:23 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8735391264; Mon,  4 Nov 2002 13:20:55 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2FE9E91263; Mon,  4 Nov 2002 13:20:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98EA591264 for <[e-mail]>; Mon,  4 Nov 2002 13:20:53 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 4DCB25DEFC; Mon,  4 Nov 2002 13:20:53 -0500 (EST)
Delivered-To: [e-mail]
Received: from www.aoygroup.com (s1.YURIEV.COM [207.106.66.145]) by segue.merit.edu (Postfix) with SMTP id CD7785DEE1 for <[e-mail]>; Mon,  4 Nov 2002 13:20:42 -0500 (EST)
Received: (qmail 25698 invoked by uid 500); 4 Nov 2002 18:29:15 -0000
Date: Mon, 4 Nov 2002 13:29:15 -0500 (EST)
From: [e-mail]
To: Jeffrey Haas <[e-mail]>
Cc: Randy Bush <[e-mail]>, [e-mail]
Subject: Re: BGP security in practice
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> On Mon, Nov 04, 2002 at 08:41:39AM -0800, Randy Bush wrote:
> > operators might like *one* major deployment of change
> 
> Thanks for the clue-by-four on the back of the head.  I need that
> sometimes. :-)
> 
> I'd argue though that the filter model *may* be implementable
> on current (bigger) hardware without the need for crypto
> accelerators.  Thats where some analysis might be handy.

How are you going to manage the keys? Are you going to protect the keys with
encryption? if a router reboots, are  you going to have someone there to
type an unlock phrase to decrypt the key used for authentication? Are you
going to use the key in a non-encrypted so everyone who can do "show key
private" will be able to cut and paste that they into their Xterm logged
into a router in Bangladesh?

Alex



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA21439 for <[e-mail]>; Mon, 4 Nov 2002 13:15:20 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 2FC5691270; Mon,  4 Nov 2002 13:12:14 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1DD19126D; Mon,  4 Nov 2002 13:12:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7485891270 for <[e-mail]>; Mon,  4 Nov 2002 13:11:52 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 5654C5DEFC; Mon,  4 Nov 2002 13:11:52 -0500 (EST)
Delivered-To: [e-mail]
Received: from blooper.utfors.se (mail.utfors.se [195.58.103.125]) by segue.merit.edu (Postfix) with ESMTP id 427E15DDEA for <[e-mail]>; Mon,  4 Nov 2002 13:11:51 -0500 (EST)
Received: from utfors.se ([195.58.105.86]) by blooper.utfors.se (8.12.6/8.12.6) with ESMTP id gA4IBo28000267 for <[e-mail]>; Mon, 4 Nov 2002 19:11:50 +0100 (MET)
Message-ID: <[e-mail]>
Date: Mon, 04 Nov 2002 19:11:51 +0100
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: idr <[e-mail]>
Subject: Last Call: draft-ietf-mpls-bgp-mpls-restart-02.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

idr working group, (mpls wg copied for information)

this is to initiate a last call on

    <draft-ietf-mpls-bgp-mpls-restart-02.txt>

The last call has been requested by the ADs and OKed by idr wg chairs.
The draft is a product of the mpls working group.


    In some scenarios BGP is used a the Label Distribution Protocol.
    A mechanism for BGP that would help minimize  the negative effects
    on routing caused by BGP restart is described in "Graceful Restart
    Mechanism for BGP" <draft-ietf-idr-restart-05>.
    <draft-ietf-mpls-bgp-mpls-restart-02.txt> extends this mechanism to
    also minimize the negative effects on MPLS forwarding caused by a
    restart of BGP when BGP is used to carry MPLS labels and the LSR
    (Label Switching Router) is capable of preserving the MPLS forwarding
    state across the restart.


Since the IETF meeting is upcoming and this is normally busy weeks, this
last call ends November 29th 5 PM EST.

/Loa

-- 
     Loa Andersson
     Chief Architect,
     Utfors Research, Architecture and Future Lab (URAX)
     Utfors AB
     Råsundavägen 12
     Box 525, 169 29 Solna
     Office          [phone]
     Office direct   [phone]
     Mobile          [phone]
     Email           [e-mail]
     WWW             www.utfors.se




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA20510 for <[e-mail]>; Mon, 4 Nov 2002 12:59:45 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BCA489125F; Mon,  4 Nov 2002 12:59:23 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9063C91260; Mon,  4 Nov 2002 12:59:22 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1B5349125F for <[e-mail]>; Mon,  4 Nov 2002 12:59:21 -0500 (EST)
Received: by segue.merit.edu (Postfix) id F36C85DDE4; Mon,  4 Nov 2002 12:59:20 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 7AB1F5DD94 for <[e-mail]>; Mon,  4 Nov 2002 12:59:20 -0500 (EST)
Received: by sentry.gw.tislabs.com; id MAA21646; Mon, 4 Nov 2002 12:59:23 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma021593; Mon, 4 Nov 02 12:58:38 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id gA4HwYn23708; Mon, 4 Nov 2002 12:58:34 -0500 (EST)
Date: Mon, 4 Nov 2002 12:58:34 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail]
Subject: Re: BGP security in practice
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

>Pray tell, how would MD5 secret solve configuration problems?

I didn't say that MD5 would solve the configuration problems, but
that the fact that just mis-configuration errors can cause lots of
damage should clue people into the fact that the protocol has
vulnerabilities to deliberate attack.

--Sandy


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA20307 for <[e-mail]>; Mon, 4 Nov 2002 12:55:53 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id CDAD99125D; Mon,  4 Nov 2002 12:55:25 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 954CB9125F; Mon,  4 Nov 2002 12:55:25 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ADBCC9125D for <[e-mail]>; Mon,  4 Nov 2002 12:55:24 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 9B1465DDEA; Mon,  4 Nov 2002 12:55:24 -0500 (EST)
Delivered-To: [e-mail]
Received: from www.aoygroup.com (s1.YURIEV.COM [207.106.66.145]) by segue.merit.edu (Postfix) with SMTP id 218A45DDE4 for <[e-mail]>; Mon,  4 Nov 2002 12:55:24 -0500 (EST)
Received: (qmail 25452 invoked by uid 500); 4 Nov 2002 18:03:56 -0000
Date: Mon, 4 Nov 2002 13:03:56 -0500 (EST)
From: [e-mail]
To: Randy Bush <[e-mail]>
Cc: Christian Martin <[e-mail]>, [e-mail]
Subject: RE: BGP security in practice
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> > 1) a PKI based system
> > 2) IPSEC based encryption of all data
> > 3) Required use of an IRR for all routing
> 
> that is not clear.  e.g. why do the data need privacy?  why do
> all relationships need to be represented in routing registries?
> 
> for an example, think about a modified s-bgp where
>   o the 'pki' is pgp-like or even real pgp
>   o basic ownership of ip space is attested to by registries
>   o sub-allocation of ip space is attested to by the basic owner,
>     and so forth
>   o the origination of the routing announcement is attested to by
>     an address space owner
>   o an announcement is signed contains
>     - the normal attributes
>     - an attribute saying to what ASn the route is being forwarded
>       (prevents monkey in the middle attacks)
>     - and all this is signed by the announcing AS

Very cute. I really trust Cisco and Juniper to do key management for me.
Not.

The prinipal is called KISS. Make routers route. Make them not break. Make
them not crash. Make them not melt. When we get a good track record on that,
we can talk about key management problems.

Alex



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA20131 for <[e-mail]>; Mon, 4 Nov 2002 12:52:35 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 580819125C; Mon,  4 Nov 2002 12:52:17 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25B679125D; Mon,  4 Nov 2002 12:52:17 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E2E69125C for <[e-mail]>; Mon,  4 Nov 2002 12:52:16 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 2C07D5DDEA; Mon,  4 Nov 2002 12:52:16 -0500 (EST)
Delivered-To: [e-mail]
Received: from www.aoygroup.com (s1.YURIEV.COM [207.106.66.145]) by segue.merit.edu (Postfix) with SMTP id E5CC55DDE4 for <[e-mail]>; Mon,  4 Nov 2002 12:52:15 -0500 (EST)
Received: (qmail 25425 invoked by uid 500); 4 Nov 2002 18:00:47 -0000
Date: Mon, 4 Nov 2002 13:00:47 -0500 (EST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: BGP security in practice
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> >Most ISPs wont react to something (note: react) until you demonstrate
> >the vulnerability to them.  Its one thing to tell them there is a
> >vulnerability.  You have to demonstrate an exploit before they will
> >care.
> 
> The accidental errors that have caused numerous problems in the past
> provide lots of evidence of vulnerability to me.  Anything that can
> fail because of accidents and misconfigurations can be made to fail
> on purpose.

Pray tell, how would MD5 secret solve configuration problems?

Alex



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA17364 for <[e-mail]>; Mon, 4 Nov 2002 12:03:39 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BE59A91257; Mon,  4 Nov 2002 12:02:45 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 556A791259; Mon,  4 Nov 2002 12:02:39 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ACCEE91257 for <[e-mail]>; Mon,  4 Nov 2002 12:02:31 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 876795DEDC; Mon,  4 Nov 2002 12:02:31 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 259D85DEC6 for <[e-mail]>; Mon,  4 Nov 2002 12:02:31 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gA4H2Tm33669; Mon, 4 Nov 2002 12:02:29 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA4H2QC33662; Mon, 4 Nov 2002 12:02:26 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA4H2QW07706; Mon, 4 Nov 2002 12:02:26 -0500 (EST)
Date: Mon, 4 Nov 2002 12:02:26 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: BGP security in practice
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Nov 04, 2002 at 11:37:28AM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Nov 04, 2002 at 11:37:28AM -0500, [e-mail] wrote:
> Intersting.  Can you tell me more, or was this one of those conversations
> whose details are understood to be on the QT?

See a conversation on idr a while back about how "origin can be
changed to affect routing policy".

Basically, where you *think* the provider may be applying default
policy at some point and you think path lengths are equal, tweaking
the origin at one point in the network may cause traffic streams
to make a *hard* turn.

For example, here's something from a current view of the Internet.
bash-2.05$ grep '       Path:.*Incomplete' gated_dump | wc -l
    1963
bash-2.05$ grep '       Path:.*IGP' gated_dump | wc -l
   43573
bash-2.05$ grep '       Path:.*EGP' gated_dump | wc -l
    40

This would argue that you could introduce intentionally suboptimal
paths just by making a lot of things that are origin IGP as origin
incomplete.

It would make an interesting experiment to see exactly what *does*
happen.

> --Sandy

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA16957 for <[e-mail]>; Mon, 4 Nov 2002 11:56:54 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id CBC4791258; Mon,  4 Nov 2002 11:56:24 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F82691259; Mon,  4 Nov 2002 11:56:24 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7FCF491258 for <[e-mail]>; Mon,  4 Nov 2002 11:56:23 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3F7F85DEC6; Mon,  4 Nov 2002 11:56:23 -0500 (EST)
Delivered-To: [e-mail]
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 14FD15E15A for <[e-mail]>; Mon,  4 Nov 2002 11:56:23 -0500 (EST)
Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 188kWU-000E80-00; Mon, 04 Nov 2002 08:56:22 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP security in practice
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 04 Nov 2002 08:56:22 -0800
Sender: [e-mail]
Precedence: bulk

> I'd argue though that the filter model *may* be implementable
> on current (bigger) hardware without the need for crypto
> accelerators.  Thats where some analysis might be handy.

it's the infrastructure deployment, not just the boxes.

randy



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA16348 for <[e-mail]>; Mon, 4 Nov 2002 11:45:25 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id A1B5E91266; Mon,  4 Nov 2002 11:44:52 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5EB9791267; Mon,  4 Nov 2002 11:44:52 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 467FC91266 for <[e-mail]>; Mon,  4 Nov 2002 11:44:48 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 337E65E167; Mon,  4 Nov 2002 11:44:48 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 79FA15E15A for <[e-mail]>; Mon,  4 Nov 2002 11:44:47 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gA4GiFx33028; Mon, 4 Nov 2002 11:44:15 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA4GiCC33021; Mon, 4 Nov 2002 11:44:12 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA4GiCs07643; Mon, 4 Nov 2002 11:44:12 -0500 (EST)
Date: Mon, 4 Nov 2002 11:44:12 -0500
From: Jeffrey Haas <[e-mail]>
To: Randy Bush <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP security in practice
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Nov 04, 2002 at 08:41:39AM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Nov 04, 2002 at 08:41:39AM -0800, Randy Bush wrote:
> operators might like *one* major deployment of change

Thanks for the clue-by-four on the back of the head.  I need that
sometimes. :-)

I'd argue though that the filter model *may* be implementable
on current (bigger) hardware without the need for crypto
accelerators.  Thats where some analysis might be handy.

> randy

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA16334 for <[e-mail]>; Mon, 4 Nov 2002 11:45:14 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 3398191255; Mon,  4 Nov 2002 11:43:08 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DDD5F9125B; Mon,  4 Nov 2002 11:43:07 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2409391255 for <[e-mail]>; Mon,  4 Nov 2002 11:43:03 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 133DB5E161; Mon,  4 Nov 2002 11:43:03 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 6E63A5E15A for <[e-mail]>; Mon,  4 Nov 2002 11:43:02 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gA4Gh0A32980; Mon, 4 Nov 2002 11:43:00 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA4GguC32966; Mon, 4 Nov 2002 11:42:56 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA4GguP07635; Mon, 4 Nov 2002 11:42:56 -0500 (EST)
Date: Mon, 4 Nov 2002 11:42:56 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: BGP security in practice
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Nov 04, 2002 at 11:35:52AM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Nov 04, 2002 at 11:35:52AM -0500, [e-mail] wrote:
> OK, I knew about using communities to affect traffic flow.  Think I talked
> about it at one meeting or aother (idr, rpsec) recently.

idr I believe.

> The vulnerabilities draft right now addresses only the base draft, with
> a recognized need to write similar stuff for communities, confederations,
> route reflectors, route refresh, ORF,....

IMO, while dealing with all of the threats is worthwhile, 
addressing the inter-as threat model gives us the best bang for the
buck in the short term.

> --Sandy

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA16118 for <[e-mail]>; Mon, 4 Nov 2002 11:42:11 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 4C59191254; Mon,  4 Nov 2002 11:41:41 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26E7091256; Mon,  4 Nov 2002 11:41:40 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C73C591254 for <[e-mail]>; Mon,  4 Nov 2002 11:41:39 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B416C5DEFC; Mon,  4 Nov 2002 11:41:39 -0500 (EST)
Delivered-To: [e-mail]
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 8A3F95DDEA for <[e-mail]>; Mon,  4 Nov 2002 11:41:39 -0500 (EST)
Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 188kIF-000Dj2-00; Mon, 04 Nov 2002 08:41:39 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP security in practice
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 04 Nov 2002 08:41:39 -0800
Sender: [e-mail]
Precedence: bulk

> In essence, I'm arguing that since both of these pieces are eventually
> necessary, the filter piece gives us the most bang for the buck
> in the shorter time.

operators might like *one* major deployment of change

randy



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA15890 for <[e-mail]>; Mon, 4 Nov 2002 11:38:13 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8324C91252; Mon,  4 Nov 2002 11:37:56 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50D2491253; Mon,  4 Nov 2002 11:37:56 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 42B9291252 for <[e-mail]>; Mon,  4 Nov 2002 11:37:55 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 28AAA5E10C; Mon,  4 Nov 2002 11:37:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (unknown [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id A6C475DEFC for <[e-mail]>; Mon,  4 Nov 2002 11:37:54 -0500 (EST)
Received: by sentry.gw.tislabs.com; id LAA18380; Mon, 4 Nov 2002 11:37:57 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma018348; Mon, 4 Nov 02 11:37:33 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id gA4GbSE18312; Mon, 4 Nov 2002 11:37:28 -0500 (EST)
Date: Mon, 4 Nov 2002 11:37:28 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail]
Subject: Re: BGP security in practice
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

>It also occurs to me (courtesy of a NANOG conversation) that one
>can do incredibly evil things to traffic flows that is difficult
>to catch just by tweaking route origin.

Intersting.  Can you tell me more, or was this one of those conversations
whose details are understood to be on the QT?

--Sandy


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA15832 for <[e-mail]>; Mon, 4 Nov 2002 11:37:11 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id AD59091251; Mon,  4 Nov 2002 11:36:53 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D10291252; Mon,  4 Nov 2002 11:36:53 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6AE8291251 for <[e-mail]>; Mon,  4 Nov 2002 11:36:52 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 55DCE5DEFC; Mon,  4 Nov 2002 11:36:52 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (unknown [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id CC4965E10C for <[e-mail]>; Mon,  4 Nov 2002 11:36:51 -0500 (EST)
Received: by sentry.gw.tislabs.com; id LAA18310; Mon, 4 Nov 2002 11:36:55 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma018272; Mon, 4 Nov 02 11:35:56 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id gA4GZq018175; Mon, 4 Nov 2002 11:35:52 -0500 (EST)
Date: Mon, 4 Nov 2002 11:35:52 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: Re: BGP security in practice
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

>>From the top of my head:
>communities in general.  NOPEER in particular.

OK, I knew about using communities to affect traffic flow.  Think I talked
about it at one meeting or aother (idr, rpsec) recently.

The vulnerabilities draft right now addresses only the base draft, with
a recognized need to write similar stuff for communities, confederations,
route reflectors, route refresh, ORF,....

--Sandy


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA15649 for <[e-mail]>; Mon, 4 Nov 2002 11:33:52 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id F19FE9124E; Mon,  4 Nov 2002 11:32:59 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8F6F9124F; Mon,  4 Nov 2002 11:32:58 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B7DD59124E for <[e-mail]>; Mon,  4 Nov 2002 11:32:56 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8DF925E169; Mon,  4 Nov 2002 11:32:56 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (unknown [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 0B3F65E10C for <[e-mail]>; Mon,  4 Nov 2002 11:32:50 -0500 (EST)
Received: by sentry.gw.tislabs.com; id LAA18194; Mon, 4 Nov 2002 11:32:53 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma018168; Mon, 4 Nov 02 11:32:34 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id gA4GWUU18003; Mon, 4 Nov 2002 11:32:30 -0500 (EST)
Date: Mon, 4 Nov 2002 11:32:30 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: RE: BGP security in practice
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

>> 2) IPSEC based encryption of all data
>
>that is not clear.  e.g. why do the data need privacy?

Some people say "encryption" when they mean "use cryptography".  Some
people say "encryption" when they mean "use cryptography to provide
privacy".  So I don't know if Christian's use meant privacy or not.
Be that as it may, in the rpsec meetings, people have spoken up to say
that they think routing data does need to be private between peers.
I don't know why, myself, but if they want it, who am I to quibble?
(Now, in the wireless world where routing protocols sometimes use the
broadcast channel, providing privacy between peers might be problematic.)

>> 3) Required use of an IRR for all routing
>..
>why do
>all relationships need to be represented in routing registries?

A minimal level of protection would be to have people checking the
routing registries to see if the routing data (origin and ASPath) was OK,
without a cryptographic protection of the messages.  This doesn't buy
much, but it is a bit better than nothing.

--Sandy


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA14045 for <[e-mail]>; Mon, 4 Nov 2002 11:05:20 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 2D1D99124C; Mon,  4 Nov 2002 11:05:08 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EAE0F9124D; Mon,  4 Nov 2002 11:05:07 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DAC0C9124C for <[e-mail]>; Mon,  4 Nov 2002 11:05:06 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C38985E14D; Mon,  4 Nov 2002 11:05:06 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 3106D5E10C for <[e-mail]>; Mon,  4 Nov 2002 11:05:06 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gA4G54n31994; Mon, 4 Nov 2002 11:05:04 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA4G51C31987; Mon, 4 Nov 2002 11:05:01 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA4G51t07461; Mon, 4 Nov 2002 11:05:01 -0500 (EST)
Date: Mon, 4 Nov 2002 11:05:01 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: BGP security in practice
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Nov 04, 2002 at 10:57:46AM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Nov 04, 2002 at 10:57:46AM -0500, [e-mail] wrote:
> I see a suggestion here that you think there are vulnerabilties to
> BGP through other transitive attributes.  Such vulnerabilities would
> be good to add to the bgp vulnerabilities draft.  Could you let me
> know what you think should be added?  I'd really like to be complete.

>From the top of my head:
communities in general.  NOPEER in particular.

It also occurs to me (courtesy of a NANOG conversation) that one
can do incredibly evil things to traffic flows that is difficult
to catch just by tweaking route origin.

> --Sandy

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA13959 for <[e-mail]>; Mon, 4 Nov 2002 11:03:45 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 316AD91237; Mon,  4 Nov 2002 11:03:22 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 015F19124C; Mon,  4 Nov 2002 11:03:21 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1FFF391237 for <[e-mail]>; Mon,  4 Nov 2002 11:03:03 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 04C765E10C; Mon,  4 Nov 2002 11:03:03 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 572405DEE1 for <[e-mail]>; Mon,  4 Nov 2002 11:03:02 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gA4G2UL31858; Mon, 4 Nov 2002 11:02:30 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA4G2QC31850; Mon, 4 Nov 2002 11:02:26 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA4G2QJ07446; Mon, 4 Nov 2002 11:02:26 -0500 (EST)
Date: Mon, 4 Nov 2002 11:02:26 -0500
From: Jeffrey Haas <[e-mail]>
To: Randy Bush <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP security in practice
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Nov 04, 2002 at 07:55:33AM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Nov 04, 2002 at 07:55:33AM -0800, Randy Bush wrote:
> presume crypto hardware on routers

One could also presume some extra hardware for filters. :-)

> but as filters do not help at all against a mitm

True.  
Solving the long-term problem means securing against that threat model.

I think the threat model that is of biggest concern to operators today
(IMO) is just making sure people don't (re)announce stuff they're
not supposed to.  

Signing only keeps people from lying about something they did.
You still need to verify that the signed thing belongs to them.

In essence, I'm arguing that since both of these pieces are eventually
necessary, the filter piece gives us the most bang for the buck
in the shorter time.

> randy

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA13704 for <[e-mail]>; Mon, 4 Nov 2002 10:59:08 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E9D619124B; Mon,  4 Nov 2002 10:58:49 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B57DA9124C; Mon,  4 Nov 2002 10:58:49 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A76319124B for <[e-mail]>; Mon,  4 Nov 2002 10:58:48 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8CDE15DEFC; Mon,  4 Nov 2002 10:58:48 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (unknown [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id DCC1F5DD94 for <[e-mail]>; Mon,  4 Nov 2002 10:58:27 -0500 (EST)
Received: by sentry.gw.tislabs.com; id KAA17023; Mon, 4 Nov 2002 10:58:31 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma017009; Mon, 4 Nov 02 10:57:50 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id gA4Fvkn15950; Mon, 4 Nov 2002 10:57:46 -0500 (EST)
Date: Mon, 4 Nov 2002 10:57:46 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: Re: BGP security in practice
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

>Right, but if we're only talking as paths, that might be doable.
>But if we're talking about "he did *foo* to this route here", it
>becomes more problematic.  Consider a change of other transitive
>attributes.

I see a suggestion here that you think there are vulnerabilties to
BGP through other transitive attributes.  Such vulnerabilities would
be good to add to the bgp vulnerabilities draft.  Could you let me
know what you think should be added?  I'd really like to be complete.

--Sandy


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA13488 for <[e-mail]>; Mon, 4 Nov 2002 10:55:56 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id F1E889124A; Mon,  4 Nov 2002 10:55:35 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD8149124B; Mon,  4 Nov 2002 10:55:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D80F09124A for <[e-mail]>; Mon,  4 Nov 2002 10:55:33 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C14A05DED6; Mon,  4 Nov 2002 10:55:33 -0500 (EST)
Delivered-To: [e-mail]
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 98B9E5DDEA for <[e-mail]>; Mon,  4 Nov 2002 10:55:33 -0500 (EST)
Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 188jZd-000COy-00; Mon, 04 Nov 2002 07:55:33 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP security in practice
References: <[e-mail]> <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 04 Nov 2002 07:55:33 -0800
Sender: [e-mail]
Precedence: bulk

> Has anyone actually checked to see what the relative computation loads
> are on a certificate chain signing on routes (which is what I understand
> s-bgp to largely be) versus an IRR cascading policy check?

presume crypto hardware on routers

but as filters do not help at all against a mitm

randy



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA13387 for <[e-mail]>; Mon, 4 Nov 2002 10:54:11 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id AED5E91248; Mon,  4 Nov 2002 10:53:34 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E85C9124A; Mon,  4 Nov 2002 10:53:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4BE7B91248 for <[e-mail]>; Mon,  4 Nov 2002 10:53:33 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3AF9C5DEDC; Mon,  4 Nov 2002 10:53:33 -0500 (EST)
Delivered-To: [e-mail]
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by segue.merit.edu (Postfix) with ESMTP id 19B7F5DED6 for <[e-mail]>; Mon,  4 Nov 2002 10:53:33 -0500 (EST)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id AB2224CF74; Mon,  4 Nov 2002 10:53:32 -0500 (EST)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id KAA14459; Mon, 4 Nov 2002 10:53:31 -0500 (EST)
From: Bill Fenner <[e-mail]>
Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id HAA12938; Mon, 4 Nov 2002 07:53:31 -0800 (PST)
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: [e-mail]
Subject: RE: draft-ietf-idr-bgp4-18.txt
Cc: [e-mail]
Date: Mon, 4 Nov 2002 07:53:30 -0800
Versions: dmail (solaris) 2.5a/makemail 2.9d
Sender: [e-mail]
Precedence: bulk

>	If it is not the policy of the Secretariat 
>(or their designate) to check with WG chairs, it
>should be.  By definition, once a draft has been
>accepted by the WG, it belongs to the WG.  Why
>should it be subject to expiry as a result of an 
>author or editor being unable to rev' it?

All drafts are subject to expiry after 6 months.  Working group
drafts aren't different than non-WG drafts in this regard.  You are
right that the WG owns the document, and can revise it without the
hypothetical too-busy authors in the loop by picking a new editor.

The expiration policy is in place to prevent drafts from being a
reference series.  Some working groups might not bother finishing
their work, instead simply leaving it as an I-D, and asking for
that I-D to never expire.  To avoid that possibility, the expiration
policy is in place.  6 months is a long time in the Internet, and
all you need is one person who cares to increment the version number
and send in the new version.

  Bill


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA13222 for <[e-mail]>; Mon, 4 Nov 2002 10:51:02 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id EE63F91247; Mon,  4 Nov 2002 10:50:41 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA0BD91248; Mon,  4 Nov 2002 10:50:40 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B411291247 for <[e-mail]>; Mon,  4 Nov 2002 10:50:39 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 9663F5DED6; Mon,  4 Nov 2002 10:50:39 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 0C6BB5DD94 for <[e-mail]>; Mon,  4 Nov 2002 10:50:39 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gA4Fo5Y31449; Mon, 4 Nov 2002 10:50:05 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA4Fo2C31442; Mon, 4 Nov 2002 10:50:02 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA4Fo2w07388; Mon, 4 Nov 2002 10:50:02 -0500 (EST)
Date: Mon, 4 Nov 2002 10:50:02 -0500
From: Jeffrey Haas <[e-mail]>
To: Randy Bush <[e-mail]>
Cc: "Martin, Christian" <[e-mail]>, [e-mail]
Subject: Re: BGP security in practice
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Nov 04, 2002 at 07:45:20AM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Nov 04, 2002 at 07:45:20AM -0800, Randy Bush wrote:
> it's worth the thought.  and note that not only is the origin signed,
> but also the forwarding path, i.e. "yes, i gave this announcement to
> mary."

Right, but if we're only talking as paths, that might be doable.
But if we're talking about "he did *foo* to this route here", it
becomes more problematic.  Consider a change of other transitive
attributes.

> randy

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA13117 for <[e-mail]>; Mon, 4 Nov 2002 10:49:06 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 287E091246; Mon,  4 Nov 2002 10:48:02 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7AC1091247; Mon,  4 Nov 2002 10:47:59 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 669E991246 for <[e-mail]>; Mon,  4 Nov 2002 10:47:58 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 574795DD9B; Mon,  4 Nov 2002 10:47:58 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 9615B5DD94 for <[e-mail]>; Mon,  4 Nov 2002 10:47:57 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gA4FlPY31333; Mon, 4 Nov 2002 10:47:25 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA4FlMC31326; Mon, 4 Nov 2002 10:47:22 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA4FlMC07368; Mon, 4 Nov 2002 10:47:22 -0500 (EST)
Date: Mon, 4 Nov 2002 10:47:22 -0500
From: Jeffrey Haas <[e-mail]>
To: Randy Bush <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP security in practice
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Nov 04, 2002 at 07:33:55AM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Randy,

On Mon, Nov 04, 2002 at 07:33:55AM -0800, Randy Bush wrote:
> that is not clear.  e.g. why do the data need privacy?  why do
> all relationships need to be represented in routing registries?

I'm going to skip over your other arguments since I haven't looked
at s-bgp in enough detail to make intelligent comments on it.

However, the piece we are missing right now is a mapping of
address space ownership to AS space.  The IRR's have a way to
represent it - we need the RIR's to track this.

Without this, all the talk of "ownership" in the world wont help.

...

Has anyone actually checked to see what the relative computation loads
are on a certificate chain signing on routes (which is what I understand
s-bgp to largely be) versus an IRR cascading policy check?
(Yeah, that presumes correct policy.)

Intuitively, it seems like it'd take fewer cpu cycles to do this
at the cost of a pretty huge database.  But I don't have a good
feel for the size of the certificate db's that would need to be
passed around.

And intuitively doesn't mean squat.  Numbers do. :-)

I'll shut-up now since I don't have time to put-up.

> randy

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA13006 for <[e-mail]>; Mon, 4 Nov 2002 10:46:57 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E4AB59123B; Mon,  4 Nov 2002 10:45:31 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA61691247; Mon,  4 Nov 2002 10:45:31 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BA92A9123B for <[e-mail]>; Mon,  4 Nov 2002 10:45:30 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 99D715DEFC; Mon,  4 Nov 2002 10:45:21 -0500 (EST)
Delivered-To: [e-mail]
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 3896B5DD94 for <[e-mail]>; Mon,  4 Nov 2002 10:45:21 -0500 (EST)
Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 188jPk-000C7k-00; Mon, 04 Nov 2002 07:45:20 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Martin, Christian" <[e-mail]>
Cc: [e-mail]
Subject: RE: BGP security in practice
References: <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 04 Nov 2002 07:45:20 -0800
Sender: [e-mail]
Precedence: bulk

> I was referring to 3) more for config generation, but are you suggesting
> that if we have signed routes, then we don't need detailed filters?

it's worth the thought.  and note that not only is the origin signed,
but also the forwarding path, i.e. "yes, i gave this announcement to
mary."

randy



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA12756 for <[e-mail]>; Mon, 4 Nov 2002 10:43:16 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 7D4F891245; Mon,  4 Nov 2002 10:43:01 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3AC0591246; Mon,  4 Nov 2002 10:43:01 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 40F7A91245 for <[e-mail]>; Mon,  4 Nov 2002 10:43:00 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 2A0955DD94; Mon,  4 Nov 2002 10:43:00 -0500 (EST)
Delivered-To: [e-mail]
Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10]) by segue.merit.edu (Postfix) with ESMTP id C8C725DEFC for <[e-mail]>; Mon,  4 Nov 2002 10:42:59 -0500 (EST)
Received: by entmail.gnilink.net with Internet Mail Service (5.5.2656.59) id <WAF3BATS>; Mon, 4 Nov 2002 10:42:59 -0500
Message-ID: <[e-mail]>
From: "Martin, Christian" <[e-mail]>
To: "'Randy Bush'" <[e-mail]>, "Martin, Christian" <[e-mail]>
Cc: [e-mail]
Subject: RE: BGP security in practice
Date: Mon, 4 Nov 2002 10:42:58 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Randy,

I was referring to 3) more for config generation, but are you suggesting
that if we have signed routes, then we don't need detailed filters?  I can
see this being a large leap of faith for many providers.   Perhaps more of a
mental block than anything, but we need to develop a level of trust.
Something transitional would be needed, I would think.

Thanks,
chris



> that is not clear.  e.g. why do the data need privacy?  why do
> all relationships need to be represented in routing registries?
> 
> for an example, think about a modified s-bgp where
>   o the 'pki' is pgp-like or even real pgp
>   o basic ownership of ip space is attested to by registries
>   o sub-allocation of ip space is attested to by the basic owner,
>     and so forth
>   o the origination of the routing announcement is attested to by
>     an address space owner
>   o an announcement is signed contains
>     - the normal attributes
>     - an attribute saying to what ASn the route is being forwarded
>       (prevents monkey in the middle attacks)
>     - and all this is signed by the announcing AS
> 
> randy
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA12689 for <[e-mail]>; Mon, 4 Nov 2002 10:42:02 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 957A191244; Mon,  4 Nov 2002 10:41:35 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F09E91245; Mon,  4 Nov 2002 10:41:35 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4EF6C91244 for <[e-mail]>; Mon,  4 Nov 2002 10:41:34 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3D0BD5DD9B; Mon,  4 Nov 2002 10:41:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id C1F655DD94 for <[e-mail]>; Mon,  4 Nov 2002 10:41:33 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gA4FfWh31157; Mon, 4 Nov 2002 10:41:32 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA4FfTC31150; Mon, 4 Nov 2002 10:41:29 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA4FfTo07349; Mon, 4 Nov 2002 10:41:29 -0500 (EST)
Date: Mon, 4 Nov 2002 10:41:29 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: BGP security in practice
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Nov 04, 2002 at 10:28:14AM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Nov 04, 2002 at 10:28:14AM -0500, [e-mail] wrote:
> The accidental errors that have caused numerous problems in the past
> provide lots of evidence of vulnerability to me.

I was speaking more to the md5 issue than the generic 'bgp security issue',
but:

> Anything that can
> fail because of accidents and misconfigurations can be made to fail
> on purpose.

Even in a "perfect" world, you are still vulnerable to the following
vulnerabilities:
o Route redistribution issues - either distributing them or not
  incorrectly.
  (Admittedly, an IRR policy check along every step could catch this.)
o Doing "bad things" to your own routes.

> And those insider problems are even harder to deal with than the
> outsider problems, which they aren't dealing with.  What's needed
> - an equivalent to a public health media campaign?

Well, getting flamed publicly doesn't seem to help.

> --Sandy

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA12493 for <[e-mail]>; Mon, 4 Nov 2002 10:38:28 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DFD1191243; Mon,  4 Nov 2002 10:38:06 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD70591244; Mon,  4 Nov 2002 10:38:06 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9F67991243 for <[e-mail]>; Mon,  4 Nov 2002 10:38:05 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 89FCC5DD9B; Mon,  4 Nov 2002 10:38:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id EC3BF5DD94 for <[e-mail]>; Mon,  4 Nov 2002 10:38:04 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gA4FbvI31016; Mon, 4 Nov 2002 10:37:57 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA4FbsC31009; Mon, 4 Nov 2002 10:37:54 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA4Fbs107335; Mon, 4 Nov 2002 10:37:54 -0500 (EST)
Date: Mon, 4 Nov 2002 10:37:54 -0500
From: Jeffrey Haas <[e-mail]>
To: Vincent Gillet <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP security in practice
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Nov 04, 2002 at 04:28:07PM +0100
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Vincent,

On Mon, Nov 04, 2002 at 04:28:07PM +0100, Vincent Gillet wrote:
> That is exactly the point i wanted to raise.
> I would push to implement MD5 (it's weak, i know) only if somebody
> demonstrate that vulnerability does exist.

TCP session resets are the most likely attack that I think we'll
see in the near future.  Its easier to hack enable privileges
on a box than it is to hijack the session and screw with routing
that way.

And an active hijack is far more likely to be noticed by a provider.

> This is true today, but i am rather confident that BGP authentication/
> authorization would be a hot issue in coming years.

Lets plug the big holes first, shall we? :-)

> Vincent.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA12271 for <[e-mail]>; Mon, 4 Nov 2002 10:34:15 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D281C91242; Mon,  4 Nov 2002 10:33:56 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A237F91243; Mon,  4 Nov 2002 10:33:56 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BEBF891242 for <[e-mail]>; Mon,  4 Nov 2002 10:33:55 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A14505DEFC; Mon,  4 Nov 2002 10:33:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 76D9E5DEE1 for <[e-mail]>; Mon,  4 Nov 2002 10:33:55 -0500 (EST)
Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 188jEh-000Bnt-00; Mon, 04 Nov 2002 07:33:55 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Christian Martin <[e-mail]>
Cc: [e-mail]
Subject: RE: BGP security in practice
References: <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 04 Nov 2002 07:33:55 -0800
Sender: [e-mail]
Precedence: bulk

> In order for BGP Security to become a reality, we need:
> 1) a PKI based system
> 2) IPSEC based encryption of all data
> 3) Required use of an IRR for all routing

that is not clear.  e.g. why do the data need privacy?  why do
all relationships need to be represented in routing registries?

for an example, think about a modified s-bgp where
  o the 'pki' is pgp-like or even real pgp
  o basic ownership of ip space is attested to by registries
  o sub-allocation of ip space is attested to by the basic owner,
    and so forth
  o the origination of the routing announcement is attested to by
    an address space owner
  o an announcement is signed contains
    - the normal attributes
    - an attribute saying to what ASn the route is being forwarded
      (prevents monkey in the middle attacks)
    - and all this is signed by the announcing AS

randy



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA12236 for <[e-mail]>; Mon, 4 Nov 2002 10:33:42 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D229B91241; Mon,  4 Nov 2002 10:33:19 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DDBC91242; Mon,  4 Nov 2002 10:33:19 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5655391241 for <[e-mail]>; Mon,  4 Nov 2002 10:32:57 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1CC675DEE1; Mon,  4 Nov 2002 10:32:57 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 5E92B5E15A for <[e-mail]>; Mon,  4 Nov 2002 10:32:56 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gA4FWtu30838 for [e-mail]; Mon, 4 Nov 2002 10:32:55 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA4FWqC30831 for <[e-mail]>; Mon, 4 Nov 2002 10:32:52 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA4FWqA07302 for [e-mail]; Mon, 4 Nov 2002 10:32:52 -0500 (EST)
Date: Mon, 4 Nov 2002 10:32:52 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-idr-bgp4-18.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Nov 01, 2002 at 03:52:43PM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Nov 01, 2002 at 03:52:43PM -0800, Bill Fenner wrote:
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time

And in the lines of "mea culpa" (they expired), I just re-submitted
the latest versions of the BGP MIBs last night, so they should
appear in the next several days.  The major changes are:

o Atomic aggregate is clarified. (about time)

v2mib:
Some bug fixes were put in:
o In the nlri tables, prefixlen and prefix were swapped.
o Clarify some text in the descriptions of the peer tables to address
  some points Venu brought up.
o Change to using SnmpAdminString instead of DisplayString to permit
  internationalization.  MIB implementors - please comment on this.
o Fix the textual convention for extended communities.
o Changed the enumerations of bgpM2PathAttrAtomicAggregate to stop
  mentioning less and more specific.
o Added a table for rfc 2545 link local nexthops.

Not addressed in these mibs:
o Some of Ran Atkinson's comments for the security section, specifically
  text requiring a MUST of using snmpv3 for implementors of these
  MIBs.  I think the language was a bit strong, but there is still
  an issue and we'll deal with it.  My suggestion is to insist on
  strong security in cases where snmp writes are allowed, but to
  allow for lesser security for most objects.
o I had some notes on table structure that I no longer understood
  since its been a while.  I'll be querying some people on these
  notes.  Sorry they didn't make this round.

The changes are light enough on the v2mib that this shouldn't 
throw a huge monkey-wrench into implementations.  Speaking of
which:
Who is implementing the v2mib?

>   Bill

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA11996 for <[e-mail]>; Mon, 4 Nov 2002 10:29:25 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 63D2291240; Mon,  4 Nov 2002 10:29:05 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3179291241; Mon,  4 Nov 2002 10:29:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2162591240 for <[e-mail]>; Mon,  4 Nov 2002 10:29:04 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 097F25DEDF; Mon,  4 Nov 2002 10:29:04 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (unknown [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 8872C5DD94 for <[e-mail]>; Mon,  4 Nov 2002 10:29:03 -0500 (EST)
Received: by sentry.gw.tislabs.com; id KAA16112; Mon, 4 Nov 2002 10:29:06 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma016069; Mon, 4 Nov 02 10:28:18 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id gA4FSEn14049; Mon, 4 Nov 2002 10:28:14 -0500 (EST)
Date: Mon, 4 Nov 2002 10:28:14 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: Re: BGP security in practice
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

>Most ISPs wont react to something (note: react) until you demonstrate
>the vulnerability to them.  Its one thing to tell them there is a
>vulnerability.  You have to demonstrate an exploit before they will
>care.

The accidental errors that have caused numerous problems in the past
provide lots of evidence of vulnerability to me.  Anything that can
fail because of accidents and misconfigurations can be made to fail
on purpose.

>In the grand scheme of things, ISPs are more concerned about "bad"
>data getting leaked into the routing system rather than they are
>about session hijacking or DoS.

And those insider problems are even harder to deal with than the
outsider problems, which they aren't dealing with.  What's needed
- an equivalent to a public health media campaign?

--Sandy


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA11945 for <[e-mail]>; Mon, 4 Nov 2002 10:28:32 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1D5D79123F; Mon,  4 Nov 2002 10:28:11 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E375391240; Mon,  4 Nov 2002 10:28:10 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BAC129123F for <[e-mail]>; Mon,  4 Nov 2002 10:28:09 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A8C1B5DEDF; Mon,  4 Nov 2002 10:28:09 -0500 (EST)
Delivered-To: [e-mail]
Received: from utopia.opentransit.net (utopia.opentransit.net [193.251.151.78]) by segue.merit.edu (Postfix) with ESMTP id 074D05DD94 for <[e-mail]>; Mon,  4 Nov 2002 10:28:09 -0500 (EST)
Received: from utopia.opentransit.net (localhost [127.0.0.1]) by utopia.opentransit.net (8.12.4/8.12.4/Debian-4) with ESMTP id gA4FS7Yd021442 for <[e-mail]>; Mon, 4 Nov 2002 16:28:07 +0100
Received: (from vgi@localhost) by utopia.opentransit.net (8.12.4/8.12.4/Debian-4) id gA4FS7Vj021441 for [e-mail]; Mon, 4 Nov 2002 16:28:07 +0100
Date: Mon, 4 Nov 2002 16:28:07 +0100
From: Vincent Gillet <[e-mail]>
To: [e-mail]
Subject: Re: BGP security in practice
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4i
Sender: [e-mail]
Precedence: bulk

Hi Jeffrey,

> On Mon, Nov 04, 2002 at 08:40:19AM -0500, [e-mail] wrote:
> > In the judgement of those on this list, is the general ISP as clueless
> > as this?  Mind you, I'm not asking if the common ISP uses the MD5, just
> > if they know that there's a security vulnerability if they don't.
> 
> Most ISPs wont react to something (note: react) until you demonstrate
> the vulnerability to them.  Its one thing to tell them there is a
> vulnerability.  You have to demonstrate an exploit before they will
> care.

That is exactly the point i wanted to raise.
I would push to implement MD5 (it's weak, i know) only if somebody
demonstrate that vulnerability does exist.

> And honestly, people are more worried about their routers getting
> hacked into rather than attacks on the BGP Protocol.

This is true today, but i am rather confident that BGP authentication/
authorization would be a hot issue in coming years.

> Major backbones *may* do this internally.  Chatting with people at
> various NANOGs seem to indicate that many of the "tier-1's" don't
> bother to authenticate their customer sessions.
> 
> In the grand scheme of things, ISPs are more concerned about "bad"
> data getting leaked into the routing system rather than they are
> about session hijacking or DoS.

Do agree. This is what i call "prefix authentication/authorization".

Vincent.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA11666 for <[e-mail]>; Mon, 4 Nov 2002 10:24:24 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id CCF119123E; Mon,  4 Nov 2002 10:24:01 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9EE109123F; Mon,  4 Nov 2002 10:24:01 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9099F9123E for <[e-mail]>; Mon,  4 Nov 2002 10:24:00 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 706265DEDF; Mon,  4 Nov 2002 10:24:00 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (unknown [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id EF5525DEE1 for <[e-mail]>; Mon,  4 Nov 2002 10:23:59 -0500 (EST)
Received: by sentry.gw.tislabs.com; id KAA15872; Mon, 4 Nov 2002 10:24:02 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma015782; Mon, 4 Nov 02 10:22:58 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id gA4FMrV13597; Mon, 4 Nov 2002 10:22:53 -0500 (EST)
Date: Mon, 4 Nov 2002 10:22:53 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail]
Subject: RE: BGP security in practice
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

>In order for BGP Security to become a reality, we need:
>
>1) a PKI based system
>2) IPSEC based encryption of all data
>3) Required use of an IRR for all routing
>
>Until then, we are running around with Bandaids trying to stop hundreds of
>leaks...

I agree, but how to convince people to do this?

--Sandy


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA10755 for <[e-mail]>; Mon, 4 Nov 2002 10:11:07 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 167359123D; Mon,  4 Nov 2002 10:10:47 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CBD569123E; Mon,  4 Nov 2002 10:10:46 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B984A9123D for <[e-mail]>; Mon,  4 Nov 2002 10:10:45 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 9FF425DEDF; Mon,  4 Nov 2002 10:10:45 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 420465DEDC for <[e-mail]>; Mon,  4 Nov 2002 10:10:45 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gA4FAh030027; Mon, 4 Nov 2002 10:10:43 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA4FAeC30020; Mon, 4 Nov 2002 10:10:40 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA4FAd507232; Mon, 4 Nov 2002 10:10:39 -0500 (EST)
Date: Mon, 4 Nov 2002 10:10:39 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: BGP security in practice
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Nov 04, 2002 at 08:40:19AM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Sandy,

On Mon, Nov 04, 2002 at 08:40:19AM -0500, [e-mail] wrote:
> In the judgement of those on this list, is the general ISP as clueless
> as this?  Mind you, I'm not asking if the common ISP uses the MD5, just
> if they know that there's a security vulnerability if they don't.

Most ISPs wont react to something (note: react) until you demonstrate
the vulnerability to them.  Its one thing to tell them there is a
vulnerability.  You have to demonstrate an exploit before they will
care.

And honestly, people are more worried about their routers getting
hacked into rather than attacks on the BGP Protocol.

> And then the second question is how many ISP's do use the MD5 authentication
> and whether it varies by distance from the backbone.  (Please tell me that
> the major backbone carriers use this!)

Major backbones *may* do this internally.  Chatting with people at
various NANOGs seem to indicate that many of the "tier-1's" don't
bother to authenticate their customer sessions.

In the grand scheme of things, ISPs are more concerned about "bad"
data getting leaked into the routing system rather than they are
about session hijacking or DoS.

> --Sandy

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA08939 for <[e-mail]>; Mon, 4 Nov 2002 09:38:43 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 01CAD91236; Mon,  4 Nov 2002 09:38:25 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C173D9123B; Mon,  4 Nov 2002 09:38:24 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B131D91236 for <[e-mail]>; Mon,  4 Nov 2002 09:38:23 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 9C9365DDEA; Mon,  4 Nov 2002 09:38:23 -0500 (EST)
Delivered-To: [e-mail]
Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10]) by segue.merit.edu (Postfix) with ESMTP id 5E3795DD94 for <[e-mail]>; Mon,  4 Nov 2002 09:38:23 -0500 (EST)
Received: by entmail.gnilink.net with Internet Mail Service (5.5.2656.59) id <WAF3BAGJ>; Mon, 4 Nov 2002 09:38:22 -0500
Message-ID: <[e-mail]>
From: "Martin, Christian" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: BGP security in practice
Date: Mon, 4 Nov 2002 09:38:21 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Sandy,

The problem has nothing to do with clue as much as it has to do with shared
secret management across potentially hundreds of external connections.  I
would think that at a minimum, most providers use authentication on their
iBGP sessions.  But eBGP is different, especially when you have to negotiate
the secret with a peer, that which is different across most, if not all, of
your peers.  Some peers do not support MD5, as you suggest, so that opens
that one router up to attack.

I think many providers are ambivalent towards MD5 because they are (perhaps
wrongfully) confident that it is not easy to hijack a BGP session.  With
properly designed ISN pseudorandomization, drawing on highly entropic
external information, the likelihood of successfully launching a BGP attack
diminishes significantly.  

What is more likely is having your MD5 secrets stolen from your NOC through
social engineering methods.  This is probably why MD5 sees so little use in
practice because it requires the entire NOC staff to have access to the
secret database.  This is of concern - it is like giving the entire NOC
staff root access to your BIND or Sendmail systems.

In order for BGP Security to become a reality, we need:

1) a PKI based system
2) IPSEC based encryption of all data
3) Required use of an IRR for all routing

Until then, we are running around with Bandaids trying to stop hundreds of
leaks...

My .02
chris

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Monday, November 04, 2002 8:40 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: BGP security in practice
> 
> 
> Lots of you folk probably read the rpsec list as well, but 
> for those who
> don't, there's a discussion going on of how many ISP's use 
> the MD5 shared
> secret form of authentication.  The response are, uh, disheartenting.
> I've attached one message that says that some ISP's are 
> ignorant of the
> existence of security problems.  That beggars the imagination.
> 
> In the judgement of those on this list, is the general ISP as clueless
> as this?  Mind you, I'm not asking if the common ISP uses the 
> MD5, just
> if they know that there's a security vulnerability if they don't.
> 
> And then the second question is how many ISP's do use the MD5 
> authentication
> and whether it varies by distance from the backbone.  (Please 
> tell me that
> the major backbone carriers use this!)
> 
> --Sandy
> 
> From [e-mail]  Mon Nov  4 05:40:04 2002
> Date: Mon, 4 Nov 2002 11:24:49 +0100
> From: Birger Toedtmann <[e-mail]>
> To: [e-mail]
> Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
> Mime-Version: 1.0
> Content-Disposition: inline
> User-Agent: Mutt/1.3.28i
> X-BeenThere: [e-mail]
> X-Mailman-Version: 2.0.12
> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
> 	<mailto:[e-mail]?subject=unsubscribe>
> List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
> List-Post: <mailto:[e-mail]>
> List-Help: <mailto:[e-mail]?subject=help>
> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
> 	<mailto:[e-mail]?subject=subscribe>
> X-MIME-Autoconverted: from 8bit to quoted-printable by 
> www1.ietf.org id gA4AQ5v16897
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by 
> raven.gw.tislabs.com id gA4Ae3328456
> 
> David G. Boney schrieb am Sun, Nov 03, 2002 at 02:12:00PM -0500:
> > Are there any implementations with MD5? Does anyone even 
> use it in practice?
> > 
> > I recently talked with the former founder of a small ISP. 
> His response 
> > was roughly, "Crypto?" They did not use it. Furthermore, 
> there was no 
> > encryption in the routing protocols with their upstream 
> providers, UUNET 
> > or Sprint.
> > 
> > I think a survey of who is actually using any of the 
> encryption features 
> > of any routing protocols would be informative.
> 
> Until recently I worked for a mid-size ISP in Northwestern Germany.  
> 
> A year ago I tried to put MD5 on both BGP uplinks it had.  The first
> uplink provider, Versatel, did not even know about security 
> issues with
> BGP, neither did they know anything about MD5 on 
> corresponding sessions.  
> Consequently, they denied the request.
> 
> The second one, ECRC (which had been bought by Cable&Wireless 
> in 2000),
> knew about it, but said: "Eh, well, if you wan't it, we will 
> do it with 
> you.  However, you'll be the first one out of 100 customers, and we'll
> have to configure it manually."
> 
> 
> Regards,
> 
> Birger Tödtmann
> 
> _______________________________________________
> RPSEC mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rpsec
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA08836 for <[e-mail]>; Mon, 4 Nov 2002 09:36:51 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8229A91216; Mon,  4 Nov 2002 09:35:57 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4161691243; Mon,  4 Nov 2002 09:35:57 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2276E91216 for <[e-mail]>; Mon,  4 Nov 2002 09:35:50 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0F0FA5DE40; Mon,  4 Nov 2002 09:35:50 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id C4D5C5DDEA for <[e-mail]>; Mon,  4 Nov 2002 09:35:49 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT0Z90>; Mon, 4 Nov 2002 09:35:49 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Bill Fenner'" <[e-mail]>
Cc: [e-mail]
Subject: RE: draft-ietf-idr-bgp4-18.txt
Date: Mon, 4 Nov 2002 09:35:48 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Bill,

	My mistake.  Apparently, some working group
chairs have directly interceded in the past, since
it has been the case at least a few times, that a
draft has passed WG last call and taken more than
18 months to progress to the next step.

	If it is not the policy of the Secretariat 
(or their designate) to check with WG chairs, it
should be.  By definition, once a draft has been
accepted by the WG, it belongs to the WG.  Why
should it be subject to expiry as a result of an 
author or editor being unable to rev' it?

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Bill Fenner [mailto:[e-mail]]
> Sent: Friday, November 01, 2002 6:53 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: RE: draft-ietf-idr-bgp4-18.txt
> 
> 
> >	My understanding has been that the ID administrator
> >would not normally remove expired working group drafts
> >(such as this one) without explicit agreement from a WG
> >chair.
> 
> I've never head of that.  -17 was submitted in January (at least, the
> timestamp on my copy is January 8) and its footers say that it expired
> in July 2002.  It also said, in the boilerplate that we all ignore,
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time
> 
> So, it's been more than 6 months, -17 was expired.  In my 7 years as a
> WG chair I don't think that the secretariat has ever checked with me
> before removing a WG draft that had expired.
> 
>   Bill


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA05728 for <[e-mail]>; Mon, 4 Nov 2002 08:41:23 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8CFE49123A; Mon,  4 Nov 2002 08:41:02 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3450191239; Mon,  4 Nov 2002 08:41:02 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E561A91236 for <[e-mail]>; Mon,  4 Nov 2002 08:41:00 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C8F6A5E15A; Mon,  4 Nov 2002 08:41:00 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (unknown [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 4DBCA5E157 for <[e-mail]>; Mon,  4 Nov 2002 08:41:00 -0500 (EST)
Received: by sentry.gw.tislabs.com; id IAA12822; Mon, 4 Nov 2002 08:40:59 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma012810; Mon, 4 Nov 02 08:40:23 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id gA4DeJm07678; Mon, 4 Nov 2002 08:40:19 -0500 (EST)
Date: Mon, 4 Nov 2002 08:40:19 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: BGP security in practice
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

Lots of you folk probably read the rpsec list as well, but for those who
don't, there's a discussion going on of how many ISP's use the MD5 shared
secret form of authentication.  The response are, uh, disheartenting.
I've attached one message that says that some ISP's are ignorant of the
existence of security problems.  That beggars the imagination.

In the judgement of those on this list, is the general ISP as clueless
as this?  Mind you, I'm not asking if the common ISP uses the MD5, just
if they know that there's a security vulnerability if they don't.

And then the second question is how many ISP's do use the MD5 authentication
and whether it varies by distance from the backbone.  (Please tell me that
the major backbone carriers use this!)

--Sandy

>From [e-mail]  Mon Nov  4 05:40:04 2002
Date: Mon, 4 Nov 2002 11:24:49 +0100
From: Birger Toedtmann <[e-mail]>
To: [e-mail]
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:[e-mail]?subject=subscribe>
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id gA4AQ5v16897
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by raven.gw.tislabs.com id gA4Ae3328456

David G. Boney schrieb am Sun, Nov 03, 2002 at 02:12:00PM -0500:
> Are there any implementations with MD5? Does anyone even use it in practice?
> 
> I recently talked with the former founder of a small ISP. His response 
> was roughly, "Crypto?" They did not use it. Furthermore, there was no 
> encryption in the routing protocols with their upstream providers, UUNET 
> or Sprint.
> 
> I think a survey of who is actually using any of the encryption features 
> of any routing protocols would be informative.

Until recently I worked for a mid-size ISP in Northwestern Germany.  

A year ago I tried to put MD5 on both BGP uplinks it had.  The first
uplink provider, Versatel, did not even know about security issues with
BGP, neither did they know anything about MD5 on corresponding sessions.  
Consequently, they denied the request.

The second one, ECRC (which had been bought by Cable&Wireless in 2000),
knew about it, but said: "Eh, well, if you wan't it, we will do it with 
you.  However, you'll be the first one out of 100 customers, and we'll
have to configure it manually."


Regards,

Birger Tödtmann

_______________________________________________
RPSEC mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rpsec



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA17344 for <[e-mail]>; Mon, 4 Nov 2002 03:03:52 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BB7CA91217; Mon,  4 Nov 2002 03:03:26 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F38A491222; Mon,  4 Nov 2002 03:03:24 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 621B891217 for <[e-mail]>; Mon,  4 Nov 2002 03:02:52 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3F4AC5E051; Mon,  4 Nov 2002 03:02:52 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id E32455E053 for <[e-mail]>; Mon,  4 Nov 2002 03:02:50 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 188cCA-000NbI-00 for [e-mail]; Mon, 04 Nov 2002 00:02:50 -0800
Date: Mon, 4 Nov 2002 00:02:40 -0800
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: Fwd: Last Call: NOPEER community for BGP route scope control to BCP
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

IDR folks,

 Please sanity-check this document.
 Thank you.
 
-- 
Alex

This is a forwarded message
From: The IESG <[e-mail]>
To: 
Cc: [e-mail]
Date: Sunday, November 03, 2002, 8:06:40 AM
Subject: Last Call: NOPEER community for BGP route scope control to BCP

===8<==============Original message text===============

The IESG has received a request from the Prefix Taxonomy Ongoing
Measurement & Inter Network Experiment Working Group to consider NOPEER
community for BGP route scope control
<draft-ietf-ptomaine-nopeer-00.txt> as a BCP.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2002-11-17.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ptomaine-nopeer-00.txt




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




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA07116 for <[e-mail]>; Fri, 1 Nov 2002 20:42:35 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 99E0A912C8; Fri,  1 Nov 2002 20:42:12 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44B01912C7; Fri,  1 Nov 2002 20:42:12 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F627912C8 for <[e-mail]>; Fri,  1 Nov 2002 20:42:10 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1A6B45DDEE; Fri,  1 Nov 2002 20:42:10 -0500 (EST)
Delivered-To: [e-mail]
Received: from sword.6test.edu.cn (unknown [202.38.99.37]) by segue.merit.edu (Postfix) with SMTP id B7D205DDCB for <[e-mail]>; Fri,  1 Nov 2002 20:42:08 -0500 (EST)
Received: (qmail 46870 invoked from network); 2 Nov 2002 01:37:11 -0000
Received: from unknown (HELO sword) (166.111.65.214) by 202.38.99.37 with SMTP; 2 Nov 2002 01:37:11 -0000
Date: Sat, 2 Nov 2002 9:43:53 +0800
From: "Qiu Jian" <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: Re: Why MinRouteAdverInterval is recommended 30
Organization: CERNET
X-mailer: Foxmail 4.1 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id UAA07116

Hello,Jeffrey Haas

======= On 2002-11-01 10:29:00 you wrote: =======

>This is a matter of some debate.
>
That means the value of MinRouteAdver is totally empirical?

>
>Theoretically, this means that if a route is still reachable (feasible),
>then you will delay sending changes to the route.  This will
>cause the entire routing system (in this case, possibly the Internet)
>to have potential for blackholes and forwarding loops due to these
>timers for some period of time.  The following paper goes into 
>some details on this:
>
>http://www.acm.org/sigcomm/sigcomm2000/conf/paper/sigcomm2000-5-2.pdf
>
>-- 
The paper said:
Under a MinRouteAdver timer, a node must process all(n-1) announcements
from its neighbors before it can send a new update.

Does it mean the function of MinRouteAdver is to wait all the other update
about a prefix before sending it? and 30 seconds is considered long enough
to guarantee it.

= = = = = = = = = = = = = = = = = = = =
	Thanks.		

Best Regards,
 
				 
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Qiu Jian
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡[e-mail]
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-11-02





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA01318 for <[e-mail]>; Fri, 1 Nov 2002 18:53:29 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E84BE912C5; Fri,  1 Nov 2002 18:52:51 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBB66912C6; Fri,  1 Nov 2002 18:52:51 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7B3BF912C5 for <[e-mail]>; Fri,  1 Nov 2002 18:52:50 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 5AD0C5DDC1; Fri,  1 Nov 2002 18:52:50 -0500 (EST)
Delivered-To: [e-mail]
Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by segue.merit.edu (Postfix) with ESMTP id 38D2A5DDB3 for <[e-mail]>; Fri,  1 Nov 2002 18:52:50 -0500 (EST)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 115671E385; Fri,  1 Nov 2002 18:52:46 -0500 (EST)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA14191; Fri, 1 Nov 2002 18:52:45 -0500 (EST)
From: Bill Fenner <[e-mail]>
Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id PAA09638; Fri, 1 Nov 2002 15:52:44 -0800 (PST)
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: [e-mail]
Subject: RE: draft-ietf-idr-bgp4-18.txt
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Date: Fri, 1 Nov 2002 15:52:43 -0800
Versions: dmail (solaris) 2.5a/makemail 2.9d
Sender: [e-mail]
Precedence: bulk

>	My understanding has been that the ID administrator 
>would not normally remove expired working group drafts
>(such as this one) without explicit agreement from a WG
>chair.

I've never head of that.  -17 was submitted in January (at least, the
timestamp on my copy is January 8) and its footers say that it expired
in July 2002.  It also said, in the boilerplate that we all ignore,

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time

So, it's been more than 6 months, -17 was expired.  In my 7 years as a
WG chair I don't think that the secretariat has ever checked with me
before removing a WG draft that had expired.

  Bill


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA19224 for <[e-mail]>; Fri, 1 Nov 2002 15:19:47 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 34E999122E; Fri,  1 Nov 2002 15:19:27 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0308E91230; Fri,  1 Nov 2002 15:19:26 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE00E9122E for <[e-mail]>; Fri,  1 Nov 2002 15:19:25 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A53195DDB3; Fri,  1 Nov 2002 15:19:25 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 786FC5DDAE for <[e-mail]>; Fri,  1 Nov 2002 15:19:25 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 187iGJ-0000zd-00; Fri, 01 Nov 2002 12:19:23 -0800
Date: Fri, 1 Nov 2002 12:19:17 -0800
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, "'Parag Deshpande'" <[e-mail]>, <[e-mail]>
Subject: Re: draft-ietf-idr-bgp4-18.txt
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

I'll check with the secretariat.
Thanks for pointing this out.

-- 
Alex

Friday, November 01, 2002, 6:01:22 AM, Gray, Eric wrote:
> Yakov,

>         If you look, it seems as if a mistake has been
> made.  The web site:

>   http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-18.txt

> indicates that this ID has been removed due to expiry.

>         My understanding has been that the ID administrator 
> would not normally remove expired working group drafts
> (such as this one) without explicit agreement from a WG
> chair.  But, if you look, the existence of this draft is
> no longer indicated on either the WG Charter page or the
> ID index page (below).  What gives?

>   http://www1.ietf.org/html.charters/idr-charter.html
>   http://www.ietf.org/html.charters/idr-charter.html
>   http://www1.ietf.org/ids.by.wg/idr.html
>   http://www.ietf.org/ids.by.wg/idr.html



> Eric W. Gray
> Systems Architect
> Celox Networks, Inc.
> [e-mail]
> 508 305 7214




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA02331 for <[e-mail]>; Fri, 1 Nov 2002 10:30:13 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B56DD912C2; Fri,  1 Nov 2002 10:29:50 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86D14912C3; Fri,  1 Nov 2002 10:29:50 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6CE40912C2 for <[e-mail]>; Fri,  1 Nov 2002 10:29:49 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 55D5C5DF71; Fri,  1 Nov 2002 10:29:49 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 9CED05DE4F for <[e-mail]>; Fri,  1 Nov 2002 10:29:48 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gA1FTYL74694; Fri, 1 Nov 2002 10:29:34 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA1FTVC74687; Fri, 1 Nov 2002 10:29:31 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA1FTVg13516; Fri, 1 Nov 2002 10:29:31 -0500 (EST)
Date: Fri, 1 Nov 2002 10:29:30 -0500
From: Jeffrey Haas <[e-mail]>
To: Qiu Jian <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: Why MinRouteAdverInterval is recommended 30
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Nov 01, 2002 at 03:37:42PM +0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Nov 01, 2002 at 03:37:42PM +0800, Qiu Jian wrote:
>     Is it right to say that the Maximal Propagation 
> Delay in Internet is almost less than 30 seconds, 

This is a matter of some debate.

> so MinRouteAdverInterval is set to 30 seconds to 
> guarantte the furthest route change can be caught 
> before sending the relevant update?

Theoretically, this means that if a route is still reachable (feasible),
then you will delay sending changes to the route.  This will
cause the entire routing system (in this case, possibly the Internet)
to have potential for blackholes and forwarding loops due to these
timers for some period of time.  The following paper goes into 
some details on this:

http://www.acm.org/sigcomm/sigcomm2000/conf/paper/sigcomm2000-5-2.pdf

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA27139 for <[e-mail]>; Fri, 1 Nov 2002 09:02:12 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 35FAE91235; Fri,  1 Nov 2002 09:01:40 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD1CC912BD; Fri,  1 Nov 2002 09:01:39 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 06BE091235 for <[e-mail]>; Fri,  1 Nov 2002 09:01:28 -0500 (EST)
Received: by segue.merit.edu (Postfix) id BCEE45DF83; Fri,  1 Nov 2002 09:01:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id A07FA5DF58 for <[e-mail]>; Fri,  1 Nov 2002 09:01:23 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT0M32>; Fri, 1 Nov 2002 09:01:23 -0500
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'Parag Deshpande'" <[e-mail]>, [e-mail]
Subject: RE: draft-ietf-idr-bgp4-18.txt 
Date: Fri, 1 Nov 2002 09:01:22 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Yakov,

	If you look, it seems as if a mistake has been
made.  The web site:

  http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-18.txt

indicates that this ID has been removed due to expiry.

	My understanding has been that the ID administrator 
would not normally remove expired working group drafts
(such as this one) without explicit agreement from a WG
chair.  But, if you look, the existence of this draft is
no longer indicated on either the WG Charter page or the
ID index page (below).  What gives?

  http://www1.ietf.org/html.charters/idr-charter.html
  http://www.ietf.org/html.charters/idr-charter.html
  http://www1.ietf.org/ids.by.wg/idr.html
  http://www.ietf.org/ids.by.wg/idr.html



Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Friday, November 01, 2002 8:53 AM
> To: Natale, Jonathan
> Cc: 'Parag Deshpande'; [e-mail]
> Subject: Re: draft-ietf-idr-bgp4-18.txt
> 
> Jonathan,
> 
> > This is obviously an "uncontrolled copy", but *I think* it is current.
> > Also, refer to the "RE: BGP Base Draft - Issue List v1.5" email sent on
> > Monday, October 28, 2002 7:00 PM for info on the proposed changes.
> > I am assuming that this current version was removed because the
> > new version is to be posted shortly.
> 
> In fact, I submitted the -18 version on Wednesday.
> 
> Yakov.
> >
> >
> > > -----Original Message-----
> > > From: Parag Deshpande [mailto:[e-mail]]
> > > Sent: Thursday, October 31, 2002 5:57 PM
> > > To: [e-mail]
> > > Cc: Susan Hares
> > > Subject: draft-ietf-idr-bgp4-18.txt
> > >
> > >
> > Hi,
> > >
> > > I am unable to locate the latest bgp draft on ietf site.
> > > Where can I get it?
> > > I would appreciate if someone could just mail it to me.
> > >
> > > Thanks,
> > > Parag
> > >
> > >
> >
> >
> > ------_=_NextPart_000_01C281A9.64ABEC00
> > Content-Type: text/plain;
> > 	name="draft-ietf-idr-bgp4-17.txt"
> > Content-Transfer-Encoding: quoted-printable
> > Content-Disposition: attachment;
> > 	filename="draft-ietf-idr-bgp4-17.txt"
> >
> >
> >
> >
> > Network Working Group                                      Y. Rekhter
> > INTERNET DRAFT                                       Juniper Networks
> >                                                                 T. Li
> >                                                Procket Networks, Inc.
> >                                                               Editors
> >
> >
> >
> >                   A Border Gateway Protocol 4 (BGP-4)
> >                       <draft-ietf-idr-bgp4-17.txt>
> >
> >
> > Status of this Memo
> >
> >
> >    This document is an Internet-Draft and is in full conformance with
> >    all provisions of Section 10 of RFC2026.
> >
> >    Internet-Drafts are working documents of the Internet Engineering
> >    Task Force (IETF), its areas, and its working groups.  Note that
> >    other groups may also distribute working documents as Internet-
> >    Drafts.
> >
> >    Internet-Drafts are draft documents valid for a maximum of six =
> > months
> >    and may be updated, replaced, or obsoleted by other documents at any
> >    time. It is inappropriate to use Internet-Drafts as reference
> >    material or to cite them other than as ``work in progress.''
> >
> >    The list of current Internet-Drafts can be accessed at
> >    http://www.ietf.org/ietf/1id-abstracts.txt
> >
> >    The list of Internet-Draft Shadow Directories can be accessed at
> >    http://www.ietf.org/shadow.html.
> >
> >
> >
> > 1. Acknowledgments
> >
> >    This document was originally published as RFC 1267 in October 1991,
> >    jointly authored by Kirk Lougheed and Yakov Rekhter.
> >
> >    We would like to express our thanks to Guy Almes, Len Bosack, and
> >    Jeffrey C. Honig for their contributions to the earlier version of
> >    this document.
> >
> >    We like to explicitly thank Bob Braden for the review of the earlier
> >    version of this document as well as his constructive and valuable
> >    comments.
> >
> >
> >
> > Expiration Date July 2002                                       =
> > =0C[Page 1]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    We would also like to thank Bob Hinden, Director for Routing of the
> >    Internet Engineering Steering Group, and the team of reviewers he
> >    assembled to review the earlier version (BGP-2) of this document.
> >    This team, consisting of Deborah Estrin, Milo Medin, John Moy, Radia
> >    Perlman, Martha Steenstrup, Mike St. Johns, and Paul Tsuchiya, acted
> >    with a strong combination of toughness, professionalism, and
> >    courtesy.
> >
> >    This updated version of the document is the product of the IETF IDR
> >    Working Group with Yakov Rekhter and Tony Li as editors. Certain
> >    sections of the document borrowed heavily from IDRP [7], which is =
> > the
> >    OSI counterpart of BGP. For this credit should be given to the ANSI
> >    X3S3.3 group chaired by Lyman Chapin and to Charles Kunzinger who =
> > was
> >    the IDRP editor within that group. We would also like to thank Enke
> >    Chen, Edward Crabbe, Mike Craren, Vincent Gillet, Eric Gray, Jeffrey
> >    Haas, Dimitry Haskin, John Krawczyk, David LeRoy, Dan Massey, Dan
> >    Pei, Mathew Richardson, John Scudder, John Stewart III, Dave Thaler,
> >    Paul Traina, Russ White, Curtis Villamizar, and Alex Zinin for their
> >    comments.
> >
> >    Many thanks to Sue Hares for her contributions to the document, and
> >    especially for her work on the BGP Finite State Machine.
> >
> >    We would like to specially acknowledge numerous contributions by
> >    Dennis Ferguson.
> >
> >
> > 2. Introduction
> >
> >    The Border Gateway Protocol (BGP) is an inter-Autonomous System
> >    routing protocol. It is built on experience gained with EGP as
> >    defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as
> >    described in RFC 1092 [2] and RFC 1093 [3].
> >
> >    The primary function of a BGP speaking system is to exchange network
> >    reachability information with other BGP systems. This network
> >    reachability information includes information on the list of
> >    Autonomous Systems (ASs) that reachability information traverses.
> >    This information 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.
> >
> >    BGP-4 provides a new set of mechanisms for supporting Classless
> >    Inter-Domain Routing (CIDR) [8, 9]. These mechanisms include support
> >    for advertising an IP prefix and eliminates the concept of network
> >    "class" within BGP.  BGP-4 also introduces mechanisms which allow
> >    aggregation of routes, including aggregation of AS paths.
> >
> >
> >
> >
> > Expiration Date July 2002                                       =
> > =0C[Page 2]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    To characterize the set of policy decisions that can be enforced
> >    using BGP, one must focus on the rule that a BGP speaker advertises
> >    to its peers (other BGP speakers which it communicates with) in
> >    neighboring ASs only those routes that it itself uses. This rule
> >    reflects the "hop-by-hop" routing paradigm generally used throughout
> >    the current Internet. Note that some policies cannot be supported by
> >    the "hop-by-hop" routing paradigm and thus require techniques such =
> > as
> >    source routing (aka explicit routing) to enforce. For example, BGP
> >    does not enable one AS to send traffic to a neighboring AS intending
> >    that the traffic take a different route from that taken by traffic
> >    originating in the neighboring AS. On the other hand, BGP can =
> > support
> >    any policy conforming to the "hop-by-hop" routing paradigm. Since =
> > the
> >    current Internet uses only the "hop-by-hop" inter-AS routing =
> > paradigm
> >    and since BGP can support any policy that conforms to that paradigm,
> >    BGP is highly applicable as an inter-AS routing protocol for the
> >    current Internet.
> >
> >    A more complete discussion of what policies can and cannot be
> >    enforced with BGP is outside the scope of this document (but refer =
> > to
> >    the companion document discussing BGP usage [5]).
> >
> >    BGP runs over a reliable transport protocol. This eliminates the =
> > need
> >    to implement explicit update fragmentation, retransmission,
> >    acknowledgment, and sequencing. Any authentication scheme used by =
> > the
> >    transport protocol (e.g., RFC2385 [10]) may be used in addition to
> >    BGP's own authentication mechanisms. The error notification =
> > mechanism
> >    used in BGP assumes that the transport protocol supports a =
> > "graceful"
> >    close, i.e., that all outstanding data will be delivered before the
> >    connection is closed.
> >
> >    BGP uses TCP [4] as its transport protocol. TCP meets BGP's =
> > transport
> >    requirements and is present in virtually all commercial routers and
> >    hosts. In the following descriptions the phrase "transport protocol
> >    connection" can be understood to refer to a TCP connection. BGP uses
> >    TCP port 179 for establishing its connections.
> >
> >    This document uses the term `Autonomous System' (AS) throughout.  =
> > The
> >    classic definition of an Autonomous System is a set of routers under
> >    a single technical administration, using an interior gateway =
> > protocol
> >    and common metrics to determine how to route packets within the AS,
> >    and using an exterior gateway protocol to determine how to route
> >    packets to other ASs. Since this classic definition was developed, =
> > it
> >    has become common for a single AS to use several interior gateway
> >    protocols and sometimes several sets of metrics within an AS. The =
> > use
> >    of the term Autonomous System here stresses the fact that, even when
> >    multiple IGPs and metrics are used, the administration of an AS
> >    appears to other ASs to have a single coherent interior routing plan
> >    and presents a consistent picture of what destinations are reachable
> >
> >
> >
> > Expiration Date July 2002                                       =
> > =0C[Page 3]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    through it.
> >
> >    The planned use of BGP in the Internet environment, including such
> >    issues as topology, the interaction between BGP and IGPs, and the
> >    enforcement of routing policy rules is presented in a companion
> >    document [5]. This document is the first of a series of documents
> >    planned to explore various aspects of BGP application.
> >
> >
> > 3. Summary of Operation
> >
> >    Two systems form a transport protocol connection between one =
> > another.
> >    They exchange messages to open and confirm the connection =
> > parameters.
> >
> >    The initial data flow is the portion of the BGP routing table that =
> is
> >    allowed by the export policy, called the Adj-Ribs-Out (see 3.2).
> >    Incremental updates are sent as the routing tables change. BGP does
> >    not require periodic refresh of the routing table. Therefore, a BGP
> >    speaker must retain the current version of the routes advertised by
> >    all of its peers for the duration of the connection. If the
> >    implementation decides to not store the routes that have been
> >    received from a peer, but have been filtered out according to
> >    configured local policy, the BGP Route Refresh extension [12] may be
> >    used to request the full set of routes from a peer without resetting
> >    the BGP session when the local policy configuration changes.
> >
> >    KEEPALIVE messages may be sent periodically to ensure the liveness =
> > of
> >    the connection. NOTIFICATION messages are sent in response to errors
> >    or special conditions. If a connection encounters an error =
> > condition,
> >    a NOTIFICATION message is sent and the connection is closed.
> >
> >    The hosts executing the Border Gateway Protocol need not be routers.
> >    A non-routing host could exchange routing information with routers
> >    via EGP or even an interior routing protocol. That non-routing host
> >    could then use BGP to exchange routing information with a border
> >    router in another Autonomous System. The implications and
> >    applications of this architecture are for further study.
> >
> >    Connections between BGP speakers of different ASs are referred to as
> >    "external" links. BGP connections between BGP speakers within the
> >    same AS are referred to as "internal" links. Similarly, a peer in a
> >    different AS is referred to as an external peer, while a peer in the
> >    same AS may be described as an internal peer. Internal BGP and
> >    external BGP are commonly abbreviated IBGP and EBGP.
> >
> >    If a particular AS has multiple BGP speakers and is providing =
> > transit
> >    service for other ASs, then care must be taken to ensure a =
> > consistent
> >    view of routing within the AS. A consistent view of the interior
> >
> >
> >
> > Expiration Date July 2002                                       =
> > =0C[Page 4]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    routes of the AS is provided by the interior routing protocol. A
> >    consistent view of the routes exterior to the AS can be provided by
> >    having all BGP speakers within the AS maintain direct IBGP
> >    connections with each other. Alternately the interior routing
> >    protocol can pass BGP information among routers within an AS, taking
> >    care not to lose BGP attributes that will be needed by EBGP speakers
> >    if transit connectivity is being provided. For the purpose of
> >    discussion, it is assumed that BGP information is passed within an =
> > AS
> >    using IBGP. Care must be taken to ensure that the interior routers
> >    have all been updated with transit information before the EBGP
> >    speakers announce to other ASs that transit service is being
> >    provided.
> >
> >
> > 3.1 Routes: Advertisement and Storage
> >
> >    For the purpose of this protocol, a route is defined as a unit of
> >    information that pairs a set of destinations with the attributes of =
> > a
> >    path to those destinations.  The set of destinations are the systems
> >    whose IP addresses are reported in the Network Layer Reachability
> >    Information (NLRI) field and the path is the information reported in
> >    the path attributes field of the same UPDATE message.
> >
> >    Routes are advertised between BGP speakers in UPDATE messages.
> >
> >    Routes are stored in the Routing Information Bases (RIBs): namely,
> >    the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out. Routes that will
> >    be advertised to other BGP speakers must be present in the Adj-RIB-
> >    Out.  Routes that will be used by the local BGP speaker must be
> >    present in the Loc-RIB, and the next hop for each of these routes
> >    must be resolvable via the local BGP speaker's Routing Table.  =
> > Routes
> >    that are received from other BGP speakers are present in the Adj-
> >    RIBs-In.
> >
> >    If a BGP speaker chooses to advertise the route, it may add to or
> >    modify the path attributes of the route before advertising it to a
> >    peer.
> >
> >    BGP provides mechanisms by which a BGP speaker can inform its peer
> >    that a previously advertised route is no longer available for use.
> >    There are three methods by which a given BGP speaker can indicate
> >    that a route has been withdrawn from service:
> >
> >       a) the IP prefix that expresses the destination for a previously
> >       advertised route can be advertised in the WITHDRAWN ROUTES field
> >       in the UPDATE message, thus marking the associated route as being
> >       no longer available for use
> >
> >
> >
> >
> > Expiration Date July 2002                                       =
> > =0C[Page 5]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >       b) a replacement route with the same NLRI can be advertised, or
> >
> >       c) the BGP speaker - BGP speaker connection can be closed, which
> >       implicitly removes from service all routes which the pair of
> >       speakers had advertised to each other.
> >
> >
> > 3.2 Routing Information Bases
> >
> >    The Routing Information Base (RIB) within a BGP speaker consists of
> >    three distinct parts:
> >
> >       a) Adj-RIBs-In: The Adj-RIBs-In store routing information that =
> > has
> >       been learned from inbound UPDATE messages. Their contents
> >       represent routes that are available as an input to the Decision
> >       Process.
> >
> >       b) Loc-RIB: The Loc-RIB contains the local routing information
> >       that the BGP speaker has selected by applying its local policies
> >       to the routing information contained in its Adj-RIBs-In.
> >
> >       c) Adj-RIBs-Out: The Adj-RIBs-Out store the information that the
> >       local BGP speaker has selected for advertisement to its peers. =
> > The
> >       routing information stored in the Adj-RIBs-Out will be carried in
> >       the local BGP speaker's UPDATE messages and advertised to its
> >       peers.
> >
> >    In summary, the Adj-RIBs-In contain unprocessed routing information
> >    that has been advertised to the local BGP speaker by its peers; the
> >    Loc-RIB contains the routes that have been selected by the local BGP
> >    speaker's Decision Process; and the Adj-RIBs-Out organize the routes
> >    for advertisement to specific peers by means of the local speaker's
> >    UPDATE messages.
> >
> >    Although the conceptual model distinguishes between Adj-RIBs-In, =
> > Loc-
> >    RIB, and Adj-RIBs-Out, this neither implies nor requires that an
> >    implementation must maintain three separate copies of the routing
> >    information. The choice of implementation (for example, 3 copies of
> >    the information vs 1 copy with pointers) is not constrained by the
> >    protocol.
> >
> >    Routing information that the router uses to forward packets (or to
> >    construct the forwarding table that is used for packet forwarding) =
> > is
> >    maintained in the Routing Table. The Routing Table accumulates =
> > routes
> >    to directly connected networks, static routes, routes learned from
> >    the IGP protocols, and routes learned from BGP.  Whether or not a
> >    specific BGP route should be installed in the Routing Table, and
> >    whether a BGP route should override a route to the same destination
> >
> >
> >
> > Expiration Date July 2002                                       =
> > =0C[Page 6]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    installed by another source is a local policy decision, not =
> > specified
> >    in this document. Besides actual packet forwarding, the Routing =
> > Table
> >    is used for resolution of the next-hop addresses specified in BGP
> >    updates (see Section 9.1.2).
> >
> >
> > 4. Message Formats
> >
> >    This section describes message formats used by BGP.
> >
> >    Messages are sent over a reliable transport protocol connection. A
> >    message is processed only after it is entirely received. The maximum
> >    message size is 4096 octets. All implementations are required to
> >    support this maximum message size. The smallest message that may be
> >    sent consists of a BGP header without a data portion, or 19 octets.
> >
> >
> > 4.1 Message Header Format
> >
> >    Each message has a fixed-size header. There may or may not be a data
> >    portion following the header, depending on the message type. The
> >    layout of these fields is shown below:
> >
> >       0                   1                   2                   3
> >       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                                                               |
> >       +                                                               +
> >       |                                                               |
> >       +                                                               +
> >       |                           Marker                              |
> >       +                                                               +
> >       |                                                               |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |          Length               |      Type     |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >
> >       Marker:
> >
> >          This 16-octet field contains a value that the receiver of the
> >          message can predict. If the Type of the message is OPEN, or if
> >          the OPEN message carries no Authentication Information (as an
> >          Optional Parameter), then the Marker must be all ones.
> >          Otherwise, the value of the marker can be predicted by some a
> >          computation specified as part of the authentication mechanism
> >          (which is specified as part of the Authentication Information)
> >          used. The Marker can be used to detect loss of synchronization
> >
> >
> >
> > Expiration Date July 2002                                       =
> > =0C[Page 7]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >          between a pair of BGP peers, and to authenticate incoming BGP
> >          messages.
> >
> >       Length:
> >
> >          This 2-octet unsigned integer indicates the total length of =
> > the
> >          message, including the header, in octets. Thus, e.g., it =
> > allows
> >          one to locate in the transport-level stream the (Marker field
> >          of the) next message. The value of the Length field must =
> > always
> >          be at least 19 and no greater than 4096, and may be further
> >          constrained, depending on the message type. No "padding" of
> >          extra data after the message is allowed, so the Length field
> >          must have the smallest value required given the rest of the
> >          message.
> >
> >       Type:
> >
> >          This 1-octet unsigned integer indicates the type code of the
> >          message. The following type codes are defined:
> >
> >                                     1 - OPEN
> >                                     2 - UPDATE
> >                                     3 - NOTIFICATION
> >                                     4 - KEEPALIVE
> >
> > 4.2 OPEN Message Format
> >
> >    After a transport protocol connection is established, the first
> >    message sent by each side is an OPEN message. If the OPEN message is
> >    acceptable, a KEEPALIVE message confirming the OPEN is sent back.
> >    Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION
> >    messages may be exchanged.
> >
> >    In addition to the fixed-size BGP header, the OPEN message contains
> >    the following fields:
> >
> >        0                   1                   2                   3
> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >        +-+-+-+-+-+-+-+-+
> >        |    Version    |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |     My Autonomous System      |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |           Hold Time           |
> >        =
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |                         BGP Identifier                        =
> > |
> >        =
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        | Opt Parm Len  |
> >
> >
> >
> > Expiration Date July 2002                                       =
> > =0C[Page 8]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >        =
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |                                                               =
> > |
> >        |             Optional Parameters (variable)                    =
> > |
> >        |                                                               =
> > |
> >        =
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >
> >       Version:
> >
> >          This 1-octet unsigned integer indicates the protocol version
> >          number of the message. The current BGP version number is 4.
> >
> >       My Autonomous System:
> >
> >          This 2-octet unsigned integer indicates the Autonomous System
> >          number of the sender.
> >
> >       Hold Time:
> >
> >          This 2-octet unsigned integer indicates the number of seconds
> >          that the sender proposes for the value of the Hold Timer. Upon
> >          receipt of an OPEN message, a BGP speaker MUST calculate the
> >          value of the Hold Timer by using the smaller of its configured
> >          Hold Time and the Hold Time received in the OPEN message. The
> >          Hold Time MUST be either zero or at least three seconds.  An
> >          implementation may reject connections on the basis of the Hold
> >          Time.  The calculated value indicates the maximum number of
> >          seconds that may elapse between the receipt of successive
> >          KEEPALIVE, and/or UPDATE messages by the sender.
> >
> >       BGP Identifier:
> >
> >          This 4-octet unsigned integer indicates the BGP Identifier of
> >          the sender. A given BGP speaker sets the value of its BGP
> >          Identifier to an IP address assigned to that BGP speaker.  The
> >          value of the BGP Identifier is determined on startup and is =
> > the
> >          same for every local interface and every BGP peer.
> >
> >       Optional Parameters Length:
> >
> >          This 1-octet unsigned integer indicates the total length of =
> > the
> >          Optional Parameters field in octets. If the value of this =
> > field
> >          is zero, no Optional Parameters are present.
> >
> >       Optional Parameters:
> >
> >          This field may contain a list of optional parameters, where
> >          each parameter is encoded as a <Parameter Type, Parameter
> >
> >
> >
> > Expiration Date July 2002                                       =
> > =0C[Page 9]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >          Length, Parameter Value> triplet.
> >
> >                0                   1
> >                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> >                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
> >                |  Parm. Type   | Parm. Length  |  Parameter Value =
> > (variable)
> >                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
> >
> >          Parameter Type is a one octet field that unambiguously
> >          identifies individual parameters. Parameter Length is a one
> >          octet field that contains the length of the Parameter Value
> >          field in octets.  Parameter Value is a variable length field
> >          that is interpreted according to the value of the Parameter
> >          Type field.
> >
> >          This document defines the following Optional Parameters:
> >
> >          a) Authentication Information (Parameter Type 1):
> >
> >
> >             This optional parameter may be used to authenticate a BGP
> >             peer. The Parameter Value field contains a 1-octet
> >             Authentication Code followed by a variable length
> >             Authentication Data.
> >
> >                 0 1 2 3 4 5 6 7 8
> >                 +-+-+-+-+-+-+-+-+
> >                 |  Auth. Code   |
> >                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >                 |                                                     |
> >                 |              Authentication Data                    |
> >                 |                                                     |
> >                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >
> >                Authentication Code:
> >
> >                   This 1-octet unsigned integer indicates the
> >                   authentication mechanism being used. Whenever an
> >                   authentication mechanism is specified for use within
> >                   BGP, three things must be included in the
> >                   specification:
> >
> >                   - the value of the Authentication Code which =
> > indicates
> >                   use of the mechanism,
> >                   - the form and meaning of the Authentication Data, =
> > and
> >                   - the algorithm for computing values of Marker =
> > fields.
> >
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 10]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >                   Note that a separate authentication mechanism may be
> >                   used in establishing the transport level connection.
> >
> >                Authentication Data:
> >
> >                   Authentication Data is a variable length field that =
> > is
>                   interpreted according to the value of the
> >                   Authentication Code field.
> >
> >
> >          The minimum length of the OPEN message is 29 octets (including
> >          message header).
> >
> >
> > 4.3 UPDATE Message Format
> >
> >
> >    UPDATE messages are used to transfer routing information between BGP
> >    peers. The information in the UPDATE packet can be used to construct
> >    a graph describing the relationships of the various Autonomous
> >    Systems. By applying rules to be discussed, routing information =
> > loops
> >    and some other anomalies may be detected and removed from inter-AS
> >    routing.
> >
> >    An UPDATE message is used to advertise feasible routes sharing =
> > common
> >    path attribute to a peer, or to withdraw multiple unfeasible routes
> >    from service (see 3.1). An UPDATE message may simultaneously
> >    advertise a feasible route and withdraw multiple unfeasible routes
> >    from service. The UPDATE message always includes the fixed-size BGP
> >    header, and also includes the other fields as shown below (note, =
> some
> >    of the shown fields may not be present in every UPDATE message):
> >
> >
> >       +-----------------------------------------------------+
> >       |   Withdrawn Routes Length (2 octets)                |
> >       +-----------------------------------------------------+
> >       |   Withdrawn Routes (variable)                       |
> >       +-----------------------------------------------------+
> >       |   Total Path Attribute Length (2 octets)            |
> >       +-----------------------------------------------------+
> >       |   Path Attributes (variable)                        |
> >       +-----------------------------------------------------+
> >       |   Network Layer Reachability Information (variable) |
> >       +-----------------------------------------------------+
> >
> >
> >
> >       Withdrawn Routes Length:
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 11]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >          This 2-octets unsigned integer indicates the total length of
>          the Withdrawn Routes field in octets.  Its value must allow =
> > the
> >          length of the Network Layer Reachability Information field to
> >          be determined as specified below.
> >
> >          A value of 0 indicates that no routes are being withdrawn from
> >          service, and that the WITHDRAWN ROUTES field is not present in
> >          this UPDATE message.
> >
> >       Withdrawn Routes:
> >
> >
> >          This is a variable length field that contains a list of IP
> >          address prefixes for the routes that are being withdrawn from
> >          service. Each IP address prefix is encoded as a 2-tuple of the
> >          form <length, prefix>, whose fields are described below:
> >
> >                   +---------------------------+
> >                   |   Length (1 octet)        |
> >                   +---------------------------+
> >                   |   Prefix (variable)       |
> >                   +---------------------------+
> >
> >
> >          The use and the meaning of these fields are as follows:
> >
> >          a) Length:
> >
> >             The Length field indicates the length in bits of the IP
> >             address prefix. A length of zero indicates a prefix that
> >             matches all IP addresses (with prefix, itself, of zero
> >             octets).
> >
> >          b) Prefix:
> >
> >             The Prefix field contains an IP address prefix followed by
> >             enough trailing bits to make the end of the field fall on =
> > an
> >             octet boundary. Note that the value of trailing bits is
> >             irrelevant.
> >
> >       Total Path Attribute Length:
> >
> >          This 2-octet unsigned integer indicates the total length of =
> > the
> >          Path Attributes field in octets. Its value must allow the
> >          length of the Network Layer Reachability field to be =
> > determined
> >          as specified below.
> >
> >          A value of 0 indicates that no Network Layer Reachability
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 12]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >          Information field is present in this UPDATE message.
> >
> >       Path Attributes:
> >
> >          A variable length sequence of path attributes is present in
> >          every UPDATE. Each path attribute is a triple <attribute type,
> >          attribute length, attribute value> of variable length.
> >
> >          Attribute Type is a two-octet field that consists of the
> >          Attribute Flags octet followed by the Attribute Type Code
> >          octet.
> >
> >
> >
> >
> >                0                   1
> >                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> >                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >                |  Attr. Flags  |Attr. Type Code|
> >                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >
> >          The high-order bit (bit 0) of the Attribute Flags octet is the
> >          Optional bit. It defines whether the attribute is optional (if
> >          set to 1) or well-known (if set to 0).
> >
> >          The second high-order bit (bit 1) of the Attribute Flags octet
> >          is the Transitive bit. It defines whether an optional =
> > attribute
> >          is transitive (if set to 1) or non-transitive (if set to 0).
> >          For well-known attributes, the Transitive bit must be set to =
> > 1.
> >          (See Section 5 for a discussion of transitive attributes.)
> >
> >          The third high-order bit (bit 2) of the Attribute Flags octet
> >          is the Partial bit. It defines whether the information
> >          contained in the optional transitive attribute is partial (if
> >          set to 1) or complete (if set to 0). For well-known attributes
> >          and for optional non-transitive attributes the Partial bit =
> > must
> >          be set to 0.
> >
> >          The fourth high-order bit (bit 3) of the Attribute Flags octet
> >          is the Extended Length bit. It defines whether the Attribute
> >          Length is one octet (if set to 0) or two octets (if set to 1).
> >
> >          The lower-order four bits of the Attribute Flags octet are
> >          unused. They must be zero when sent and must be ignored when
> >          received.
> >
> >          The Attribute Type Code octet contains the Attribute Type =
> > Code.
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 13]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >          Currently defined Attribute Type Codes are discussed in =
> > Section
> >          5.
> >
> >          If the Extended Length bit of the Attribute Flags octet is set
> >          to 0, the third octet of the Path Attribute contains the =
> > length
> >          of the attribute data in octets.
> >
> >          If the Extended Length bit of the Attribute Flags octet is set
> >          to 1, then the third and the fourth octets of the path
> >          attribute contain the length of the attribute data in octets.
> >
> >          The remaining octets of the Path Attribute represent the
> >          attribute value and are interpreted according to the Attribute
> >          Flags and the Attribute Type Code. The supported Attribute =
> > Type
> >          Codes, their attribute values and uses are the following:
> >
> >          a)   ORIGIN (Type Code 1):
> >
> >             ORIGIN is a well-known mandatory attribute that defines the
> >             origin of the path information.  The data octet can assume
> >             the following values:
> >
> >                   Value      Meaning
> >
> >                   0         IGP - Network Layer Reachability =
> > Information
> >                                is interior to the originating AS
> >
> >                   1         EGP - Network Layer Reachability =
> > Information
> >                                learned via the EGP protocol
> >
> >                   2         INCOMPLETE - Network Layer Reachability
> >                                Information learned by some other means
> >
> >             Its usage is defined in 5.1.1
> >
> >          b) AS_PATH (Type Code 2):
> >
> >             AS_PATH is a well-known mandatory attribute that is =
> > composed
> >             of a sequence of AS path segments. Each AS path segment is
> >             represented by a triple <path segment type, path segment
> >             length, path segment value>.
> >
> >             The path segment type is a 1-octet long field with the
> >             following values defined:
> >
> >                   Value      Segment Type
> >
> >                   1         AS_SET: unordered set of ASs a route in the
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 14]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >                                UPDATE message has traversed
> >
> >                   2         AS_SEQUENCE: ordered set of ASs a route in
> >                                the UPDATE message has traversed
> >
> >             The path segment length is a 1-octet long field containing
> >             the number of ASs in the path segment value field.
> >
> >             The path segment value field contains one or more AS
> >             numbers, each encoded as a 2-octets long field.
> >
> >             Usage of this attribute is defined in 5.1.2.
> >
> >          c)   NEXT_HOP (Type Code 3):
> >
> >             This is a well-known mandatory attribute that defines the =
> > IP
> >             address of the border router that should be used as the =
> > next
> >             hop to the destinations listed in the Network Layer
> >             Reachability Information field of the UPDATE message.
> >
> >             Usage of this attribute is defined in 5.1.3.
> >
> >
> >          d) MULTI_EXIT_DISC (Type Code 4):
> >
> >             This is an optional non-transitive attribute that is a four
> >             octet non-negative integer. The value of this attribute may
> >             be used by a BGP speaker's decision process to discriminate
> >             among multiple entry points to a neighboring autonomous
> >             system.
> >
> >             Its usage is defined in 5.1.4.
> >
> >          e) LOCAL_PREF (Type Code 5):
> >
> >             LOCAL_PREF is a well-known attribute that is a four octet
> >             non-negative integer. A BGP speaker uses it to inform other
> >             internal peers of the advertising speaker's degree of
> >             preference for an advertised route. Usage of this attribute
> >             is described in 5.1.5.
> >
> >          f) ATOMIC_AGGREGATE (Type Code 6)
> >
> >             ATOMIC_AGGREGATE is a well-known discretionary attribute of
> >             length 0. Usage of this attribute is described in 5.1.6.
> >
> >          g) AGGREGATOR (Type Code 7)
> >
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 15]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >             AGGREGATOR is an optional transitive attribute of length 6.
> >             The attribute contains the last AS number that formed the
> >             aggregate route (encoded as 2 octets), followed by the IP
> >             address of the BGP speaker that formed the aggregate route
> >             (encoded as 4 octets).  This should be the same address as
> >             the one used for the BGP Identifier of the speaker.  Usage
> >             of this attribute is described in 5.1.7.
> >
> >       Network Layer Reachability Information:
> >
> >          This variable length field contains a list of IP address
> >          prefixes. The length in octets of the Network Layer
> >          Reachability Information is not encoded explicitly, but can be
> >          calculated as:
> >
> >             UPDATE message Length - 23 - Total Path Attributes Length -
> >             Withdrawn Routes Length
> >
> >          where UPDATE message Length is the value encoded in the fixed-
> >          size BGP header, Total Path Attribute Length and Withdrawn
> >          Routes Length are the values encoded in the variable part of
> >          the UPDATE message, and 23 is a combined length of the fixed-
> >          size BGP header, the Total Path Attribute Length field and the
> >          Withdrawn Routes Length field.
> >
> >          Reachability information is encoded as one or more 2-tuples of
> >          the form <length, prefix>, whose fields are described below:
> >
> >
> >                   +---------------------------+
> >                   |   Length (1 octet)        |
> >                   +---------------------------+
> >                   |   Prefix (variable)       |
> >                   +---------------------------+
> >
> >
> >          The use and the meaning of these fields are as follows:
> >
> >          a) Length:
> >
> >             The Length field indicates the length in bits of the IP
> >             address prefix. A length of zero indicates a prefix that
> >             matches all IP addresses (with prefix, itself, of zero
> >             octets).
> >
> >          b) Prefix:
> >
> >             The Prefix field contains IP address prefixes followed by
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 16]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >             enough trailing bits to make the end of the field fall on =
> > an
> >             octet boundary. Note that the value of the trailing bits is
> >             irrelevant.
> >
> >    The minimum length of the UPDATE message is 23 octets -- 19 octets
> >    for the fixed header + 2 octets for the Withdrawn Routes Length + 2
> >    octets for the Total Path Attribute Length (the value of Withdrawn
> >    Routes Length is 0 and the value of Total Path Attribute Length is
> >    0).
> >
> >    An UPDATE message can advertise at most one set of path attributes,
> >    but multiple destinations, provided that the destinations share =
> > these
> >    attributes. All path attributes contained in a given UPDATE message
> >    apply to all destinations carried in the NLRI field of the UPDATE
> >    message.
> >
> >    An UPDATE message can list multiple routes to be withdrawn from
> >    service.  Each such route is identified by its destination =
> > (expressed
> >    as an IP prefix), which unambiguously identifies the route in the
> >    context of the BGP speaker - BGP speaker connection to which it has
> >    been previously advertised.
> >
> >    An UPDATE message might advertise only routes to be withdrawn from
> >    service, in which case it will not include path attributes or =
> > Network
> >    Layer Reachability Information. Conversely, it may advertise only a
> >    feasible route, in which case the WITHDRAWN ROUTES field need not be
> >    present.
> >
> >    An UPDATE message should not include the same address prefix in the
> >    WITHDRAWN ROUTES and Network Layer Reachability Information fields,
> >    however a BGP speaker MUST be able to process UPDATE messages in =
> > this
> >    form. A BGP speaker should treat an UPDATE message of this form as =
> > if
> >    the WITHDRAWN ROUTES doesn't contain the address prefix.
> >
> >
> > 4.4 KEEPALIVE Message Format
> >
> >
> >    BGP does not use any transport protocol-based keep-alive mechanism =
> > to
> >    determine if peers are reachable. Instead, KEEPALIVE messages are
> >    exchanged between peers often enough as not to cause the Hold Timer
> >    to expire. A reasonable maximum time between KEEPALIVE messages =
> > would
> >    be one third of the Hold Time interval. KEEPALIVE messages MUST NOT
> >    be sent more frequently than one per second. An implementation MAY
> >    adjust the rate at which it sends KEEPALIVE messages as a function =
> > of
> >    the Hold Time interval.
> >
> >    If the negotiated Hold Time interval is zero, then periodic =
> > KEEPALIVE
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 17]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    messages MUST NOT be sent.
> >
> >    KEEPALIVE message consists of only message header and has a length =
> > of
> >    19 octets.
> >
> >
> > 4.5 NOTIFICATION Message Format
> >
> >
> >    A NOTIFICATION message is sent when an error condition is detected.
> >    The BGP connection is closed immediately after sending it.
> >
> >    In addition to the fixed-size BGP header, the NOTIFICATION message
> >    contains the following fields:
> >
> >
> >        0                   1                   2                   3
> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >        =
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        | Error code    | Error subcode |   Data (variable)             =
> > |
> >        =
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >
> >
> >       Error Code:
> >
> >          This 1-octet unsigned integer indicates the type of
> >          NOTIFICATION. The following Error Codes have been defined:
> >
> >             Error Code       Symbolic Name               Reference
> >
> >               1         Message Header Error             Section 6.1
> >
> >               2         OPEN Message Error               Section 6.2
> >
> >               3         UPDATE Message Error             Section 6.3
> >
> >               4         Hold Timer Expired               Section 6.5
> >
> >               5         Finite State Machine Error       Section 6.6
> >
> >               6         Cease                            Section 6.7
> >
> >
> >       Error subcode:
> >
> >          This 1-octet unsigned integer provides more specific
> >          information about the nature of the reported error.  Each =
> > Error
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 18]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >          Code may have one or more Error Subcodes associated with it. =
> > If
> >          no appropriate Error Subcode is defined, then a zero
> >          (Unspecific) value is used for the Error Subcode field.
> >
> >          Message Header Error subcodes:
> >
> >                                1  - Connection Not Synchronized.
> >                                2  - Bad Message Length.
> >                                3  - Bad Message Type.
> >
> >          OPEN Message Error subcodes:
> >
> >                                1  - Unsupported Version Number.
> >                                2  - Bad Peer AS.
> >                                3  - Bad BGP Identifier.
> >                                4  - Unsupported Optional Parameter.
> >                                5  - Authentication Failure.
> >                                6  - Unacceptable Hold Time.
> >
> >          UPDATE Message Error subcodes:
> >
> >                                1 - Malformed Attribute List.
> >                                2 - Unrecognized Well-known Attribute.
> >                                3 - Missing Well-known Attribute.
> >                                4 - Attribute Flags Error.
> >                                5 - Attribute Length Error.
> >                                6 - Invalid ORIGIN Attribute
> >                                8 - Invalid NEXT_HOP Attribute.
> >                                9 - Optional Attribute Error.
> >                               10 - Invalid Network Field.
> >                               11 - Malformed AS_PATH.
> >
> >
> >       Data:
> >
> >          This variable-length field is used to diagnose the reason for
> >          the NOTIFICATION. The contents of the Data field depend upon
> >          the Error Code and Error Subcode. See Section 6 below for more
> >          details.
> >
> >          Note that the length of the Data field can be determined from
> >          the message Length field by the formula:
> >
> >                   Message Length =3D 21 + Data Length
> >
> >
> >    The minimum length of the NOTIFICATION message is 21 octets
> >    (including message header).
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 19]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> > 5. Path Attributes
> >
> >
> >    This section discusses the path attributes of the UPDATE message.
> >
> >    Path attributes fall into four separate categories:
> >
> >                1. Well-known mandatory.
> >                2. Well-known discretionary.
> >                3. Optional transitive.
> >                4. Optional non-transitive.
> >
> >    Well-known attributes must be recognized by all BGP implementations.
> >    Some of these attributes are mandatory and must be included in every
> >    UPDATE message that contains NLRI. Others are discretionary and may
> >    or may not be sent in a particular UPDATE message.
> >
> >    All well-known attributes must be passed along (after proper
> >    updating, if necessary) to other BGP peers.
> >
> >    In addition to well-known attributes, each path may contain one or
> >    more optional attributes. It is not required or expected that all =
> > BGP
> >    implementations support all optional attributes. The handling of an
> >    unrecognized optional attribute is determined by the setting of the
> >    Transitive bit in the attribute flags octet. Paths with unrecognized
> >    transitive optional attributes should be accepted. If a path with
> >    unrecognized transitive optional attribute is accepted and passed
> >    along to other BGP peers, then the unrecognized transitive optional
> >    attribute of that path must be passed along with the path to other
> >    BGP peers with the Partial bit in the Attribute Flags octet set to =
> > 1.
> >    If a path with recognized transitive optional attribute is accepted
> >    and passed along to other BGP peers and the Partial bit in the
> >    Attribute Flags octet is set to 1 by some previous AS, it is not set
> >    back to 0 by the current AS. Unrecognized non-transitive optional
> >    attributes must be quietly ignored and not passed along to other BGP
> >    peers.
> >
> >    New transitive optional attributes may be attached to the path by =
> > the
> >    originator or by any other BGP speaker in the path. If they are not
> >    attached by the originator, the Partial bit in the Attribute Flags
> >    octet is set to 1. The rules for attaching new non-transitive
> >    optional attributes will depend on the nature of the specific
> >    attribute. The documentation of each new non-transitive optional
> >    attribute will be expected to include such rules. (The description =
> > of
> >    the MULTI_EXIT_DISC attribute gives an example.) All optional
> >    attributes (both transitive and non-transitive) may be updated (if
> >    appropriate) by BGP speakers in the path.
> >
> >
> 
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 20]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    The sender of an UPDATE message should order path attributes within
> >    the UPDATE message in ascending order of attribute type. The =
> > receiver
> >    of an UPDATE message must be prepared to handle path attributes
> >    within the UPDATE message that are out of order.
> >
> >    The same attribute cannot appear more than once within the Path
> >    Attributes field of a particular UPDATE message.
> >
> >    The mandatory category refers to an attribute which must be present
> >    in both IBGP and EBGP exchanges if NLRI are contained in the UPDATE
> >    message.  Attributes classified as optional for the purpose of the
> >    protocol extension mechanism may be purely discretionary, or
> >    discretionary, required, or disallowed in certain contexts.
> >
> >         attribute           EBGP                    IBGP
> >          ORIGIN             mandatory               mandatory
> >          AS_PATH            mandatory               mandatory
> >          NEXT_HOP           mandatory               mandatory
> >          MULTI_EXIT_DISC    discretionary           discretionary
> >          LOCAL_PREF         disallowed              required
> >          ATOMIC_AGGREGATE   see section 5.1.6 and 9.1.4
> >          AGGREGATOR         discretionary           discretionary
> >
> >
> >
> >
> > 5.1 Path Attribute Usage
> >
> >
> >    The usage of each BGP path attributes is described in the following
> >    clauses.
> >
> >
> >
> > 5.1.1 ORIGIN
> >
> >
> >    ORIGIN is a well-known mandatory attribute.  The ORIGIN attribute
> >    shall be generated by the autonomous system that originates the
> >    associated routing information. It shall be included in the UPDATE
> >    messages of all BGP speakers that choose to propagate this
> >    information to other BGP speakers.
> >
> >
> > 5.1.2 AS_PATH
> >
> >
> >    AS_PATH is a well-known mandatory attribute. This attribute
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 21]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    identifies the autonomous systems through which routing information
> >    carried in this UPDATE message has passed. The components of this
> >    list can be AS_SETs or AS_SEQUENCEs.
> >
> >    When a BGP speaker propagates a route which it has learned from
> >    another BGP speaker's UPDATE message, it shall modify the route's
> >    AS_PATH attribute based on the location of the BGP speaker to which
> >    the route will be sent:
> >
> >       a) When a given BGP speaker advertises the route to an internal
> >       peer, the advertising speaker shall not modify the AS_PATH
> >       attribute associated with the route.
> >
> >       b) When a given BGP speaker advertises the route to an external
> >       peer, then the advertising speaker shall update the AS_PATH
> >       attribute as follows:
> >
> >          1) if the first path segment of the AS_PATH is of type
> >          AS_SEQUENCE, the local system shall prepend its own AS number
> >          as the last element of the sequence (put it in the leftmost
> >          position). If the act of prepending will cause an overflow in
> >          the AS_PATH segment, i.e. more than 255 elements, it shall be
> >          legal to prepend a new segment of type AS_SEQUENCE and prepend
> >          its own AS number to this new segment.
> >
> >          2) if the first path segment of the AS_PATH is of type AS_SET,
> >          the local system shall prepend a new path segment of type
> >          AS_SEQUENCE to the AS_PATH, including its own AS number in =
> > that
> >          segment.
> >
> >    When a BGP speaker originates a route then:
> >
> >       a) the originating speaker shall include its own AS number in a
> >       path segment of type AS_SEQUENCE in the AS_PATH attribute of all
> >       UPDATE messages sent to an external peer. (In this case, the AS
> >       number of the originating speaker's autonomous system will be the
> >       only entry the path segment, and this path segment will be the
> >       only segment in the AS_PATH attribute).
> >
> >       b) the originating speaker shall include an empty AS_PATH
> >       attribute in all UPDATE messages sent to internal peers.  (An
> >       empty AS_PATH attribute is one whose length field contains the
> >       value zero).
> >
> >    Whenever the modification of the AS_PATH attribute calls for
> >    including or prepending the AS number of the local system, the local
> >    system may include/prepend more than one instance of its own AS
> >    number in the AS_PATH attribute. This is controlled via local
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 22]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    configuration.
> >
> >
> > 5.1.3 NEXT_HOP
> >
> >
> >
> >    The NEXT_HOP path attribute defines the IP address of the border
> >    router that should be used as the next hop to the destinations =
> > listed
> >    in the UPDATE message. The NEXT_HOP attribute is calculated as
> >    follows.
> >
> >       1) When sending a message to an internal peer, the BGP speaker
> >       should not modify the NEXT_HOP attribute, unless it has been
> >       explicitly configured to announce its own IP address as the
> >       NEXT_HOP.
> >
> >       2) When sending a message to an external peer X, and the peer is
> >       one IP hop away from the speaker:
> >
> >          - If the route being announced was learned from an internal
> >          peer or is locally originated, the BGP speaker can use for the
> >          NEXT_HOP attribute an interface address of the internal peer
> >          router (or the internal router) through which the announced
> >          network is reachable for the speaker, provided that peer X
> >          shares a common subnet with this address. This is a form of
> >          "third party" NEXT_HOP attribute.
> >
> >          - If the route being announced was learned from an external
> >          peer, the speaker can use in the NEXT_HOP attribute an IP
> >          address of any adjacent router (known from the received
> >          NEXT_HOP attribute) that the speaker itself uses for local
> >          route calculation, provided that peer X shares a common subnet
> >          with this address. This is a second form of "third party"
> >          NEXT_HOP attribute.
> >
> >          - If the external peer to which the route is being advertised
> >          shares a common subnet with one of the announcing router's own
> >          interfaces, the router may use the IP address associated with
> >          such an interface in the NEXT_HOP attribute. This is known as =
> > a
> >          "first party" NEXT_HOP attribute.
> >
> >          - By default (if none of the above conditions apply), the BGP
> >          speaker should use in the NEXT_HOP attribute the IP address of
> >          the interface that the speaker uses to establish the BGP
> >          session to peer X.
> >
> >       3) When sending a message to an external peer X, and the peer is
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 23]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >       multiple IP hops away from the speaker (aka "multihop EBGP"):
> >
> >          - The speaker may be configured to propagate the NEXT_HOP
> >          attribute.  In this case when advertising a route that the
> >          speaker learned from one of its peers, the NEXT_HOP attribute
> >          of the advertised route is exactly the same as the NEXT_HOP
> >          attribute of the learned route (the speaker just doesn't =
> > modify
> >          the NEXT_HOP attribute).
> >
> >          - By default, the BGP speaker should use in the NEXT_HOP
> >          attribute the IP address of the interface that the speaker =
> > uses
> >          to establish the BGP session to peer X.
> >
> >    Normally the NEXT_HOP attribute is chosen such that the shortest
> >    available path will be taken. A BGP speaker must be able to support
> >    disabling advertisement of third party NEXT_HOP attributes to handle
> >    imperfectly bridged media.
> >
> >    A BGP speaker must never advertise an address of a peer to that peer
> >    as a NEXT_HOP, for a route that the speaker is originating. A BGP
> >    speaker must never install a route with itself as the next hop.
> >
> >    The NEXT_HOP attribute is used by the BGP speaker to determine the
> >    actual outbound interface and immediate next-hop address that should
> >    be used to forward transit packets to the associated destinations.
> >    The immediate next-hop address is determined by performing a
> >    recursive route lookup operation for the IP address in the NEXT_HOP
> >    attribute using the contents of the Routing Table (see Section
> >    9.1.2.2). The resolving route will always specify the outbound
> >    interface. If the resolving route specifies the next-hop address,
> >    this address should be used as the immediate address for packet
> >    forwarding. If the address in the NEXT_HOP attribute is directly
> >    resolved through a route to an attached subnet (such a route will =
> > not
> >    specify the next-hop address), the outbound interface should be =
> > taken
> >    from the resolving route and the address in the NEXT_HOP attribute
> >    should be used as the immediate next-hop address.
> >
> >
> > 5.1.4 MULTI_EXIT_DISC
> >
> >
> >    The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
> >    links to discriminate among multiple exit or entry points to the =
> > same
> >    neighboring AS. The value of the MULTI_EXIT_DISC attribute is a four
> >    octet unsigned number which is called a metric. All other factors
> >    being equal, the exit point with lower metric should be preferred. =
> > If
> >    received over external links, the MULTI_EXIT_DISC attribute MAY be
> >    propagated over internal links to other BGP speakers within the same
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 24]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    AS. The MULTI_EXIT_DISC attribute received from a neighboring AS =
> MUST
> >    NOT be propagated to other neighboring ASs.
> >
> >    A BGP speaker MUST IMPLEMENT a mechanism based on local =
> > configuration
> >    which allows the MULTI_EXIT_DISC attribute to be removed from a
> >    route. This MAY be done prior to determining the degree of =
> > preference
> >    of the route and performing route selection (decision process phases
> >    1 and 2).
> >
> >    An implementation MAY also (based on local configuration) alter the
> >    value of the MULTI_EXIT_DISC attribute received over an external
> >    link.  If it does so, it shall do so prior to determining the degree
> >    of preference of the route and performing route selection (decision
> >    process phases 1 and 2).
> >
> >
> > 5.1.5 LOCAL_PREF
> >
> >
> >    LOCAL_PREF is a well-known attribute that SHALL be included in all
> >    UPDATE messages that a given BGP speaker sends to the other internal
> >    peers. A BGP speaker SHALL calculate the degree of preference for
> >    each external route based on the locally configured policy, and
> >    include the degree of preference when advertising a route to its
> >    internal peers. The higher degree of preference MUST be preferred.  =
> > A
> >    BGP speaker shall use the degree of preference learned via =
> > LOCAL_PREF
> >    in its decision process (see section 9.1.1).
> >
> >    A BGP speaker MUST NOT include this attribute in UPDATE messages =
> > that
> >    it sends to external peers, except for the case of BGP =
> > Confederations
> >    [13]. If it is contained in an UPDATE message that is received from
> >    an external peer, then this attribute MUST be ignored by the
> >    receiving speaker, except for the case of BGP Confederations [13].
> >
> >
> > 5.1.6 ATOMIC_AGGREGATE
> >
> >
> >    ATOMIC_AGGREGATE is a well-known discretionary attribute.
> >
> >    When a router aggregates several routes for the purpose of
> >    advertisement to a particular peer, and the AS_PATH of the =
> > aggregated
> >    route excludes at least some of the AS numbers present in the =
> > AS_PATH
> >    of the routes that are aggregated, the aggregated route, when
> >    advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.
> >
> >    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
> >    attribute MUST NOT remove the attribute from the route when
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 25]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    propagating it to other speakers.
> >
> >    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
> >    attribute MUST NOT make any NLRI of that route more specific (as
> >    defined in 9.1.4) when advertising this route to other BGP speakers.
> 
> >    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
> >    attribute needs to be cognizant of the fact that the actual path to
> >    destinations, as specified in the NLRI of the route, while having =
> > the
> >    loop-free property, may not be the path specified in the AS_PATH
> >    attribute of the route.
> >
> >
> > 5.1.7 AGGREGATOR
> >
> >
> >    AGGREGATOR is an optional transitive attribute which may be included
> >    in updates which are formed by aggregation (see Section 9.2.2.2). A
> >    BGP speaker which performs route aggregation may add the AGGREGATOR
> >    attribute which shall contain its own AS number and IP address. The
> >    IP address should be the same as the BGP Identifier of the speaker.
> >
> >
> > 6. BGP Error Handling.
> >
> >
> >    This section describes actions to be taken when errors are detected
> >    while processing BGP messages.
> >
> >    When any of the conditions described here are detected, a
> >    NOTIFICATION message with the indicated Error Code, Error Subcode,
> >    and Data fields is sent, and the BGP connection is closed. If no
> >    Error Subcode is specified, then a zero must be used.
> >
> >    The phrase "the BGP connection is closed" means that the transport
> >    protocol connection has been closed, the associated Adj-RIB-In has
> >    been cleared, and that all resources for that BGP connection have
> >    been deallocated. Entries in the Loc-RIB associated with the remote
> >    peer are marked as invalid. The fact that the routes have become
> >    invalid is passed to other BGP peers before the routes are deleted
> >    from the system.
> >
> >    Unless specified explicitly, the Data field of the NOTIFICATION
> >    message that is sent to indicate an error is empty.
> >
> >
> >
> >
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 26]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> > 6.1 Message Header error handling.
> >
> >
> >    All errors detected while processing the Message Header are =
> > indicated
> >    by sending the NOTIFICATION message with Error Code Message Header
> >    Error. The Error Subcode elaborates on the specific nature of the
> >    error.
> >
> >    The expected value of the Marker field of the message header is all
> >    ones if the message type is OPEN. The expected value of the Marker
> >    field for all other types of BGP messages determined based on the
> >    presence of the Authentication Information Optional Parameter in the
> >    BGP OPEN message and the actual authentication mechanism (if the
> >    Authentication Information in the BGP OPEN message is present). The
> >    Marker field should be all ones if the OPEN message carried no
> >    authentication information. If the Marker field of the message =
> > header
> >    is not the expected one, then a synchronization error has occurred
> >    and the Error Subcode is set to Connection Not Synchronized.
> >
> >    If the Length field of the message header is less than 19 or greater
> >    than 4096, or if the Length field of an OPEN message is less than =
> > the
> >    minimum length of the OPEN message, or if the Length field of an
> >    UPDATE message is less than the minimum length of the UPDATE =
> > message,
> >    or if the Length field of a KEEPALIVE message is not equal to 19, or
> >    if the Length field of a NOTIFICATION message is less than the
> >    minimum length of the NOTIFICATION message, then the Error Subcode =
> > is
> >    set to Bad Message Length. The Data field contains the erroneous
> >    Length field.
> >
> >    If the Type field of the message header is not recognized, then the
> >    Error Subcode is set to Bad Message Type. The Data field contains =
> > the
> >    erroneous Type field.
> >
> >
> > 6.2 OPEN message error handling.
> >
> >
> >    All errors detected while processing the OPEN message are indicated
> >    by sending the NOTIFICATION message with Error Code OPEN Message
> >    Error. The Error Subcode elaborates on the specific nature of the
> >    error.
> >
> >    If the version number contained in the Version field of the received
> >    OPEN message is not supported, then the Error Subcode is set to
> >    Unsupported Version Number. The Data field is a 2-octets unsigned
> >    integer, which indicates the largest locally supported version =
> > number
> >    less than the version the remote BGP peer bid (as indicated in the
> >    received OPEN message), or if the smallest locally supported version
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 27]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    number is greater than the version the remote BGP peer bid, then the
> >    smallest locally supported version number.
> >
> >    If the Autonomous System field of the OPEN message is unacceptable,
> >    then the Error Subcode is set to Bad Peer AS. The determination of
> >    acceptable Autonomous System numbers is outside the scope of this
> >    protocol.
> >
> >    If the Hold Time field of the OPEN message is unacceptable, then the
> >    Error Subcode MUST be set to Unacceptable Hold Time. An
> >    implementation MUST reject Hold Time values of one or two seconds.
> >    An implementation MAY reject any proposed Hold Time. An
> >    implementation which accepts a Hold Time MUST use the negotiated
> >    value for the Hold Time.
> >
> >    If the BGP Identifier field of the OPEN message is syntactically
> >    incorrect, then the Error Subcode is set to Bad BGP Identifier.
> >    Syntactic correctness means that the BGP Identifier field represents
> >    a valid IP host address.
> >
> >    If one of the Optional Parameters in the OPEN message is not
> >    recognized, then the Error Subcode is set to Unsupported Optional
> >    Parameters.
> >
> >    If one of the Optional Parameters in the OPEN message is recognized,
> >    but is malformed, then the Error Subcode is set to 0 (Unspecific).
> >
> >
> >    If the OPEN message carries Authentication Information (as an
> >    Optional Parameter), then the corresponding authentication procedure
> >    is invoked. If the authentication procedure (based on Authentication
> >    Code and Authentication Data) fails, then the Error Subcode is set =
> > to
> >    Authentication Failure.
> >
> >
> >
> > 6.3 UPDATE message error handling.
> >
> >
> >    All errors detected while processing the UPDATE message are =
> > indicated
> >    by sending the NOTIFICATION message with Error Code UPDATE Message
> >    Error. The error subcode elaborates on the specific nature of the
> >    error.
> >
> >    Error checking of an UPDATE message begins by examining the path
> >    attributes. If the Withdrawn Routes Length or Total Attribute Length
> >    is too large (i.e., if Withdrawn Routes Length + Total Attribute
> >    Length + 23 exceeds the message Length), then the Error Subcode is
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 28]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    set to Malformed Attribute List.
> >
> >    If any recognized attribute has Attribute Flags that conflict with
> >    the Attribute Type Code, then the Error Subcode is set to Attribute
> >    Flags Error. The Data field contains the erroneous attribute (type,
> >    length and value).
> >
> >    If any recognized attribute has Attribute Length that conflicts with
> >    the expected length (based on the attribute type code), then the
> >    Error Subcode is set to Attribute Length Error. The Data field
> >    contains the erroneous attribute (type, length and value).
> >
> >    If any of the mandatory well-known attributes are not present, then
> >    the Error Subcode is set to Missing Well-known Attribute. The Data
> >    field contains the Attribute Type Code of the missing well-known
> >    attribute.
> >
> >    If any of the mandatory well-known attributes are not recognized,
> >    then the Error Subcode is set to Unrecognized Well-known Attribute.
> >    The Data field contains the unrecognized attribute (type, length and
> >    value).
> >
> >    If the ORIGIN attribute has an undefined value, then the Error
> >    Subcode is set to Invalid Origin Attribute. The Data field contains
> >    the unrecognized attribute (type, length and value).
> >
> >    If the NEXT_HOP attribute field is syntactically incorrect, then the
> >    Error Subcode is set to Invalid NEXT_HOP Attribute.  The Data field
> >    contains the incorrect attribute (type, length and value).  =
> > Syntactic
> >    correctness means that the NEXT_HOP attribute represents a valid IP
> >    host address.  Semantic correctness applies only to the external BGP
> >    links, and only when the sender and the receiving speaker are one IP
> >    hop away from each other. To be semantically correct, the IP address
> >    in the NEXT_HOP must not be the IP address of the receiving speaker,
> >    and the NEXT_HOP IP address must either be the sender's IP address
> >    (used to establish the BGP session), or the interface associated =
> > with
> >    the NEXT_HOP IP address must share a common subnet with the =
> > receiving
> >    BGP speaker. If the NEXT_HOP attribute is semantically incorrect, =
> > the
> >    error should be logged, and the route should be ignored. In this
> >    case, no NOTIFICATION message should be sent.
> >
> >    The AS_PATH attribute is checked for syntactic correctness. If the
> >    path is syntactically incorrect, then the Error Subcode is set to
> >    Malformed AS_PATH.
> >
> >
> >    The information carried by the AS_PATH attribute is checked for AS
> >    loops. AS loop detection is done by scanning the full AS path (as
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 29]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    specified in the AS_PATH attribute), and checking that the =
> > autonomous
> >    system number of the local system does not appear in the AS path. If
> >    the autonomous system number appears in the AS path the route may be
> >    stored in the Adj-RIB-In, but unless the router is configured to
> >    accept routes with its own autonomous system in the AS path, the
> >    route shall not be passed to the BGP Decision Process.  Operations =
> > of
> >    a router that is configured to accept routes with its own autonomous
> >    system number in the AS path are outside the scope of this document.
> >
> >    If an optional attribute is recognized, then the value of this
> >    attribute is checked. If an error is detected, the attribute is
> >    discarded, and the Error Subcode is set to Optional Attribute Error.
> >    The Data field contains the attribute (type, length and value).
> >
> >    If any attribute appears more than once in the UPDATE message, then
> >    the Error Subcode is set to Malformed Attribute List.
> >
> >    The NLRI field in the UPDATE message is checked for syntactic
> >    validity. If the field is syntactically incorrect, then the Error
> >    Subcode is set to Invalid Network Field.
> >
> >    If a prefix in the NLRI field is semantically incorrect (e.g., an
> >    unexpected multicast IP address), an error should be logged locally,
> >    and the prefix should be ignored.
> >
> >    An UPDATE message that contains correct path attributes, but no =
> > NLRI,
> >    shall be treated as a valid UPDATE message.
> >
> >
> > 6.4 NOTIFICATION message error handling.
> >
> >
> >    If a peer sends a NOTIFICATION message, and there is an error in =
> > that
> >    message, there is unfortunately no means of reporting this error via
> >    a subsequent NOTIFICATION message. Any such error, such as an
> >    unrecognized Error Code or Error Subcode, should be noticed, logged
> >    locally, and brought to the attention of the administration of the
> >    peer. The means to do this, however, lies outside the scope of this
> >    document.
> >
> >
> > 6.5 Hold Timer Expired error handling.
> >
> >
> >    If a system does not receive successive KEEPALIVE and/or UPDATE
> >    and/or NOTIFICATION messages within the period specified in the Hold
> >    Time field of the OPEN message, then the NOTIFICATION message with
> >    Hold Timer Expired Error Code must be sent and the BGP connection
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 30]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    closed.
> >
> >
> > 6.6 Finite State Machine error handling.
> >
> >
> >    Any error detected by the BGP Finite State Machine (e.g., receipt of
> >    an unexpected event) is indicated by sending the NOTIFICATION =
> > message
> >    with Error Code Finite State Machine Error.
> >
> >
> > 6.7 Cease.
> >
> >
> >    In absence of any fatal errors (that are indicated in this section),
> >    a BGP peer may choose at any given time to close its BGP connection
> >    by sending the NOTIFICATION message with Error Code Cease. However,
> >    the Cease NOTIFICATION message must not be used when a fatal error
> >    indicated by this section does exist.
> >
> >    A BGP speaker may support the ability to impose an (locally
> >    configured) upper bound on the number of address prefixes the =
> > speaker
> >    is willing to accept from a neighbor. When the upper bound is
> >    reached, the speaker (under control of local configuration) may
> >    either (a) discard new address prefixes from the neighbor, or (b)
> >    terminate the BGP peering with the neighbor. If the BGP speaker
> >    decides to terminate its peering with a neighbor because the number
> >    of address prefixes received from the neighbor exceeds the locally
> >    configured upper bound, then the speaker must send to the neighbor a
> >    NOTIFICATION message with the Error Code Cease.
> >
> >
> > 6.8 Connection collision detection.
> >
> >
> >    If a pair of BGP speakers try simultaneously to establish a BGP
> >    connection to each other, then two parallel connections between this
> >    pair of speakers might well be formed. If the source IP address used
> >    by one of these connections is the same as the destination IP =
> > address
> >    used by the other, and the destination IP address used by the first
> >    connection is the same as the source IP address used by the other, =
> > we
> >    refer to this situation as connection collision.  Clearly in the
> >    presence of connection collision, one of these connections must be
> >    closed.
> >
> >    Based on the value of the BGP Identifier a convention is established
> >    for detecting which BGP connection is to be preserved when a
> >    collision does occur. The convention is to compare the BGP
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 31]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    Identifiers of the peers involved in the collision and to retain =
> > only
> >    the connection initiated by the BGP speaker with the higher-valued
> >    BGP Identifier.
> >
> >    Upon receipt of an OPEN message, the local system must examine all =
> > of
> >    its connections that are in the OpenConfirm state. A BGP speaker may
> >    also examine connections in an OpenSent state if it knows the BGP
> >    Identifier of the peer by means outside of the protocol. If among
> >    these connections there is a connection to a remote BGP speaker =
> > whose
> >    BGP Identifier equals the one in the OPEN message, and this
> >    connection collides with the connection over which the OPEN message
> >    is received then the local system performs the following collision
> >    resolution procedure:
> >
> >
> >       1. The BGP Identifier of the local system is compared to the BGP
> >       Identifier of the remote system (as specified in the OPEN
> >       message).
> >
> >       2. If the value of the local BGP Identifier is less than the
> >       remote one, the local system closes BGP connection that already
> >       exists (the one that is already in the OpenConfirm state), and
> >       accepts BGP connection initiated by the remote system.
> >
> >       3. Otherwise, the local system closes newly created BGP =
> > connection
> >       (the one associated with the newly received OPEN message), and
> >       continues to use the existing one (the one that is already in the
> >       OpenConfirm state).
> >
> >       Comparing BGP Identifiers is done by treating them as (4-octet
> >       long) unsigned integers.
> >
> >       Unless allowed via configuration, a connection collision with an
> >       existing BGP connection that is in Established state causes
> >       closing of the newly created connection.
> >
> >       Note that a connection collision cannot be detected with
> >       connections that are in Idle, or Connect, or Active states.
> >
> >       Closing the BGP connection (that results from the collision
> >       resolution procedure) is accomplished by sending the NOTIFICATION
> >       message with the Error Code Cease.
> >
> >
> > 7. BGP Version Negotiation.
> >
> >
> >    BGP speakers may negotiate the version of the protocol by making
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 32]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    multiple attempts to open a BGP connection, starting with the =
> > highest
> >    version number each supports. If an open attempt fails with an Error
> >    Code OPEN Message Error, and an Error Subcode Unsupported Version
> >    Number, then the BGP speaker has available the version number it
> >    tried, the version number its peer tried, the version number passed
> >    by its peer in the NOTIFICATION message, and the version numbers =
> > that
> >    it supports. If the two peers do support one or more common =
> > versions,
> >    then this will allow them to rapidly determine the highest common
> >    version. In order to support BGP version negotiation, future =
> > versions
> >    of BGP must retain the format of the OPEN and NOTIFICATION messages.
> >
> >
> > 8. BGP Finite State machine.
> >
> >
> >    This section specifies BGP operation in terms of a Finite State
> >    Machine (FSM). Following is a brief summary and overview of BGP
> >    operations by state as determined by this FSM.
> >
> >    Initially BGP is in the Idle state.
> >
> >       Idle state:
> >
> >          A manual start event is a start event initiated by an =
> > operator.
> >          An automatic start event is a start event generated by the
> >          system.
> >
> >          In this state BGP refuses all incoming BGP connections.  No
> >          resources are allocated to the peer.    In response to a Start
> >          event (manual or automatic), the local system:
> >
> >             - initializes all BGP resources,
> >
> >             - starts the ConnectRetry timer,
> >
> >             - initiates a transport connection to the other BGP peer,
> >
> >             - listens for a connection that may be initiated by the
> >             remote BGP peer, and
> >
> >             - changes its state to connect.
> >
> >          The exact value of the ConnectRetry timer is a local matter,
> >          but it should be sufficiently large to allow TCP
> >          initialization.
> >
> >          Any other event received in the IDLE state, is ignored.
> >
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 33]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >       IdleHold state:
> >
> >          The IdleHold state keeps the system in "Idle" mode until a
> >          certain time period has passed or an operator intervenes to
> >          manually restart the connection.  This "IdleHold timeout"
> >          prevents persistent flapping of a BGP peering session.
> >
> >          Upon entering the Idle Hold state, if the IdleHoldTimer =
> > exceeds
> >          the local limit the "Keep Idle" flag is set.
> >
> >          Upon receiving a Manual start, the local system:
> >
> >             - clears the IdleHoldtimer,
> >
> >             - clears "keep Idle" flag
> >
> >             - initializes all BGP resources,
> >
> >             - starts the ConnectRetry timer,
> >
> >             - initiates a transport connection to the other BGP peer,
> >
> >             - listens for a connection that may be initiated by the
> >             remote BGPPeer, and
> >
> >             - changes its state to connect.
> >
> >          Upon receiving a IdleHoldtimer expired event, the local system
> >          checks to see that the Keep Idle flag is set.  If the Keep =
> > Idle
> >          flag is set, the system stays in the "Idle Hold" state.
> >
> >          If the Keep Idle flag is not set, the local system:
> >
> >             - clears the IdleHoldtimer,
> >
> >             - and transitions the state to Idle.
> >
> >          Getting out of the IdleHoldstate requires either operator
> >          intervention via a manual start or the IdleHoldtimer to expire
> >          with the "Keep Idle" flag to be clear.
> >
> >          Any other event received in the IdleHold state is ignored.
> >
> >       Connect State:
> >
> >          In this state, BGP is waiting for the transport protocol
> >          connection to be completed.
> >
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 34]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >          If the transport connection succeeds, the local system:
> >
> >             - clears the ConnectRetry timer,
> >
> >             - completes initialization,
> >
> >             - send an Open message to its peer,
> >
> >             - set Hold timer to a large value,  and
> >
> >             - changes its state to Open Sent.
> >
> >          A hold timer value of 4 minutes is suggested.
> >
> >          If the transport protocol connection fails (e.g.,
> >          retransmission timeout), the local system:
> >
> >             - restarts the ConnectRetry timer,
> >
> >             - continues to listen for a connection that may be =
> > initiated
> >             by the remote BGP peer, and
> >
> >             - changes its state to Active.
> >
> >          In response to the ConnectRetry timer expired event, the local
> >          system:
> >
> >             - restarts the ConnectRetry timer,
> >
> >             - initiates a transport connection to the other BGP peer,
> >
> >             - continues to listen for a connection that may be =
> > initiated
> >             by the remote BGP peer, and
> >
> >             - stays in Connect state.
> >
> >          The start event (manual or automatic) is ignored in the =
> > Connect
> >          state.
> >
> >          In response to any other event (initiated by the system or
> >          operator), the local system:
> >
> >             - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> >
> >             - Increment ConnectRetryCnt by 1,
> >
> >             - Set connect retry timer to zero,
> >
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 35]
> >
> >
> >
> >
> >
> RFC DRAFT                                                   January =
> > 2002
> >
> >
> >             - Drops TCP connection,
> >
> >             - Releases all BGP resources, and
> >
> >             - Goes to IdleHoldstate
> >
> >       Active State:
> >
> >          In this state BGP is trying to acquire a peer by listening for
> >          and accepting a transport protocol connection.
> >
> >          If the transport connection succeeds, the local system:
> >
> >             - clears the ConnectRetry timer,
> >
> >             - completes the initialization,
> >
> >             - sends the Open message to it's peer,
> >
> >             - sets its Hold timer to a large value,
> >
> >             - and changes its state to OpenSent.
> >
> >          A Hold timer value of 4 minutes is suggested.
> >
> >          In response the ConnectRetry timer expired event, the local
> >          system:
> >
> >             - restarts the ConnectRetry timer,
> >
> >             - initiates a transport connection to the other BGP peer,
> >
> >             - continues to listen for connection that may be initiated
> >             by remote BGP peer,
> >
> >             - and changes its state to Connect.
> >
> >          If the local system does not allow BGP connections with
> >          unconfigured peers, then the local system:
> >
> >             - rejects connections from IP addresses that are not
> >             configured peers,
> >
> >             - and remains in the Active state.
> >
> >          The start events (initiated by the system or operator) are
> >          ignored in the Active state.
> >
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 36]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >          In response to any other event (initiated by the system or
> >          operator), the local system:
> >
> >             - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> >
> >             - Increment ConnectRetryCnt by 1,
> >
> >             - Set connect retry timer to zero, and
> >
> >             - Drops TCP connection,
> >
> >             - Releases all BGP resources,
> >
> >             - Goes to IdleHold state.
> >
> >       Open Sent:
> >
> >          In this state BGP waits for an Open Message from its peer.
> >          When an OPEN message is received, all fields are check for
> >          correctness.  If the BGP message header checking or OPEN
> >          message check detects an error (see Section 6.2), or a
> >          connection collision (see Section 6.8) the local system:
> >
> >             - sends a NOTIFICATION message
> >
> >             - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> >
> >             - Increment ConnectRetryCnt by 1,
> >
> >             - Set connect retry timer to zero, and
> >
> >             - Drops TCP connection,
> >
> >             - Releases all BGP resources,
> >
> >             - Goes to IdleHold state.
> >
> >          If there are no errors in the OPEN message, the local system:
> >
> >             - sends a KEEPALIVE message and
> >
> >             - sets a KeepAlive timer (via the text below)
> >
> >             - set the Hold timer according to the negotiated value (see
> >             section 4.2),
> >
> >             - set the state to Open Confirm.
> >
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 37]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >          If the negotiated Hold time value is zero, then the Hold Time
> >          timer and KeepAlive timers are not started.   If the value of
> >          the Autonomous System field is the same as the local =
> > Autonomous
> >          System number, then the connection is an "internal" =
> > connection;
> >          otherwise, it is an "external" connection.   (This will impact
> >          UPDATE processing as described below.)
> >
> >          If a disconnect NOTIFICATION is received from the underlying
> >          transport protocol, the local system:
> >
> >             - closes the BGP connection,
> >
> >             - restarts the Connect Retry timer,
> >
> >             - and continues to listen for a connection that may be
> >             initiated by the remote BGP peer, and goes into Active
> >             state.
> >
> >          If the Hold Timer expires, the local system:
> >
> >             - send a NOTIFICATION message with error code Hold Timer
> >             Expired,
> >
> >             - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> >
> >             - Increment ConnectRetryCnt by 1,
> >
> >             - Set connect retry timer to zero, and
> >
> >             - Drops TCP connection,
> >
> >             - Releases all BGP resources, and
> >
> >             - Goes to IdleHold state.
> >
> >          The Start event (manual and automatic) is ignored in the
> >          OpenSent state.
> >
> >          If a NOTIFICATION message is received with a version error, =
> > the
> >          local system:
> >
> >             - Closes the transport connection
> >
> >             - Releases BGP resources,
> >
> >             - ConnectRetryCnt =3D 0,
> >
> >             - Connect retry timer =3D 0, and
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 38]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >             - transition to Idle state.
> >
> >          If any other NOTIFICATION is received, the local system:
> >
> >             - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> >
> >             - Increment ConnectRetryCnt by 1,
> >
> >             - Set connect retry timer to zero, and
> >
> >             - Drops TCP connection,
> >
> >             - Releases all BGP resources,
> >
> >             - Goes to IdleHold state.
> >
> >          In response to any other event, the local system:
> >
> >             - sends the NOTFICATION message with Error Code Finite =
> > State
> >             Machine  Error,
> >
> >             - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> >
> >             - Increment ConnectRetryCnt by 1,
> >
> >             - Set connect retry timer to zero,
> >
> >             - Drops TCP connection,
> >
> >             - Releases all BGP resources, and
> >
> >             - Goes to IdleHold state.
> >
> >       Open Confirm State
> >
> >          In this state BGP waits for a KEEPALIVE or NOTIFICATION
> >          message.
> >
> >          If the local system receives a KEEPALIVE message, it changes
> >          its state to Established.
> >
> >          If the Hold Timer expires before a KEEPALIVE message is
> >          received, the local system:
> >
> >             - send the NOTIFICATION message with the error code Hold
> >             Timer Expired,
> >
> >             - sets IdleHoldTimer =3D 2**(ConnectRetryCnt)*60
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 39]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >             - Increments ConnectRetryCnt by 1,
> >
> >             - Sets the connect retry timer to zero,
> >
> >             - Drop the TCP connection,
> >
> >             - Releases all BGP resources,
> >
> >             - Goes to IdleHoldState.
> >
> >          If the local system receives a NOTIFICATION message or =
> > receives
> >          a disconnect NOTIFICATION from the underlying transport
> >          protocol, the local system:
> >
> >             - Sets IdleHold Timer =3D 2**(ConnectRetryCnt)*60
> >
> >             - Increments ConnectRetryCnt by 1,
> >
> >             - Sets the connect retry timer to zero,
> >
> >             - Drops the TCP connection,
> >
> >             - Releases all BGP resources,
> >
> >             - Goes to IdleHoldstate.
> >
> >          In response to the Stop event initiated by the system, the
> >          local system:
> >
> >             - sends the NOTIFICATION message with Cease,
> >
> >             - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> >
> >             - Increments ConnectRetryCnt by 1,
> >
> >             - Sets the Connect retry timer to zero,
> >
> >             - Drops the TCP connection,
> >
> >             - Releases all BGP resources,
> >
> >             - Goes to IdleHoldstate.
> >
> >
> >          In response to a Stop event initiated by the operator, the
> >          local system:
> >
> >             - sends the NOTIFICATION message with Cease,
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 40]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >             - releases all BGP resources
> >
> >             - sets the ConnectRetryCnt to zero
> >
> >             - sets the connect retry timer to 0
> >
> >             - transitions to Idle state.
> >
> >          The Start event is ignored in the OpenConfirm state.
> >
> >          In response to any other event, the local system:
> >
> >             - sends a NOTIFICATION with a code of Finite State Machine
> >             Error,
> >
> >             - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> >
> >             - Increments ConnectRetryCnt by 1,
> >
> >             - Sets the Connect retry timer to zero,
> >
> >             - Drops the TCP connection,
> >
> >             - Releases all BGP resources,
> >
> >             - Goes to IdleHoldstate.
> >
> >       Established State:
> >
> >          In the Established state BGP can exchange UPDATE, NOTFICATION,
> >          and KEEPALIVE messages with its peer.
> >
> >          If the local system receives an UPDATE or KEEPALIVE message, =
> > it
> >          restarts its Hold Timer, if the negotiated Hold Time value is
> >          non-zero.
> >
> >          If the local system receives a NOTIFICATION message or a
> >          disconnect from the underlying transport protocol, it:
> >
> >             - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60,
> >
> >             - Increments ConnectRetryCnt by 1,
> >
> >             - Sets the Connect retry timer to zero,
> >
> >             - Drops the TCP connection,
> >
> >             - Releases all BGP resources, and
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 41]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >             - Goes to IdleHoldstate.
> >
> >          If the local system receives an UPDATE message, and the Update
> >          message error handling procedure (see Section 6.3) detecs an
> >          error, the local system:
> >
> >             - sends a NOTIFICATION message with Update error,
> >
> >             - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> >
> >             - Increments ConnectRetryCnt by 1,
> >
> >             - Sets the Connect retry timer to zero,
> >
> >             - Drops the TCP connection,
> >
> >             - Releases all BGP resources, and
> >
> >             - Goes to IdleHoldstate.
> >
> >          If the Hold timer expires, the local system:
> >
> >             - sends a NOTIFICATION message with Error Code Hold Timer
> >             Expired,
> >
> >             - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> >
> >             - Increments ConnectRetryCnt by 1,
> >
> >             - Sets the connect retry timer to zero,
> >
> >             - Drops the TCP connection,
> >
> >             - Releases all BGP resources,
> >
> >             - Goes to IdleHold state.
> >
> >          If the KeepAlive timer expires, the local system sends a
> >          KEEPALIVE message, it restarts its KeepAlive timer, unless the
> >          negotiated Hold Time value is zero.
> >
> >          Each time time the local system sends a KEEPALIVE or UPDATE
> >          message, it restarts its KeepAlive timer, unless the =
> > negotiated
> >          Hold Time value is zero.
> >
> >          In response to the Stop event initiated by the system
> >          (automatic), the local system:
> >
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 42]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >             - sends a NOTIFICATION with Cease,
> >
> >             - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> >
> >             - increments ConnectRetryCnt by 1,
> >
> >             - sets the connect retry timer to zero,
> >
> >             - drops the TCP connection,
> >
> >             - releases all BGP resources,
> >
> >             - goes to IdleHold state, and
> >
> >             - deletes all routes.
> >
> >          An example automatic stop event is exceeding the number of
> >          prefixes for a given peer and the local system automatically
> >          disconnecting the peer.
> >
> >          In response to a stop event initiated by an operator:
> >
> >             - release all resources (including deleting all routes),
> >
> >             - set ConnectRetryCnt to zero (0),
> >
> >             - set connect retry timer to zero (0), and
> >
> >             - transition to the Idle.
> >
> >          The Start event is ignored in the Established state.
> >
> >          In response to any other event, the local system:
> >
> >             - sends a NOTIFICATION message with Error Code Finite State
> >             Machine Error,
> >
> >             - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> >
> >             - increments ConnectRetryCnt by 1,
> >
> >             - sets the connect retry timer to zero,
> >
> >             - drops the TCP connection,
> >
> >             - releases all BGP resources
> >
> >             - goes to IdleHoldstate, and
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 43]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >             - deletes all routes.
> >
> >
> > 9. UPDATE Message Handling
> >
> >
> >    An UPDATE message may be received only in the Established state.
> >    When an UPDATE message is received, each field is checked for
> >    validity as specified in Section 6.3.
> >
> >    If an optional non-transitive attribute is unrecognized, it is
> >    quietly ignored. If an optional transitive attribute is =
> > unrecognized,
> >    the Partial bit (the third high-order bit) in the attribute flags
> >    octet is set to 1, and the attribute is retained for propagation to
> >    other BGP speakers.
> >
> >    If an optional attribute is recognized, and has a valid value, then,
> >    depending on the type of the optional attribute, it is processed
> >    locally, retained, and updated, if necessary, for possible
> >    propagation to other BGP speakers.
> >
> >    If the UPDATE message contains a non-empty WITHDRAWN ROUTES field,
> >    the previously advertised routes whose destinations (expressed as IP
> >    prefixes) contained in this field shall be removed from the Adj-RIB-
> >    In.  This BGP speaker shall run its Decision Process since the
> >    previously advertised route is no longer available for use.
> >
> >    If the UPDATE message contains a feasible route, the Adj-RIB-In will
> >    be updated with this route as follows: if the NLRI of the new route
> >    is identical to the one of the route currently stored in the =
> > Adj-RIB-
> >    In, then the new route shall replace the older route in the Adj-RIB-
> >    In, thus implicitly withdrawing the older route from service.
> >    Otherwise, if the Adj-RIB-In has no route with NLRI identical to the
> >    new route, the new route shall be placed in the Adj-RIB-In.
> >
> >    Once the BGP speaker updates the Adj-RIB-In, the speaker shall run
> >    its Decision Process.
> >
> >
> > 9.1 Decision Process
> >
> >
> >    The Decision Process selects routes for subsequent advertisement by
> >    applying the policies in the local Policy Information Base (PIB) to
> >    the routes stored in its Adj-RIBs-In. The output of the Decision
> >    Process is the set of routes that will be advertised to all peers;
> >    the selected routes will be stored in the local speaker's Adj-RIB-
> >    Out.
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 44]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    The selection process is formalized by defining a function that =
> > takes
> >    the attribute of a given route as an argument and returns either (a)
> >    a non-negative integer denoting the degree of preference for the
> >    route, or (b) a value denoting that this route is ineligible to be
> >    installed in LocRib and will be excluded from the next phase of =
> > route
> >    selection.
> >
> >    The function that calculates the degree of preference for a given
> >    route shall not use as its inputs any of the following: the =
> > existence
> >    of other routes, the non-existence of other routes, or the path
> >    attributes of other routes. Route selection then consists of
> >    individual application of the degree of preference function to each
> >    feasible route, followed by the choice of the one with the highest
> >    degree of preference.
> >
> >    The Decision Process operates on routes contained in the Adj-RIB-In,
> >    and is responsible for:
> >
> >       - selection of routes to be used locally by the speaker
> >
> >       - selection of routes to be advertised to other BGP peers
> >
> >       - route aggregation and route information reduction
> >
> >    The Decision Process takes place in three distinct phases, each
> >    triggered by a different event:
> >
> >       a) Phase 1 is responsible for calculating the degree of =
> > preference
> >       for each route received from a peer.
> >
> >       b) Phase 2 is invoked on completion of phase 1. It is responsible
> >       for choosing the best route out of all those available for each
> >       distinct destination, and for installing each chosen route into
> >       the Loc-RIB.
> >
> >       c) Phase 3 is invoked after the Loc-RIB has been modified. It is
> >       responsible for disseminating routes in the Loc-RIB to each peer,
> >       according to the policies contained in the PIB. Route aggregation
> >       and information reduction can optionally be performed within this
> >       phase.
> >
> >
> > 9.1.1 Phase 1: Calculation of Degree of Preference
> >
> >
> >    The Phase 1 decision function shall be invoked whenever the local =
> > BGP
> >    speaker receives from a peer an UPDATE message that advertises a new
> >    route, a replacement route, or withdrawn routes.
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 45]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    The Phase 1 decision function is a separate process which completes
> >    when it has no further work to do.
> >
> >    The Phase 1 decision function shall lock an Adj-RIB-In prior to
> >    operating on any route contained within it, and shall unlock it =
> > after
> >    operating on all new or unfeasible routes contained within it.
> >
> >    For each newly received or replacement feasible route, the local BGP
> >    speaker shall determine a degree of preference as follows:
> >
> >       If the route is learned from an internal peer, either the value =
> > of
> >       the LOCAL_PREF attribute shall be taken as the degree of
> >       preference, or the local system may compute the degree of
> >       preference of the route based on preconfigured policy =
> > information.
> >       Note that the latter (computing the degree of preference based on
> >       preconfigured policy information) may result in formation of
> >       persistent routing loops.
> >
> >       If the route is learned from an external peer, then the local BGP
> >       speaker computes the degree of preference based on preconfigured
> >       policy information. If the return value indicates that the route
> >       is ineligible, the route may not serve as an input to the next
> >       phase of route selection; otherwise the return value is used as
> >       the LOCAL_PREF value in any IBGP readvertisement.
> >
> >       The exact nature of this policy information and the computation
> >       involved is a local matter.
> >
> >
> > 9.1.2 Phase 2: Route Selection
> >
> >
> >    The Phase 2 decision function shall be invoked on completion of =
> > Phase
> >    1. The Phase 2 function is a separate process which completes when =
> > it
> >    has no further work to do. The Phase 2 process shall consider all
> >    routes that are eligible in the Adj-RIBs-In.
> >
> >    The Phase 2 decision function shall be blocked from running while =
> > the
> >    Phase 3 decision function is in process. The Phase 2 function shall
> >    lock all Adj-RIBs-In prior to commencing its function, and shall
> >    unlock them on completion.
> >
> >    If the NEXT_HOP attribute of a BGP route depicts an address that is
> >    not resolvable, or it would become unresolvable if the route was
> >    installed in the routing table the BGP route should be excluded from
> >    the Phase 2 decision function.
> >
> >    It is critical that routers within an AS do not make conflicting
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 46]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    decisions regarding route selection that would cause forwarding =
> > loops
> >    to occur.
> >
> >    For each set of destinations for which a feasible route exists in =
> > the
> >    Adj-RIBs-In, the local BGP speaker shall identify the route that =
> > has:
> >
> >       a) the highest degree of preference of any route to the same set
> >       of destinations, or
> >
> >       b) is the only route to that destination, or
> >
> >       c) is selected as a result of the Phase 2 tie breaking rules
> >       specified in 9.1.2.2.
> >
> >    The local speaker SHALL then install that route in the Loc-RIB,
> >    replacing any route to the same destination that is currently being
> >    held in the Loc-RIB. If the new BGP route is installed in the =
> > Routing
> >    Table (as a result of the local policy decision), care must be taken
> >    to ensure that invalid BGP routes to the same destination are =
> > removed
> >    from the Routing Table. Whether or not the new route replaces an
> >    already existing non-BGP route in the routing table depends on the
> >    policy configured on the BGP speaker.
> >
> >    The local speaker MUST determine the immediate next hop to the
> >    address depicted by the NEXT_HOP attribute of the selected route by
> >    performing a best matching route lookup in the Routing Table and
> >    selecting one of the possible paths (if multiple best paths to the
> >    same prefix are available). If the route to the address depicted by
> >    the NEXT_HOP attribute changes such that the immediate next hop or
> >    the IGP cost to the NEXT_HOP (if the NEXT_HOP is resolved through an
> >    IGP route) changes, route selection should be recalculated as
> >    specified above.
> >
> >    Notice that even though BGP routes do not have to be installed in =
> > the
> >    Routing Table with the immediate next hop(s), implementations must
> >    take care that before any packets are forwarded along a BGP route,
> >    its associated NEXT_HOP address is resolved to the immediate
> >    (directly connected) next-hop address and this address (or multiple
> >    addresses) is finally used for actual packet forwarding.
> >
> >    Unresolvable routes SHALL be removed from the Loc-RIB and the =
> > routing
> >    table. However, corresponding unresolvable routes SHOULD be kept in
> >    the Adj-RIBs-In.
> >
> >
> >
> >
> >
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 47]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> > 9.1.2.1 Route Resolvability Condition
> >
> >
> >    As indicated in Section 9.1.2, BGP routers should exclude
> >    unresolvable routes from the Phase 2 decision. This ensures that =
> > only
> >    valid routes are installed in Loc-RIB and the Routing Table.
> >
> >    The route resolvability condition is defined as follows.
> >
> >       1. A route Rte1, referencing only the intermediate network
> >       address, is considered resolvable if the Routing Table contains =
> > at
> >       least one resolvable route Rte2 that matches Rte1's intermediate
> >       network address and is not recursively resolved (directly or
> >       indirectly) through Rte1. If multiple matching routes are
> >       available, only the longest matching route should be considered.
> >
> >       2. Routes referencing interfaces (with or without intermediate
> >       addresses) are considered resolvable if the state of the
> >       referenced interface is up and IP processing is enabled on this
> >       interface.
> >
> >    BGP routes do not refer to interfaces, but can be resolved through
> >    the routes in the Routing Table that can be of both types. IGP =
> > routes
> >    and routes to directly connected networks are expected to specify =
> > the
> >    outbound interface.
> >
> >    Note that a BGP route is considered unresolvable not only in
> >    situations where the router's Routing Table contains no route
> >    matching the BGP route's NEXT_HOP. Mutually recursive routes (routes
> >    resolving each other or themselves), also fail the resolvability
> >    check.
> >
> >    It is also important that implementations do not consider feasible
> >    routes that would become unresolvable if they were installed in the
> >    Routing Table even if their NEXT_HOPs are resolvable using the
> >    current contents of the Routing Table (an example of such routes
> >    would be mutually recursive routes). This check ensures that a BGP
> >    speaker does not install in the Routing Table routes that will be
> >    removed and not used by the speaker. Therefore, in addition to local
> >    Routing Table stability, this check also improves behavior of the
> >    protocol in the network.
> >
> >    Whenever a BGP speaker identifies a route that fails the
> >    resolvability check because of mutual recursion, an error message
> >    should be logged.
> >
> >
> >
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 48]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> > 9.1.2.2 Breaking Ties (Phase 2)
> >
> >
> >    In its Adj-RIBs-In a BGP speaker may have several routes to the same
> >    destination that have the same degree of preference. The local
> >    speaker can select only one of these routes for inclusion in the
> >    associated Loc-RIB. The local speaker considers all routes with the
> >    same degrees of preference, both those received from internal peers,
> >    and those received from external peers.
> >
> >    The following tie-breaking procedure assumes that for each candidate
> >    route all the BGP speakers within an autonomous system can ascertain
> >    the cost of a path (interior distance) to the address depicted by =
> > the
> >    NEXT_HOP attribute of the route, and follow the same route selection
> >    algorithm.
> >
> >    The tie-breaking algorithm begins by considering all equally
> >    preferable routes to the same destination, and then selects routes =
> > to
> >    be removed from consideration. The algorithm terminates as soon as
> >    only one route remains in consideration.  The criteria must be
> >    applied in the order specified.
> >
> >    Several of the criteria are described using pseudo-code. Note that
> >    the pseudo-code shown was chosen for clarity, not efficiency. It is
> >    not intended to specify any particular implementation. BGP
> >    implementations MAY use any algorithm which produces the same =
> > results
> >    as those described here.
> >
> >       a) Remove from consideration all routes which are not tied for
> >       having the smallest number of AS numbers present in their AS_PATH
> >       attributes. Note, that when counting this number, an AS_SET =
> > counts
> >       as 1, no matter how many ASs are in the set, and that, if the
> >       implementation supports [13], then AS numbers present in segments
> >       of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in
> >       the count of AS numbers present in the AS_PATH.
> >
> >       b) Remove from consideration all routes which are not tied for
> >       having the lowest Origin number in their Origin attribute.
> >
> >       c) Remove from consideration routes with less-preferred
> >       MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
> >       between routes learned from the same neighboring AS. Routes which
> >       do not have the MULTI_EXIT_DISC attribute are considered to have
> >       the lowest possible MULTI_EXIT_DISC value.
> >
> >       This is also described in the following procedure:
> >
> >             for m =3D all routes still under consideration
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 49]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >                 for n =3D all routes still under consideration
> >                     if (neighborAS(m) =3D=3D neighborAS(n)) and (MED(n)
> =
> > < MED(m))
> >                         remove route m from consideration
> >
> >       In the pseudo-code above, MED(n) is a function which returns the
> >       value of route n's MULTI_EXIT_DISC attribute. If route n has no
> >       MULTI_EXIT_DISC attribute, the function returns the lowest
> >       possible MULTI_EXIT_DISC value, i.e. 0.
> >
> >       Similarly, neighborAS(n) is a function which returns the neighbor
> >       AS from which the route was received.
> >
> >       d) If at least one of the candidate routes was received from an
> >       external peer in a neighboring autonomous system, remove from
> >       consideration all routes which were received from internal peers.
> >
> >       e) Remove from consideration any routes with less-preferred
> >       interior cost.  The interior cost of a route is determined by
> >       calculating the metric to the next hop for the route using the
> >       Routing Table. If the next hop for a route is reachable, but no
> >       cost can be determined, then this step should be skipped
> >       (equivalently, consider all routes to have equal costs).
> >
> >       This is also described in the following procedure.
> >
> >             for m =3D all routes still under consideration
> >                 for n =3D all routes in still under consideration
> >                     if (cost(n) is better than cost(m))
> >                         remove m from consideration
> >
> >       In the pseudo-code above, cost(n) is a function which returns the
> >       cost of the path (interior distance) to the address given in the
> >       NEXT_HOP attribute of the route.
> >
> >       f) Remove from consideration all routes other than the route that
> >       was advertised by the BGP speaker whose BGP Identifier has the
> >       lowest value.
> >
> >       g) Prefer the route received from the lowest neighbor address.
> >
> >
> > 9.1.3 Phase 3: Route Dissemination
> >
> >
> >    The Phase 3 decision function shall be invoked on completion of =
> > Phase
> >    2, or when any of the following events occur:
> >
> >       a) when routes in the Loc-RIB to local destinations have changed
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 50]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >       b) when locally generated routes learned by means outside of BGP
> >       have changed
> >
> >       c) when a new BGP speaker - BGP speaker connection has been
> >       established
> >
> >    The Phase 3 function is a separate process which completes when it
> >    has no further work to do. The Phase 3 Routing Decision function
> >    shall be blocked from running while the Phase 2 decision function is
> >    in process.
> >
> >    All routes in the Loc-RIB shall be processed into Adj-RIBs-Out
> >    according to configured policy. This policy may exclude a route in
> >    the Loc-RIB from being installed in a particular Adj-RIB-Out.  A
> >    route shall not be installed in the Adj-Rib-Out unless the
> >    destination and NEXT_HOP described by this route may be forwarded
> >    appropriately by the Routing Table. If a route in Loc-RIB is =
> > excluded
> >    from a particular Adj-RIB-Out the previously advertised route in =
> > that
> >    Adj-RIB-Out must be withdrawn from service by means of an UPDATE
> >    message (see 9.2).
> >
> >    Route aggregation and information reduction techniques (see 9.2.2.1)
> >    may optionally be applied.
> >
> >    When the updating of the Adj-RIBs-Out and the Routing Table is
> >    complete, the local BGP speaker shall run the Update-Send process of
> >    9.2.
> >
> >
> > 9.1.4 Overlapping Routes
> >
> >
> >    A BGP speaker may transmit routes with overlapping Network Layer
> >    Reachability Information (NLRI) to another BGP speaker. NLRI overlap
> >    occurs when a set of destinations are identified in non-matching
> >    multiple routes. Since BGP encodes NLRI using IP prefixes, overlap
> >    will always exhibit subset relationships.  A route describing a
> >    smaller set of destinations (a longer prefix) is said to be more
> >    specific than a route describing a larger set of destinations (a
> >    shorted prefix); similarly, a route describing a larger set of
> >    destinations (a shorter prefix) is said to be less specific than a
> >    route describing a smaller set of destinations (a longer prefix).
> >
> >    The precedence relationship effectively decomposes less specific
> >    routes into two parts:
> >
> >       - a set of destinations described only by the less specific =
> > route,
> >       and
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 51]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >       - a set of destinations described by the overlap of the less
> >       specific and the more specific routes
> >
> >
> >    When overlapping routes are present in the same Adj-RIB-In, the more
> >    specific route shall take precedence, in order from more specific to
> >    least specific.
> >
> >    The set of destinations described by the overlap represents a =
> > portion
> >    of the less specific route that is feasible, but is not currently in
> >    use.  If a more specific route is later withdrawn, the set of
> >    destinations described by the overlap will still be reachable using
> >    the less specific route.
> >
> >    If a BGP speaker receives overlapping routes, the Decision Process
> >    MUST consider both routes based on the configured acceptance policy.
> >    If both a less and a more specific route are accepted, then the
> >    Decision Process MUST either install both the less and the more
> >    specific routes or it MUST aggregate the two routes and install the
> >    aggregated route, provided that both routes have the same value of
> >    the NEXT_HOP attribute.
> >
> >    If a BGP speaker chooses to aggregate, then it MUST add
> >    ATOMIC_AGGREGATE attribute to the route. A route that carries
> >    ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the
> >    NLRI of this route can not be made more specific. Forwarding along
> >    such a route does not guarantee that IP packets will actually
> >    traverse only ASs listed in the AS_PATH attribute of the route.
> >
> >
> > 9.2 Update-Send Process
> >
> >
> >    The Update-Send process is responsible for advertising UPDATE
> >    messages to all peers. For example, it distributes the routes chosen
> >    by the Decision Process to other BGP speakers which may be located =
> > in
> >    either the same autonomous system or a neighboring autonomous =
> > system.
> >
> >    When a BGP speaker receives an UPDATE message from an internal peer,
> >    the receiving BGP speaker shall not re-distribute the routing
> >    information contained in that UPDATE message to other internal =
> > peers,
> >    unless the speaker acts as a BGP Route Reflector [11].
> >
> >    As part of Phase 3 of the route selection process, the BGP speaker
> >    has updated its Adj-RIBs-Out. All newly installed routes and all
> >    newly unfeasible routes for which there is no replacement route =
> > shall
> >    be advertised to its peers by means of an UPDATE message.
> >
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 52]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    A BGP speaker should not advertise a given feasible BGP route from
> >    its Adj-RIB-Out if it would produce an UPDATE message containing the
> >    same BGP route as was previously advertised.
> >
> >    Any routes in the Loc-RIB marked as unfeasible shall be removed.
> >    Changes to the reachable destinations within its own autonomous
> >    system shall also be advertised in an UPDATE message.
> >
> >
> > 9.2.1 Controlling Routing Traffic Overhead
> >
> >
> >    The BGP protocol constrains the amount of routing traffic (that is,
> >    UPDATE messages) in order to limit both the link bandwidth needed to
> >    advertise UPDATE messages and the processing power needed by the
> >    Decision Process to digest the information contained in the UPDATE
> >    messages.
> >
> >
> > 9.2.1.1 Frequency of Route Advertisement
> >
> >
> >    The parameter MinRouteAdvertisementInterval determines the minimum
> >    amount of time that must elapse between advertisement of routes to a
> >    particular destination from a single BGP speaker. This rate limiting
> >    procedure applies on a per-destination basis, although the value of
> >    MinRouteAdvertisementInterval is set on a per BGP peer basis.
> >
> >    Two UPDATE messages sent from a single BGP speaker that advertise
> >    feasible routes to some common set of destinations received from
> >    external peers must be separated by at least
> >    MinRouteAdvertisementInterval. Clearly, this can only be achieved
> >    precisely by keeping a separate timer for each common set of
> >    destinations. This would be unwarranted overhead. Any technique =
> > which
> >    ensures that the interval between two UPDATE messages sent from a
> >    single BGP speaker that advertise feasible routes to some common set
> >    of destinations received from external peers will be at least
> >    MinRouteAdvertisementInterval, and will also ensure a constant upper
> >    bound on the interval is acceptable.
> >
> >    Since fast convergence is needed within an autonomous system, this
> >    procedure does not apply for routes received from other internal
> >    peers.  To avoid long-lived black holes, the procedure does not =
> > apply
> >    to the explicit withdrawal of unfeasible routes (that is, routes
> >    whose destinations (expressed as IP prefixes) are listed in the
> >    WITHDRAWN ROUTES field of an UPDATE message).
> >
> >    This procedure does not limit the rate of route selection, but only
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 53]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    the rate of route advertisement. If new routes are selected multiple
> >    times while awaiting the expiration of =
> > MinRouteAdvertisementInterval,
> >    the last route selected shall be advertised at the end of
> >    MinRouteAdvertisementInterval.
> >
> >
> > 9.2.1.2 Frequency of Route Origination
> >
> >
> >    The parameter MinASOriginationInterval determines the minimum amount
> >    of time that must elapse between successive advertisements of UPDATE
> >    messages that report changes within the advertising BGP speaker's =
> > own
> >    autonomous systems.
> >
> >
> > 9.2.1.3 Jitter
> >
> >
> >    To minimize the likelihood that the distribution of BGP messages by =
> > a
> >    given BGP speaker will contain peaks, jitter should be applied to =
> > the
> >    timers associated with MinASOriginationInterval, Keepalive, and
> >    MinRouteAdvertisementInterval. A given BGP speaker shall apply the
> >    same jitter to each of these quantities regardless of the
> >    destinations to which the updates are being sent; that is, jitter
> >    will not be applied on a "per peer" basis.
> >
> >    The amount of jitter to be introduced shall be determined by
> >    multiplying the base value of the appropriate timer by a random
> >    factor which is uniformly distributed in the range from 0.75 to 1.0.
> >
> >
> > 9.2.2 Efficient Organization of Routing Information
> >
> >
> >    Having selected the routing information which it will advertise, a
> >    BGP speaker may avail itself of several methods to organize this
> >    information in an efficient manner.
> >
> >
> > 9.2.2.1 Information Reduction
> >
> >
> >    Information reduction may imply a reduction in granularity of policy
> >    control - after information is collapsed, the same policies will
> >    apply to all destinations and paths in the equivalence class.
> >
> >    The Decision Process may optionally reduce the amount of information
> >    that it will place in the Adj-RIBs-Out by any of the following
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 54]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    methods:
> >
> >       a)   Network Layer Reachability Information (NLRI):
> >
> >       Destination IP addresses can be represented as IP address
> >       prefixes. In cases where there is a correspondence between the
> >       address structure and the systems under control of an autonomous
> >       system administrator, it will be possible to reduce the size of
> >       the NLRI carried in the UPDATE messages.
> >
> >       b)   AS_PATHs:
> >
> >       AS path information can be represented as ordered AS_SEQUENCEs or
> >       unordered AS_SETs. AS_SETs are used in the route aggregation
> >       algorithm described in 9.2.2.2. They reduce the size of the
> >       AS_PATH information by listing each AS number only once,
> >       regardless of how many times it may have appeared in multiple
> >       AS_PATHs that were aggregated.
> >
> >       An AS_SET implies that the destinations listed in the NLRI can be
> >       reached through paths that traverse at least some of the
> >       constituent autonomous systems. AS_SETs provide sufficient
> >       information to avoid routing information looping; however their
> >       use may prune potentially feasible paths, since such paths are no
> >       longer listed individually as in the form of AS_SEQUENCEs. In
> >       practice this is not likely to be a problem, since once an IP
> >       packet arrives at the edge of a group of autonomous systems, the
> >       BGP speaker at that point is likely to have more detailed path
> >       information and can distinguish individual paths to destinations.
> >
> >
> > 9.2.2.2 Aggregating Routing Information
> >
> >
> >    Aggregation is the process of combining the characteristics of
> >    several different routes in such a way that a single route can be
> >    advertised.  Aggregation can occur as part of the decision process =
> > to
> >    reduce the amount of routing information that will be placed in the
> >    Adj-RIBs-Out.
> >
> >    Aggregation reduces the amount of information that a BGP speaker =
> > must
> >    store and exchange with other BGP speakers. Routes can be aggregated
> >    by applying the following procedure separately to path attributes of
> >    like type and to the Network Layer Reachability Information.
> >
> >    Routes that have the following attributes shall not be aggregated
> >    unless the corresponding attributes of each route are identical:
> >    MULTI_EXIT_DISC, NEXT_HOP.
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 55]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    If the aggregation occurs as part of the update process, routes with
> >    different NEXT_HOP values can be aggregated when announced through =
> > an
> >    external BGP session.
> >
> >    Path attributes that have different type codes can not be aggregated
> >    together. Path attributes of the same type code may be aggregated,
> >    according to the following rules:
> >
> >       ORIGIN attribute: If at least one route among routes that are
> >       aggregated has ORIGIN with the value INCOMPLETE, then the
> >       aggregated route must have the ORIGIN attribute with the value
> >       INCOMPLETE.  Otherwise, if at least one route among routes that
> >       are aggregated has ORIGIN with the value EGP, then the aggregated
> >       route must have the origin attribute with the value EGP. In all
> >       other case the value of the ORIGIN attribute of the aggregated
> >       route is IGP.
> >
> >       AS_PATH attribute: If routes to be aggregated have identical
> >       AS_PATH attributes, then the aggregated route has the same =
> > AS_PATH
> >       attribute as each individual route.
> >
> >       For the purpose of aggregating AS_PATH attributes we model each =
> > AS
> >       within the AS_PATH attribute as a tuple <type, value>, where
> >       "type" identifies a type of the path segment the AS belongs to
> >       (e.g. AS_SEQUENCE, AS_SET), and "value" is the AS number. If the
> >       routes to be aggregated have different AS_PATH attributes, then
> >       the aggregated AS_PATH attribute shall satisfy all of the
> >       following conditions:
> >
> >          - all tuples of type AS_SEQUENCE in the aggregated AS_PATH
> >          shall appear in all of the AS_PATH in the initial set of =
> > routes
> >          to be aggregated.
> >
> >          - all tuples of type AS_SET in the aggregated AS_PATH shall
> >          appear in at least one of the AS_PATH in the initial set (they
> >          may appear as either AS_SET or AS_SEQUENCE types).
> >
> >          - for any tuple X of type AS_SEQUENCE in the aggregated =
> > AS_PATH
> >          which precedes tuple Y in the aggregated AS_PATH, X precedes Y
> >          in each AS_PATH in the initial set which contains Y, =
> > regardless
> >          of the type of Y.
> >
> >          - No tuple of type AS_SET with the same value shall appear =
> > more
> >          than once in the aggregated AS_PATH.
> >
> >          - Multiple tuples of type AS_SEQUENCE with the same value may
> >          appear in the aggregated AS_PATH only when adjacent to another
> >          tuple of the same type and value.
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 56]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >       An implementation may choose any algorithm which conforms to =
> > these
> >       rules. At a minimum a conformant implementation shall be able to
> >       perform the following algorithm that meets all of the above
> >       conditions:
> >
> >          - determine the longest leading sequence of tuples (as defined
> >          above) common to all the AS_PATH attributes of the routes to =
> > be
> >          aggregated. Make this sequence the leading sequence of the
> >          aggregated AS_PATH attribute.
> >
> >          - set the type of the rest of the tuples from the AS_PATH
> >          attributes of the routes to be aggregated to AS_SET, and =
> > append
> >          them to the aggregated AS_PATH attribute.
> >
> >          - if the aggregated AS_PATH has more than one tuple with the
> >          same value (regardless of tuple's type), eliminate all, but =
> > one
> >          such tuple by deleting tuples of the type AS_SET from the
> >          aggregated AS_PATH attribute.
> >
> >       Appendix 6, section 6.8 presents another algorithm that satisfies
> >       the conditions and allows for more complex policy configurations.
> >
> >       ATOMIC_AGGREGATE: If at least one of the routes to be aggregated
> >       has ATOMIC_AGGREGATE path attribute, then the aggregated route
> >       shall have this attribute as well.
> >
> >       AGGREGATOR: All AGGREGATOR attributes of all routes to be
> >       aggregated should be ignored. The BGP speaker performing the =
> > route
> >       aggregation may attach a new AGGREGATOR attribute (see Section
> >       5.1.7).
> >
> >
> > 9.3 Route Selection Criteria
> >
> >
> >    Generally speaking, additional rules for comparing routes among
> >    several alternatives are outside the scope of this document. There
> >    are two exceptions:
> >
> >       - If the local AS appears in the AS path of the new route being
> >       considered, then that new route cannot be viewed as better than
> >       any other route (provided that the speaker is configured to =
> > accept
> >       such routes). If such a route were ever used, a routing loop =
> > could
> >       result (see Section 6.3).
> >
> >       - In order to achieve successful distributed operation, only
> >       routes with a likelihood of stability can be chosen. Thus, an AS
> >       must avoid using unstable routes, and it must not make rapid
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 57]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >       spontaneous changes to its choice of route. Quantifying the terms
> >       "unstable" and "rapid" in the previous sentence will require
> >       experience, but the principle is clear.
> >
> >       Care must be taken to ensure that BGP speakers in the same AS do
> >       not make inconsistent decisions.
> >
> >
> > 9.4 Originating BGP routes
> >
> >    A BGP speaker may originate BGP routes by injecting routing
> >    information acquired by some other means (e.g. via an IGP) into BGP.
> >    A BGP speaker that originates BGP routes shall assign the degree of
> >    preference to these routes by passing them through the Decision
> >    Process (see Section 9.1). These routes may also be distributed to
> >    other BGP speakers within the local AS as part of the update process
> >    (see Section 9.2). The decision whether to distribute non-BGP
> >    acquired routes within an AS via BGP or not depends on the
> >    environment within the AS (e.g. type of IGP) and should be =
> > controlled
> >    via configuration.
> >
> >
> >
> >
> >
> > Appendix 1. Comparison with RFC1771
> >
> >
> >    There are numerous editorial changes (too many to list here).
> >
> >    The following list the technical changes:
> >
> >       Changes to reflect the usages of such features as TCP MD5 [10],
> >       BGP Route Reflectors [11], BGP Confederations [13], and BGP Route
> >       Refresh [12].
> >
> >       Clarification on the use of the BGP Identifier in the AGGREGATOR
> >       attribute.
> >
> >       Procedures for imposing an upper bound on the number of prefixes
> >       that a BGP speaker would accept from a peer.
> >
> >       The ability of a BGP speaker to include more than one instance of
> >       its own AS in the AS_PATH attribute for the purpose of inter-AS
> >       traffic engineering.
> >
> >       Clarifications on the various types of NEXT_HOPs.
> >
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 58]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >       Clarifications to the use of the ATOMIC_AGGREGATE attribute.
> >
> >       The relationship between the immediate next hop, and the next hop
> >       as specified in the NEXT_HOP path attribute.
> >
> >       Clarifications on the tie-breaking procedures.
> >
> >
> > Appendix 2. Comparison with RFC1267
> >
> >
> >    All the changes listed in Appendix 1, plus the following.
> >
> >    BGP-4 is capable of operating in an environment where a set of
> >    reachable destinations may be expressed via a single IP prefix.  The
> >    concept of network classes, or subnetting is foreign to BGP-4.  To
> >    accommodate these capabilities BGP-4 changes semantics and encoding
> >    associated with the AS_PATH attribute. New text has been added to
> >    define semantics associated with IP prefixes. These abilities allow
> >    BGP-4 to support the proposed supernetting scheme [9].
> >
> >    To simplify configuration this version introduces a new attribute,
> >    LOCAL_PREF, that facilitates route selection procedures.
> >
> >    The INTER_AS_METRIC attribute has been renamed to be =
> > MULTI_EXIT_DISC.
> >    A new attribute, ATOMIC_AGGREGATE, has been introduced to insure =
> > that
> >    certain aggregates are not de-aggregated. Another new attribute,
> >    AGGREGATOR, can be added to aggregate routes in order to advertise
> >    which AS and which BGP speaker within that AS caused the =
> > aggregation.
> >
> >    To insure that Hold Timers are symmetric, the Hold Time is now
> >    negotiated on a per-connection basis. Hold Times of zero are now
> >    supported.
> >
> > Appendix 3. Comparison with RFC 1163
> >
> >
> >    All of the changes listed in Appendices 1 and 2, plus the following.
> >
> >    To detect and recover from BGP connection collision, a new field =
> > (BGP
> >    Identifier) has been added to the OPEN message. New text (Section
> >    6.8) has been added to specify the procedure for detecting and
> >    recovering from collision.
> >
> >    The new document no longer restricts the border router that is =
> > passed
> >    in the NEXT_HOP path attribute to be part of the same Autonomous
> >    System as the BGP Speaker.
> >
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 59]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    New document optimizes and simplifies the exchange of the =
> > information
>    about previously reachable routes.
> >
> >
> > Appendix 4. Comparison with RFC 1105
> >
> >
> >    All of the changes listed in Appendices 1, 2 and 3, plus the
> >    following.
> >
> >    Minor changes to the RFC1105 Finite State Machine were necessary to
> >    accommodate the TCP user interface provided by 4.3 BSD.
> >
> >    The notion of Up/Down/Horizontal relations present in RFC1105 has
> >    been removed from the protocol.
> >
> >    The changes in the message format from RFC1105 are as follows:
> >
> >       1.  The Hold Time field has been removed from the BGP header and
> >       added to the OPEN message.
> >
> >       2.  The version field has been removed from the BGP header and
> >       added to the OPEN message.
> >
> >       3.  The Link Type field has been removed from the OPEN message.
> >
> >       4.  The OPEN CONFIRM message has been eliminated and replaced =
> > with
> >       implicit confirmation provided by the KEEPALIVE message.
> >
> >       5.  The format of the UPDATE message has been changed
> >       significantly.  New fields were added to the UPDATE message to
> >       support multiple path attributes.
> >
> >       6.  The Marker field has been expanded and its role broadened to
> >       support authentication.
> >
> >       Note that quite often BGP, as specified in RFC 1105, is referred
> >       to as BGP-1, BGP, as specified in RFC 1163, is referred to as
> >       BGP-2, BGP, as specified in RFC1267 is referred to as BGP-3, and
> >       BGP, as specified in this document is referred to as BGP-4.
> >
> >
> > Appendix 5.  TCP options that may be used with BGP
> >
> >
> >    If a local system TCP user interface supports TCP PUSH function, =
> > then
> >    each BGP message should be transmitted with PUSH flag set.  Setting
> >    PUSH flag forces BGP messages to be transmitted promptly to the
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 60]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    receiver.
> >
> >    If a local system TCP user interface supports setting precedence for
> >    TCP connection, then the BGP transport connection should be opened
> >    with precedence set to Internetwork Control (110) value (see also
> >    [6]).
> >
> >    A local system may protect its BGP sessions by using the TCP MD5
> >    Signature Option [10].
> >
> >
> > Appendix 6.  Implementation Recommendations
> >
> >
> >    This section presents some implementation recommendations.
> >
> >
> > 6.1 Multiple Networks Per Message
> >
> >
> >    The BGP protocol allows for multiple address prefixes with the same
> >    path attributes to be specified in one message. Making use of this
> >    capability is highly recommended. With one address prefix per =
> > message
> >    there is a substantial increase in overhead in the receiver. Not =
> > only
> >    does the system overhead increase due to the reception of multiple
> >    messages, but the overhead of scanning the routing table for updates
> >    to BGP peers and other routing protocols (and sending the associated
> >    messages) is incurred multiple times as well.
> >
> >    One method of building messages containing many address prefixes per
> >    a path attribute set from a routing table that is not organized on a
> >    per path attribute set basis is to build many messages as the =
> > routing
> >    table is scanned. As each address prefix is processed, a message for
> >    the associated set of path attributes is allocated, if it does not
> >    exist, and the new address prefix is added to it.  If such a message
> >    exists, the new address prefix is just appended to it. If the =
> > message
> >    lacks the space to hold the new address prefix, it is transmitted, a
> >    new message is allocated, and the new address prefix is inserted =
> > into
> >    the new message. When the entire routing table has been scanned, all
> >    allocated messages are sent and their resources released.  Maximum
> >    compression is achieved when all  the destinations covered by the
> >    address prefixes share a common set of path attributes making it
> >    possible to send many address prefixes in one 4096-byte message.
> >
> >    When peering with a BGP implementation that does not compress
> >    multiple address prefixes into one message, it may be necessary to
> >    take steps to reduce the overhead from the flood of data received
> >    when a peer is acquired or a significant network topology change
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 61]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    occurs. One method of doing this is to limit the rate of updates.
> >    This will eliminate the redundant scanning of the routing table to
> >    provide flash updates for BGP peers and other routing protocols. A
> >    disadvantage of this approach is that it increases the propagation
> >    latency of routing information.  By choosing a minimum flash update
> >    interval that is not much greater than the time it takes to process
> >    the multiple messages this latency should be minimized. A better
> >    method would be to read all received messages before sending =
> > updates.
> >
> >
> > 6.2  Processing Messages on a Stream Protocol
> >
> >
> >    BGP uses TCP as a transport mechanism.  Due to the stream nature of
> >    TCP, all the data for received messages does not necessarily arrive
> >    at the same time. This can make it difficult to process the data as
> >    messages, especially on systems such as BSD Unix where it is not
> >    possible to determine how much data has been received but not yet
> >    processed.
> >
> >    One method that can be used in this situation is to first try to =
> > read
> >    just the message header. For the KEEPALIVE message type, this is a
> >    complete message; for other message types, the header should first =
> > be
> >    verified, in particular the total length. If all checks are
> >    successful, the specified length, minus the size of the message
> >    header is the amount of data left to read. An implementation that
> >    would "hang" the routing information process while trying to read
> >    from a peer could set up a message buffer (4096 bytes) per peer and
> >    fill it with data as available until a complete message has been
> >    received.
> >
> >
> > 6.3 Reducing route flapping
> >
> >
> >    To avoid excessive route flapping a BGP speaker which needs to
> >    withdraw a destination and send an update about a more specific or
> >    less specific route SHOULD combine them into the same UPDATE =
> > message.
> >
> >
> > 6.4 BGP Timers
> >
> >
> >    BGP employs five timers: ConnectRetry, Hold Time, KeepAlive,
> >    MinASOriginationInterval, and MinRouteAdvertisementInterval The
> >    suggested value for the ConnectRetry timer is 120 seconds.  The
> >    suggested value for the Hold Time is 90 seconds.  The suggested =
> > value
> >    for the KeepAlive timer is 1/3 of the Hold Time.  The suggested =
> > value
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 62]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >    for the MinASOriginationInterval is 15 seconds.  The suggested value
> >    for the MinRouteAdvertisementInterval is 30 seconds.
> >
> >    An implementation of BGP MUST allow the Hold Time timer to be
> >    configurable, and MAY allow the other timers to be configurable.
> >
> >
> >
> > 6.5 Path attribute ordering
> >
> >
> >    Implementations which combine update messages as described above in
> >    6.1 may prefer to see all path attributes presented in a known =
> > order.
> >    This permits them to quickly identify sets of attributes from
> >    different update messages which are semantically identical.  To
> >    facilitate this, it is a useful optimization to order the path
> >    attributes according to type code.  This optimization is entirely
> >    optional.
> >
> >
> > 6.6 AS_SET sorting
> >
> >
> >    Another useful optimization that can be done to simplify this
> >    situation is to sort the AS numbers found in an AS_SET.  This
> >    optimization is entirely optional.
> >
> >
> > 6.7 Control over version negotiation
> >
> >
> >    Since BGP-4 is capable of carrying aggregated routes which cannot be
> >    properly represented in BGP-3, an implementation which supports =
> > BGP-4
> >    and another BGP version should provide the capability to only speak
> >    BGP-4 on a per-peer basis.
> >
> >
> > 6.8 Complex AS_PATH aggregation
> >
> >
> >    An implementation which chooses to provide a path aggregation
> >    algorithm which retains significant amounts of path information may
> >    wish to use the following procedure:
> >
> >       For the purpose of aggregating AS_PATH attributes of two routes,
> >       we model each AS as a tuple <type, value>, where "type" =
> > identifies
> >       a type of the path segment the AS belongs to (e.g.  AS_SEQUENCE,
> >       AS_SET), and "value" is the AS number.  Two ASs are said to be =
> > the
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 63]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> >       same if their corresponding <type, value> tuples are the same.
> >
> >       The algorithm to aggregate two AS_PATH attributes works as
> >       follows:
> >
> >          a) Identify the same ASs (as defined above) within each =
> > AS_PATH
> >          attribute that are in the same relative order within both
> >          AS_PATH attributes.  Two ASs, X and Y, are said to be in the
> >          same order if either:
> >             - X precedes Y in both AS_PATH attributes, or - Y precedes =
> > X
> >             in both AS_PATH attributes.
> >
> >          b) The aggregated AS_PATH attribute consists of ASs identified
> >          in (a) in exactly the same order as they appear in the AS_PATH
> >          attributes to be aggregated. If two consecutive ASs identified
> >          in (a) do not immediately follow each other in both of the
> >          AS_PATH attributes to be aggregated, then the intervening ASs
> >          (ASs that are between the two consecutive ASs that are the
> >          same) in both attributes are combined into an AS_SET path
> >          segment that consists of the intervening ASs from both AS_PATH
> >          attributes; this segment is then placed in between the two
> >          consecutive ASs identified in (a) of the aggregated attribute.
> >          If two consecutive ASs identified in (a) immediately follow
> >          each other in one attribute, but do not follow in another, =
> > then
> >          the intervening ASs of the latter are combined into an AS_SET
> >          path segment; this segment is then placed in between the two
> >          consecutive ASs identified in (a) of the aggregated attribute.
> >
> >       If as a result of the above procedure a given AS number appears
> >       more than once within the aggregated AS_PATH attribute, all, but
> >       the last instance (rightmost occurrence) of that AS number should
> >       be removed from the aggregated AS_PATH attribute.
> >
> >
> > Security Considerations
> >
> >
> >    BGP supports the ability to authenticate BGP messages by using BGP
> >    authentication. The authentication could be done on a per peer =
> > basis.
> >    In addition, BGP supports the ability to authenticate its data =
> > stream
> >    by using [10]. This authentication could be done on a per peer =
> > basis.
> >    Finally, BGP could also use IPSec to authenticate its data stream.
> >    Among the mechanisms mentioned in this paragraph, [10] is the most
> >    widely deployed.
> >
> >
> >
> >
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 64]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> > References
> >
> >
> >    [1] Mills, D., "Exterior Gateway Protocol Formal Specification",
> >    RFC904, April 1984.
> >
> >    [2] Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET
> >    Backbone", RFC1092, February 1989.
> >
> >    [3] Braun, H-W., "The NSFNET Routing Architecture", RFC1093, =
> > February
> >    1989.
> >
> >    [4] Postel, J., "Transmission Control Protocol - DARPA Internet
> >    Program Protocol Specification", RFC793, September 1981.
> >
> >    [5] Rekhter, Y., and P. Gross, "Application of the Border Gateway
> >    Protocol in the Internet", RFC1772, March 1995.
> >
> >    [6] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
> >    Specification", RFC791, September 1981.
> >
> >    [7] "Information Processing Systems - Telecommunications and
> >    Information Exchange between Systems - Protocol for Exchange of
> >    Inter-domain Routeing Information among Intermediate Systems to
> >    Support Forwarding of ISO 8473 PDUs", ISO/IEC IS10747, 1993
> >
> >    [8] Fuller, V., Li, T., Yu, J., and Varadhan, K., ""Classless Inter-
> >    Domain Routing (CIDR): an Address Assignment and Aggregation
> >    Strategy", RFC1519, September 1993.
> >
> >    [9] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation
> >    with CIDR", RFC 1518, September 1993.
> >
> >    [10] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
> >    Signature Option", RFC2385, August 1998.
> >
> >    [11] Bates, T., Chandra, R., Chen, E., "BGP Route Reflection - An
> >    Alternative to Full Mesh IBGP", RFC2796,  April 2000.
> >
> >    [12] Chen, E., "Route Refresh Capability for BGP-4", RFC2918,
> >    September 2000.
> >
> >    [13] Traina, P, McPherson, D., Scudder, J., "Autonomous System
> >    Confederations for BGP", RFC3065, February 2001.
> >
> >
> >
> >
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 65]
> >
> >
> >
> >
> >
> > RFC DRAFT                                                   January =
> > 2002
> >
> >
> > Editors' Addresses
> >
> >    Yakov Rekhter
> >    Juniper Networks
> >    1194 N. Mathilda Avenue
> >    Sunnyvale, CA 94089
> >    email:  [e-mail]
> >
> >    Tony Li
> >    Procket Networks
> >    1100 Cadillac Ct.
> >    Milpitas, CA 95035
> >    Email:  [e-mail]
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Expiration Date July 2002                                      =0C[Page
> =
> > 66]
> >
> >
> >
> >
> > ------_=_NextPart_000_01C281A9.64ABEC00--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA26657 for <[e-mail]>; Fri, 1 Nov 2002 08:54:15 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 905379122C; Fri,  1 Nov 2002 08:53:31 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 358ED91235; Fri,  1 Nov 2002 08:53:31 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B52509122C for <[e-mail]>; Fri,  1 Nov 2002 08:53:23 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 81CCE5DEF4; Fri,  1 Nov 2002 08:53:23 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id ACD5A5DE17 for <[e-mail]>; Fri,  1 Nov 2002 08:53:21 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gA1DrIm43866; Fri, 1 Nov 2002 05:53:18 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Parag Deshpande'" <[e-mail]>, [e-mail]
Subject: Re: draft-ietf-idr-bgp4-18.txt 
In-Reply-To: Your message of "Fri, 01 Nov 2002 08:20:05 EST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 01 Nov 2002 05:53:18 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> This is obviously an "uncontrolled copy", but *I think* it is current.
> Also, refer to the "RE: BGP Base Draft - Issue List v1.5" email sent on
> Monday, October 28, 2002 7:00 PM for info on the proposed changes. 
> I am assuming that this current version was removed because the
> new version is to be posted shortly.

In fact, I submitted the -18 version on Wednesday.

Yakov.
> 
> 
> > -----Original Message-----
> > From: Parag Deshpande [mailto:[e-mail]] 
> > Sent: Thursday, October 31, 2002 5:57 PM
> > To: [e-mail]
> > Cc: Susan Hares
> > Subject: draft-ietf-idr-bgp4-18.txt
> > 
> > 
> Hi,
> > 
> > I am unable to locate the latest bgp draft on ietf site. 
> > Where can I get it?
> > I would appreciate if someone could just mail it to me.
> > 
> > Thanks,
> > Parag
> > 
> > 
> 
> 
> ------_=_NextPart_000_01C281A9.64ABEC00
> Content-Type: text/plain;
> 	name="draft-ietf-idr-bgp4-17.txt"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: attachment;
> 	filename="draft-ietf-idr-bgp4-17.txt"
> 
> 
> 
> 
> Network Working Group                                      Y. Rekhter
> INTERNET DRAFT                                       Juniper Networks
>                                                                 T. Li
>                                                Procket Networks, Inc.
>                                                               Editors
> 
> 
> 
>                   A Border Gateway Protocol 4 (BGP-4)
>                       <draft-ietf-idr-bgp4-17.txt>
> 
> 
> Status of this Memo
> 
> 
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
> 
>    Internet-Drafts are draft documents valid for a maximum of six =
> months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time. It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as ``work in progress.''
> 
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
> 
> 
> 
> 1. Acknowledgments
> 
>    This document was originally published as RFC 1267 in October 1991,
>    jointly authored by Kirk Lougheed and Yakov Rekhter.
> 
>    We would like to express our thanks to Guy Almes, Len Bosack, and
>    Jeffrey C. Honig for their contributions to the earlier version of
>    this document.
> 
>    We like to explicitly thank Bob Braden for the review of the earlier
>    version of this document as well as his constructive and valuable
>    comments.
> 
> 
> 
> Expiration Date July 2002                                       =
> =0C[Page 1]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    We would also like to thank Bob Hinden, Director for Routing of the
>    Internet Engineering Steering Group, and the team of reviewers he
>    assembled to review the earlier version (BGP-2) of this document.
>    This team, consisting of Deborah Estrin, Milo Medin, John Moy, Radia
>    Perlman, Martha Steenstrup, Mike St. Johns, and Paul Tsuchiya, acted
>    with a strong combination of toughness, professionalism, and
>    courtesy.
> 
>    This updated version of the document is the product of the IETF IDR
>    Working Group with Yakov Rekhter and Tony Li as editors. Certain
>    sections of the document borrowed heavily from IDRP [7], which is =
> the
>    OSI counterpart of BGP. For this credit should be given to the ANSI
>    X3S3.3 group chaired by Lyman Chapin and to Charles Kunzinger who =
> was
>    the IDRP editor within that group. We would also like to thank Enke
>    Chen, Edward Crabbe, Mike Craren, Vincent Gillet, Eric Gray, Jeffrey
>    Haas, Dimitry Haskin, John Krawczyk, David LeRoy, Dan Massey, Dan
>    Pei, Mathew Richardson, John Scudder, John Stewart III, Dave Thaler,
>    Paul Traina, Russ White, Curtis Villamizar, and Alex Zinin for their
>    comments.
> 
>    Many thanks to Sue Hares for her contributions to the document, and
>    especially for her work on the BGP Finite State Machine.
> 
>    We would like to specially acknowledge numerous contributions by
>    Dennis Ferguson.
> 
> 
> 2. Introduction
> 
>    The Border Gateway Protocol (BGP) is an inter-Autonomous System
>    routing protocol. It is built on experience gained with EGP as
>    defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as
>    described in RFC 1092 [2] and RFC 1093 [3].
> 
>    The primary function of a BGP speaking system is to exchange network
>    reachability information with other BGP systems. This network
>    reachability information includes information on the list of
>    Autonomous Systems (ASs) that reachability information traverses.
>    This information 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.
> 
>    BGP-4 provides a new set of mechanisms for supporting Classless
>    Inter-Domain Routing (CIDR) [8, 9]. These mechanisms include support
>    for advertising an IP prefix and eliminates the concept of network
>    "class" within BGP.  BGP-4 also introduces mechanisms which allow
>    aggregation of routes, including aggregation of AS paths.
> 
> 
> 
> 
> Expiration Date July 2002                                       =
> =0C[Page 2]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    To characterize the set of policy decisions that can be enforced
>    using BGP, one must focus on the rule that a BGP speaker advertises
>    to its peers (other BGP speakers which it communicates with) in
>    neighboring ASs only those routes that it itself uses. This rule
>    reflects the "hop-by-hop" routing paradigm generally used throughout
>    the current Internet. Note that some policies cannot be supported by
>    the "hop-by-hop" routing paradigm and thus require techniques such =
> as
>    source routing (aka explicit routing) to enforce. For example, BGP
>    does not enable one AS to send traffic to a neighboring AS intending
>    that the traffic take a different route from that taken by traffic
>    originating in the neighboring AS. On the other hand, BGP can =
> support
>    any policy conforming to the "hop-by-hop" routing paradigm. Since =
> the
>    current Internet uses only the "hop-by-hop" inter-AS routing =
> paradigm
>    and since BGP can support any policy that conforms to that paradigm,
>    BGP is highly applicable as an inter-AS routing protocol for the
>    current Internet.
> 
>    A more complete discussion of what policies can and cannot be
>    enforced with BGP is outside the scope of this document (but refer =
> to
>    the companion document discussing BGP usage [5]).
> 
>    BGP runs over a reliable transport protocol. This eliminates the =
> need
>    to implement explicit update fragmentation, retransmission,
>    acknowledgment, and sequencing. Any authentication scheme used by =
> the
>    transport protocol (e.g., RFC2385 [10]) may be used in addition to
>    BGP's own authentication mechanisms. The error notification =
> mechanism
>    used in BGP assumes that the transport protocol supports a =
> "graceful"
>    close, i.e., that all outstanding data will be delivered before the
>    connection is closed.
> 
>    BGP uses TCP [4] as its transport protocol. TCP meets BGP's =
> transport
>    requirements and is present in virtually all commercial routers and
>    hosts. In the following descriptions the phrase "transport protocol
>    connection" can be understood to refer to a TCP connection. BGP uses
>    TCP port 179 for establishing its connections.
> 
>    This document uses the term `Autonomous System' (AS) throughout.  =
> The
>    classic definition of an Autonomous System is a set of routers under
>    a single technical administration, using an interior gateway =
> protocol
>    and common metrics to determine how to route packets within the AS,
>    and using an exterior gateway protocol to determine how to route
>    packets to other ASs. Since this classic definition was developed, =
> it
>    has become common for a single AS to use several interior gateway
>    protocols and sometimes several sets of metrics within an AS. The =
> use
>    of the term Autonomous System here stresses the fact that, even when
>    multiple IGPs and metrics are used, the administration of an AS
>    appears to other ASs to have a single coherent interior routing plan
>    and presents a consistent picture of what destinations are reachable
> 
> 
> 
> Expiration Date July 2002                                       =
> =0C[Page 3]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    through it.
> 
>    The planned use of BGP in the Internet environment, including such
>    issues as topology, the interaction between BGP and IGPs, and the
>    enforcement of routing policy rules is presented in a companion
>    document [5]. This document is the first of a series of documents
>    planned to explore various aspects of BGP application.
> 
> 
> 3. Summary of Operation
> 
>    Two systems form a transport protocol connection between one =
> another.
>    They exchange messages to open and confirm the connection =
> parameters.
> 
>    The initial data flow is the portion of the BGP routing table that =
is
>    allowed by the export policy, called the Adj-Ribs-Out (see 3.2).
>    Incremental updates are sent as the routing tables change. BGP does
>    not require periodic refresh of the routing table. Therefore, a BGP
>    speaker must retain the current version of the routes advertised by
>    all of its peers for the duration of the connection. If the
>    implementation decides to not store the routes that have been
>    received from a peer, but have been filtered out according to
>    configured local policy, the BGP Route Refresh extension [12] may be
>    used to request the full set of routes from a peer without resetting
>    the BGP session when the local policy configuration changes.
> 
>    KEEPALIVE messages may be sent periodically to ensure the liveness =
> of
>    the connection. NOTIFICATION messages are sent in response to errors
>    or special conditions. If a connection encounters an error =
> condition,
>    a NOTIFICATION message is sent and the connection is closed.
> 
>    The hosts executing the Border Gateway Protocol need not be routers.
>    A non-routing host could exchange routing information with routers
>    via EGP or even an interior routing protocol. That non-routing host
>    could then use BGP to exchange routing information with a border
>    router in another Autonomous System. The implications and
>    applications of this architecture are for further study.
> 
>    Connections between BGP speakers of different ASs are referred to as
>    "external" links. BGP connections between BGP speakers within the
>    same AS are referred to as "internal" links. Similarly, a peer in a
>    different AS is referred to as an external peer, while a peer in the
>    same AS may be described as an internal peer. Internal BGP and
>    external BGP are commonly abbreviated IBGP and EBGP.
> 
>    If a particular AS has multiple BGP speakers and is providing =
> transit
>    service for other ASs, then care must be taken to ensure a =
> consistent
>    view of routing within the AS. A consistent view of the interior
> 
> 
> 
> Expiration Date July 2002                                       =
> =0C[Page 4]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    routes of the AS is provided by the interior routing protocol. A
>    consistent view of the routes exterior to the AS can be provided by
>    having all BGP speakers within the AS maintain direct IBGP
>    connections with each other. Alternately the interior routing
>    protocol can pass BGP information among routers within an AS, taking
>    care not to lose BGP attributes that will be needed by EBGP speakers
>    if transit connectivity is being provided. For the purpose of
>    discussion, it is assumed that BGP information is passed within an =
> AS
>    using IBGP. Care must be taken to ensure that the interior routers
>    have all been updated with transit information before the EBGP
>    speakers announce to other ASs that transit service is being
>    provided.
> 
> 
> 3.1 Routes: Advertisement and Storage
> 
>    For the purpose of this protocol, a route is defined as a unit of
>    information that pairs a set of destinations with the attributes of =
> a
>    path to those destinations.  The set of destinations are the systems
>    whose IP addresses are reported in the Network Layer Reachability
>    Information (NLRI) field and the path is the information reported in
>    the path attributes field of the same UPDATE message.
> 
>    Routes are advertised between BGP speakers in UPDATE messages.
> 
>    Routes are stored in the Routing Information Bases (RIBs): namely,
>    the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out. Routes that will
>    be advertised to other BGP speakers must be present in the Adj-RIB-
>    Out.  Routes that will be used by the local BGP speaker must be
>    present in the Loc-RIB, and the next hop for each of these routes
>    must be resolvable via the local BGP speaker's Routing Table.  =
> Routes
>    that are received from other BGP speakers are present in the Adj-
>    RIBs-In.
> 
>    If a BGP speaker chooses to advertise the route, it may add to or
>    modify the path attributes of the route before advertising it to a
>    peer.
> 
>    BGP provides mechanisms by which a BGP speaker can inform its peer
>    that a previously advertised route is no longer available for use.
>    There are three methods by which a given BGP speaker can indicate
>    that a route has been withdrawn from service:
> 
>       a) the IP prefix that expresses the destination for a previously
>       advertised route can be advertised in the WITHDRAWN ROUTES field
>       in the UPDATE message, thus marking the associated route as being
>       no longer available for use
> 
> 
> 
> 
> Expiration Date July 2002                                       =
> =0C[Page 5]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>       b) a replacement route with the same NLRI can be advertised, or
> 
>       c) the BGP speaker - BGP speaker connection can be closed, which
>       implicitly removes from service all routes which the pair of
>       speakers had advertised to each other.
> 
> 
> 3.2 Routing Information Bases
> 
>    The Routing Information Base (RIB) within a BGP speaker consists of
>    three distinct parts:
> 
>       a) Adj-RIBs-In: The Adj-RIBs-In store routing information that =
> has
>       been learned from inbound UPDATE messages. Their contents
>       represent routes that are available as an input to the Decision
>       Process.
> 
>       b) Loc-RIB: The Loc-RIB contains the local routing information
>       that the BGP speaker has selected by applying its local policies
>       to the routing information contained in its Adj-RIBs-In.
> 
>       c) Adj-RIBs-Out: The Adj-RIBs-Out store the information that the
>       local BGP speaker has selected for advertisement to its peers. =
> The
>       routing information stored in the Adj-RIBs-Out will be carried in
>       the local BGP speaker's UPDATE messages and advertised to its
>       peers.
> 
>    In summary, the Adj-RIBs-In contain unprocessed routing information
>    that has been advertised to the local BGP speaker by its peers; the
>    Loc-RIB contains the routes that have been selected by the local BGP
>    speaker's Decision Process; and the Adj-RIBs-Out organize the routes
>    for advertisement to specific peers by means of the local speaker's
>    UPDATE messages.
> 
>    Although the conceptual model distinguishes between Adj-RIBs-In, =
> Loc-
>    RIB, and Adj-RIBs-Out, this neither implies nor requires that an
>    implementation must maintain three separate copies of the routing
>    information. The choice of implementation (for example, 3 copies of
>    the information vs 1 copy with pointers) is not constrained by the
>    protocol.
> 
>    Routing information that the router uses to forward packets (or to
>    construct the forwarding table that is used for packet forwarding) =
> is
>    maintained in the Routing Table. The Routing Table accumulates =
> routes
>    to directly connected networks, static routes, routes learned from
>    the IGP protocols, and routes learned from BGP.  Whether or not a
>    specific BGP route should be installed in the Routing Table, and
>    whether a BGP route should override a route to the same destination
> 
> 
> 
> Expiration Date July 2002                                       =
> =0C[Page 6]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    installed by another source is a local policy decision, not =
> specified
>    in this document. Besides actual packet forwarding, the Routing =
> Table
>    is used for resolution of the next-hop addresses specified in BGP
>    updates (see Section 9.1.2).
> 
> 
> 4. Message Formats
> 
>    This section describes message formats used by BGP.
> 
>    Messages are sent over a reliable transport protocol connection. A
>    message is processed only after it is entirely received. The maximum
>    message size is 4096 octets. All implementations are required to
>    support this maximum message size. The smallest message that may be
>    sent consists of a BGP header without a data portion, or 19 octets.
> 
> 
> 4.1 Message Header Format
> 
>    Each message has a fixed-size header. There may or may not be a data
>    portion following the header, depending on the message type. The
>    layout of these fields is shown below:
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       +                                                               +
>       |                                                               |
>       +                                                               +
>       |                           Marker                              |
>       +                                                               +
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |          Length               |      Type     |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>       Marker:
> 
>          This 16-octet field contains a value that the receiver of the
>          message can predict. If the Type of the message is OPEN, or if
>          the OPEN message carries no Authentication Information (as an
>          Optional Parameter), then the Marker must be all ones.
>          Otherwise, the value of the marker can be predicted by some a
>          computation specified as part of the authentication mechanism
>          (which is specified as part of the Authentication Information)
>          used. The Marker can be used to detect loss of synchronization
> 
> 
> 
> Expiration Date July 2002                                       =
> =0C[Page 7]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>          between a pair of BGP peers, and to authenticate incoming BGP
>          messages.
> 
>       Length:
> 
>          This 2-octet unsigned integer indicates the total length of =
> the
>          message, including the header, in octets. Thus, e.g., it =
> allows
>          one to locate in the transport-level stream the (Marker field
>          of the) next message. The value of the Length field must =
> always
>          be at least 19 and no greater than 4096, and may be further
>          constrained, depending on the message type. No "padding" of
>          extra data after the message is allowed, so the Length field
>          must have the smallest value required given the rest of the
>          message.
> 
>       Type:
> 
>          This 1-octet unsigned integer indicates the type code of the
>          message. The following type codes are defined:
> 
>                                     1 - OPEN
>                                     2 - UPDATE
>                                     3 - NOTIFICATION
>                                     4 - KEEPALIVE
> 
> 4.2 OPEN Message Format
> 
>    After a transport protocol connection is established, the first
>    message sent by each side is an OPEN message. If the OPEN message is
>    acceptable, a KEEPALIVE message confirming the OPEN is sent back.
>    Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION
>    messages may be exchanged.
> 
>    In addition to the fixed-size BGP header, the OPEN message contains
>    the following fields:
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+
>        |    Version    |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |     My Autonomous System      |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |           Hold Time           |
>        =
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                         BGP Identifier                        =
> |
>        =
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        | Opt Parm Len  |
> 
> 
> 
> Expiration Date July 2002                                       =
> =0C[Page 8]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>        =
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               =
> |
>        |             Optional Parameters (variable)                    =
> |
>        |                                                               =
> |
>        =
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>       Version:
> 
>          This 1-octet unsigned integer indicates the protocol version
>          number of the message. The current BGP version number is 4.
> 
>       My Autonomous System:
> 
>          This 2-octet unsigned integer indicates the Autonomous System
>          number of the sender.
> 
>       Hold Time:
> 
>          This 2-octet unsigned integer indicates the number of seconds
>          that the sender proposes for the value of the Hold Timer. Upon
>          receipt of an OPEN message, a BGP speaker MUST calculate the
>          value of the Hold Timer by using the smaller of its configured
>          Hold Time and the Hold Time received in the OPEN message. The
>          Hold Time MUST be either zero or at least three seconds.  An
>          implementation may reject connections on the basis of the Hold
>          Time.  The calculated value indicates the maximum number of
>          seconds that may elapse between the receipt of successive
>          KEEPALIVE, and/or UPDATE messages by the sender.
> 
>       BGP Identifier:
> 
>          This 4-octet unsigned integer indicates the BGP Identifier of
>          the sender. A given BGP speaker sets the value of its BGP
>          Identifier to an IP address assigned to that BGP speaker.  The
>          value of the BGP Identifier is determined on startup and is =
> the
>          same for every local interface and every BGP peer.
> 
>       Optional Parameters Length:
> 
>          This 1-octet unsigned integer indicates the total length of =
> the
>          Optional Parameters field in octets. If the value of this =
> field
>          is zero, no Optional Parameters are present.
> 
>       Optional Parameters:
> 
>          This field may contain a list of optional parameters, where
>          each parameter is encoded as a <Parameter Type, Parameter
> 
> 
> 
> Expiration Date July 2002                                       =
> =0C[Page 9]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>          Length, Parameter Value> triplet.
> 
>                0                   1
>                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
>                |  Parm. Type   | Parm. Length  |  Parameter Value =
> (variable)
>                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
> 
>          Parameter Type is a one octet field that unambiguously
>          identifies individual parameters. Parameter Length is a one
>          octet field that contains the length of the Parameter Value
>          field in octets.  Parameter Value is a variable length field
>          that is interpreted according to the value of the Parameter
>          Type field.
> 
>          This document defines the following Optional Parameters:
> 
>          a) Authentication Information (Parameter Type 1):
> 
> 
>             This optional parameter may be used to authenticate a BGP
>             peer. The Parameter Value field contains a 1-octet
>             Authentication Code followed by a variable length
>             Authentication Data.
> 
>                 0 1 2 3 4 5 6 7 8
>                 +-+-+-+-+-+-+-+-+
>                 |  Auth. Code   |
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                 |                                                     |
>                 |              Authentication Data                    |
>                 |                                                     |
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>                Authentication Code:
> 
>                   This 1-octet unsigned integer indicates the
>                   authentication mechanism being used. Whenever an
>                   authentication mechanism is specified for use within
>                   BGP, three things must be included in the
>                   specification:
> 
>                   - the value of the Authentication Code which =
> indicates
>                   use of the mechanism,
>                   - the form and meaning of the Authentication Data, =
> and
>                   - the algorithm for computing values of Marker =
> fields.
> 
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 10]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>                   Note that a separate authentication mechanism may be
>                   used in establishing the transport level connection.
> 
>                Authentication Data:
> 
>                   Authentication Data is a variable length field that =
> is
                  interpreted according to the value of the
>                   Authentication Code field.
> 
> 
>          The minimum length of the OPEN message is 29 octets (including
>          message header).
> 
> 
> 4.3 UPDATE Message Format
> 
> 
>    UPDATE messages are used to transfer routing information between BGP
>    peers. The information in the UPDATE packet can be used to construct
>    a graph describing the relationships of the various Autonomous
>    Systems. By applying rules to be discussed, routing information =
> loops
>    and some other anomalies may be detected and removed from inter-AS
>    routing.
> 
>    An UPDATE message is used to advertise feasible routes sharing =
> common
>    path attribute to a peer, or to withdraw multiple unfeasible routes
>    from service (see 3.1). An UPDATE message may simultaneously
>    advertise a feasible route and withdraw multiple unfeasible routes
>    from service. The UPDATE message always includes the fixed-size BGP
>    header, and also includes the other fields as shown below (note, =
some
>    of the shown fields may not be present in every UPDATE message):
> 
> 
>       +-----------------------------------------------------+
>       |   Withdrawn Routes Length (2 octets)                |
>       +-----------------------------------------------------+
>       |   Withdrawn Routes (variable)                       |
>       +-----------------------------------------------------+
>       |   Total Path Attribute Length (2 octets)            |
>       +-----------------------------------------------------+
>       |   Path Attributes (variable)                        |
>       +-----------------------------------------------------+
>       |   Network Layer Reachability Information (variable) |
>       +-----------------------------------------------------+
> 
> 
> 
>       Withdrawn Routes Length:
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 11]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>          This 2-octets unsigned integer indicates the total length of
         the Withdrawn Routes field in octets.  Its value must allow =
> the
>          length of the Network Layer Reachability Information field to
>          be determined as specified below.
> 
>          A value of 0 indicates that no routes are being withdrawn from
>          service, and that the WITHDRAWN ROUTES field is not present in
>          this UPDATE message.
> 
>       Withdrawn Routes:
> 
> 
>          This is a variable length field that contains a list of IP
>          address prefixes for the routes that are being withdrawn from
>          service. Each IP address prefix is encoded as a 2-tuple of the
>          form <length, prefix>, whose fields are described below:
> 
>                   +---------------------------+
>                   |   Length (1 octet)        |
>                   +---------------------------+
>                   |   Prefix (variable)       |
>                   +---------------------------+
> 
> 
>          The use and the meaning of these fields are as follows:
> 
>          a) Length:
> 
>             The Length field indicates the length in bits of the IP
>             address prefix. A length of zero indicates a prefix that
>             matches all IP addresses (with prefix, itself, of zero
>             octets).
> 
>          b) Prefix:
> 
>             The Prefix field contains an IP address prefix followed by
>             enough trailing bits to make the end of the field fall on =
> an
>             octet boundary. Note that the value of trailing bits is
>             irrelevant.
> 
>       Total Path Attribute Length:
> 
>          This 2-octet unsigned integer indicates the total length of =
> the
>          Path Attributes field in octets. Its value must allow the
>          length of the Network Layer Reachability field to be =
> determined
>          as specified below.
> 
>          A value of 0 indicates that no Network Layer Reachability
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 12]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>          Information field is present in this UPDATE message.
> 
>       Path Attributes:
> 
>          A variable length sequence of path attributes is present in
>          every UPDATE. Each path attribute is a triple <attribute type,
>          attribute length, attribute value> of variable length.
> 
>          Attribute Type is a two-octet field that consists of the
>          Attribute Flags octet followed by the Attribute Type Code
>          octet.
> 
> 
> 
> 
>                0                   1
>                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                |  Attr. Flags  |Attr. Type Code|
>                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>          The high-order bit (bit 0) of the Attribute Flags octet is the
>          Optional bit. It defines whether the attribute is optional (if
>          set to 1) or well-known (if set to 0).
> 
>          The second high-order bit (bit 1) of the Attribute Flags octet
>          is the Transitive bit. It defines whether an optional =
> attribute
>          is transitive (if set to 1) or non-transitive (if set to 0).
>          For well-known attributes, the Transitive bit must be set to =
> 1.
>          (See Section 5 for a discussion of transitive attributes.)
> 
>          The third high-order bit (bit 2) of the Attribute Flags octet
>          is the Partial bit. It defines whether the information
>          contained in the optional transitive attribute is partial (if
>          set to 1) or complete (if set to 0). For well-known attributes
>          and for optional non-transitive attributes the Partial bit =
> must
>          be set to 0.
> 
>          The fourth high-order bit (bit 3) of the Attribute Flags octet
>          is the Extended Length bit. It defines whether the Attribute
>          Length is one octet (if set to 0) or two octets (if set to 1).
> 
>          The lower-order four bits of the Attribute Flags octet are
>          unused. They must be zero when sent and must be ignored when
>          received.
> 
>          The Attribute Type Code octet contains the Attribute Type =
> Code.
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 13]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>          Currently defined Attribute Type Codes are discussed in =
> Section
>          5.
> 
>          If the Extended Length bit of the Attribute Flags octet is set
>          to 0, the third octet of the Path Attribute contains the =
> length
>          of the attribute data in octets.
> 
>          If the Extended Length bit of the Attribute Flags octet is set
>          to 1, then the third and the fourth octets of the path
>          attribute contain the length of the attribute data in octets.
> 
>          The remaining octets of the Path Attribute represent the
>          attribute value and are interpreted according to the Attribute
>          Flags and the Attribute Type Code. The supported Attribute =
> Type
>          Codes, their attribute values and uses are the following:
> 
>          a)   ORIGIN (Type Code 1):
> 
>             ORIGIN is a well-known mandatory attribute that defines the
>             origin of the path information.  The data octet can assume
>             the following values:
> 
>                   Value      Meaning
> 
>                   0         IGP - Network Layer Reachability =
> Information
>                                is interior to the originating AS
> 
>                   1         EGP - Network Layer Reachability =
> Information
>                                learned via the EGP protocol
> 
>                   2         INCOMPLETE - Network Layer Reachability
>                                Information learned by some other means
> 
>             Its usage is defined in 5.1.1
> 
>          b) AS_PATH (Type Code 2):
> 
>             AS_PATH is a well-known mandatory attribute that is =
> composed
>             of a sequence of AS path segments. Each AS path segment is
>             represented by a triple <path segment type, path segment
>             length, path segment value>.
> 
>             The path segment type is a 1-octet long field with the
>             following values defined:
> 
>                   Value      Segment Type
> 
>                   1         AS_SET: unordered set of ASs a route in the
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 14]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>                                UPDATE message has traversed
> 
>                   2         AS_SEQUENCE: ordered set of ASs a route in
>                                the UPDATE message has traversed
> 
>             The path segment length is a 1-octet long field containing
>             the number of ASs in the path segment value field.
> 
>             The path segment value field contains one or more AS
>             numbers, each encoded as a 2-octets long field.
> 
>             Usage of this attribute is defined in 5.1.2.
> 
>          c)   NEXT_HOP (Type Code 3):
> 
>             This is a well-known mandatory attribute that defines the =
> IP
>             address of the border router that should be used as the =
> next
>             hop to the destinations listed in the Network Layer
>             Reachability Information field of the UPDATE message.
> 
>             Usage of this attribute is defined in 5.1.3.
> 
> 
>          d) MULTI_EXIT_DISC (Type Code 4):
> 
>             This is an optional non-transitive attribute that is a four
>             octet non-negative integer. The value of this attribute may
>             be used by a BGP speaker's decision process to discriminate
>             among multiple entry points to a neighboring autonomous
>             system.
> 
>             Its usage is defined in 5.1.4.
> 
>          e) LOCAL_PREF (Type Code 5):
> 
>             LOCAL_PREF is a well-known attribute that is a four octet
>             non-negative integer. A BGP speaker uses it to inform other
>             internal peers of the advertising speaker's degree of
>             preference for an advertised route. Usage of this attribute
>             is described in 5.1.5.
> 
>          f) ATOMIC_AGGREGATE (Type Code 6)
> 
>             ATOMIC_AGGREGATE is a well-known discretionary attribute of
>             length 0. Usage of this attribute is described in 5.1.6.
> 
>          g) AGGREGATOR (Type Code 7)
> 
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 15]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>             AGGREGATOR is an optional transitive attribute of length 6.
>             The attribute contains the last AS number that formed the
>             aggregate route (encoded as 2 octets), followed by the IP
>             address of the BGP speaker that formed the aggregate route
>             (encoded as 4 octets).  This should be the same address as
>             the one used for the BGP Identifier of the speaker.  Usage
>             of this attribute is described in 5.1.7.
> 
>       Network Layer Reachability Information:
> 
>          This variable length field contains a list of IP address
>          prefixes. The length in octets of the Network Layer
>          Reachability Information is not encoded explicitly, but can be
>          calculated as:
> 
>             UPDATE message Length - 23 - Total Path Attributes Length -
>             Withdrawn Routes Length
> 
>          where UPDATE message Length is the value encoded in the fixed-
>          size BGP header, Total Path Attribute Length and Withdrawn
>          Routes Length are the values encoded in the variable part of
>          the UPDATE message, and 23 is a combined length of the fixed-
>          size BGP header, the Total Path Attribute Length field and the
>          Withdrawn Routes Length field.
> 
>          Reachability information is encoded as one or more 2-tuples of
>          the form <length, prefix>, whose fields are described below:
> 
> 
>                   +---------------------------+
>                   |   Length (1 octet)        |
>                   +---------------------------+
>                   |   Prefix (variable)       |
>                   +---------------------------+
> 
> 
>          The use and the meaning of these fields are as follows:
> 
>          a) Length:
> 
>             The Length field indicates the length in bits of the IP
>             address prefix. A length of zero indicates a prefix that
>             matches all IP addresses (with prefix, itself, of zero
>             octets).
> 
>          b) Prefix:
> 
>             The Prefix field contains IP address prefixes followed by
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 16]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>             enough trailing bits to make the end of the field fall on =
> an
>             octet boundary. Note that the value of the trailing bits is
>             irrelevant.
> 
>    The minimum length of the UPDATE message is 23 octets -- 19 octets
>    for the fixed header + 2 octets for the Withdrawn Routes Length + 2
>    octets for the Total Path Attribute Length (the value of Withdrawn
>    Routes Length is 0 and the value of Total Path Attribute Length is
>    0).
> 
>    An UPDATE message can advertise at most one set of path attributes,
>    but multiple destinations, provided that the destinations share =
> these
>    attributes. All path attributes contained in a given UPDATE message
>    apply to all destinations carried in the NLRI field of the UPDATE
>    message.
> 
>    An UPDATE message can list multiple routes to be withdrawn from
>    service.  Each such route is identified by its destination =
> (expressed
>    as an IP prefix), which unambiguously identifies the route in the
>    context of the BGP speaker - BGP speaker connection to which it has
>    been previously advertised.
> 
>    An UPDATE message might advertise only routes to be withdrawn from
>    service, in which case it will not include path attributes or =
> Network
>    Layer Reachability Information. Conversely, it may advertise only a
>    feasible route, in which case the WITHDRAWN ROUTES field need not be
>    present.
> 
>    An UPDATE message should not include the same address prefix in the
>    WITHDRAWN ROUTES and Network Layer Reachability Information fields,
>    however a BGP speaker MUST be able to process UPDATE messages in =
> this
>    form. A BGP speaker should treat an UPDATE message of this form as =
> if
>    the WITHDRAWN ROUTES doesn't contain the address prefix.
> 
> 
> 4.4 KEEPALIVE Message Format
> 
> 
>    BGP does not use any transport protocol-based keep-alive mechanism =
> to
>    determine if peers are reachable. Instead, KEEPALIVE messages are
>    exchanged between peers often enough as not to cause the Hold Timer
>    to expire. A reasonable maximum time between KEEPALIVE messages =
> would
>    be one third of the Hold Time interval. KEEPALIVE messages MUST NOT
>    be sent more frequently than one per second. An implementation MAY
>    adjust the rate at which it sends KEEPALIVE messages as a function =
> of
>    the Hold Time interval.
> 
>    If the negotiated Hold Time interval is zero, then periodic =
> KEEPALIVE
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 17]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    messages MUST NOT be sent.
> 
>    KEEPALIVE message consists of only message header and has a length =
> of
>    19 octets.
> 
> 
> 4.5 NOTIFICATION Message Format
> 
> 
>    A NOTIFICATION message is sent when an error condition is detected.
>    The BGP connection is closed immediately after sending it.
> 
>    In addition to the fixed-size BGP header, the NOTIFICATION message
>    contains the following fields:
> 
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        =
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        | Error code    | Error subcode |   Data (variable)             =
> |
>        =
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> 
>       Error Code:
> 
>          This 1-octet unsigned integer indicates the type of
>          NOTIFICATION. The following Error Codes have been defined:
> 
>             Error Code       Symbolic Name               Reference
> 
>               1         Message Header Error             Section 6.1
> 
>               2         OPEN Message Error               Section 6.2
> 
>               3         UPDATE Message Error             Section 6.3
> 
>               4         Hold Timer Expired               Section 6.5
> 
>               5         Finite State Machine Error       Section 6.6
> 
>               6         Cease                            Section 6.7
> 
> 
>       Error subcode:
> 
>          This 1-octet unsigned integer provides more specific
>          information about the nature of the reported error.  Each =
> Error
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 18]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>          Code may have one or more Error Subcodes associated with it. =
> If
>          no appropriate Error Subcode is defined, then a zero
>          (Unspecific) value is used for the Error Subcode field.
> 
>          Message Header Error subcodes:
> 
>                                1  - Connection Not Synchronized.
>                                2  - Bad Message Length.
>                                3  - Bad Message Type.
> 
>          OPEN Message Error subcodes:
> 
>                                1  - Unsupported Version Number.
>                                2  - Bad Peer AS.
>                                3  - Bad BGP Identifier.
>                                4  - Unsupported Optional Parameter.
>                                5  - Authentication Failure.
>                                6  - Unacceptable Hold Time.
> 
>          UPDATE Message Error subcodes:
> 
>                                1 - Malformed Attribute List.
>                                2 - Unrecognized Well-known Attribute.
>                                3 - Missing Well-known Attribute.
>                                4 - Attribute Flags Error.
>                                5 - Attribute Length Error.
>                                6 - Invalid ORIGIN Attribute
>                                8 - Invalid NEXT_HOP Attribute.
>                                9 - Optional Attribute Error.
>                               10 - Invalid Network Field.
>                               11 - Malformed AS_PATH.
> 
> 
>       Data:
> 
>          This variable-length field is used to diagnose the reason for
>          the NOTIFICATION. The contents of the Data field depend upon
>          the Error Code and Error Subcode. See Section 6 below for more
>          details.
> 
>          Note that the length of the Data field can be determined from
>          the message Length field by the formula:
> 
>                   Message Length =3D 21 + Data Length
> 
> 
>    The minimum length of the NOTIFICATION message is 21 octets
>    (including message header).
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 19]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
> 5. Path Attributes
> 
> 
>    This section discusses the path attributes of the UPDATE message.
> 
>    Path attributes fall into four separate categories:
> 
>                1. Well-known mandatory.
>                2. Well-known discretionary.
>                3. Optional transitive.
>                4. Optional non-transitive.
> 
>    Well-known attributes must be recognized by all BGP implementations.
>    Some of these attributes are mandatory and must be included in every
>    UPDATE message that contains NLRI. Others are discretionary and may
>    or may not be sent in a particular UPDATE message.
> 
>    All well-known attributes must be passed along (after proper
>    updating, if necessary) to other BGP peers.
> 
>    In addition to well-known attributes, each path may contain one or
>    more optional attributes. It is not required or expected that all =
> BGP
>    implementations support all optional attributes. The handling of an
>    unrecognized optional attribute is determined by the setting of the
>    Transitive bit in the attribute flags octet. Paths with unrecognized
>    transitive optional attributes should be accepted. If a path with
>    unrecognized transitive optional attribute is accepted and passed
>    along to other BGP peers, then the unrecognized transitive optional
>    attribute of that path must be passed along with the path to other
>    BGP peers with the Partial bit in the Attribute Flags octet set to =
> 1.
>    If a path with recognized transitive optional attribute is accepted
>    and passed along to other BGP peers and the Partial bit in the
>    Attribute Flags octet is set to 1 by some previous AS, it is not set
>    back to 0 by the current AS. Unrecognized non-transitive optional
>    attributes must be quietly ignored and not passed along to other BGP
>    peers.
> 
>    New transitive optional attributes may be attached to the path by =
> the
>    originator or by any other BGP speaker in the path. If they are not
>    attached by the originator, the Partial bit in the Attribute Flags
>    octet is set to 1. The rules for attaching new non-transitive
>    optional attributes will depend on the nature of the specific
>    attribute. The documentation of each new non-transitive optional
>    attribute will be expected to include such rules. (The description =
> of
>    the MULTI_EXIT_DISC attribute gives an example.) All optional
>    attributes (both transitive and non-transitive) may be updated (if
>    appropriate) by BGP speakers in the path.
> 
> 

> 
> Expiration Date July 2002                                      =0C[Page =
> 20]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    The sender of an UPDATE message should order path attributes within
>    the UPDATE message in ascending order of attribute type. The =
> receiver
>    of an UPDATE message must be prepared to handle path attributes
>    within the UPDATE message that are out of order.
> 
>    The same attribute cannot appear more than once within the Path
>    Attributes field of a particular UPDATE message.
> 
>    The mandatory category refers to an attribute which must be present
>    in both IBGP and EBGP exchanges if NLRI are contained in the UPDATE
>    message.  Attributes classified as optional for the purpose of the
>    protocol extension mechanism may be purely discretionary, or
>    discretionary, required, or disallowed in certain contexts.
> 
>         attribute           EBGP                    IBGP
>          ORIGIN             mandatory               mandatory
>          AS_PATH            mandatory               mandatory
>          NEXT_HOP           mandatory               mandatory
>          MULTI_EXIT_DISC    discretionary           discretionary
>          LOCAL_PREF         disallowed              required
>          ATOMIC_AGGREGATE   see section 5.1.6 and 9.1.4
>          AGGREGATOR         discretionary           discretionary
> 
> 
> 
> 
> 5.1 Path Attribute Usage
> 
> 
>    The usage of each BGP path attributes is described in the following
>    clauses.
> 
> 
> 
> 5.1.1 ORIGIN
> 
> 
>    ORIGIN is a well-known mandatory attribute.  The ORIGIN attribute
>    shall be generated by the autonomous system that originates the
>    associated routing information. It shall be included in the UPDATE
>    messages of all BGP speakers that choose to propagate this
>    information to other BGP speakers.
> 
> 
> 5.1.2 AS_PATH
> 
> 
>    AS_PATH is a well-known mandatory attribute. This attribute
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 21]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    identifies the autonomous systems through which routing information
>    carried in this UPDATE message has passed. The components of this
>    list can be AS_SETs or AS_SEQUENCEs.
> 
>    When a BGP speaker propagates a route which it has learned from
>    another BGP speaker's UPDATE message, it shall modify the route's
>    AS_PATH attribute based on the location of the BGP speaker to which
>    the route will be sent:
> 
>       a) When a given BGP speaker advertises the route to an internal
>       peer, the advertising speaker shall not modify the AS_PATH
>       attribute associated with the route.
> 
>       b) When a given BGP speaker advertises the route to an external
>       peer, then the advertising speaker shall update the AS_PATH
>       attribute as follows:
> 
>          1) if the first path segment of the AS_PATH is of type
>          AS_SEQUENCE, the local system shall prepend its own AS number
>          as the last element of the sequence (put it in the leftmost
>          position). If the act of prepending will cause an overflow in
>          the AS_PATH segment, i.e. more than 255 elements, it shall be
>          legal to prepend a new segment of type AS_SEQUENCE and prepend
>          its own AS number to this new segment.
> 
>          2) if the first path segment of the AS_PATH is of type AS_SET,
>          the local system shall prepend a new path segment of type
>          AS_SEQUENCE to the AS_PATH, including its own AS number in =
> that
>          segment.
> 
>    When a BGP speaker originates a route then:
> 
>       a) the originating speaker shall include its own AS number in a
>       path segment of type AS_SEQUENCE in the AS_PATH attribute of all
>       UPDATE messages sent to an external peer. (In this case, the AS
>       number of the originating speaker's autonomous system will be the
>       only entry the path segment, and this path segment will be the
>       only segment in the AS_PATH attribute).
> 
>       b) the originating speaker shall include an empty AS_PATH
>       attribute in all UPDATE messages sent to internal peers.  (An
>       empty AS_PATH attribute is one whose length field contains the
>       value zero).
> 
>    Whenever the modification of the AS_PATH attribute calls for
>    including or prepending the AS number of the local system, the local
>    system may include/prepend more than one instance of its own AS
>    number in the AS_PATH attribute. This is controlled via local
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 22]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    configuration.
> 
> 
> 5.1.3 NEXT_HOP
> 
> 
> 
>    The NEXT_HOP path attribute defines the IP address of the border
>    router that should be used as the next hop to the destinations =
> listed
>    in the UPDATE message. The NEXT_HOP attribute is calculated as
>    follows.
> 
>       1) When sending a message to an internal peer, the BGP speaker
>       should not modify the NEXT_HOP attribute, unless it has been
>       explicitly configured to announce its own IP address as the
>       NEXT_HOP.
> 
>       2) When sending a message to an external peer X, and the peer is
>       one IP hop away from the speaker:
> 
>          - If the route being announced was learned from an internal
>          peer or is locally originated, the BGP speaker can use for the
>          NEXT_HOP attribute an interface address of the internal peer
>          router (or the internal router) through which the announced
>          network is reachable for the speaker, provided that peer X
>          shares a common subnet with this address. This is a form of
>          "third party" NEXT_HOP attribute.
> 
>          - If the route being announced was learned from an external
>          peer, the speaker can use in the NEXT_HOP attribute an IP
>          address of any adjacent router (known from the received
>          NEXT_HOP attribute) that the speaker itself uses for local
>          route calculation, provided that peer X shares a common subnet
>          with this address. This is a second form of "third party"
>          NEXT_HOP attribute.
> 
>          - If the external peer to which the route is being advertised
>          shares a common subnet with one of the announcing router's own
>          interfaces, the router may use the IP address associated with
>          such an interface in the NEXT_HOP attribute. This is known as =
> a
>          "first party" NEXT_HOP attribute.
> 
>          - By default (if none of the above conditions apply), the BGP
>          speaker should use in the NEXT_HOP attribute the IP address of
>          the interface that the speaker uses to establish the BGP
>          session to peer X.
> 
>       3) When sending a message to an external peer X, and the peer is
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 23]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>       multiple IP hops away from the speaker (aka "multihop EBGP"):
> 
>          - The speaker may be configured to propagate the NEXT_HOP
>          attribute.  In this case when advertising a route that the
>          speaker learned from one of its peers, the NEXT_HOP attribute
>          of the advertised route is exactly the same as the NEXT_HOP
>          attribute of the learned route (the speaker just doesn't =
> modify
>          the NEXT_HOP attribute).
> 
>          - By default, the BGP speaker should use in the NEXT_HOP
>          attribute the IP address of the interface that the speaker =
> uses
>          to establish the BGP session to peer X.
> 
>    Normally the NEXT_HOP attribute is chosen such that the shortest
>    available path will be taken. A BGP speaker must be able to support
>    disabling advertisement of third party NEXT_HOP attributes to handle
>    imperfectly bridged media.
> 
>    A BGP speaker must never advertise an address of a peer to that peer
>    as a NEXT_HOP, for a route that the speaker is originating. A BGP
>    speaker must never install a route with itself as the next hop.
> 
>    The NEXT_HOP attribute is used by the BGP speaker to determine the
>    actual outbound interface and immediate next-hop address that should
>    be used to forward transit packets to the associated destinations.
>    The immediate next-hop address is determined by performing a
>    recursive route lookup operation for the IP address in the NEXT_HOP
>    attribute using the contents of the Routing Table (see Section
>    9.1.2.2). The resolving route will always specify the outbound
>    interface. If the resolving route specifies the next-hop address,
>    this address should be used as the immediate address for packet
>    forwarding. If the address in the NEXT_HOP attribute is directly
>    resolved through a route to an attached subnet (such a route will =
> not
>    specify the next-hop address), the outbound interface should be =
> taken
>    from the resolving route and the address in the NEXT_HOP attribute
>    should be used as the immediate next-hop address.
> 
> 
> 5.1.4 MULTI_EXIT_DISC
> 
> 
>    The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
>    links to discriminate among multiple exit or entry points to the =
> same
>    neighboring AS. The value of the MULTI_EXIT_DISC attribute is a four
>    octet unsigned number which is called a metric. All other factors
>    being equal, the exit point with lower metric should be preferred. =
> If
>    received over external links, the MULTI_EXIT_DISC attribute MAY be
>    propagated over internal links to other BGP speakers within the same
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 24]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    AS. The MULTI_EXIT_DISC attribute received from a neighboring AS =
MUST
>    NOT be propagated to other neighboring ASs.
> 
>    A BGP speaker MUST IMPLEMENT a mechanism based on local =
> configuration
>    which allows the MULTI_EXIT_DISC attribute to be removed from a
>    route. This MAY be done prior to determining the degree of =
> preference
>    of the route and performing route selection (decision process phases
>    1 and 2).
> 
>    An implementation MAY also (based on local configuration) alter the
>    value of the MULTI_EXIT_DISC attribute received over an external
>    link.  If it does so, it shall do so prior to determining the degree
>    of preference of the route and performing route selection (decision
>    process phases 1 and 2).
> 
> 
> 5.1.5 LOCAL_PREF
> 
> 
>    LOCAL_PREF is a well-known attribute that SHALL be included in all
>    UPDATE messages that a given BGP speaker sends to the other internal
>    peers. A BGP speaker SHALL calculate the degree of preference for
>    each external route based on the locally configured policy, and
>    include the degree of preference when advertising a route to its
>    internal peers. The higher degree of preference MUST be preferred.  =
> A
>    BGP speaker shall use the degree of preference learned via =
> LOCAL_PREF
>    in its decision process (see section 9.1.1).
> 
>    A BGP speaker MUST NOT include this attribute in UPDATE messages =
> that
>    it sends to external peers, except for the case of BGP =
> Confederations
>    [13]. If it is contained in an UPDATE message that is received from
>    an external peer, then this attribute MUST be ignored by the
>    receiving speaker, except for the case of BGP Confederations [13].
> 
> 
> 5.1.6 ATOMIC_AGGREGATE
> 
> 
>    ATOMIC_AGGREGATE is a well-known discretionary attribute.
> 
>    When a router aggregates several routes for the purpose of
>    advertisement to a particular peer, and the AS_PATH of the =
> aggregated
>    route excludes at least some of the AS numbers present in the =
> AS_PATH
>    of the routes that are aggregated, the aggregated route, when
>    advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.
> 
>    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
>    attribute MUST NOT remove the attribute from the route when
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 25]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    propagating it to other speakers.
> 
>    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
>    attribute MUST NOT make any NLRI of that route more specific (as
>    defined in 9.1.4) when advertising this route to other BGP speakers.

>    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
>    attribute needs to be cognizant of the fact that the actual path to
>    destinations, as specified in the NLRI of the route, while having =
> the
>    loop-free property, may not be the path specified in the AS_PATH
>    attribute of the route.
> 
> 
> 5.1.7 AGGREGATOR
> 
> 
>    AGGREGATOR is an optional transitive attribute which may be included
>    in updates which are formed by aggregation (see Section 9.2.2.2). A
>    BGP speaker which performs route aggregation may add the AGGREGATOR
>    attribute which shall contain its own AS number and IP address. The
>    IP address should be the same as the BGP Identifier of the speaker.
> 
> 
> 6. BGP Error Handling.
> 
> 
>    This section describes actions to be taken when errors are detected
>    while processing BGP messages.
> 
>    When any of the conditions described here are detected, a
>    NOTIFICATION message with the indicated Error Code, Error Subcode,
>    and Data fields is sent, and the BGP connection is closed. If no
>    Error Subcode is specified, then a zero must be used.
> 
>    The phrase "the BGP connection is closed" means that the transport
>    protocol connection has been closed, the associated Adj-RIB-In has
>    been cleared, and that all resources for that BGP connection have
>    been deallocated. Entries in the Loc-RIB associated with the remote
>    peer are marked as invalid. The fact that the routes have become
>    invalid is passed to other BGP peers before the routes are deleted
>    from the system.
> 
>    Unless specified explicitly, the Data field of the NOTIFICATION
>    message that is sent to indicate an error is empty.
> 
> 
> 
> 
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 26]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
> 6.1 Message Header error handling.
> 
> 
>    All errors detected while processing the Message Header are =
> indicated
>    by sending the NOTIFICATION message with Error Code Message Header
>    Error. The Error Subcode elaborates on the specific nature of the
>    error.
> 
>    The expected value of the Marker field of the message header is all
>    ones if the message type is OPEN. The expected value of the Marker
>    field for all other types of BGP messages determined based on the
>    presence of the Authentication Information Optional Parameter in the
>    BGP OPEN message and the actual authentication mechanism (if the
>    Authentication Information in the BGP OPEN message is present). The
>    Marker field should be all ones if the OPEN message carried no
>    authentication information. If the Marker field of the message =
> header
>    is not the expected one, then a synchronization error has occurred
>    and the Error Subcode is set to Connection Not Synchronized.
> 
>    If the Length field of the message header is less than 19 or greater
>    than 4096, or if the Length field of an OPEN message is less than =
> the
>    minimum length of the OPEN message, or if the Length field of an
>    UPDATE message is less than the minimum length of the UPDATE =
> message,
>    or if the Length field of a KEEPALIVE message is not equal to 19, or
>    if the Length field of a NOTIFICATION message is less than the
>    minimum length of the NOTIFICATION message, then the Error Subcode =
> is
>    set to Bad Message Length. The Data field contains the erroneous
>    Length field.
> 
>    If the Type field of the message header is not recognized, then the
>    Error Subcode is set to Bad Message Type. The Data field contains =
> the
>    erroneous Type field.
> 
> 
> 6.2 OPEN message error handling.
> 
> 
>    All errors detected while processing the OPEN message are indicated
>    by sending the NOTIFICATION message with Error Code OPEN Message
>    Error. The Error Subcode elaborates on the specific nature of the
>    error.
> 
>    If the version number contained in the Version field of the received
>    OPEN message is not supported, then the Error Subcode is set to
>    Unsupported Version Number. The Data field is a 2-octets unsigned
>    integer, which indicates the largest locally supported version =
> number
>    less than the version the remote BGP peer bid (as indicated in the
>    received OPEN message), or if the smallest locally supported version
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 27]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    number is greater than the version the remote BGP peer bid, then the
>    smallest locally supported version number.
> 
>    If the Autonomous System field of the OPEN message is unacceptable,
>    then the Error Subcode is set to Bad Peer AS. The determination of
>    acceptable Autonomous System numbers is outside the scope of this
>    protocol.
> 
>    If the Hold Time field of the OPEN message is unacceptable, then the
>    Error Subcode MUST be set to Unacceptable Hold Time. An
>    implementation MUST reject Hold Time values of one or two seconds.
>    An implementation MAY reject any proposed Hold Time. An
>    implementation which accepts a Hold Time MUST use the negotiated
>    value for the Hold Time.
> 
>    If the BGP Identifier field of the OPEN message is syntactically
>    incorrect, then the Error Subcode is set to Bad BGP Identifier.
>    Syntactic correctness means that the BGP Identifier field represents
>    a valid IP host address.
> 
>    If one of the Optional Parameters in the OPEN message is not
>    recognized, then the Error Subcode is set to Unsupported Optional
>    Parameters.
> 
>    If one of the Optional Parameters in the OPEN message is recognized,
>    but is malformed, then the Error Subcode is set to 0 (Unspecific).
> 
> 
>    If the OPEN message carries Authentication Information (as an
>    Optional Parameter), then the corresponding authentication procedure
>    is invoked. If the authentication procedure (based on Authentication
>    Code and Authentication Data) fails, then the Error Subcode is set =
> to
>    Authentication Failure.
> 
> 
> 
> 6.3 UPDATE message error handling.
> 
> 
>    All errors detected while processing the UPDATE message are =
> indicated
>    by sending the NOTIFICATION message with Error Code UPDATE Message
>    Error. The error subcode elaborates on the specific nature of the
>    error.
> 
>    Error checking of an UPDATE message begins by examining the path
>    attributes. If the Withdrawn Routes Length or Total Attribute Length
>    is too large (i.e., if Withdrawn Routes Length + Total Attribute
>    Length + 23 exceeds the message Length), then the Error Subcode is
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 28]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    set to Malformed Attribute List.
> 
>    If any recognized attribute has Attribute Flags that conflict with
>    the Attribute Type Code, then the Error Subcode is set to Attribute
>    Flags Error. The Data field contains the erroneous attribute (type,
>    length and value).
> 
>    If any recognized attribute has Attribute Length that conflicts with
>    the expected length (based on the attribute type code), then the
>    Error Subcode is set to Attribute Length Error. The Data field
>    contains the erroneous attribute (type, length and value).
> 
>    If any of the mandatory well-known attributes are not present, then
>    the Error Subcode is set to Missing Well-known Attribute. The Data
>    field contains the Attribute Type Code of the missing well-known
>    attribute.
> 
>    If any of the mandatory well-known attributes are not recognized,
>    then the Error Subcode is set to Unrecognized Well-known Attribute.
>    The Data field contains the unrecognized attribute (type, length and
>    value).
> 
>    If the ORIGIN attribute has an undefined value, then the Error
>    Subcode is set to Invalid Origin Attribute. The Data field contains
>    the unrecognized attribute (type, length and value).
> 
>    If the NEXT_HOP attribute field is syntactically incorrect, then the
>    Error Subcode is set to Invalid NEXT_HOP Attribute.  The Data field
>    contains the incorrect attribute (type, length and value).  =
> Syntactic
>    correctness means that the NEXT_HOP attribute represents a valid IP
>    host address.  Semantic correctness applies only to the external BGP
>    links, and only when the sender and the receiving speaker are one IP
>    hop away from each other. To be semantically correct, the IP address
>    in the NEXT_HOP must not be the IP address of the receiving speaker,
>    and the NEXT_HOP IP address must either be the sender's IP address
>    (used to establish the BGP session), or the interface associated =
> with
>    the NEXT_HOP IP address must share a common subnet with the =
> receiving
>    BGP speaker. If the NEXT_HOP attribute is semantically incorrect, =
> the
>    error should be logged, and the route should be ignored. In this
>    case, no NOTIFICATION message should be sent.
> 
>    The AS_PATH attribute is checked for syntactic correctness. If the
>    path is syntactically incorrect, then the Error Subcode is set to
>    Malformed AS_PATH.
> 
> 
>    The information carried by the AS_PATH attribute is checked for AS
>    loops. AS loop detection is done by scanning the full AS path (as
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 29]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    specified in the AS_PATH attribute), and checking that the =
> autonomous
>    system number of the local system does not appear in the AS path. If
>    the autonomous system number appears in the AS path the route may be
>    stored in the Adj-RIB-In, but unless the router is configured to
>    accept routes with its own autonomous system in the AS path, the
>    route shall not be passed to the BGP Decision Process.  Operations =
> of
>    a router that is configured to accept routes with its own autonomous
>    system number in the AS path are outside the scope of this document.
> 
>    If an optional attribute is recognized, then the value of this
>    attribute is checked. If an error is detected, the attribute is
>    discarded, and the Error Subcode is set to Optional Attribute Error.
>    The Data field contains the attribute (type, length and value).
> 
>    If any attribute appears more than once in the UPDATE message, then
>    the Error Subcode is set to Malformed Attribute List.
> 
>    The NLRI field in the UPDATE message is checked for syntactic
>    validity. If the field is syntactically incorrect, then the Error
>    Subcode is set to Invalid Network Field.
> 
>    If a prefix in the NLRI field is semantically incorrect (e.g., an
>    unexpected multicast IP address), an error should be logged locally,
>    and the prefix should be ignored.
> 
>    An UPDATE message that contains correct path attributes, but no =
> NLRI,
>    shall be treated as a valid UPDATE message.
> 
> 
> 6.4 NOTIFICATION message error handling.
> 
> 
>    If a peer sends a NOTIFICATION message, and there is an error in =
> that
>    message, there is unfortunately no means of reporting this error via
>    a subsequent NOTIFICATION message. Any such error, such as an
>    unrecognized Error Code or Error Subcode, should be noticed, logged
>    locally, and brought to the attention of the administration of the
>    peer. The means to do this, however, lies outside the scope of this
>    document.
> 
> 
> 6.5 Hold Timer Expired error handling.
> 
> 
>    If a system does not receive successive KEEPALIVE and/or UPDATE
>    and/or NOTIFICATION messages within the period specified in the Hold
>    Time field of the OPEN message, then the NOTIFICATION message with
>    Hold Timer Expired Error Code must be sent and the BGP connection
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 30]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    closed.
> 
> 
> 6.6 Finite State Machine error handling.
> 
> 
>    Any error detected by the BGP Finite State Machine (e.g., receipt of
>    an unexpected event) is indicated by sending the NOTIFICATION =
> message
>    with Error Code Finite State Machine Error.
> 
> 
> 6.7 Cease.
> 
> 
>    In absence of any fatal errors (that are indicated in this section),
>    a BGP peer may choose at any given time to close its BGP connection
>    by sending the NOTIFICATION message with Error Code Cease. However,
>    the Cease NOTIFICATION message must not be used when a fatal error
>    indicated by this section does exist.
> 
>    A BGP speaker may support the ability to impose an (locally
>    configured) upper bound on the number of address prefixes the =
> speaker
>    is willing to accept from a neighbor. When the upper bound is
>    reached, the speaker (under control of local configuration) may
>    either (a) discard new address prefixes from the neighbor, or (b)
>    terminate the BGP peering with the neighbor. If the BGP speaker
>    decides to terminate its peering with a neighbor because the number
>    of address prefixes received from the neighbor exceeds the locally
>    configured upper bound, then the speaker must send to the neighbor a
>    NOTIFICATION message with the Error Code Cease.
> 
> 
> 6.8 Connection collision detection.
> 
> 
>    If a pair of BGP speakers try simultaneously to establish a BGP
>    connection to each other, then two parallel connections between this
>    pair of speakers might well be formed. If the source IP address used
>    by one of these connections is the same as the destination IP =
> address
>    used by the other, and the destination IP address used by the first
>    connection is the same as the source IP address used by the other, =
> we
>    refer to this situation as connection collision.  Clearly in the
>    presence of connection collision, one of these connections must be
>    closed.
> 
>    Based on the value of the BGP Identifier a convention is established
>    for detecting which BGP connection is to be preserved when a
>    collision does occur. The convention is to compare the BGP
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 31]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    Identifiers of the peers involved in the collision and to retain =
> only
>    the connection initiated by the BGP speaker with the higher-valued
>    BGP Identifier.
> 
>    Upon receipt of an OPEN message, the local system must examine all =
> of
>    its connections that are in the OpenConfirm state. A BGP speaker may
>    also examine connections in an OpenSent state if it knows the BGP
>    Identifier of the peer by means outside of the protocol. If among
>    these connections there is a connection to a remote BGP speaker =
> whose
>    BGP Identifier equals the one in the OPEN message, and this
>    connection collides with the connection over which the OPEN message
>    is received then the local system performs the following collision
>    resolution procedure:
> 
> 
>       1. The BGP Identifier of the local system is compared to the BGP
>       Identifier of the remote system (as specified in the OPEN
>       message).
> 
>       2. If the value of the local BGP Identifier is less than the
>       remote one, the local system closes BGP connection that already
>       exists (the one that is already in the OpenConfirm state), and
>       accepts BGP connection initiated by the remote system.
> 
>       3. Otherwise, the local system closes newly created BGP =
> connection
>       (the one associated with the newly received OPEN message), and
>       continues to use the existing one (the one that is already in the
>       OpenConfirm state).
> 
>       Comparing BGP Identifiers is done by treating them as (4-octet
>       long) unsigned integers.
> 
>       Unless allowed via configuration, a connection collision with an
>       existing BGP connection that is in Established state causes
>       closing of the newly created connection.
> 
>       Note that a connection collision cannot be detected with
>       connections that are in Idle, or Connect, or Active states.
> 
>       Closing the BGP connection (that results from the collision
>       resolution procedure) is accomplished by sending the NOTIFICATION
>       message with the Error Code Cease.
> 
> 
> 7. BGP Version Negotiation.
> 
> 
>    BGP speakers may negotiate the version of the protocol by making
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 32]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    multiple attempts to open a BGP connection, starting with the =
> highest
>    version number each supports. If an open attempt fails with an Error
>    Code OPEN Message Error, and an Error Subcode Unsupported Version
>    Number, then the BGP speaker has available the version number it
>    tried, the version number its peer tried, the version number passed
>    by its peer in the NOTIFICATION message, and the version numbers =
> that
>    it supports. If the two peers do support one or more common =
> versions,
>    then this will allow them to rapidly determine the highest common
>    version. In order to support BGP version negotiation, future =
> versions
>    of BGP must retain the format of the OPEN and NOTIFICATION messages.
> 
> 
> 8. BGP Finite State machine.
> 
> 
>    This section specifies BGP operation in terms of a Finite State
>    Machine (FSM). Following is a brief summary and overview of BGP
>    operations by state as determined by this FSM.
> 
>    Initially BGP is in the Idle state.
> 
>       Idle state:
> 
>          A manual start event is a start event initiated by an =
> operator.
>          An automatic start event is a start event generated by the
>          system.
> 
>          In this state BGP refuses all incoming BGP connections.  No
>          resources are allocated to the peer.    In response to a Start
>          event (manual or automatic), the local system:
> 
>             - initializes all BGP resources,
> 
>             - starts the ConnectRetry timer,
> 
>             - initiates a transport connection to the other BGP peer,
> 
>             - listens for a connection that may be initiated by the
>             remote BGP peer, and
> 
>             - changes its state to connect.
> 
>          The exact value of the ConnectRetry timer is a local matter,
>          but it should be sufficiently large to allow TCP
>          initialization.
> 
>          Any other event received in the IDLE state, is ignored.
> 
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 33]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>       IdleHold state:
> 
>          The IdleHold state keeps the system in "Idle" mode until a
>          certain time period has passed or an operator intervenes to
>          manually restart the connection.  This "IdleHold timeout"
>          prevents persistent flapping of a BGP peering session.
> 
>          Upon entering the Idle Hold state, if the IdleHoldTimer =
> exceeds
>          the local limit the "Keep Idle" flag is set.
> 
>          Upon receiving a Manual start, the local system:
> 
>             - clears the IdleHoldtimer,
> 
>             - clears "keep Idle" flag
> 
>             - initializes all BGP resources,
> 
>             - starts the ConnectRetry timer,
> 
>             - initiates a transport connection to the other BGP peer,
> 
>             - listens for a connection that may be initiated by the
>             remote BGPPeer, and
> 
>             - changes its state to connect.
> 
>          Upon receiving a IdleHoldtimer expired event, the local system
>          checks to see that the Keep Idle flag is set.  If the Keep =
> Idle
>          flag is set, the system stays in the "Idle Hold" state.
> 
>          If the Keep Idle flag is not set, the local system:
> 
>             - clears the IdleHoldtimer,
> 
>             - and transitions the state to Idle.
> 
>          Getting out of the IdleHoldstate requires either operator
>          intervention via a manual start or the IdleHoldtimer to expire
>          with the "Keep Idle" flag to be clear.
> 
>          Any other event received in the IdleHold state is ignored.
> 
>       Connect State:
> 
>          In this state, BGP is waiting for the transport protocol
>          connection to be completed.
> 
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 34]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>          If the transport connection succeeds, the local system:
> 
>             - clears the ConnectRetry timer,
> 
>             - completes initialization,
> 
>             - send an Open message to its peer,
> 
>             - set Hold timer to a large value,  and
> 
>             - changes its state to Open Sent.
> 
>          A hold timer value of 4 minutes is suggested.
> 
>          If the transport protocol connection fails (e.g.,
>          retransmission timeout), the local system:
> 
>             - restarts the ConnectRetry timer,
> 
>             - continues to listen for a connection that may be =
> initiated
>             by the remote BGP peer, and
> 
>             - changes its state to Active.
> 
>          In response to the ConnectRetry timer expired event, the local
>          system:
> 
>             - restarts the ConnectRetry timer,
> 
>             - initiates a transport connection to the other BGP peer,
> 
>             - continues to listen for a connection that may be =
> initiated
>             by the remote BGP peer, and
> 
>             - stays in Connect state.
> 
>          The start event (manual or automatic) is ignored in the =
> Connect
>          state.
> 
>          In response to any other event (initiated by the system or
>          operator), the local system:
> 
>             - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> 
>             - Increment ConnectRetryCnt by 1,
> 
>             - Set connect retry timer to zero,
> 
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 35]
> 
> 
> 
> 
> 
RFC DRAFT                                                   January =
> 2002
> 
> 
>             - Drops TCP connection,
> 
>             - Releases all BGP resources, and
> 
>             - Goes to IdleHoldstate
> 
>       Active State:
> 
>          In this state BGP is trying to acquire a peer by listening for
>          and accepting a transport protocol connection.
> 
>          If the transport connection succeeds, the local system:
> 
>             - clears the ConnectRetry timer,
> 
>             - completes the initialization,
> 
>             - sends the Open message to it's peer,
> 
>             - sets its Hold timer to a large value,
> 
>             - and changes its state to OpenSent.
> 
>          A Hold timer value of 4 minutes is suggested.
> 
>          In response the ConnectRetry timer expired event, the local
>          system:
> 
>             - restarts the ConnectRetry timer,
> 
>             - initiates a transport connection to the other BGP peer,
> 
>             - continues to listen for connection that may be initiated
>             by remote BGP peer,
> 
>             - and changes its state to Connect.
> 
>          If the local system does not allow BGP connections with
>          unconfigured peers, then the local system:
> 
>             - rejects connections from IP addresses that are not
>             configured peers,
> 
>             - and remains in the Active state.
> 
>          The start events (initiated by the system or operator) are
>          ignored in the Active state.
> 
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 36]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>          In response to any other event (initiated by the system or
>          operator), the local system:
> 
>             - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> 
>             - Increment ConnectRetryCnt by 1,
> 
>             - Set connect retry timer to zero, and
> 
>             - Drops TCP connection,
> 
>             - Releases all BGP resources,
> 
>             - Goes to IdleHold state.
> 
>       Open Sent:
> 
>          In this state BGP waits for an Open Message from its peer.
>          When an OPEN message is received, all fields are check for
>          correctness.  If the BGP message header checking or OPEN
>          message check detects an error (see Section 6.2), or a
>          connection collision (see Section 6.8) the local system:
> 
>             - sends a NOTIFICATION message
> 
>             - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> 
>             - Increment ConnectRetryCnt by 1,
> 
>             - Set connect retry timer to zero, and
> 
>             - Drops TCP connection,
> 
>             - Releases all BGP resources,
> 
>             - Goes to IdleHold state.
> 
>          If there are no errors in the OPEN message, the local system:
> 
>             - sends a KEEPALIVE message and
> 
>             - sets a KeepAlive timer (via the text below)
> 
>             - set the Hold timer according to the negotiated value (see
>             section 4.2),
> 
>             - set the state to Open Confirm.
> 
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 37]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>          If the negotiated Hold time value is zero, then the Hold Time
>          timer and KeepAlive timers are not started.   If the value of
>          the Autonomous System field is the same as the local =
> Autonomous
>          System number, then the connection is an "internal" =
> connection;
>          otherwise, it is an "external" connection.   (This will impact
>          UPDATE processing as described below.)
> 
>          If a disconnect NOTIFICATION is received from the underlying
>          transport protocol, the local system:
> 
>             - closes the BGP connection,
> 
>             - restarts the Connect Retry timer,
> 
>             - and continues to listen for a connection that may be
>             initiated by the remote BGP peer, and goes into Active
>             state.
> 
>          If the Hold Timer expires, the local system:
> 
>             - send a NOTIFICATION message with error code Hold Timer
>             Expired,
> 
>             - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> 
>             - Increment ConnectRetryCnt by 1,
> 
>             - Set connect retry timer to zero, and
> 
>             - Drops TCP connection,
> 
>             - Releases all BGP resources, and
> 
>             - Goes to IdleHold state.
> 
>          The Start event (manual and automatic) is ignored in the
>          OpenSent state.
> 
>          If a NOTIFICATION message is received with a version error, =
> the
>          local system:
> 
>             - Closes the transport connection
> 
>             - Releases BGP resources,
> 
>             - ConnectRetryCnt =3D 0,
> 
>             - Connect retry timer =3D 0, and
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 38]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>             - transition to Idle state.
> 
>          If any other NOTIFICATION is received, the local system:
> 
>             - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> 
>             - Increment ConnectRetryCnt by 1,
> 
>             - Set connect retry timer to zero, and
> 
>             - Drops TCP connection,
> 
>             - Releases all BGP resources,
> 
>             - Goes to IdleHold state.
> 
>          In response to any other event, the local system:
> 
>             - sends the NOTFICATION message with Error Code Finite =
> State
>             Machine  Error,
> 
>             - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> 
>             - Increment ConnectRetryCnt by 1,
> 
>             - Set connect retry timer to zero,
> 
>             - Drops TCP connection,
> 
>             - Releases all BGP resources, and
> 
>             - Goes to IdleHold state.
> 
>       Open Confirm State
> 
>          In this state BGP waits for a KEEPALIVE or NOTIFICATION
>          message.
> 
>          If the local system receives a KEEPALIVE message, it changes
>          its state to Established.
> 
>          If the Hold Timer expires before a KEEPALIVE message is
>          received, the local system:
> 
>             - send the NOTIFICATION message with the error code Hold
>             Timer Expired,
> 
>             - sets IdleHoldTimer =3D 2**(ConnectRetryCnt)*60
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 39]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>             - Increments ConnectRetryCnt by 1,
> 
>             - Sets the connect retry timer to zero,
> 
>             - Drop the TCP connection,
> 
>             - Releases all BGP resources,
> 
>             - Goes to IdleHoldState.
> 
>          If the local system receives a NOTIFICATION message or =
> receives
>          a disconnect NOTIFICATION from the underlying transport
>          protocol, the local system:
> 
>             - Sets IdleHold Timer =3D 2**(ConnectRetryCnt)*60
> 
>             - Increments ConnectRetryCnt by 1,
> 
>             - Sets the connect retry timer to zero,
> 
>             - Drops the TCP connection,
> 
>             - Releases all BGP resources,
> 
>             - Goes to IdleHoldstate.
> 
>          In response to the Stop event initiated by the system, the
>          local system:
> 
>             - sends the NOTIFICATION message with Cease,
> 
>             - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> 
>             - Increments ConnectRetryCnt by 1,
> 
>             - Sets the Connect retry timer to zero,
> 
>             - Drops the TCP connection,
> 
>             - Releases all BGP resources,
> 
>             - Goes to IdleHoldstate.
> 
> 
>          In response to a Stop event initiated by the operator, the
>          local system:
> 
>             - sends the NOTIFICATION message with Cease,
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 40]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>             - releases all BGP resources
> 
>             - sets the ConnectRetryCnt to zero
> 
>             - sets the connect retry timer to 0
> 
>             - transitions to Idle state.
> 
>          The Start event is ignored in the OpenConfirm state.
> 
>          In response to any other event, the local system:
> 
>             - sends a NOTIFICATION with a code of Finite State Machine
>             Error,
> 
>             - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> 
>             - Increments ConnectRetryCnt by 1,
> 
>             - Sets the Connect retry timer to zero,
> 
>             - Drops the TCP connection,
> 
>             - Releases all BGP resources,
> 
>             - Goes to IdleHoldstate.
> 
>       Established State:
> 
>          In the Established state BGP can exchange UPDATE, NOTFICATION,
>          and KEEPALIVE messages with its peer.
> 
>          If the local system receives an UPDATE or KEEPALIVE message, =
> it
>          restarts its Hold Timer, if the negotiated Hold Time value is
>          non-zero.
> 
>          If the local system receives a NOTIFICATION message or a
>          disconnect from the underlying transport protocol, it:
> 
>             - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60,
> 
>             - Increments ConnectRetryCnt by 1,
> 
>             - Sets the Connect retry timer to zero,
> 
>             - Drops the TCP connection,
> 
>             - Releases all BGP resources, and
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 41]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>             - Goes to IdleHoldstate.
> 
>          If the local system receives an UPDATE message, and the Update
>          message error handling procedure (see Section 6.3) detecs an
>          error, the local system:
> 
>             - sends a NOTIFICATION message with Update error,
> 
>             - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> 
>             - Increments ConnectRetryCnt by 1,
> 
>             - Sets the Connect retry timer to zero,
> 
>             - Drops the TCP connection,
> 
>             - Releases all BGP resources, and
> 
>             - Goes to IdleHoldstate.
> 
>          If the Hold timer expires, the local system:
> 
>             - sends a NOTIFICATION message with Error Code Hold Timer
>             Expired,
> 
>             - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> 
>             - Increments ConnectRetryCnt by 1,
> 
>             - Sets the connect retry timer to zero,
> 
>             - Drops the TCP connection,
> 
>             - Releases all BGP resources,
> 
>             - Goes to IdleHold state.
> 
>          If the KeepAlive timer expires, the local system sends a
>          KEEPALIVE message, it restarts its KeepAlive timer, unless the
>          negotiated Hold Time value is zero.
> 
>          Each time time the local system sends a KEEPALIVE or UPDATE
>          message, it restarts its KeepAlive timer, unless the =
> negotiated
>          Hold Time value is zero.
> 
>          In response to the Stop event initiated by the system
>          (automatic), the local system:
> 
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 42]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>             - sends a NOTIFICATION with Cease,
> 
>             - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> 
>             - increments ConnectRetryCnt by 1,
> 
>             - sets the connect retry timer to zero,
> 
>             - drops the TCP connection,
> 
>             - releases all BGP resources,
> 
>             - goes to IdleHold state, and
> 
>             - deletes all routes.
> 
>          An example automatic stop event is exceeding the number of
>          prefixes for a given peer and the local system automatically
>          disconnecting the peer.
> 
>          In response to a stop event initiated by an operator:
> 
>             - release all resources (including deleting all routes),
> 
>             - set ConnectRetryCnt to zero (0),
> 
>             - set connect retry timer to zero (0), and
> 
>             - transition to the Idle.
> 
>          The Start event is ignored in the Established state.
> 
>          In response to any other event, the local system:
> 
>             - sends a NOTIFICATION message with Error Code Finite State
>             Machine Error,
> 
>             - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60
> 
>             - increments ConnectRetryCnt by 1,
> 
>             - sets the connect retry timer to zero,
> 
>             - drops the TCP connection,
> 
>             - releases all BGP resources
> 
>             - goes to IdleHoldstate, and
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 43]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>             - deletes all routes.
> 
> 
> 9. UPDATE Message Handling
> 
> 
>    An UPDATE message may be received only in the Established state.
>    When an UPDATE message is received, each field is checked for
>    validity as specified in Section 6.3.
> 
>    If an optional non-transitive attribute is unrecognized, it is
>    quietly ignored. If an optional transitive attribute is =
> unrecognized,
>    the Partial bit (the third high-order bit) in the attribute flags
>    octet is set to 1, and the attribute is retained for propagation to
>    other BGP speakers.
> 
>    If an optional attribute is recognized, and has a valid value, then,
>    depending on the type of the optional attribute, it is processed
>    locally, retained, and updated, if necessary, for possible
>    propagation to other BGP speakers.
> 
>    If the UPDATE message contains a non-empty WITHDRAWN ROUTES field,
>    the previously advertised routes whose destinations (expressed as IP
>    prefixes) contained in this field shall be removed from the Adj-RIB-
>    In.  This BGP speaker shall run its Decision Process since the
>    previously advertised route is no longer available for use.
> 
>    If the UPDATE message contains a feasible route, the Adj-RIB-In will
>    be updated with this route as follows: if the NLRI of the new route
>    is identical to the one of the route currently stored in the =
> Adj-RIB-
>    In, then the new route shall replace the older route in the Adj-RIB-
>    In, thus implicitly withdrawing the older route from service.
>    Otherwise, if the Adj-RIB-In has no route with NLRI identical to the
>    new route, the new route shall be placed in the Adj-RIB-In.
> 
>    Once the BGP speaker updates the Adj-RIB-In, the speaker shall run
>    its Decision Process.
> 
> 
> 9.1 Decision Process
> 
> 
>    The Decision Process selects routes for subsequent advertisement by
>    applying the policies in the local Policy Information Base (PIB) to
>    the routes stored in its Adj-RIBs-In. The output of the Decision
>    Process is the set of routes that will be advertised to all peers;
>    the selected routes will be stored in the local speaker's Adj-RIB-
>    Out.
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 44]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    The selection process is formalized by defining a function that =
> takes
>    the attribute of a given route as an argument and returns either (a)
>    a non-negative integer denoting the degree of preference for the
>    route, or (b) a value denoting that this route is ineligible to be
>    installed in LocRib and will be excluded from the next phase of =
> route
>    selection.
> 
>    The function that calculates the degree of preference for a given
>    route shall not use as its inputs any of the following: the =
> existence
>    of other routes, the non-existence of other routes, or the path
>    attributes of other routes. Route selection then consists of
>    individual application of the degree of preference function to each
>    feasible route, followed by the choice of the one with the highest
>    degree of preference.
> 
>    The Decision Process operates on routes contained in the Adj-RIB-In,
>    and is responsible for:
> 
>       - selection of routes to be used locally by the speaker
> 
>       - selection of routes to be advertised to other BGP peers
> 
>       - route aggregation and route information reduction
> 
>    The Decision Process takes place in three distinct phases, each
>    triggered by a different event:
> 
>       a) Phase 1 is responsible for calculating the degree of =
> preference
>       for each route received from a peer.
> 
>       b) Phase 2 is invoked on completion of phase 1. It is responsible
>       for choosing the best route out of all those available for each
>       distinct destination, and for installing each chosen route into
>       the Loc-RIB.
> 
>       c) Phase 3 is invoked after the Loc-RIB has been modified. It is
>       responsible for disseminating routes in the Loc-RIB to each peer,
>       according to the policies contained in the PIB. Route aggregation
>       and information reduction can optionally be performed within this
>       phase.
> 
> 
> 9.1.1 Phase 1: Calculation of Degree of Preference
> 
> 
>    The Phase 1 decision function shall be invoked whenever the local =
> BGP
>    speaker receives from a peer an UPDATE message that advertises a new
>    route, a replacement route, or withdrawn routes.
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 45]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    The Phase 1 decision function is a separate process which completes
>    when it has no further work to do.
> 
>    The Phase 1 decision function shall lock an Adj-RIB-In prior to
>    operating on any route contained within it, and shall unlock it =
> after
>    operating on all new or unfeasible routes contained within it.
> 
>    For each newly received or replacement feasible route, the local BGP
>    speaker shall determine a degree of preference as follows:
> 
>       If the route is learned from an internal peer, either the value =
> of
>       the LOCAL_PREF attribute shall be taken as the degree of
>       preference, or the local system may compute the degree of
>       preference of the route based on preconfigured policy =
> information.
>       Note that the latter (computing the degree of preference based on
>       preconfigured policy information) may result in formation of
>       persistent routing loops.
> 
>       If the route is learned from an external peer, then the local BGP
>       speaker computes the degree of preference based on preconfigured
>       policy information. If the return value indicates that the route
>       is ineligible, the route may not serve as an input to the next
>       phase of route selection; otherwise the return value is used as
>       the LOCAL_PREF value in any IBGP readvertisement.
> 
>       The exact nature of this policy information and the computation
>       involved is a local matter.
> 
> 
> 9.1.2 Phase 2: Route Selection
> 
> 
>    The Phase 2 decision function shall be invoked on completion of =
> Phase
>    1. The Phase 2 function is a separate process which completes when =
> it
>    has no further work to do. The Phase 2 process shall consider all
>    routes that are eligible in the Adj-RIBs-In.
> 
>    The Phase 2 decision function shall be blocked from running while =
> the
>    Phase 3 decision function is in process. The Phase 2 function shall
>    lock all Adj-RIBs-In prior to commencing its function, and shall
>    unlock them on completion.
> 
>    If the NEXT_HOP attribute of a BGP route depicts an address that is
>    not resolvable, or it would become unresolvable if the route was
>    installed in the routing table the BGP route should be excluded from
>    the Phase 2 decision function.
> 
>    It is critical that routers within an AS do not make conflicting
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 46]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    decisions regarding route selection that would cause forwarding =
> loops
>    to occur.
> 
>    For each set of destinations for which a feasible route exists in =
> the
>    Adj-RIBs-In, the local BGP speaker shall identify the route that =
> has:
> 
>       a) the highest degree of preference of any route to the same set
>       of destinations, or
> 
>       b) is the only route to that destination, or
> 
>       c) is selected as a result of the Phase 2 tie breaking rules
>       specified in 9.1.2.2.
> 
>    The local speaker SHALL then install that route in the Loc-RIB,
>    replacing any route to the same destination that is currently being
>    held in the Loc-RIB. If the new BGP route is installed in the =
> Routing
>    Table (as a result of the local policy decision), care must be taken
>    to ensure that invalid BGP routes to the same destination are =
> removed
>    from the Routing Table. Whether or not the new route replaces an
>    already existing non-BGP route in the routing table depends on the
>    policy configured on the BGP speaker.
> 
>    The local speaker MUST determine the immediate next hop to the
>    address depicted by the NEXT_HOP attribute of the selected route by
>    performing a best matching route lookup in the Routing Table and
>    selecting one of the possible paths (if multiple best paths to the
>    same prefix are available). If the route to the address depicted by
>    the NEXT_HOP attribute changes such that the immediate next hop or
>    the IGP cost to the NEXT_HOP (if the NEXT_HOP is resolved through an
>    IGP route) changes, route selection should be recalculated as
>    specified above.
> 
>    Notice that even though BGP routes do not have to be installed in =
> the
>    Routing Table with the immediate next hop(s), implementations must
>    take care that before any packets are forwarded along a BGP route,
>    its associated NEXT_HOP address is resolved to the immediate
>    (directly connected) next-hop address and this address (or multiple
>    addresses) is finally used for actual packet forwarding.
> 
>    Unresolvable routes SHALL be removed from the Loc-RIB and the =
> routing
>    table. However, corresponding unresolvable routes SHOULD be kept in
>    the Adj-RIBs-In.
> 
> 
> 
> 
> 
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 47]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
> 9.1.2.1 Route Resolvability Condition
> 
> 
>    As indicated in Section 9.1.2, BGP routers should exclude
>    unresolvable routes from the Phase 2 decision. This ensures that =
> only
>    valid routes are installed in Loc-RIB and the Routing Table.
> 
>    The route resolvability condition is defined as follows.
> 
>       1. A route Rte1, referencing only the intermediate network
>       address, is considered resolvable if the Routing Table contains =
> at
>       least one resolvable route Rte2 that matches Rte1's intermediate
>       network address and is not recursively resolved (directly or
>       indirectly) through Rte1. If multiple matching routes are
>       available, only the longest matching route should be considered.
> 
>       2. Routes referencing interfaces (with or without intermediate
>       addresses) are considered resolvable if the state of the
>       referenced interface is up and IP processing is enabled on this
>       interface.
> 
>    BGP routes do not refer to interfaces, but can be resolved through
>    the routes in the Routing Table that can be of both types. IGP =
> routes
>    and routes to directly connected networks are expected to specify =
> the
>    outbound interface.
> 
>    Note that a BGP route is considered unresolvable not only in
>    situations where the router's Routing Table contains no route
>    matching the BGP route's NEXT_HOP. Mutually recursive routes (routes
>    resolving each other or themselves), also fail the resolvability
>    check.
> 
>    It is also important that implementations do not consider feasible
>    routes that would become unresolvable if they were installed in the
>    Routing Table even if their NEXT_HOPs are resolvable using the
>    current contents of the Routing Table (an example of such routes
>    would be mutually recursive routes). This check ensures that a BGP
>    speaker does not install in the Routing Table routes that will be
>    removed and not used by the speaker. Therefore, in addition to local
>    Routing Table stability, this check also improves behavior of the
>    protocol in the network.
> 
>    Whenever a BGP speaker identifies a route that fails the
>    resolvability check because of mutual recursion, an error message
>    should be logged.
> 
> 
> 
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 48]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
> 9.1.2.2 Breaking Ties (Phase 2)
> 
> 
>    In its Adj-RIBs-In a BGP speaker may have several routes to the same
>    destination that have the same degree of preference. The local
>    speaker can select only one of these routes for inclusion in the
>    associated Loc-RIB. The local speaker considers all routes with the
>    same degrees of preference, both those received from internal peers,
>    and those received from external peers.
> 
>    The following tie-breaking procedure assumes that for each candidate
>    route all the BGP speakers within an autonomous system can ascertain
>    the cost of a path (interior distance) to the address depicted by =
> the
>    NEXT_HOP attribute of the route, and follow the same route selection
>    algorithm.
> 
>    The tie-breaking algorithm begins by considering all equally
>    preferable routes to the same destination, and then selects routes =
> to
>    be removed from consideration. The algorithm terminates as soon as
>    only one route remains in consideration.  The criteria must be
>    applied in the order specified.
> 
>    Several of the criteria are described using pseudo-code. Note that
>    the pseudo-code shown was chosen for clarity, not efficiency. It is
>    not intended to specify any particular implementation. BGP
>    implementations MAY use any algorithm which produces the same =
> results
>    as those described here.
> 
>       a) Remove from consideration all routes which are not tied for
>       having the smallest number of AS numbers present in their AS_PATH
>       attributes. Note, that when counting this number, an AS_SET =
> counts
>       as 1, no matter how many ASs are in the set, and that, if the
>       implementation supports [13], then AS numbers present in segments
>       of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in
>       the count of AS numbers present in the AS_PATH.
> 
>       b) Remove from consideration all routes which are not tied for
>       having the lowest Origin number in their Origin attribute.
> 
>       c) Remove from consideration routes with less-preferred
>       MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
>       between routes learned from the same neighboring AS. Routes which
>       do not have the MULTI_EXIT_DISC attribute are considered to have
>       the lowest possible MULTI_EXIT_DISC value.
> 
>       This is also described in the following procedure:
> 
>             for m =3D all routes still under consideration
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 49]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>                 for n =3D all routes still under consideration
>                     if (neighborAS(m) =3D=3D neighborAS(n)) and (MED(n) =
> < MED(m))
>                         remove route m from consideration
> 
>       In the pseudo-code above, MED(n) is a function which returns the
>       value of route n's MULTI_EXIT_DISC attribute. If route n has no
>       MULTI_EXIT_DISC attribute, the function returns the lowest
>       possible MULTI_EXIT_DISC value, i.e. 0.
> 
>       Similarly, neighborAS(n) is a function which returns the neighbor
>       AS from which the route was received.
> 
>       d) If at least one of the candidate routes was received from an
>       external peer in a neighboring autonomous system, remove from
>       consideration all routes which were received from internal peers.
> 
>       e) Remove from consideration any routes with less-preferred
>       interior cost.  The interior cost of a route is determined by
>       calculating the metric to the next hop for the route using the
>       Routing Table. If the next hop for a route is reachable, but no
>       cost can be determined, then this step should be skipped
>       (equivalently, consider all routes to have equal costs).
> 
>       This is also described in the following procedure.
> 
>             for m =3D all routes still under consideration
>                 for n =3D all routes in still under consideration
>                     if (cost(n) is better than cost(m))
>                         remove m from consideration
> 
>       In the pseudo-code above, cost(n) is a function which returns the
>       cost of the path (interior distance) to the address given in the
>       NEXT_HOP attribute of the route.
> 
>       f) Remove from consideration all routes other than the route that
>       was advertised by the BGP speaker whose BGP Identifier has the
>       lowest value.
> 
>       g) Prefer the route received from the lowest neighbor address.
> 
> 
> 9.1.3 Phase 3: Route Dissemination
> 
> 
>    The Phase 3 decision function shall be invoked on completion of =
> Phase
>    2, or when any of the following events occur:
> 
>       a) when routes in the Loc-RIB to local destinations have changed
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 50]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>       b) when locally generated routes learned by means outside of BGP
>       have changed
> 
>       c) when a new BGP speaker - BGP speaker connection has been
>       established
> 
>    The Phase 3 function is a separate process which completes when it
>    has no further work to do. The Phase 3 Routing Decision function
>    shall be blocked from running while the Phase 2 decision function is
>    in process.
> 
>    All routes in the Loc-RIB shall be processed into Adj-RIBs-Out
>    according to configured policy. This policy may exclude a route in
>    the Loc-RIB from being installed in a particular Adj-RIB-Out.  A
>    route shall not be installed in the Adj-Rib-Out unless the
>    destination and NEXT_HOP described by this route may be forwarded
>    appropriately by the Routing Table. If a route in Loc-RIB is =
> excluded
>    from a particular Adj-RIB-Out the previously advertised route in =
> that
>    Adj-RIB-Out must be withdrawn from service by means of an UPDATE
>    message (see 9.2).
> 
>    Route aggregation and information reduction techniques (see 9.2.2.1)
>    may optionally be applied.
> 
>    When the updating of the Adj-RIBs-Out and the Routing Table is
>    complete, the local BGP speaker shall run the Update-Send process of
>    9.2.
> 
> 
> 9.1.4 Overlapping Routes
> 
> 
>    A BGP speaker may transmit routes with overlapping Network Layer
>    Reachability Information (NLRI) to another BGP speaker. NLRI overlap
>    occurs when a set of destinations are identified in non-matching
>    multiple routes. Since BGP encodes NLRI using IP prefixes, overlap
>    will always exhibit subset relationships.  A route describing a
>    smaller set of destinations (a longer prefix) is said to be more
>    specific than a route describing a larger set of destinations (a
>    shorted prefix); similarly, a route describing a larger set of
>    destinations (a shorter prefix) is said to be less specific than a
>    route describing a smaller set of destinations (a longer prefix).
> 
>    The precedence relationship effectively decomposes less specific
>    routes into two parts:
> 
>       - a set of destinations described only by the less specific =
> route,
>       and
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 51]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>       - a set of destinations described by the overlap of the less
>       specific and the more specific routes
> 
> 
>    When overlapping routes are present in the same Adj-RIB-In, the more
>    specific route shall take precedence, in order from more specific to
>    least specific.
> 
>    The set of destinations described by the overlap represents a =
> portion
>    of the less specific route that is feasible, but is not currently in
>    use.  If a more specific route is later withdrawn, the set of
>    destinations described by the overlap will still be reachable using
>    the less specific route.
> 
>    If a BGP speaker receives overlapping routes, the Decision Process
>    MUST consider both routes based on the configured acceptance policy.
>    If both a less and a more specific route are accepted, then the
>    Decision Process MUST either install both the less and the more
>    specific routes or it MUST aggregate the two routes and install the
>    aggregated route, provided that both routes have the same value of
>    the NEXT_HOP attribute.
> 
>    If a BGP speaker chooses to aggregate, then it MUST add
>    ATOMIC_AGGREGATE attribute to the route. A route that carries
>    ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the
>    NLRI of this route can not be made more specific. Forwarding along
>    such a route does not guarantee that IP packets will actually
>    traverse only ASs listed in the AS_PATH attribute of the route.
> 
> 
> 9.2 Update-Send Process
> 
> 
>    The Update-Send process is responsible for advertising UPDATE
>    messages to all peers. For example, it distributes the routes chosen
>    by the Decision Process to other BGP speakers which may be located =
> in
>    either the same autonomous system or a neighboring autonomous =
> system.
> 
>    When a BGP speaker receives an UPDATE message from an internal peer,
>    the receiving BGP speaker shall not re-distribute the routing
>    information contained in that UPDATE message to other internal =
> peers,
>    unless the speaker acts as a BGP Route Reflector [11].
> 
>    As part of Phase 3 of the route selection process, the BGP speaker
>    has updated its Adj-RIBs-Out. All newly installed routes and all
>    newly unfeasible routes for which there is no replacement route =
> shall
>    be advertised to its peers by means of an UPDATE message.
> 
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 52]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    A BGP speaker should not advertise a given feasible BGP route from
>    its Adj-RIB-Out if it would produce an UPDATE message containing the
>    same BGP route as was previously advertised.
> 
>    Any routes in the Loc-RIB marked as unfeasible shall be removed.
>    Changes to the reachable destinations within its own autonomous
>    system shall also be advertised in an UPDATE message.
> 
> 
> 9.2.1 Controlling Routing Traffic Overhead
> 
> 
>    The BGP protocol constrains the amount of routing traffic (that is,
>    UPDATE messages) in order to limit both the link bandwidth needed to
>    advertise UPDATE messages and the processing power needed by the
>    Decision Process to digest the information contained in the UPDATE
>    messages.
> 
> 
> 9.2.1.1 Frequency of Route Advertisement
> 
> 
>    The parameter MinRouteAdvertisementInterval determines the minimum
>    amount of time that must elapse between advertisement of routes to a
>    particular destination from a single BGP speaker. This rate limiting
>    procedure applies on a per-destination basis, although the value of
>    MinRouteAdvertisementInterval is set on a per BGP peer basis.
> 
>    Two UPDATE messages sent from a single BGP speaker that advertise
>    feasible routes to some common set of destinations received from
>    external peers must be separated by at least
>    MinRouteAdvertisementInterval. Clearly, this can only be achieved
>    precisely by keeping a separate timer for each common set of
>    destinations. This would be unwarranted overhead. Any technique =
> which
>    ensures that the interval between two UPDATE messages sent from a
>    single BGP speaker that advertise feasible routes to some common set
>    of destinations received from external peers will be at least
>    MinRouteAdvertisementInterval, and will also ensure a constant upper
>    bound on the interval is acceptable.
> 
>    Since fast convergence is needed within an autonomous system, this
>    procedure does not apply for routes received from other internal
>    peers.  To avoid long-lived black holes, the procedure does not =
> apply
>    to the explicit withdrawal of unfeasible routes (that is, routes
>    whose destinations (expressed as IP prefixes) are listed in the
>    WITHDRAWN ROUTES field of an UPDATE message).
> 
>    This procedure does not limit the rate of route selection, but only
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 53]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    the rate of route advertisement. If new routes are selected multiple
>    times while awaiting the expiration of =
> MinRouteAdvertisementInterval,
>    the last route selected shall be advertised at the end of
>    MinRouteAdvertisementInterval.
> 
> 
> 9.2.1.2 Frequency of Route Origination
> 
> 
>    The parameter MinASOriginationInterval determines the minimum amount
>    of time that must elapse between successive advertisements of UPDATE
>    messages that report changes within the advertising BGP speaker's =
> own
>    autonomous systems.
> 
> 
> 9.2.1.3 Jitter
> 
> 
>    To minimize the likelihood that the distribution of BGP messages by =
> a
>    given BGP speaker will contain peaks, jitter should be applied to =
> the
>    timers associated with MinASOriginationInterval, Keepalive, and
>    MinRouteAdvertisementInterval. A given BGP speaker shall apply the
>    same jitter to each of these quantities regardless of the
>    destinations to which the updates are being sent; that is, jitter
>    will not be applied on a "per peer" basis.
> 
>    The amount of jitter to be introduced shall be determined by
>    multiplying the base value of the appropriate timer by a random
>    factor which is uniformly distributed in the range from 0.75 to 1.0.
> 
> 
> 9.2.2 Efficient Organization of Routing Information
> 
> 
>    Having selected the routing information which it will advertise, a
>    BGP speaker may avail itself of several methods to organize this
>    information in an efficient manner.
> 
> 
> 9.2.2.1 Information Reduction
> 
> 
>    Information reduction may imply a reduction in granularity of policy
>    control - after information is collapsed, the same policies will
>    apply to all destinations and paths in the equivalence class.
> 
>    The Decision Process may optionally reduce the amount of information
>    that it will place in the Adj-RIBs-Out by any of the following
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 54]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    methods:
> 
>       a)   Network Layer Reachability Information (NLRI):
> 
>       Destination IP addresses can be represented as IP address
>       prefixes. In cases where there is a correspondence between the
>       address structure and the systems under control of an autonomous
>       system administrator, it will be possible to reduce the size of
>       the NLRI carried in the UPDATE messages.
> 
>       b)   AS_PATHs:
> 
>       AS path information can be represented as ordered AS_SEQUENCEs or
>       unordered AS_SETs. AS_SETs are used in the route aggregation
>       algorithm described in 9.2.2.2. They reduce the size of the
>       AS_PATH information by listing each AS number only once,
>       regardless of how many times it may have appeared in multiple
>       AS_PATHs that were aggregated.
> 
>       An AS_SET implies that the destinations listed in the NLRI can be
>       reached through paths that traverse at least some of the
>       constituent autonomous systems. AS_SETs provide sufficient
>       information to avoid routing information looping; however their
>       use may prune potentially feasible paths, since such paths are no
>       longer listed individually as in the form of AS_SEQUENCEs. In
>       practice this is not likely to be a problem, since once an IP
>       packet arrives at the edge of a group of autonomous systems, the
>       BGP speaker at that point is likely to have more detailed path
>       information and can distinguish individual paths to destinations.
> 
> 
> 9.2.2.2 Aggregating Routing Information
> 
> 
>    Aggregation is the process of combining the characteristics of
>    several different routes in such a way that a single route can be
>    advertised.  Aggregation can occur as part of the decision process =
> to
>    reduce the amount of routing information that will be placed in the
>    Adj-RIBs-Out.
> 
>    Aggregation reduces the amount of information that a BGP speaker =
> must
>    store and exchange with other BGP speakers. Routes can be aggregated
>    by applying the following procedure separately to path attributes of
>    like type and to the Network Layer Reachability Information.
> 
>    Routes that have the following attributes shall not be aggregated
>    unless the corresponding attributes of each route are identical:
>    MULTI_EXIT_DISC, NEXT_HOP.
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 55]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    If the aggregation occurs as part of the update process, routes with
>    different NEXT_HOP values can be aggregated when announced through =
> an
>    external BGP session.
> 
>    Path attributes that have different type codes can not be aggregated
>    together. Path attributes of the same type code may be aggregated,
>    according to the following rules:
> 
>       ORIGIN attribute: If at least one route among routes that are
>       aggregated has ORIGIN with the value INCOMPLETE, then the
>       aggregated route must have the ORIGIN attribute with the value
>       INCOMPLETE.  Otherwise, if at least one route among routes that
>       are aggregated has ORIGIN with the value EGP, then the aggregated
>       route must have the origin attribute with the value EGP. In all
>       other case the value of the ORIGIN attribute of the aggregated
>       route is IGP.
> 
>       AS_PATH attribute: If routes to be aggregated have identical
>       AS_PATH attributes, then the aggregated route has the same =
> AS_PATH
>       attribute as each individual route.
> 
>       For the purpose of aggregating AS_PATH attributes we model each =
> AS
>       within the AS_PATH attribute as a tuple <type, value>, where
>       "type" identifies a type of the path segment the AS belongs to
>       (e.g. AS_SEQUENCE, AS_SET), and "value" is the AS number. If the
>       routes to be aggregated have different AS_PATH attributes, then
>       the aggregated AS_PATH attribute shall satisfy all of the
>       following conditions:
> 
>          - all tuples of type AS_SEQUENCE in the aggregated AS_PATH
>          shall appear in all of the AS_PATH in the initial set of =
> routes
>          to be aggregated.
> 
>          - all tuples of type AS_SET in the aggregated AS_PATH shall
>          appear in at least one of the AS_PATH in the initial set (they
>          may appear as either AS_SET or AS_SEQUENCE types).
> 
>          - for any tuple X of type AS_SEQUENCE in the aggregated =
> AS_PATH
>          which precedes tuple Y in the aggregated AS_PATH, X precedes Y
>          in each AS_PATH in the initial set which contains Y, =
> regardless
>          of the type of Y.
> 
>          - No tuple of type AS_SET with the same value shall appear =
> more
>          than once in the aggregated AS_PATH.
> 
>          - Multiple tuples of type AS_SEQUENCE with the same value may
>          appear in the aggregated AS_PATH only when adjacent to another
>          tuple of the same type and value.
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 56]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>       An implementation may choose any algorithm which conforms to =
> these
>       rules. At a minimum a conformant implementation shall be able to
>       perform the following algorithm that meets all of the above
>       conditions:
> 
>          - determine the longest leading sequence of tuples (as defined
>          above) common to all the AS_PATH attributes of the routes to =
> be
>          aggregated. Make this sequence the leading sequence of the
>          aggregated AS_PATH attribute.
> 
>          - set the type of the rest of the tuples from the AS_PATH
>          attributes of the routes to be aggregated to AS_SET, and =
> append
>          them to the aggregated AS_PATH attribute.
> 
>          - if the aggregated AS_PATH has more than one tuple with the
>          same value (regardless of tuple's type), eliminate all, but =
> one
>          such tuple by deleting tuples of the type AS_SET from the
>          aggregated AS_PATH attribute.
> 
>       Appendix 6, section 6.8 presents another algorithm that satisfies
>       the conditions and allows for more complex policy configurations.
> 
>       ATOMIC_AGGREGATE: If at least one of the routes to be aggregated
>       has ATOMIC_AGGREGATE path attribute, then the aggregated route
>       shall have this attribute as well.
> 
>       AGGREGATOR: All AGGREGATOR attributes of all routes to be
>       aggregated should be ignored. The BGP speaker performing the =
> route
>       aggregation may attach a new AGGREGATOR attribute (see Section
>       5.1.7).
> 
> 
> 9.3 Route Selection Criteria
> 
> 
>    Generally speaking, additional rules for comparing routes among
>    several alternatives are outside the scope of this document. There
>    are two exceptions:
> 
>       - If the local AS appears in the AS path of the new route being
>       considered, then that new route cannot be viewed as better than
>       any other route (provided that the speaker is configured to =
> accept
>       such routes). If such a route were ever used, a routing loop =
> could
>       result (see Section 6.3).
> 
>       - In order to achieve successful distributed operation, only
>       routes with a likelihood of stability can be chosen. Thus, an AS
>       must avoid using unstable routes, and it must not make rapid
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 57]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>       spontaneous changes to its choice of route. Quantifying the terms
>       "unstable" and "rapid" in the previous sentence will require
>       experience, but the principle is clear.
> 
>       Care must be taken to ensure that BGP speakers in the same AS do
>       not make inconsistent decisions.
> 
> 
> 9.4 Originating BGP routes
> 
>    A BGP speaker may originate BGP routes by injecting routing
>    information acquired by some other means (e.g. via an IGP) into BGP.
>    A BGP speaker that originates BGP routes shall assign the degree of
>    preference to these routes by passing them through the Decision
>    Process (see Section 9.1). These routes may also be distributed to
>    other BGP speakers within the local AS as part of the update process
>    (see Section 9.2). The decision whether to distribute non-BGP
>    acquired routes within an AS via BGP or not depends on the
>    environment within the AS (e.g. type of IGP) and should be =
> controlled
>    via configuration.
> 
> 
> 
> 
> 
> Appendix 1. Comparison with RFC1771
> 
> 
>    There are numerous editorial changes (too many to list here).
> 
>    The following list the technical changes:
> 
>       Changes to reflect the usages of such features as TCP MD5 [10],
>       BGP Route Reflectors [11], BGP Confederations [13], and BGP Route
>       Refresh [12].
> 
>       Clarification on the use of the BGP Identifier in the AGGREGATOR
>       attribute.
> 
>       Procedures for imposing an upper bound on the number of prefixes
>       that a BGP speaker would accept from a peer.
> 
>       The ability of a BGP speaker to include more than one instance of
>       its own AS in the AS_PATH attribute for the purpose of inter-AS
>       traffic engineering.
> 
>       Clarifications on the various types of NEXT_HOPs.
> 
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 58]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>       Clarifications to the use of the ATOMIC_AGGREGATE attribute.
> 
>       The relationship between the immediate next hop, and the next hop
>       as specified in the NEXT_HOP path attribute.
> 
>       Clarifications on the tie-breaking procedures.
> 
> 
> Appendix 2. Comparison with RFC1267
> 
> 
>    All the changes listed in Appendix 1, plus the following.
> 
>    BGP-4 is capable of operating in an environment where a set of
>    reachable destinations may be expressed via a single IP prefix.  The
>    concept of network classes, or subnetting is foreign to BGP-4.  To
>    accommodate these capabilities BGP-4 changes semantics and encoding
>    associated with the AS_PATH attribute. New text has been added to
>    define semantics associated with IP prefixes. These abilities allow
>    BGP-4 to support the proposed supernetting scheme [9].
> 
>    To simplify configuration this version introduces a new attribute,
>    LOCAL_PREF, that facilitates route selection procedures.
> 
>    The INTER_AS_METRIC attribute has been renamed to be =
> MULTI_EXIT_DISC.
>    A new attribute, ATOMIC_AGGREGATE, has been introduced to insure =
> that
>    certain aggregates are not de-aggregated. Another new attribute,
>    AGGREGATOR, can be added to aggregate routes in order to advertise
>    which AS and which BGP speaker within that AS caused the =
> aggregation.
> 
>    To insure that Hold Timers are symmetric, the Hold Time is now
>    negotiated on a per-connection basis. Hold Times of zero are now
>    supported.
> 
> Appendix 3. Comparison with RFC 1163
> 
> 
>    All of the changes listed in Appendices 1 and 2, plus the following.
> 
>    To detect and recover from BGP connection collision, a new field =
> (BGP
>    Identifier) has been added to the OPEN message. New text (Section
>    6.8) has been added to specify the procedure for detecting and
>    recovering from collision.
> 
>    The new document no longer restricts the border router that is =
> passed
>    in the NEXT_HOP path attribute to be part of the same Autonomous
>    System as the BGP Speaker.
> 
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 59]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    New document optimizes and simplifies the exchange of the =
> information
   about previously reachable routes.
> 
> 
> Appendix 4. Comparison with RFC 1105
> 
> 
>    All of the changes listed in Appendices 1, 2 and 3, plus the
>    following.
> 
>    Minor changes to the RFC1105 Finite State Machine were necessary to
>    accommodate the TCP user interface provided by 4.3 BSD.
> 
>    The notion of Up/Down/Horizontal relations present in RFC1105 has
>    been removed from the protocol.
> 
>    The changes in the message format from RFC1105 are as follows:
> 
>       1.  The Hold Time field has been removed from the BGP header and
>       added to the OPEN message.
> 
>       2.  The version field has been removed from the BGP header and
>       added to the OPEN message.
> 
>       3.  The Link Type field has been removed from the OPEN message.
> 
>       4.  The OPEN CONFIRM message has been eliminated and replaced =
> with
>       implicit confirmation provided by the KEEPALIVE message.
> 
>       5.  The format of the UPDATE message has been changed
>       significantly.  New fields were added to the UPDATE message to
>       support multiple path attributes.
> 
>       6.  The Marker field has been expanded and its role broadened to
>       support authentication.
> 
>       Note that quite often BGP, as specified in RFC 1105, is referred
>       to as BGP-1, BGP, as specified in RFC 1163, is referred to as
>       BGP-2, BGP, as specified in RFC1267 is referred to as BGP-3, and
>       BGP, as specified in this document is referred to as BGP-4.
> 
> 
> Appendix 5.  TCP options that may be used with BGP
> 
> 
>    If a local system TCP user interface supports TCP PUSH function, =
> then
>    each BGP message should be transmitted with PUSH flag set.  Setting
>    PUSH flag forces BGP messages to be transmitted promptly to the
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 60]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    receiver.
> 
>    If a local system TCP user interface supports setting precedence for
>    TCP connection, then the BGP transport connection should be opened
>    with precedence set to Internetwork Control (110) value (see also
>    [6]).
> 
>    A local system may protect its BGP sessions by using the TCP MD5
>    Signature Option [10].
> 
> 
> Appendix 6.  Implementation Recommendations
> 
> 
>    This section presents some implementation recommendations.
> 
> 
> 6.1 Multiple Networks Per Message
> 
> 
>    The BGP protocol allows for multiple address prefixes with the same
>    path attributes to be specified in one message. Making use of this
>    capability is highly recommended. With one address prefix per =
> message
>    there is a substantial increase in overhead in the receiver. Not =
> only
>    does the system overhead increase due to the reception of multiple
>    messages, but the overhead of scanning the routing table for updates
>    to BGP peers and other routing protocols (and sending the associated
>    messages) is incurred multiple times as well.
> 
>    One method of building messages containing many address prefixes per
>    a path attribute set from a routing table that is not organized on a
>    per path attribute set basis is to build many messages as the =
> routing
>    table is scanned. As each address prefix is processed, a message for
>    the associated set of path attributes is allocated, if it does not
>    exist, and the new address prefix is added to it.  If such a message
>    exists, the new address prefix is just appended to it. If the =
> message
>    lacks the space to hold the new address prefix, it is transmitted, a
>    new message is allocated, and the new address prefix is inserted =
> into
>    the new message. When the entire routing table has been scanned, all
>    allocated messages are sent and their resources released.  Maximum
>    compression is achieved when all  the destinations covered by the
>    address prefixes share a common set of path attributes making it
>    possible to send many address prefixes in one 4096-byte message.
> 
>    When peering with a BGP implementation that does not compress
>    multiple address prefixes into one message, it may be necessary to
>    take steps to reduce the overhead from the flood of data received
>    when a peer is acquired or a significant network topology change
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 61]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    occurs. One method of doing this is to limit the rate of updates.
>    This will eliminate the redundant scanning of the routing table to
>    provide flash updates for BGP peers and other routing protocols. A
>    disadvantage of this approach is that it increases the propagation
>    latency of routing information.  By choosing a minimum flash update
>    interval that is not much greater than the time it takes to process
>    the multiple messages this latency should be minimized. A better
>    method would be to read all received messages before sending =
> updates.
> 
> 
> 6.2  Processing Messages on a Stream Protocol
> 
> 
>    BGP uses TCP as a transport mechanism.  Due to the stream nature of
>    TCP, all the data for received messages does not necessarily arrive
>    at the same time. This can make it difficult to process the data as
>    messages, especially on systems such as BSD Unix where it is not
>    possible to determine how much data has been received but not yet
>    processed.
> 
>    One method that can be used in this situation is to first try to =
> read
>    just the message header. For the KEEPALIVE message type, this is a
>    complete message; for other message types, the header should first =
> be
>    verified, in particular the total length. If all checks are
>    successful, the specified length, minus the size of the message
>    header is the amount of data left to read. An implementation that
>    would "hang" the routing information process while trying to read
>    from a peer could set up a message buffer (4096 bytes) per peer and
>    fill it with data as available until a complete message has been
>    received.
> 
> 
> 6.3 Reducing route flapping
> 
> 
>    To avoid excessive route flapping a BGP speaker which needs to
>    withdraw a destination and send an update about a more specific or
>    less specific route SHOULD combine them into the same UPDATE =
> message.
> 
> 
> 6.4 BGP Timers
> 
> 
>    BGP employs five timers: ConnectRetry, Hold Time, KeepAlive,
>    MinASOriginationInterval, and MinRouteAdvertisementInterval The
>    suggested value for the ConnectRetry timer is 120 seconds.  The
>    suggested value for the Hold Time is 90 seconds.  The suggested =
> value
>    for the KeepAlive timer is 1/3 of the Hold Time.  The suggested =
> value
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 62]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>    for the MinASOriginationInterval is 15 seconds.  The suggested value
>    for the MinRouteAdvertisementInterval is 30 seconds.
> 
>    An implementation of BGP MUST allow the Hold Time timer to be
>    configurable, and MAY allow the other timers to be configurable.
> 
> 
> 
> 6.5 Path attribute ordering
> 
> 
>    Implementations which combine update messages as described above in
>    6.1 may prefer to see all path attributes presented in a known =
> order.
>    This permits them to quickly identify sets of attributes from
>    different update messages which are semantically identical.  To
>    facilitate this, it is a useful optimization to order the path
>    attributes according to type code.  This optimization is entirely
>    optional.
> 
> 
> 6.6 AS_SET sorting
> 
> 
>    Another useful optimization that can be done to simplify this
>    situation is to sort the AS numbers found in an AS_SET.  This
>    optimization is entirely optional.
> 
> 
> 6.7 Control over version negotiation
> 
> 
>    Since BGP-4 is capable of carrying aggregated routes which cannot be
>    properly represented in BGP-3, an implementation which supports =
> BGP-4
>    and another BGP version should provide the capability to only speak
>    BGP-4 on a per-peer basis.
> 
> 
> 6.8 Complex AS_PATH aggregation
> 
> 
>    An implementation which chooses to provide a path aggregation
>    algorithm which retains significant amounts of path information may
>    wish to use the following procedure:
> 
>       For the purpose of aggregating AS_PATH attributes of two routes,
>       we model each AS as a tuple <type, value>, where "type" =
> identifies
>       a type of the path segment the AS belongs to (e.g.  AS_SEQUENCE,
>       AS_SET), and "value" is the AS number.  Two ASs are said to be =
> the
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 63]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
>       same if their corresponding <type, value> tuples are the same.
> 
>       The algorithm to aggregate two AS_PATH attributes works as
>       follows:
> 
>          a) Identify the same ASs (as defined above) within each =
> AS_PATH
>          attribute that are in the same relative order within both
>          AS_PATH attributes.  Two ASs, X and Y, are said to be in the
>          same order if either:
>             - X precedes Y in both AS_PATH attributes, or - Y precedes =
> X
>             in both AS_PATH attributes.
> 
>          b) The aggregated AS_PATH attribute consists of ASs identified
>          in (a) in exactly the same order as they appear in the AS_PATH
>          attributes to be aggregated. If two consecutive ASs identified
>          in (a) do not immediately follow each other in both of the
>          AS_PATH attributes to be aggregated, then the intervening ASs
>          (ASs that are between the two consecutive ASs that are the
>          same) in both attributes are combined into an AS_SET path
>          segment that consists of the intervening ASs from both AS_PATH
>          attributes; this segment is then placed in between the two
>          consecutive ASs identified in (a) of the aggregated attribute.
>          If two consecutive ASs identified in (a) immediately follow
>          each other in one attribute, but do not follow in another, =
> then
>          the intervening ASs of the latter are combined into an AS_SET
>          path segment; this segment is then placed in between the two
>          consecutive ASs identified in (a) of the aggregated attribute.
> 
>       If as a result of the above procedure a given AS number appears
>       more than once within the aggregated AS_PATH attribute, all, but
>       the last instance (rightmost occurrence) of that AS number should
>       be removed from the aggregated AS_PATH attribute.
> 
> 
> Security Considerations
> 
> 
>    BGP supports the ability to authenticate BGP messages by using BGP
>    authentication. The authentication could be done on a per peer =
> basis.
>    In addition, BGP supports the ability to authenticate its data =
> stream
>    by using [10]. This authentication could be done on a per peer =
> basis.
>    Finally, BGP could also use IPSec to authenticate its data stream.
>    Among the mechanisms mentioned in this paragraph, [10] is the most
>    widely deployed.
> 
> 
> 
> 
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 64]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
> References
> 
> 
>    [1] Mills, D., "Exterior Gateway Protocol Formal Specification",
>    RFC904, April 1984.
> 
>    [2] Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET
>    Backbone", RFC1092, February 1989.
> 
>    [3] Braun, H-W., "The NSFNET Routing Architecture", RFC1093, =
> February
>    1989.
> 
>    [4] Postel, J., "Transmission Control Protocol - DARPA Internet
>    Program Protocol Specification", RFC793, September 1981.
> 
>    [5] Rekhter, Y., and P. Gross, "Application of the Border Gateway
>    Protocol in the Internet", RFC1772, March 1995.
> 
>    [6] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
>    Specification", RFC791, September 1981.
> 
>    [7] "Information Processing Systems - Telecommunications and
>    Information Exchange between Systems - Protocol for Exchange of
>    Inter-domain Routeing Information among Intermediate Systems to
>    Support Forwarding of ISO 8473 PDUs", ISO/IEC IS10747, 1993
> 
>    [8] Fuller, V., Li, T., Yu, J., and Varadhan, K., ""Classless Inter-
>    Domain Routing (CIDR): an Address Assignment and Aggregation
>    Strategy", RFC1519, September 1993.
> 
>    [9] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation
>    with CIDR", RFC 1518, September 1993.
> 
>    [10] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
>    Signature Option", RFC2385, August 1998.
> 
>    [11] Bates, T., Chandra, R., Chen, E., "BGP Route Reflection - An
>    Alternative to Full Mesh IBGP", RFC2796,  April 2000.
> 
>    [12] Chen, E., "Route Refresh Capability for BGP-4", RFC2918,
>    September 2000.
> 
>    [13] Traina, P, McPherson, D., Scudder, J., "Autonomous System
>    Confederations for BGP", RFC3065, February 2001.
> 
> 
> 
> 
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 65]
> 
> 
> 
> 
> 
> RFC DRAFT                                                   January =
> 2002
> 
> 
> Editors' Addresses
> 
>    Yakov Rekhter
>    Juniper Networks
>    1194 N. Mathilda Avenue
>    Sunnyvale, CA 94089
>    email:  [e-mail]
> 
>    Tony Li
>    Procket Networks
>    1100 Cadillac Ct.
>    Milpitas, CA 95035
>    Email:  [e-mail]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Expiration Date July 2002                                      =0C[Page =
> 66]
> 
> 
> 
> 
> ------_=_NextPart_000_01C281A9.64ABEC00--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA24815 for <[e-mail]>; Fri, 1 Nov 2002 08:21:01 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E160991229; Fri,  1 Nov 2002 08:20:19 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88A4A91235; Fri,  1 Nov 2002 08:20:19 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ABAA591229 for <[e-mail]>; Fri,  1 Nov 2002 08:20:10 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 7FCCA5DDD3; Fri,  1 Nov 2002 08:20:10 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 91CD45DDD1 for <[e-mail]>; Fri,  1 Nov 2002 08:20:06 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT0MG5>; Fri, 1 Nov 2002 08:20:05 -0500
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Parag Deshpande'" <[e-mail]>
Cc: [e-mail]
Subject: RE: draft-ietf-idr-bgp4-18.txt
Date: Fri, 1 Nov 2002 08:20:05 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C281A9.64ABEC00"
Sender: [e-mail]
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C281A9.64ABEC00
Content-Type: text/plain

This is obviously an "uncontrolled copy", but *I think* it is current.
Also, refer to the "RE: BGP Base Draft - Issue List v1.5" email sent on
Monday, October 28, 2002 7:00 PM for info on the proposed changes. 
I am assuming that this current version was removed because the
new version is to be posted shortly.


> -----Original Message-----
> From: Parag Deshpande [mailto:[e-mail]] 
> Sent: Thursday, October 31, 2002 5:57 PM
> To: [e-mail]
> Cc: Susan Hares
> Subject: draft-ietf-idr-bgp4-18.txt
> 
> 
> Hi,
> 
> I am unable to locate the latest bgp draft on ietf site. 
> Where can I get it?
> I would appreciate if someone could just mail it to me.
> 
> Thanks,
> Parag
> 
> 


------_=_NextPart_000_01C281A9.64ABEC00
Content-Type: text/plain;
	name="draft-ietf-idr-bgp4-17.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-idr-bgp4-17.txt"




Network Working Group                                      Y. Rekhter
INTERNET DRAFT                                       Juniper Networks
                                                                T. Li
                                               Procket Networks, Inc.
                                                              Editors



                  A Border Gateway Protocol 4 (BGP-4)
                      <draft-ietf-idr-bgp4-17.txt>


Status of this Memo


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.



1. Acknowledgments

   This document was originally published as RFC 1267 in October 1991,
   jointly authored by Kirk Lougheed and Yakov Rekhter.

   We would like to express our thanks to Guy Almes, Len Bosack, and
   Jeffrey C. Honig for their contributions to the earlier version of
   this document.

   We like to explicitly thank Bob Braden for the review of the earlier
   version of this document as well as his constructive and valuable
   comments.



Expiration Date July 2002                                       =
=0C[Page 1]





RFC DRAFT                                                   January =
2002


   We would also like to thank Bob Hinden, Director for Routing of the
   Internet Engineering Steering Group, and the team of reviewers he
   assembled to review the earlier version (BGP-2) of this document.
   This team, consisting of Deborah Estrin, Milo Medin, John Moy, Radia
   Perlman, Martha Steenstrup, Mike St. Johns, and Paul Tsuchiya, acted
   with a strong combination of toughness, professionalism, and
   courtesy.

   This updated version of the document is the product of the IETF IDR
   Working Group with Yakov Rekhter and Tony Li as editors. Certain
   sections of the document borrowed heavily from IDRP [7], which is =
the
   OSI counterpart of BGP. For this credit should be given to the ANSI
   X3S3.3 group chaired by Lyman Chapin and to Charles Kunzinger who =
was
   the IDRP editor within that group. We would also like to thank Enke
   Chen, Edward Crabbe, Mike Craren, Vincent Gillet, Eric Gray, Jeffrey
   Haas, Dimitry Haskin, John Krawczyk, David LeRoy, Dan Massey, Dan
   Pei, Mathew Richardson, John Scudder, John Stewart III, Dave Thaler,
   Paul Traina, Russ White, Curtis Villamizar, and Alex Zinin for their
   comments.

   Many thanks to Sue Hares for her contributions to the document, and
   especially for her work on the BGP Finite State Machine.

   We would like to specially acknowledge numerous contributions by
   Dennis Ferguson.


2. Introduction

   The Border Gateway Protocol (BGP) is an inter-Autonomous System
   routing protocol. It is built on experience gained with EGP as
   defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as
   described in RFC 1092 [2] and RFC 1093 [3].

   The primary function of a BGP speaking system is to exchange network
   reachability information with other BGP systems. This network
   reachability information includes information on the list of
   Autonomous Systems (ASs) that reachability information traverses.
   This information 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.

   BGP-4 provides a new set of mechanisms for supporting Classless
   Inter-Domain Routing (CIDR) [8, 9]. These mechanisms include support
   for advertising an IP prefix and eliminates the concept of network
   "class" within BGP.  BGP-4 also introduces mechanisms which allow
   aggregation of routes, including aggregation of AS paths.




Expiration Date July 2002                                       =
=0C[Page 2]





RFC DRAFT                                                   January =
2002


   To characterize the set of policy decisions that can be enforced
   using BGP, one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with) in
   neighboring ASs only those routes that it itself uses. This rule
   reflects the "hop-by-hop" routing paradigm generally used throughout
   the current Internet. Note that some policies cannot be supported by
   the "hop-by-hop" routing paradigm and thus require techniques such =
as
   source routing (aka explicit routing) to enforce. For example, BGP
   does not enable one AS to send traffic to a neighboring AS intending
   that the traffic take a different route from that taken by traffic
   originating in the neighboring AS. On the other hand, BGP can =
support
   any policy conforming to the "hop-by-hop" routing paradigm. Since =
the
   current Internet uses only the "hop-by-hop" inter-AS routing =
paradigm
   and since BGP can support any policy that conforms to that paradigm,
   BGP is highly applicable as an inter-AS routing protocol for the
   current Internet.

   A more complete discussion of what policies can and cannot be
   enforced with BGP is outside the scope of this document (but refer =
to
   the companion document discussing BGP usage [5]).

   BGP runs over a reliable transport protocol. This eliminates the =
need
   to implement explicit update fragmentation, retransmission,
   acknowledgment, and sequencing. Any authentication scheme used by =
the
   transport protocol (e.g., RFC2385 [10]) may be used in addition to
   BGP's own authentication mechanisms. The error notification =
mechanism
   used in BGP assumes that the transport protocol supports a =
"graceful"
   close, i.e., that all outstanding data will be delivered before the
   connection is closed.

   BGP uses TCP [4] as its transport protocol. TCP meets BGP's =
transport
   requirements and is present in virtually all commercial routers and
   hosts. In the following descriptions the phrase "transport protocol
   connection" can be understood to refer to a TCP connection. BGP uses
   TCP port 179 for establishing its connections.

   This document uses the term `Autonomous System' (AS) throughout.  =
The
   classic definition of an Autonomous System is a set of routers under
   a single technical administration, using an interior gateway =
protocol
   and common metrics to determine how to route packets within the AS,
   and using an exterior gateway protocol to determine how to route
   packets to other ASs. Since this classic definition was developed, =
it
   has become common for a single AS to use several interior gateway
   protocols and sometimes several sets of metrics within an AS. The =
use
   of the term Autonomous System here stresses the fact that, even when
   multiple IGPs and metrics are used, the administration of an AS
   appears to other ASs to have a single coherent interior routing plan
   and presents a consistent picture of what destinations are reachable



Expiration Date July 2002                                       =
=0C[Page 3]





RFC DRAFT                                                   January =
2002


   through it.

   The planned use of BGP in the Internet environment, including such
   issues as topology, the interaction between BGP and IGPs, and the
   enforcement of routing policy rules is presented in a companion
   document [5]. This document is the first of a series of documents
   planned to explore various aspects of BGP application.


3. Summary of Operation

   Two systems form a transport protocol connection between one =
another.
   They exchange messages to open and confirm the connection =
parameters.

   The initial data flow is the portion of the BGP routing table that =
is
   allowed by the export policy, called the Adj-Ribs-Out (see 3.2).
   Incremental updates are sent as the routing tables change. BGP does
   not require periodic refresh of the routing table. Therefore, a BGP
   speaker must retain the current version of the routes advertised by
   all of its peers for the duration of the connection. If the
   implementation decides to not store the routes that have been
   received from a peer, but have been filtered out according to
   configured local policy, the BGP Route Refresh extension [12] may be
   used to request the full set of routes from a peer without resetting
   the BGP session when the local policy configuration changes.

   KEEPALIVE messages may be sent periodically to ensure the liveness =
of
   the connection. NOTIFICATION messages are sent in response to errors
   or special conditions. If a connection encounters an error =
condition,
   a NOTIFICATION message is sent and the connection is closed.

   The hosts executing the Border Gateway Protocol need not be routers.
   A non-routing host could exchange routing information with routers
   via EGP or even an interior routing protocol. That non-routing host
   could then use BGP to exchange routing information with a border
   router in another Autonomous System. The implications and
   applications of this architecture are for further study.

   Connections between BGP speakers of different ASs are referred to as
   "external" links. BGP connections between BGP speakers within the
   same AS are referred to as "internal" links. Similarly, a peer in a
   different AS is referred to as an external peer, while a peer in the
   same AS may be described as an internal peer. Internal BGP and
   external BGP are commonly abbreviated IBGP and EBGP.

   If a particular AS has multiple BGP speakers and is providing =
transit
   service for other ASs, then care must be taken to ensure a =
consistent
   view of routing within the AS. A consistent view of the interior



Expiration Date July 2002                                       =
=0C[Page 4]





RFC DRAFT                                                   January =
2002


   routes of the AS is provided by the interior routing protocol. A
   consistent view of the routes exterior to the AS can be provided by
   having all BGP speakers within the AS maintain direct IBGP
   connections with each other. Alternately the interior routing
   protocol can pass BGP information among routers within an AS, taking
   care not to lose BGP attributes that will be needed by EBGP speakers
   if transit connectivity is being provided. For the purpose of
   discussion, it is assumed that BGP information is passed within an =
AS
   using IBGP. Care must be taken to ensure that the interior routers
   have all been updated with transit information before the EBGP
   speakers announce to other ASs that transit service is being
   provided.


3.1 Routes: Advertisement and Storage

   For the purpose of this protocol, a route is defined as a unit of
   information that pairs a set of destinations with the attributes of =
a
   path to those destinations.  The set of destinations are the systems
   whose IP addresses are reported in the Network Layer Reachability
   Information (NLRI) field and the path is the information reported in
   the path attributes field of the same UPDATE message.

   Routes are advertised between BGP speakers in UPDATE messages.

   Routes are stored in the Routing Information Bases (RIBs): namely,
   the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out. Routes that will
   be advertised to other BGP speakers must be present in the Adj-RIB-
   Out.  Routes that will be used by the local BGP speaker must be
   present in the Loc-RIB, and the next hop for each of these routes
   must be resolvable via the local BGP speaker's Routing Table.  =
Routes
   that are received from other BGP speakers are present in the Adj-
   RIBs-In.

   If a BGP speaker chooses to advertise the route, it may add to or
   modify the path attributes of the route before advertising it to a
   peer.

   BGP provides mechanisms by which a BGP speaker can inform its peer
   that a previously advertised route is no longer available for use.
   There are three methods by which a given BGP speaker can indicate
   that a route has been withdrawn from service:

      a) the IP prefix that expresses the destination for a previously
      advertised route can be advertised in the WITHDRAWN ROUTES field
      in the UPDATE message, thus marking the associated route as being
      no longer available for use




Expiration Date July 2002                                       =
=0C[Page 5]





RFC DRAFT                                                   January =
2002


      b) a replacement route with the same NLRI can be advertised, or

      c) the BGP speaker - BGP speaker connection can be closed, which
      implicitly removes from service all routes which the pair of
      speakers had advertised to each other.


3.2 Routing Information Bases

   The Routing Information Base (RIB) within a BGP speaker consists of
   three distinct parts:

      a) Adj-RIBs-In: The Adj-RIBs-In store routing information that =
has
      been learned from inbound UPDATE messages. Their contents
      represent routes that are available as an input to the Decision
      Process.

      b) Loc-RIB: The Loc-RIB contains the local routing information
      that the BGP speaker has selected by applying its local policies
      to the routing information contained in its Adj-RIBs-In.

      c) Adj-RIBs-Out: The Adj-RIBs-Out store the information that the
      local BGP speaker has selected for advertisement to its peers. =
The
      routing information stored in the Adj-RIBs-Out will be carried in
      the local BGP speaker's UPDATE messages and advertised to its
      peers.

   In summary, the Adj-RIBs-In contain unprocessed routing information
   that has been advertised to the local BGP speaker by its peers; the
   Loc-RIB contains the routes that have been selected by the local BGP
   speaker's Decision Process; and the Adj-RIBs-Out organize the routes
   for advertisement to specific peers by means of the local speaker's
   UPDATE messages.

   Although the conceptual model distinguishes between Adj-RIBs-In, =
Loc-
   RIB, and Adj-RIBs-Out, this neither implies nor requires that an
   implementation must maintain three separate copies of the routing
   information. The choice of implementation (for example, 3 copies of
   the information vs 1 copy with pointers) is not constrained by the
   protocol.

   Routing information that the router uses to forward packets (or to
   construct the forwarding table that is used for packet forwarding) =
is
   maintained in the Routing Table. The Routing Table accumulates =
routes
   to directly connected networks, static routes, routes learned from
   the IGP protocols, and routes learned from BGP.  Whether or not a
   specific BGP route should be installed in the Routing Table, and
   whether a BGP route should override a route to the same destination



Expiration Date July 2002                                       =
=0C[Page 6]





RFC DRAFT                                                   January =
2002


   installed by another source is a local policy decision, not =
specified
   in this document. Besides actual packet forwarding, the Routing =
Table
   is used for resolution of the next-hop addresses specified in BGP
   updates (see Section 9.1.2).


4. Message Formats

   This section describes message formats used by BGP.

   Messages are sent over a reliable transport protocol connection. A
   message is processed only after it is entirely received. The maximum
   message size is 4096 octets. All implementations are required to
   support this maximum message size. The smallest message that may be
   sent consists of a BGP header without a data portion, or 19 octets.


4.1 Message Header Format

   Each message has a fixed-size header. There may or may not be a data
   portion following the header, depending on the message type. The
   layout of these fields is shown below:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                                                               +
      |                           Marker                              |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Length               |      Type     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Marker:

         This 16-octet field contains a value that the receiver of the
         message can predict. If the Type of the message is OPEN, or if
         the OPEN message carries no Authentication Information (as an
         Optional Parameter), then the Marker must be all ones.
         Otherwise, the value of the marker can be predicted by some a
         computation specified as part of the authentication mechanism
         (which is specified as part of the Authentication Information)
         used. The Marker can be used to detect loss of synchronization



Expiration Date July 2002                                       =
=0C[Page 7]





RFC DRAFT                                                   January =
2002


         between a pair of BGP peers, and to authenticate incoming BGP
         messages.

      Length:

         This 2-octet unsigned integer indicates the total length of =
the
         message, including the header, in octets. Thus, e.g., it =
allows
         one to locate in the transport-level stream the (Marker field
         of the) next message. The value of the Length field must =
always
         be at least 19 and no greater than 4096, and may be further
         constrained, depending on the message type. No "padding" of
         extra data after the message is allowed, so the Length field
         must have the smallest value required given the rest of the
         message.

      Type:

         This 1-octet unsigned integer indicates the type code of the
         message. The following type codes are defined:

                                    1 - OPEN
                                    2 - UPDATE
                                    3 - NOTIFICATION
                                    4 - KEEPALIVE

4.2 OPEN Message Format

   After a transport protocol connection is established, the first
   message sent by each side is an OPEN message. If the OPEN message is
   acceptable, a KEEPALIVE message confirming the OPEN is sent back.
   Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION
   messages may be exchanged.

   In addition to the fixed-size BGP header, the OPEN message contains
   the following fields:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+
       |    Version    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     My Autonomous System      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Hold Time           |
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         BGP Identifier                        =
|
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Opt Parm Len  |



Expiration Date July 2002                                       =
=0C[Page 8]





RFC DRAFT                                                   January =
2002


       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               =
|
       |             Optional Parameters (variable)                    =
|
       |                                                               =
|
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Version:

         This 1-octet unsigned integer indicates the protocol version
         number of the message. The current BGP version number is 4.

      My Autonomous System:

         This 2-octet unsigned integer indicates the Autonomous System
         number of the sender.

      Hold Time:

         This 2-octet unsigned integer indicates the number of seconds
         that the sender proposes for the value of the Hold Timer. Upon
         receipt of an OPEN message, a BGP speaker MUST calculate the
         value of the Hold Timer by using the smaller of its configured
         Hold Time and the Hold Time received in the OPEN message. The
         Hold Time MUST be either zero or at least three seconds.  An
         implementation may reject connections on the basis of the Hold
         Time.  The calculated value indicates the maximum number of
         seconds that may elapse between the receipt of successive
         KEEPALIVE, and/or UPDATE messages by the sender.

      BGP Identifier:

         This 4-octet unsigned integer indicates the BGP Identifier of
         the sender. A given BGP speaker sets the value of its BGP
         Identifier to an IP address assigned to that BGP speaker.  The
         value of the BGP Identifier is determined on startup and is =
the
         same for every local interface and every BGP peer.

      Optional Parameters Length:

         This 1-octet unsigned integer indicates the total length of =
the
         Optional Parameters field in octets. If the value of this =
field
         is zero, no Optional Parameters are present.

      Optional Parameters:

         This field may contain a list of optional parameters, where
         each parameter is encoded as a <Parameter Type, Parameter



Expiration Date July 2002                                       =
=0C[Page 9]





RFC DRAFT                                                   January =
2002


         Length, Parameter Value> triplet.

               0                   1
               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
               |  Parm. Type   | Parm. Length  |  Parameter Value =
(variable)
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

         Parameter Type is a one octet field that unambiguously
         identifies individual parameters. Parameter Length is a one
         octet field that contains the length of the Parameter Value
         field in octets.  Parameter Value is a variable length field
         that is interpreted according to the value of the Parameter
         Type field.

         This document defines the following Optional Parameters:

         a) Authentication Information (Parameter Type 1):


            This optional parameter may be used to authenticate a BGP
            peer. The Parameter Value field contains a 1-octet
            Authentication Code followed by a variable length
            Authentication Data.

                0 1 2 3 4 5 6 7 8
                +-+-+-+-+-+-+-+-+
                |  Auth. Code   |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |                                                     |
                |              Authentication Data                    |
                |                                                     |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Authentication Code:

                  This 1-octet unsigned integer indicates the
                  authentication mechanism being used. Whenever an
                  authentication mechanism is specified for use within
                  BGP, three things must be included in the
                  specification:

                  - the value of the Authentication Code which =
indicates
                  use of the mechanism,
                  - the form and meaning of the Authentication Data, =
and
                  - the algorithm for computing values of Marker =
fields.




Expiration Date July 2002                                      =0C[Page =
10]





RFC DRAFT                                                   January =
2002


                  Note that a separate authentication mechanism may be
                  used in establishing the transport level connection.

               Authentication Data:

                  Authentication Data is a variable length field that =
is
                  interpreted according to the value of the
                  Authentication Code field.


         The minimum length of the OPEN message is 29 octets (including
         message header).


4.3 UPDATE Message Format


   UPDATE messages are used to transfer routing information between BGP
   peers. The information in the UPDATE packet can be used to construct
   a graph describing the relationships of the various Autonomous
   Systems. By applying rules to be discussed, routing information =
loops
   and some other anomalies may be detected and removed from inter-AS
   routing.

   An UPDATE message is used to advertise feasible routes sharing =
common
   path attribute to a peer, or to withdraw multiple unfeasible routes
   from service (see 3.1). An UPDATE message may simultaneously
   advertise a feasible route and withdraw multiple unfeasible routes
   from service. The UPDATE message always includes the fixed-size BGP
   header, and also includes the other fields as shown below (note, =
some
   of the shown fields may not be present in every UPDATE message):


      +-----------------------------------------------------+
      |   Withdrawn Routes Length (2 octets)                |
      +-----------------------------------------------------+
      |   Withdrawn Routes (variable)                       |
      +-----------------------------------------------------+
      |   Total Path Attribute Length (2 octets)            |
      +-----------------------------------------------------+
      |   Path Attributes (variable)                        |
      +-----------------------------------------------------+
      |   Network Layer Reachability Information (variable) |
      +-----------------------------------------------------+



      Withdrawn Routes Length:



Expiration Date July 2002                                      =0C[Page =
11]





RFC DRAFT                                                   January =
2002


         This 2-octets unsigned integer indicates the total length of
         the Withdrawn Routes field in octets.  Its value must allow =
the
         length of the Network Layer Reachability Information field to
         be determined as specified below.

         A value of 0 indicates that no routes are being withdrawn from
         service, and that the WITHDRAWN ROUTES field is not present in
         this UPDATE message.

      Withdrawn Routes:


         This is a variable length field that contains a list of IP
         address prefixes for the routes that are being withdrawn from
         service. Each IP address prefix is encoded as a 2-tuple of the
         form <length, prefix>, whose fields are described below:

                  +---------------------------+
                  |   Length (1 octet)        |
                  +---------------------------+
                  |   Prefix (variable)       |
                  +---------------------------+


         The use and the meaning of these fields are as follows:

         a) Length:

            The Length field indicates the length in bits of the IP
            address prefix. A length of zero indicates a prefix that
            matches all IP addresses (with prefix, itself, of zero
            octets).

         b) Prefix:

            The Prefix field contains an IP address prefix followed by
            enough trailing bits to make the end of the field fall on =
an
            octet boundary. Note that the value of trailing bits is
            irrelevant.

      Total Path Attribute Length:

         This 2-octet unsigned integer indicates the total length of =
the
         Path Attributes field in octets. Its value must allow the
         length of the Network Layer Reachability field to be =
determined
         as specified below.

         A value of 0 indicates that no Network Layer Reachability



Expiration Date July 2002                                      =0C[Page =
12]





RFC DRAFT                                                   January =
2002


         Information field is present in this UPDATE message.

      Path Attributes:

         A variable length sequence of path attributes is present in
         every UPDATE. Each path attribute is a triple <attribute type,
         attribute length, attribute value> of variable length.

         Attribute Type is a two-octet field that consists of the
         Attribute Flags octet followed by the Attribute Type Code
         octet.




               0                   1
               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |  Attr. Flags  |Attr. Type Code|
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


         The high-order bit (bit 0) of the Attribute Flags octet is the
         Optional bit. It defines whether the attribute is optional (if
         set to 1) or well-known (if set to 0).

         The second high-order bit (bit 1) of the Attribute Flags octet
         is the Transitive bit. It defines whether an optional =
attribute
         is transitive (if set to 1) or non-transitive (if set to 0).
         For well-known attributes, the Transitive bit must be set to =
1.
         (See Section 5 for a discussion of transitive attributes.)

         The third high-order bit (bit 2) of the Attribute Flags octet
         is the Partial bit. It defines whether the information
         contained in the optional transitive attribute is partial (if
         set to 1) or complete (if set to 0). For well-known attributes
         and for optional non-transitive attributes the Partial bit =
must
         be set to 0.

         The fourth high-order bit (bit 3) of the Attribute Flags octet
         is the Extended Length bit. It defines whether the Attribute
         Length is one octet (if set to 0) or two octets (if set to 1).

         The lower-order four bits of the Attribute Flags octet are
         unused. They must be zero when sent and must be ignored when
         received.

         The Attribute Type Code octet contains the Attribute Type =
Code.



Expiration Date July 2002                                      =0C[Page =
13]





RFC DRAFT                                                   January =
2002


         Currently defined Attribute Type Codes are discussed in =
Section
         5.

         If the Extended Length bit of the Attribute Flags octet is set
         to 0, the third octet of the Path Attribute contains the =
length
         of the attribute data in octets.

         If the Extended Length bit of the Attribute Flags octet is set
         to 1, then the third and the fourth octets of the path
         attribute contain the length of the attribute data in octets.

         The remaining octets of the Path Attribute represent the
         attribute value and are interpreted according to the Attribute
         Flags and the Attribute Type Code. The supported Attribute =
Type
         Codes, their attribute values and uses are the following:

         a)   ORIGIN (Type Code 1):

            ORIGIN is a well-known mandatory attribute that defines the
            origin of the path information.  The data octet can assume
            the following values:

                  Value      Meaning

                  0         IGP - Network Layer Reachability =
Information
                               is interior to the originating AS

                  1         EGP - Network Layer Reachability =
Information
                               learned via the EGP protocol

                  2         INCOMPLETE - Network Layer Reachability
                               Information learned by some other means

            Its usage is defined in 5.1.1

         b) AS_PATH (Type Code 2):

            AS_PATH is a well-known mandatory attribute that is =
composed
            of a sequence of AS path segments. Each AS path segment is
            represented by a triple <path segment type, path segment
            length, path segment value>.

            The path segment type is a 1-octet long field with the
            following values defined:

                  Value      Segment Type

                  1         AS_SET: unordered set of ASs a route in the



Expiration Date July 2002                                      =0C[Page =
14]





RFC DRAFT                                                   January =
2002


                               UPDATE message has traversed

                  2         AS_SEQUENCE: ordered set of ASs a route in
                               the UPDATE message has traversed

            The path segment length is a 1-octet long field containing
            the number of ASs in the path segment value field.

            The path segment value field contains one or more AS
            numbers, each encoded as a 2-octets long field.

            Usage of this attribute is defined in 5.1.2.

         c)   NEXT_HOP (Type Code 3):

            This is a well-known mandatory attribute that defines the =
IP
            address of the border router that should be used as the =
next
            hop to the destinations listed in the Network Layer
            Reachability Information field of the UPDATE message.

            Usage of this attribute is defined in 5.1.3.


         d) MULTI_EXIT_DISC (Type Code 4):

            This is an optional non-transitive attribute that is a four
            octet non-negative integer. The value of this attribute may
            be used by a BGP speaker's decision process to discriminate
            among multiple entry points to a neighboring autonomous
            system.

            Its usage is defined in 5.1.4.

         e) LOCAL_PREF (Type Code 5):

            LOCAL_PREF is a well-known attribute that is a four octet
            non-negative integer. A BGP speaker uses it to inform other
            internal peers of the advertising speaker's degree of
            preference for an advertised route. Usage of this attribute
            is described in 5.1.5.

         f) ATOMIC_AGGREGATE (Type Code 6)

            ATOMIC_AGGREGATE is a well-known discretionary attribute of
            length 0. Usage of this attribute is described in 5.1.6.

         g) AGGREGATOR (Type Code 7)




Expiration Date July 2002                                      =0C[Page =
15]





RFC DRAFT                                                   January =
2002


            AGGREGATOR is an optional transitive attribute of length 6.
            The attribute contains the last AS number that formed the
            aggregate route (encoded as 2 octets), followed by the IP
            address of the BGP speaker that formed the aggregate route
            (encoded as 4 octets).  This should be the same address as
            the one used for the BGP Identifier of the speaker.  Usage
            of this attribute is described in 5.1.7.

      Network Layer Reachability Information:

         This variable length field contains a list of IP address
         prefixes. The length in octets of the Network Layer
         Reachability Information is not encoded explicitly, but can be
         calculated as:

            UPDATE message Length - 23 - Total Path Attributes Length -
            Withdrawn Routes Length

         where UPDATE message Length is the value encoded in the fixed-
         size BGP header, Total Path Attribute Length and Withdrawn
         Routes Length are the values encoded in the variable part of
         the UPDATE message, and 23 is a combined length of the fixed-
         size BGP header, the Total Path Attribute Length field and the
         Withdrawn Routes Length field.

         Reachability information is encoded as one or more 2-tuples of
         the form <length, prefix>, whose fields are described below:


                  +---------------------------+
                  |   Length (1 octet)        |
                  +---------------------------+
                  |   Prefix (variable)       |
                  +---------------------------+


         The use and the meaning of these fields are as follows:

         a) Length:

            The Length field indicates the length in bits of the IP
            address prefix. A length of zero indicates a prefix that
            matches all IP addresses (with prefix, itself, of zero
            octets).

         b) Prefix:

            The Prefix field contains IP address prefixes followed by



Expiration Date July 2002                                      =0C[Page =
16]





RFC DRAFT                                                   January =
2002


            enough trailing bits to make the end of the field fall on =
an
            octet boundary. Note that the value of the trailing bits is
            irrelevant.

   The minimum length of the UPDATE message is 23 octets -- 19 octets
   for the fixed header + 2 octets for the Withdrawn Routes Length + 2
   octets for the Total Path Attribute Length (the value of Withdrawn
   Routes Length is 0 and the value of Total Path Attribute Length is
   0).

   An UPDATE message can advertise at most one set of path attributes,
   but multiple destinations, provided that the destinations share =
these
   attributes. All path attributes contained in a given UPDATE message
   apply to all destinations carried in the NLRI field of the UPDATE
   message.

   An UPDATE message can list multiple routes to be withdrawn from
   service.  Each such route is identified by its destination =
(expressed
   as an IP prefix), which unambiguously identifies the route in the
   context of the BGP speaker - BGP speaker connection to which it has
   been previously advertised.

   An UPDATE message might advertise only routes to be withdrawn from
   service, in which case it will not include path attributes or =
Network
   Layer Reachability Information. Conversely, it may advertise only a
   feasible route, in which case the WITHDRAWN ROUTES field need not be
   present.

   An UPDATE message should not include the same address prefix in the
   WITHDRAWN ROUTES and Network Layer Reachability Information fields,
   however a BGP speaker MUST be able to process UPDATE messages in =
this
   form. A BGP speaker should treat an UPDATE message of this form as =
if
   the WITHDRAWN ROUTES doesn't contain the address prefix.


4.4 KEEPALIVE Message Format


   BGP does not use any transport protocol-based keep-alive mechanism =
to
   determine if peers are reachable. Instead, KEEPALIVE messages are
   exchanged between peers often enough as not to cause the Hold Timer
   to expire. A reasonable maximum time between KEEPALIVE messages =
would
   be one third of the Hold Time interval. KEEPALIVE messages MUST NOT
   be sent more frequently than one per second. An implementation MAY
   adjust the rate at which it sends KEEPALIVE messages as a function =
of
   the Hold Time interval.

   If the negotiated Hold Time interval is zero, then periodic =
KEEPALIVE



Expiration Date July 2002                                      =0C[Page =
17]





RFC DRAFT                                                   January =
2002


   messages MUST NOT be sent.

   KEEPALIVE message consists of only message header and has a length =
of
   19 octets.


4.5 NOTIFICATION Message Format


   A NOTIFICATION message is sent when an error condition is detected.
   The BGP connection is closed immediately after sending it.

   In addition to the fixed-size BGP header, the NOTIFICATION message
   contains the following fields:


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Error code    | Error subcode |   Data (variable)             =
|
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



      Error Code:

         This 1-octet unsigned integer indicates the type of
         NOTIFICATION. The following Error Codes have been defined:

            Error Code       Symbolic Name               Reference

              1         Message Header Error             Section 6.1

              2         OPEN Message Error               Section 6.2

              3         UPDATE Message Error             Section 6.3

              4         Hold Timer Expired               Section 6.5

              5         Finite State Machine Error       Section 6.6

              6         Cease                            Section 6.7


      Error subcode:

         This 1-octet unsigned integer provides more specific
         information about the nature of the reported error.  Each =
Error



Expiration Date July 2002                                      =0C[Page =
18]





RFC DRAFT                                                   January =
2002


         Code may have one or more Error Subcodes associated with it. =
If
         no appropriate Error Subcode is defined, then a zero
         (Unspecific) value is used for the Error Subcode field.

         Message Header Error subcodes:

                               1  - Connection Not Synchronized.
                               2  - Bad Message Length.
                               3  - Bad Message Type.

         OPEN Message Error subcodes:

                               1  - Unsupported Version Number.
                               2  - Bad Peer AS.
                               3  - Bad BGP Identifier.
                               4  - Unsupported Optional Parameter.
                               5  - Authentication Failure.
                               6  - Unacceptable Hold Time.

         UPDATE Message Error subcodes:

                               1 - Malformed Attribute List.
                               2 - Unrecognized Well-known Attribute.
                               3 - Missing Well-known Attribute.
                               4 - Attribute Flags Error.
                               5 - Attribute Length Error.
                               6 - Invalid ORIGIN Attribute
                               8 - Invalid NEXT_HOP Attribute.
                               9 - Optional Attribute Error.
                              10 - Invalid Network Field.
                              11 - Malformed AS_PATH.


      Data:

         This variable-length field is used to diagnose the reason for
         the NOTIFICATION. The contents of the Data field depend upon
         the Error Code and Error Subcode. See Section 6 below for more
         details.

         Note that the length of the Data field can be determined from
         the message Length field by the formula:

                  Message Length =3D 21 + Data Length


   The minimum length of the NOTIFICATION message is 21 octets
   (including message header).



Expiration Date July 2002                                      =0C[Page =
19]





RFC DRAFT                                                   January =
2002


5. Path Attributes


   This section discusses the path attributes of the UPDATE message.

   Path attributes fall into four separate categories:

               1. Well-known mandatory.
               2. Well-known discretionary.
               3. Optional transitive.
               4. Optional non-transitive.

   Well-known attributes must be recognized by all BGP implementations.
   Some of these attributes are mandatory and must be included in every
   UPDATE message that contains NLRI. Others are discretionary and may
   or may not be sent in a particular UPDATE message.

   All well-known attributes must be passed along (after proper
   updating, if necessary) to other BGP peers.

   In addition to well-known attributes, each path may contain one or
   more optional attributes. It is not required or expected that all =
BGP
   implementations support all optional attributes. The handling of an
   unrecognized optional attribute is determined by the setting of the
   Transitive bit in the attribute flags octet. Paths with unrecognized
   transitive optional attributes should be accepted. If a path with
   unrecognized transitive optional attribute is accepted and passed
   along to other BGP peers, then the unrecognized transitive optional
   attribute of that path must be passed along with the path to other
   BGP peers with the Partial bit in the Attribute Flags octet set to =
1.
   If a path with recognized transitive optional attribute is accepted
   and passed along to other BGP peers and the Partial bit in the
   Attribute Flags octet is set to 1 by some previous AS, it is not set
   back to 0 by the current AS. Unrecognized non-transitive optional
   attributes must be quietly ignored and not passed along to other BGP
   peers.

   New transitive optional attributes may be attached to the path by =
the
   originator or by any other BGP speaker in the path. If they are not
   attached by the originator, the Partial bit in the Attribute Flags
   octet is set to 1. The rules for attaching new non-transitive
   optional attributes will depend on the nature of the specific
   attribute. The documentation of each new non-transitive optional
   attribute will be expected to include such rules. (The description =
of
   the MULTI_EXIT_DISC attribute gives an example.) All optional
   attributes (both transitive and non-transitive) may be updated (if
   appropriate) by BGP speakers in the path.




Expiration Date July 2002                                      =0C[Page =
20]





RFC DRAFT                                                   January =
2002


   The sender of an UPDATE message should order path attributes within
   the UPDATE message in ascending order of attribute type. The =
receiver
   of an UPDATE message must be prepared to handle path attributes
   within the UPDATE message that are out of order.

   The same attribute cannot appear more than once within the Path
   Attributes field of a particular UPDATE message.

   The mandatory category refers to an attribute which must be present
   in both IBGP and EBGP exchanges if NLRI are contained in the UPDATE
   message.  Attributes classified as optional for the purpose of the
   protocol extension mechanism may be purely discretionary, or
   discretionary, required, or disallowed in certain contexts.

        attribute           EBGP                    IBGP
         ORIGIN             mandatory               mandatory
         AS_PATH            mandatory               mandatory
         NEXT_HOP           mandatory               mandatory
         MULTI_EXIT_DISC    discretionary           discretionary
         LOCAL_PREF         disallowed              required
         ATOMIC_AGGREGATE   see section 5.1.6 and 9.1.4
         AGGREGATOR         discretionary           discretionary




5.1 Path Attribute Usage


   The usage of each BGP path attributes is described in the following
   clauses.



5.1.1 ORIGIN


   ORIGIN is a well-known mandatory attribute.  The ORIGIN attribute
   shall be generated by the autonomous system that originates the
   associated routing information. It shall be included in the UPDATE
   messages of all BGP speakers that choose to propagate this
   information to other BGP speakers.


5.1.2 AS_PATH


   AS_PATH is a well-known mandatory attribute. This attribute



Expiration Date July 2002                                      =0C[Page =
21]





RFC DRAFT                                                   January =
2002


   identifies the autonomous systems through which routing information
   carried in this UPDATE message has passed. The components of this
   list can be AS_SETs or AS_SEQUENCEs.

   When a BGP speaker propagates a route which it has learned from
   another BGP speaker's UPDATE message, it shall modify the route's
   AS_PATH attribute based on the location of the BGP speaker to which
   the route will be sent:

      a) When a given BGP speaker advertises the route to an internal
      peer, the advertising speaker shall not modify the AS_PATH
      attribute associated with the route.

      b) When a given BGP speaker advertises the route to an external
      peer, then the advertising speaker shall update the AS_PATH
      attribute as follows:

         1) if the first path segment of the AS_PATH is of type
         AS_SEQUENCE, the local system shall prepend its own AS number
         as the last element of the sequence (put it in the leftmost
         position). If the act of prepending will cause an overflow in
         the AS_PATH segment, i.e. more than 255 elements, it shall be
         legal to prepend a new segment of type AS_SEQUENCE and prepend
         its own AS number to this new segment.

         2) if the first path segment of the AS_PATH is of type AS_SET,
         the local system shall prepend a new path segment of type
         AS_SEQUENCE to the AS_PATH, including its own AS number in =
that
         segment.

   When a BGP speaker originates a route then:

      a) the originating speaker shall include its own AS number in a
      path segment of type AS_SEQUENCE in the AS_PATH attribute of all
      UPDATE messages sent to an external peer. (In this case, the AS
      number of the originating speaker's autonomous system will be the
      only entry the path segment, and this path segment will be the
      only segment in the AS_PATH attribute).

      b) the originating speaker shall include an empty AS_PATH
      attribute in all UPDATE messages sent to internal peers.  (An
      empty AS_PATH attribute is one whose length field contains the
      value zero).

   Whenever the modification of the AS_PATH attribute calls for
   including or prepending the AS number of the local system, the local
   system may include/prepend more than one instance of its own AS
   number in the AS_PATH attribute. This is controlled via local



Expiration Date July 2002                                      =0C[Page =
22]





RFC DRAFT                                                   January =
2002


   configuration.


5.1.3 NEXT_HOP



   The NEXT_HOP path attribute defines the IP address of the border
   router that should be used as the next hop to the destinations =
listed
   in the UPDATE message. The NEXT_HOP attribute is calculated as
   follows.

      1) When sending a message to an internal peer, the BGP speaker
      should not modify the NEXT_HOP attribute, unless it has been
      explicitly configured to announce its own IP address as the
      NEXT_HOP.

      2) When sending a message to an external peer X, and the peer is
      one IP hop away from the speaker:

         - If the route being announced was learned from an internal
         peer or is locally originated, the BGP speaker can use for the
         NEXT_HOP attribute an interface address of the internal peer
         router (or the internal router) through which the announced
         network is reachable for the speaker, provided that peer X
         shares a common subnet with this address. This is a form of
         "third party" NEXT_HOP attribute.

         - If the route being announced was learned from an external
         peer, the speaker can use in the NEXT_HOP attribute an IP
         address of any adjacent router (known from the received
         NEXT_HOP attribute) that the speaker itself uses for local
         route calculation, provided that peer X shares a common subnet
         with this address. This is a second form of "third party"
         NEXT_HOP attribute.

         - If the external peer to which the route is being advertised
         shares a common subnet with one of the announcing router's own
         interfaces, the router may use the IP address associated with
         such an interface in the NEXT_HOP attribute. This is known as =
a
         "first party" NEXT_HOP attribute.

         - By default (if none of the above conditions apply), the BGP
         speaker should use in the NEXT_HOP attribute the IP address of
         the interface that the speaker uses to establish the BGP
         session to peer X.

      3) When sending a message to an external peer X, and the peer is



Expiration Date July 2002                                      =0C[Page =
23]





RFC DRAFT                                                   January =
2002


      multiple IP hops away from the speaker (aka "multihop EBGP"):

         - The speaker may be configured to propagate the NEXT_HOP
         attribute.  In this case when advertising a route that the
         speaker learned from one of its peers, the NEXT_HOP attribute
         of the advertised route is exactly the same as the NEXT_HOP
         attribute of the learned route (the speaker just doesn't =
modify
         the NEXT_HOP attribute).

         - By default, the BGP speaker should use in the NEXT_HOP
         attribute the IP address of the interface that the speaker =
uses
         to establish the BGP session to peer X.

   Normally the NEXT_HOP attribute is chosen such that the shortest
   available path will be taken. A BGP speaker must be able to support
   disabling advertisement of third party NEXT_HOP attributes to handle
   imperfectly bridged media.

   A BGP speaker must never advertise an address of a peer to that peer
   as a NEXT_HOP, for a route that the speaker is originating. A BGP
   speaker must never install a route with itself as the next hop.

   The NEXT_HOP attribute is used by the BGP speaker to determine the
   actual outbound interface and immediate next-hop address that should
   be used to forward transit packets to the associated destinations.
   The immediate next-hop address is determined by performing a
   recursive route lookup operation for the IP address in the NEXT_HOP
   attribute using the contents of the Routing Table (see Section
   9.1.2.2). The resolving route will always specify the outbound
   interface. If the resolving route specifies the next-hop address,
   this address should be used as the immediate address for packet
   forwarding. If the address in the NEXT_HOP attribute is directly
   resolved through a route to an attached subnet (such a route will =
not
   specify the next-hop address), the outbound interface should be =
taken
   from the resolving route and the address in the NEXT_HOP attribute
   should be used as the immediate next-hop address.


5.1.4 MULTI_EXIT_DISC


   The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
   links to discriminate among multiple exit or entry points to the =
same
   neighboring AS. The value of the MULTI_EXIT_DISC attribute is a four
   octet unsigned number which is called a metric. All other factors
   being equal, the exit point with lower metric should be preferred. =
If
   received over external links, the MULTI_EXIT_DISC attribute MAY be
   propagated over internal links to other BGP speakers within the same



Expiration Date July 2002                                      =0C[Page =
24]





RFC DRAFT                                                   January =
2002


   AS. The MULTI_EXIT_DISC attribute received from a neighboring AS =
MUST
   NOT be propagated to other neighboring ASs.

   A BGP speaker MUST IMPLEMENT a mechanism based on local =
configuration
   which allows the MULTI_EXIT_DISC attribute to be removed from a
   route. This MAY be done prior to determining the degree of =
preference
   of the route and performing route selection (decision process phases
   1 and 2).

   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over an external
   link.  If it does so, it shall do so prior to determining the degree
   of preference of the route and performing route selection (decision
   process phases 1 and 2).


5.1.5 LOCAL_PREF


   LOCAL_PREF is a well-known attribute that SHALL be included in all
   UPDATE messages that a given BGP speaker sends to the other internal
   peers. A BGP speaker SHALL calculate the degree of preference for
   each external route based on the locally configured policy, and
   include the degree of preference when advertising a route to its
   internal peers. The higher degree of preference MUST be preferred.  =
A
   BGP speaker shall use the degree of preference learned via =
LOCAL_PREF
   in its decision process (see section 9.1.1).

   A BGP speaker MUST NOT include this attribute in UPDATE messages =
that
   it sends to external peers, except for the case of BGP =
Confederations
   [13]. If it is contained in an UPDATE message that is received from
   an external peer, then this attribute MUST be ignored by the
   receiving speaker, except for the case of BGP Confederations [13].


5.1.6 ATOMIC_AGGREGATE


   ATOMIC_AGGREGATE is a well-known discretionary attribute.

   When a router aggregates several routes for the purpose of
   advertisement to a particular peer, and the AS_PATH of the =
aggregated
   route excludes at least some of the AS numbers present in the =
AS_PATH
   of the routes that are aggregated, the aggregated route, when
   advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.

   A BGP speaker that receives a route with the ATOMIC_AGGREGATE
   attribute MUST NOT remove the attribute from the route when



Expiration Date July 2002                                      =0C[Page =
25]





RFC DRAFT                                                   January =
2002


   propagating it to other speakers.

   A BGP speaker that receives a route with the ATOMIC_AGGREGATE
   attribute MUST NOT make any NLRI of that route more specific (as
   defined in 9.1.4) when advertising this route to other BGP speakers.

   A BGP speaker that receives a route with the ATOMIC_AGGREGATE
   attribute needs to be cognizant of the fact that the actual path to
   destinations, as specified in the NLRI of the route, while having =
the
   loop-free property, may not be the path specified in the AS_PATH
   attribute of the route.


5.1.7 AGGREGATOR


   AGGREGATOR is an optional transitive attribute which may be included
   in updates which are formed by aggregation (see Section 9.2.2.2). A
   BGP speaker which performs route aggregation may add the AGGREGATOR
   attribute which shall contain its own AS number and IP address. The
   IP address should be the same as the BGP Identifier of the speaker.


6. BGP Error Handling.


   This section describes actions to be taken when errors are detected
   while processing BGP messages.

   When any of the conditions described here are detected, a
   NOTIFICATION message with the indicated Error Code, Error Subcode,
   and Data fields is sent, and the BGP connection is closed. If no
   Error Subcode is specified, then a zero must be used.

   The phrase "the BGP connection is closed" means that the transport
   protocol connection has been closed, the associated Adj-RIB-In has
   been cleared, and that all resources for that BGP connection have
   been deallocated. Entries in the Loc-RIB associated with the remote
   peer are marked as invalid. The fact that the routes have become
   invalid is passed to other BGP peers before the routes are deleted
   from the system.

   Unless specified explicitly, the Data field of the NOTIFICATION
   message that is sent to indicate an error is empty.







Expiration Date July 2002                                      =0C[Page =
26]





RFC DRAFT                                                   January =
2002


6.1 Message Header error handling.


   All errors detected while processing the Message Header are =
indicated
   by sending the NOTIFICATION message with Error Code Message Header
   Error. The Error Subcode elaborates on the specific nature of the
   error.

   The expected value of the Marker field of the message header is all
   ones if the message type is OPEN. The expected value of the Marker
   field for all other types of BGP messages determined based on the
   presence of the Authentication Information Optional Parameter in the
   BGP OPEN message and the actual authentication mechanism (if the
   Authentication Information in the BGP OPEN message is present). The
   Marker field should be all ones if the OPEN message carried no
   authentication information. If the Marker field of the message =
header
   is not the expected one, then a synchronization error has occurred
   and the Error Subcode is set to Connection Not Synchronized.

   If the Length field of the message header is less than 19 or greater
   than 4096, or if the Length field of an OPEN message is less than =
the
   minimum length of the OPEN message, or if the Length field of an
   UPDATE message is less than the minimum length of the UPDATE =
message,
   or if the Length field of a KEEPALIVE message is not equal to 19, or
   if the Length field of a NOTIFICATION message is less than the
   minimum length of the NOTIFICATION message, then the Error Subcode =
is
   set to Bad Message Length. The Data field contains the erroneous
   Length field.

   If the Type field of the message header is not recognized, then the
   Error Subcode is set to Bad Message Type. The Data field contains =
the
   erroneous Type field.


6.2 OPEN message error handling.


   All errors detected while processing the OPEN message are indicated
   by sending the NOTIFICATION message with Error Code OPEN Message
   Error. The Error Subcode elaborates on the specific nature of the
   error.

   If the version number contained in the Version field of the received
   OPEN message is not supported, then the Error Subcode is set to
   Unsupported Version Number. The Data field is a 2-octets unsigned
   integer, which indicates the largest locally supported version =
number
   less than the version the remote BGP peer bid (as indicated in the
   received OPEN message), or if the smallest locally supported version



Expiration Date July 2002                                      =0C[Page =
27]





RFC DRAFT                                                   January =
2002


   number is greater than the version the remote BGP peer bid, then the
   smallest locally supported version number.

   If the Autonomous System field of the OPEN message is unacceptable,
   then the Error Subcode is set to Bad Peer AS. The determination of
   acceptable Autonomous System numbers is outside the scope of this
   protocol.

   If the Hold Time field of the OPEN message is unacceptable, then the
   Error Subcode MUST be set to Unacceptable Hold Time. An
   implementation MUST reject Hold Time values of one or two seconds.
   An implementation MAY reject any proposed Hold Time. An
   implementation which accepts a Hold Time MUST use the negotiated
   value for the Hold Time.

   If the BGP Identifier field of the OPEN message is syntactically
   incorrect, then the Error Subcode is set to Bad BGP Identifier.
   Syntactic correctness means that the BGP Identifier field represents
   a valid IP host address.

   If one of the Optional Parameters in the OPEN message is not
   recognized, then the Error Subcode is set to Unsupported Optional
   Parameters.

   If one of the Optional Parameters in the OPEN message is recognized,
   but is malformed, then the Error Subcode is set to 0 (Unspecific).


   If the OPEN message carries Authentication Information (as an
   Optional Parameter), then the corresponding authentication procedure
   is invoked. If the authentication procedure (based on Authentication
   Code and Authentication Data) fails, then the Error Subcode is set =
to
   Authentication Failure.



6.3 UPDATE message error handling.


   All errors detected while processing the UPDATE message are =
indicated
   by sending the NOTIFICATION message with Error Code UPDATE Message
   Error. The error subcode elaborates on the specific nature of the
   error.

   Error checking of an UPDATE message begins by examining the path
   attributes. If the Withdrawn Routes Length or Total Attribute Length
   is too large (i.e., if Withdrawn Routes Length + Total Attribute
   Length + 23 exceeds the message Length), then the Error Subcode is



Expiration Date July 2002                                      =0C[Page =
28]





RFC DRAFT                                                   January =
2002


   set to Malformed Attribute List.

   If any recognized attribute has Attribute Flags that conflict with
   the Attribute Type Code, then the Error Subcode is set to Attribute
   Flags Error. The Data field contains the erroneous attribute (type,
   length and value).

   If any recognized attribute has Attribute Length that conflicts with
   the expected length (based on the attribute type code), then the
   Error Subcode is set to Attribute Length Error. The Data field
   contains the erroneous attribute (type, length and value).

   If any of the mandatory well-known attributes are not present, then
   the Error Subcode is set to Missing Well-known Attribute. The Data
   field contains the Attribute Type Code of the missing well-known
   attribute.

   If any of the mandatory well-known attributes are not recognized,
   then the Error Subcode is set to Unrecognized Well-known Attribute.
   The Data field contains the unrecognized attribute (type, length and
   value).

   If the ORIGIN attribute has an undefined value, then the Error
   Subcode is set to Invalid Origin Attribute. The Data field contains
   the unrecognized attribute (type, length and value).

   If the NEXT_HOP attribute field is syntactically incorrect, then the
   Error Subcode is set to Invalid NEXT_HOP Attribute.  The Data field
   contains the incorrect attribute (type, length and value).  =
Syntactic
   correctness means that the NEXT_HOP attribute represents a valid IP
   host address.  Semantic correctness applies only to the external BGP
   links, and only when the sender and the receiving speaker are one IP
   hop away from each other. To be semantically correct, the IP address
   in the NEXT_HOP must not be the IP address of the receiving speaker,
   and the NEXT_HOP IP address must either be the sender's IP address
   (used to establish the BGP session), or the interface associated =
with
   the NEXT_HOP IP address must share a common subnet with the =
receiving
   BGP speaker. If the NEXT_HOP attribute is semantically incorrect, =
the
   error should be logged, and the route should be ignored. In this
   case, no NOTIFICATION message should be sent.

   The AS_PATH attribute is checked for syntactic correctness. If the
   path is syntactically incorrect, then the Error Subcode is set to
   Malformed AS_PATH.


   The information carried by the AS_PATH attribute is checked for AS
   loops. AS loop detection is done by scanning the full AS path (as



Expiration Date July 2002                                      =0C[Page =
29]





RFC DRAFT                                                   January =
2002


   specified in the AS_PATH attribute), and checking that the =
autonomous
   system number of the local system does not appear in the AS path. If
   the autonomous system number appears in the AS path the route may be
   stored in the Adj-RIB-In, but unless the router is configured to
   accept routes with its own autonomous system in the AS path, the
   route shall not be passed to the BGP Decision Process.  Operations =
of
   a router that is configured to accept routes with its own autonomous
   system number in the AS path are outside the scope of this document.

   If an optional attribute is recognized, then the value of this
   attribute is checked. If an error is detected, the attribute is
   discarded, and the Error Subcode is set to Optional Attribute Error.
   The Data field contains the attribute (type, length and value).

   If any attribute appears more than once in the UPDATE message, then
   the Error Subcode is set to Malformed Attribute List.

   The NLRI field in the UPDATE message is checked for syntactic
   validity. If the field is syntactically incorrect, then the Error
   Subcode is set to Invalid Network Field.

   If a prefix in the NLRI field is semantically incorrect (e.g., an
   unexpected multicast IP address), an error should be logged locally,
   and the prefix should be ignored.

   An UPDATE message that contains correct path attributes, but no =
NLRI,
   shall be treated as a valid UPDATE message.


6.4 NOTIFICATION message error handling.


   If a peer sends a NOTIFICATION message, and there is an error in =
that
   message, there is unfortunately no means of reporting this error via
   a subsequent NOTIFICATION message. Any such error, such as an
   unrecognized Error Code or Error Subcode, should be noticed, logged
   locally, and brought to the attention of the administration of the
   peer. The means to do this, however, lies outside the scope of this
   document.


6.5 Hold Timer Expired error handling.


   If a system does not receive successive KEEPALIVE and/or UPDATE
   and/or NOTIFICATION messages within the period specified in the Hold
   Time field of the OPEN message, then the NOTIFICATION message with
   Hold Timer Expired Error Code must be sent and the BGP connection



Expiration Date July 2002                                      =0C[Page =
30]





RFC DRAFT                                                   January =
2002


   closed.


6.6 Finite State Machine error handling.


   Any error detected by the BGP Finite State Machine (e.g., receipt of
   an unexpected event) is indicated by sending the NOTIFICATION =
message
   with Error Code Finite State Machine Error.


6.7 Cease.


   In absence of any fatal errors (that are indicated in this section),
   a BGP peer may choose at any given time to close its BGP connection
   by sending the NOTIFICATION message with Error Code Cease. However,
   the Cease NOTIFICATION message must not be used when a fatal error
   indicated by this section does exist.

   A BGP speaker may support the ability to impose an (locally
   configured) upper bound on the number of address prefixes the =
speaker
   is willing to accept from a neighbor. When the upper bound is
   reached, the speaker (under control of local configuration) may
   either (a) discard new address prefixes from the neighbor, or (b)
   terminate the BGP peering with the neighbor. If the BGP speaker
   decides to terminate its peering with a neighbor because the number
   of address prefixes received from the neighbor exceeds the locally
   configured upper bound, then the speaker must send to the neighbor a
   NOTIFICATION message with the Error Code Cease.


6.8 Connection collision detection.


   If a pair of BGP speakers try simultaneously to establish a BGP
   connection to each other, then two parallel connections between this
   pair of speakers might well be formed. If the source IP address used
   by one of these connections is the same as the destination IP =
address
   used by the other, and the destination IP address used by the first
   connection is the same as the source IP address used by the other, =
we
   refer to this situation as connection collision.  Clearly in the
   presence of connection collision, one of these connections must be
   closed.

   Based on the value of the BGP Identifier a convention is established
   for detecting which BGP connection is to be preserved when a
   collision does occur. The convention is to compare the BGP



Expiration Date July 2002                                      =0C[Page =
31]





RFC DRAFT                                                   January =
2002


   Identifiers of the peers involved in the collision and to retain =
only
   the connection initiated by the BGP speaker with the higher-valued
   BGP Identifier.

   Upon receipt of an OPEN message, the local system must examine all =
of
   its connections that are in the OpenConfirm state. A BGP speaker may
   also examine connections in an OpenSent state if it knows the BGP
   Identifier of the peer by means outside of the protocol. If among
   these connections there is a connection to a remote BGP speaker =
whose
   BGP Identifier equals the one in the OPEN message, and this
   connection collides with the connection over which the OPEN message
   is received then the local system performs the following collision
   resolution procedure:


      1. The BGP Identifier of the local system is compared to the BGP
      Identifier of the remote system (as specified in the OPEN
      message).

      2. If the value of the local BGP Identifier is less than the
      remote one, the local system closes BGP connection that already
      exists (the one that is already in the OpenConfirm state), and
      accepts BGP connection initiated by the remote system.

      3. Otherwise, the local system closes newly created BGP =
connection
      (the one associated with the newly received OPEN message), and
      continues to use the existing one (the one that is already in the
      OpenConfirm state).

      Comparing BGP Identifiers is done by treating them as (4-octet
      long) unsigned integers.

      Unless allowed via configuration, a connection collision with an
      existing BGP connection that is in Established state causes
      closing of the newly created connection.

      Note that a connection collision cannot be detected with
      connections that are in Idle, or Connect, or Active states.

      Closing the BGP connection (that results from the collision
      resolution procedure) is accomplished by sending the NOTIFICATION
      message with the Error Code Cease.


7. BGP Version Negotiation.


   BGP speakers may negotiate the version of the protocol by making



Expiration Date July 2002                                      =0C[Page =
32]





RFC DRAFT                                                   January =
2002


   multiple attempts to open a BGP connection, starting with the =
highest
   version number each supports. If an open attempt fails with an Error
   Code OPEN Message Error, and an Error Subcode Unsupported Version
   Number, then the BGP speaker has available the version number it
   tried, the version number its peer tried, the version number passed
   by its peer in the NOTIFICATION message, and the version numbers =
that
   it supports. If the two peers do support one or more common =
versions,
   then this will allow them to rapidly determine the highest common
   version. In order to support BGP version negotiation, future =
versions
   of BGP must retain the format of the OPEN and NOTIFICATION messages.


8. BGP Finite State machine.


   This section specifies BGP operation in terms of a Finite State
   Machine (FSM). Following is a brief summary and overview of BGP
   operations by state as determined by this FSM.

   Initially BGP is in the Idle state.

      Idle state:

         A manual start event is a start event initiated by an =
operator.
         An automatic start event is a start event generated by the
         system.

         In this state BGP refuses all incoming BGP connections.  No
         resources are allocated to the peer.    In response to a Start
         event (manual or automatic), the local system:

            - initializes all BGP resources,

            - starts the ConnectRetry timer,

            - initiates a transport connection to the other BGP peer,

            - listens for a connection that may be initiated by the
            remote BGP peer, and

            - changes its state to connect.

         The exact value of the ConnectRetry timer is a local matter,
         but it should be sufficiently large to allow TCP
         initialization.

         Any other event received in the IDLE state, is ignored.




Expiration Date July 2002                                      =0C[Page =
33]





RFC DRAFT                                                   January =
2002


      IdleHold state:

         The IdleHold state keeps the system in "Idle" mode until a
         certain time period has passed or an operator intervenes to
         manually restart the connection.  This "IdleHold timeout"
         prevents persistent flapping of a BGP peering session.

         Upon entering the Idle Hold state, if the IdleHoldTimer =
exceeds
         the local limit the "Keep Idle" flag is set.

         Upon receiving a Manual start, the local system:

            - clears the IdleHoldtimer,

            - clears "keep Idle" flag

            - initializes all BGP resources,

            - starts the ConnectRetry timer,

            - initiates a transport connection to the other BGP peer,

            - listens for a connection that may be initiated by the
            remote BGPPeer, and

            - changes its state to connect.

         Upon receiving a IdleHoldtimer expired event, the local system
         checks to see that the Keep Idle flag is set.  If the Keep =
Idle
         flag is set, the system stays in the "Idle Hold" state.

         If the Keep Idle flag is not set, the local system:

            - clears the IdleHoldtimer,

            - and transitions the state to Idle.

         Getting out of the IdleHoldstate requires either operator
         intervention via a manual start or the IdleHoldtimer to expire
         with the "Keep Idle" flag to be clear.

         Any other event received in the IdleHold state is ignored.

      Connect State:

         In this state, BGP is waiting for the transport protocol
         connection to be completed.




Expiration Date July 2002                                      =0C[Page =
34]





RFC DRAFT                                                   January =
2002


         If the transport connection succeeds, the local system:

            - clears the ConnectRetry timer,

            - completes initialization,

            - send an Open message to its peer,

            - set Hold timer to a large value,  and

            - changes its state to Open Sent.

         A hold timer value of 4 minutes is suggested.

         If the transport protocol connection fails (e.g.,
         retransmission timeout), the local system:

            - restarts the ConnectRetry timer,

            - continues to listen for a connection that may be =
initiated
            by the remote BGP peer, and

            - changes its state to Active.

         In response to the ConnectRetry timer expired event, the local
         system:

            - restarts the ConnectRetry timer,

            - initiates a transport connection to the other BGP peer,

            - continues to listen for a connection that may be =
initiated
            by the remote BGP peer, and

            - stays in Connect state.

         The start event (manual or automatic) is ignored in the =
Connect
         state.

         In response to any other event (initiated by the system or
         operator), the local system:

            - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Set connect retry timer to zero,




Expiration Date July 2002                                      =0C[Page =
35]





RFC DRAFT                                                   January =
2002


            - Drops TCP connection,

            - Releases all BGP resources, and

            - Goes to IdleHoldstate

      Active State:

         In this state BGP is trying to acquire a peer by listening for
         and accepting a transport protocol connection.

         If the transport connection succeeds, the local system:

            - clears the ConnectRetry timer,

            - completes the initialization,

            - sends the Open message to it's peer,

            - sets its Hold timer to a large value,

            - and changes its state to OpenSent.

         A Hold timer value of 4 minutes is suggested.

         In response the ConnectRetry timer expired event, the local
         system:

            - restarts the ConnectRetry timer,

            - initiates a transport connection to the other BGP peer,

            - continues to listen for connection that may be initiated
            by remote BGP peer,

            - and changes its state to Connect.

         If the local system does not allow BGP connections with
         unconfigured peers, then the local system:

            - rejects connections from IP addresses that are not
            configured peers,

            - and remains in the Active state.

         The start events (initiated by the system or operator) are
         ignored in the Active state.




Expiration Date July 2002                                      =0C[Page =
36]





RFC DRAFT                                                   January =
2002


         In response to any other event (initiated by the system or
         operator), the local system:

            - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Set connect retry timer to zero, and

            - Drops TCP connection,

            - Releases all BGP resources,

            - Goes to IdleHold state.

      Open Sent:

         In this state BGP waits for an Open Message from its peer.
         When an OPEN message is received, all fields are check for
         correctness.  If the BGP message header checking or OPEN
         message check detects an error (see Section 6.2), or a
         connection collision (see Section 6.8) the local system:

            - sends a NOTIFICATION message

            - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Set connect retry timer to zero, and

            - Drops TCP connection,

            - Releases all BGP resources,

            - Goes to IdleHold state.

         If there are no errors in the OPEN message, the local system:

            - sends a KEEPALIVE message and

            - sets a KeepAlive timer (via the text below)

            - set the Hold timer according to the negotiated value (see
            section 4.2),

            - set the state to Open Confirm.




Expiration Date July 2002                                      =0C[Page =
37]





RFC DRAFT                                                   January =
2002


         If the negotiated Hold time value is zero, then the Hold Time
         timer and KeepAlive timers are not started.   If the value of
         the Autonomous System field is the same as the local =
Autonomous
         System number, then the connection is an "internal" =
connection;
         otherwise, it is an "external" connection.   (This will impact
         UPDATE processing as described below.)

         If a disconnect NOTIFICATION is received from the underlying
         transport protocol, the local system:

            - closes the BGP connection,

            - restarts the Connect Retry timer,

            - and continues to listen for a connection that may be
            initiated by the remote BGP peer, and goes into Active
            state.

         If the Hold Timer expires, the local system:

            - send a NOTIFICATION message with error code Hold Timer
            Expired,

            - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Set connect retry timer to zero, and

            - Drops TCP connection,

            - Releases all BGP resources, and

            - Goes to IdleHold state.

         The Start event (manual and automatic) is ignored in the
         OpenSent state.

         If a NOTIFICATION message is received with a version error, =
the
         local system:

            - Closes the transport connection

            - Releases BGP resources,

            - ConnectRetryCnt =3D 0,

            - Connect retry timer =3D 0, and



Expiration Date July 2002                                      =0C[Page =
38]





RFC DRAFT                                                   January =
2002


            - transition to Idle state.

         If any other NOTIFICATION is received, the local system:

            - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Set connect retry timer to zero, and

            - Drops TCP connection,

            - Releases all BGP resources,

            - Goes to IdleHold state.

         In response to any other event, the local system:

            - sends the NOTFICATION message with Error Code Finite =
State
            Machine  Error,

            - IdleHoldtimer =3D 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Set connect retry timer to zero,

            - Drops TCP connection,

            - Releases all BGP resources, and

            - Goes to IdleHold state.

      Open Confirm State

         In this state BGP waits for a KEEPALIVE or NOTIFICATION
         message.

         If the local system receives a KEEPALIVE message, it changes
         its state to Established.

         If the Hold Timer expires before a KEEPALIVE message is
         received, the local system:

            - send the NOTIFICATION message with the error code Hold
            Timer Expired,

            - sets IdleHoldTimer =3D 2**(ConnectRetryCnt)*60



Expiration Date July 2002                                      =0C[Page =
39]





RFC DRAFT                                                   January =
2002


            - Increments ConnectRetryCnt by 1,

            - Sets the connect retry timer to zero,

            - Drop the TCP connection,

            - Releases all BGP resources,

            - Goes to IdleHoldState.

         If the local system receives a NOTIFICATION message or =
receives
         a disconnect NOTIFICATION from the underlying transport
         protocol, the local system:

            - Sets IdleHold Timer =3D 2**(ConnectRetryCnt)*60

            - Increments ConnectRetryCnt by 1,

            - Sets the connect retry timer to zero,

            - Drops the TCP connection,

            - Releases all BGP resources,

            - Goes to IdleHoldstate.

         In response to the Stop event initiated by the system, the
         local system:

            - sends the NOTIFICATION message with Cease,

            - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60

            - Increments ConnectRetryCnt by 1,

            - Sets the Connect retry timer to zero,

            - Drops the TCP connection,

            - Releases all BGP resources,

            - Goes to IdleHoldstate.


         In response to a Stop event initiated by the operator, the
         local system:

            - sends the NOTIFICATION message with Cease,



Expiration Date July 2002                                      =0C[Page =
40]





RFC DRAFT                                                   January =
2002


            - releases all BGP resources

            - sets the ConnectRetryCnt to zero

            - sets the connect retry timer to 0

            - transitions to Idle state.

         The Start event is ignored in the OpenConfirm state.

         In response to any other event, the local system:

            - sends a NOTIFICATION with a code of Finite State Machine
            Error,

            - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60

            - Increments ConnectRetryCnt by 1,

            - Sets the Connect retry timer to zero,

            - Drops the TCP connection,

            - Releases all BGP resources,

            - Goes to IdleHoldstate.

      Established State:

         In the Established state BGP can exchange UPDATE, NOTFICATION,
         and KEEPALIVE messages with its peer.

         If the local system receives an UPDATE or KEEPALIVE message, =
it
         restarts its Hold Timer, if the negotiated Hold Time value is
         non-zero.

         If the local system receives a NOTIFICATION message or a
         disconnect from the underlying transport protocol, it:

            - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60,

            - Increments ConnectRetryCnt by 1,

            - Sets the Connect retry timer to zero,

            - Drops the TCP connection,

            - Releases all BGP resources, and



Expiration Date July 2002                                      =0C[Page =
41]





RFC DRAFT                                                   January =
2002


            - Goes to IdleHoldstate.

         If the local system receives an UPDATE message, and the Update
         message error handling procedure (see Section 6.3) detecs an
         error, the local system:

            - sends a NOTIFICATION message with Update error,

            - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60

            - Increments ConnectRetryCnt by 1,

            - Sets the Connect retry timer to zero,

            - Drops the TCP connection,

            - Releases all BGP resources, and

            - Goes to IdleHoldstate.

         If the Hold timer expires, the local system:

            - sends a NOTIFICATION message with Error Code Hold Timer
            Expired,

            - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60

            - Increments ConnectRetryCnt by 1,

            - Sets the connect retry timer to zero,

            - Drops the TCP connection,

            - Releases all BGP resources,

            - Goes to IdleHold state.

         If the KeepAlive timer expires, the local system sends a
         KEEPALIVE message, it restarts its KeepAlive timer, unless the
         negotiated Hold Time value is zero.

         Each time time the local system sends a KEEPALIVE or UPDATE
         message, it restarts its KeepAlive timer, unless the =
negotiated
         Hold Time value is zero.

         In response to the Stop event initiated by the system
         (automatic), the local system:




Expiration Date July 2002                                      =0C[Page =
42]





RFC DRAFT                                                   January =
2002


            - sends a NOTIFICATION with Cease,

            - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60

            - increments ConnectRetryCnt by 1,

            - sets the connect retry timer to zero,

            - drops the TCP connection,

            - releases all BGP resources,

            - goes to IdleHold state, and

            - deletes all routes.

         An example automatic stop event is exceeding the number of
         prefixes for a given peer and the local system automatically
         disconnecting the peer.

         In response to a stop event initiated by an operator:

            - release all resources (including deleting all routes),

            - set ConnectRetryCnt to zero (0),

            - set connect retry timer to zero (0), and

            - transition to the Idle.

         The Start event is ignored in the Established state.

         In response to any other event, the local system:

            - sends a NOTIFICATION message with Error Code Finite State
            Machine Error,

            - sets IdleHoldtimer =3D 2**(ConnectRetryCnt)*60

            - increments ConnectRetryCnt by 1,

            - sets the connect retry timer to zero,

            - drops the TCP connection,

            - releases all BGP resources

            - goes to IdleHoldstate, and



Expiration Date July 2002                                      =0C[Page =
43]





RFC DRAFT                                                   January =
2002


            - deletes all routes.


9. UPDATE Message Handling


   An UPDATE message may be received only in the Established state.
   When an UPDATE message is received, each field is checked for
   validity as specified in Section 6.3.

   If an optional non-transitive attribute is unrecognized, it is
   quietly ignored. If an optional transitive attribute is =
unrecognized,
   the Partial bit (the third high-order bit) in the attribute flags
   octet is set to 1, and the attribute is retained for propagation to
   other BGP speakers.

   If an optional attribute is recognized, and has a valid value, then,
   depending on the type of the optional attribute, it is processed
   locally, retained, and updated, if necessary, for possible
   propagation to other BGP speakers.

   If the UPDATE message contains a non-empty WITHDRAWN ROUTES field,
   the previously advertised routes whose destinations (expressed as IP
   prefixes) contained in this field shall be removed from the Adj-RIB-
   In.  This BGP speaker shall run its Decision Process since the
   previously advertised route is no longer available for use.

   If the UPDATE message contains a feasible route, the Adj-RIB-In will
   be updated with this route as follows: if the NLRI of the new route
   is identical to the one of the route currently stored in the =
Adj-RIB-
   In, then the new route shall replace the older route in the Adj-RIB-
   In, thus implicitly withdrawing the older route from service.
   Otherwise, if the Adj-RIB-In has no route with NLRI identical to the
   new route, the new route shall be placed in the Adj-RIB-In.

   Once the BGP speaker updates the Adj-RIB-In, the speaker shall run
   its Decision Process.


9.1 Decision Process


   The Decision Process selects routes for subsequent advertisement by
   applying the policies in the local Policy Information Base (PIB) to
   the routes stored in its Adj-RIBs-In. The output of the Decision
   Process is the set of routes that will be advertised to all peers;
   the selected routes will be stored in the local speaker's Adj-RIB-
   Out.



Expiration Date July 2002                                      =0C[Page =
44]





RFC DRAFT                                                   January =
2002


   The selection process is formalized by defining a function that =
takes
   the attribute of a given route as an argument and returns either (a)
   a non-negative integer denoting the degree of preference for the
   route, or (b) a value denoting that this route is ineligible to be
   installed in LocRib and will be excluded from the next phase of =
route
   selection.

   The function that calculates the degree of preference for a given
   route shall not use as its inputs any of the following: the =
existence
   of other routes, the non-existence of other routes, or the path
   attributes of other routes. Route selection then consists of
   individual application of the degree of preference function to each
   feasible route, followed by the choice of the one with the highest
   degree of preference.

   The Decision Process operates on routes contained in the Adj-RIB-In,
   and is responsible for:

      - selection of routes to be used locally by the speaker

      - selection of routes to be advertised to other BGP peers

      - route aggregation and route information reduction

   The Decision Process takes place in three distinct phases, each
   triggered by a different event:

      a) Phase 1 is responsible for calculating the degree of =
preference
      for each route received from a peer.

      b) Phase 2 is invoked on completion of phase 1. It is responsible
      for choosing the best route out of all those available for each
      distinct destination, and for installing each chosen route into
      the Loc-RIB.

      c) Phase 3 is invoked after the Loc-RIB has been modified. It is
      responsible for disseminating routes in the Loc-RIB to each peer,
      according to the policies contained in the PIB. Route aggregation
      and information reduction can optionally be performed within this
      phase.


9.1.1 Phase 1: Calculation of Degree of Preference


   The Phase 1 decision function shall be invoked whenever the local =
BGP
   speaker receives from a peer an UPDATE message that advertises a new
   route, a replacement route, or withdrawn routes.



Expiration Date July 2002                                      =0C[Page =
45]





RFC DRAFT                                                   January =
2002


   The Phase 1 decision function is a separate process which completes
   when it has no further work to do.

   The Phase 1 decision function shall lock an Adj-RIB-In prior to
   operating on any route contained within it, and shall unlock it =
after
   operating on all new or unfeasible routes contained within it.

   For each newly received or replacement feasible route, the local BGP
   speaker shall determine a degree of preference as follows:

      If the route is learned from an internal peer, either the value =
of
      the LOCAL_PREF attribute shall be taken as the degree of
      preference, or the local system may compute the degree of
      preference of the route based on preconfigured policy =
information.
      Note that the latter (computing the degree of preference based on
      preconfigured policy information) may result in formation of
      persistent routing loops.

      If the route is learned from an external peer, then the local BGP
      speaker computes the degree of preference based on preconfigured
      policy information. If the return value indicates that the route
      is ineligible, the route may not serve as an input to the next
      phase of route selection; otherwise the return value is used as
      the LOCAL_PREF value in any IBGP readvertisement.

      The exact nature of this policy information and the computation
      involved is a local matter.


9.1.2 Phase 2: Route Selection


   The Phase 2 decision function shall be invoked on completion of =
Phase
   1. The Phase 2 function is a separate process which completes when =
it
   has no further work to do. The Phase 2 process shall consider all
   routes that are eligible in the Adj-RIBs-In.

   The Phase 2 decision function shall be blocked from running while =
the
   Phase 3 decision function is in process. The Phase 2 function shall
   lock all Adj-RIBs-In prior to commencing its function, and shall
   unlock them on completion.

   If the NEXT_HOP attribute of a BGP route depicts an address that is
   not resolvable, or it would become unresolvable if the route was
   installed in the routing table the BGP route should be excluded from
   the Phase 2 decision function.

   It is critical that routers within an AS do not make conflicting



Expiration Date July 2002                                      =0C[Page =
46]





RFC DRAFT                                                   January =
2002


   decisions regarding route selection that would cause forwarding =
loops
   to occur.

   For each set of destinations for which a feasible route exists in =
the
   Adj-RIBs-In, the local BGP speaker shall identify the route that =
has:

      a) the highest degree of preference of any route to the same set
      of destinations, or

      b) is the only route to that destination, or

      c) is selected as a result of the Phase 2 tie breaking rules
      specified in 9.1.2.2.

   The local speaker SHALL then install that route in the Loc-RIB,
   replacing any route to the same destination that is currently being
   held in the Loc-RIB. If the new BGP route is installed in the =
Routing
   Table (as a result of the local policy decision), care must be taken
   to ensure that invalid BGP routes to the same destination are =
removed
   from the Routing Table. Whether or not the new route replaces an
   already existing non-BGP route in the routing table depends on the
   policy configured on the BGP speaker.

   The local speaker MUST determine the immediate next hop to the
   address depicted by the NEXT_HOP attribute of the selected route by
   performing a best matching route lookup in the Routing Table and
   selecting one of the possible paths (if multiple best paths to the
   same prefix are available). If the route to the address depicted by
   the NEXT_HOP attribute changes such that the immediate next hop or
   the IGP cost to the NEXT_HOP (if the NEXT_HOP is resolved through an
   IGP route) changes, route selection should be recalculated as
   specified above.

   Notice that even though BGP routes do not have to be installed in =
the
   Routing Table with the immediate next hop(s), implementations must
   take care that before any packets are forwarded along a BGP route,
   its associated NEXT_HOP address is resolved to the immediate
   (directly connected) next-hop address and this address (or multiple
   addresses) is finally used for actual packet forwarding.

   Unresolvable routes SHALL be removed from the Loc-RIB and the =
routing
   table. However, corresponding unresolvable routes SHOULD be kept in
   the Adj-RIBs-In.








Expiration Date July 2002                                      =0C[Page =
47]





RFC DRAFT                                                   January =
2002


9.1.2.1 Route Resolvability Condition


   As indicated in Section 9.1.2, BGP routers should exclude
   unresolvable routes from the Phase 2 decision. This ensures that =
only
   valid routes are installed in Loc-RIB and the Routing Table.

   The route resolvability condition is defined as follows.

      1. A route Rte1, referencing only the intermediate network
      address, is considered resolvable if the Routing Table contains =
at
      least one resolvable route Rte2 that matches Rte1's intermediate
      network address and is not recursively resolved (directly or
      indirectly) through Rte1. If multiple matching routes are
      available, only the longest matching route should be considered.

      2. Routes referencing interfaces (with or without intermediate
      addresses) are considered resolvable if the state of the
      referenced interface is up and IP processing is enabled on this
      interface.

   BGP routes do not refer to interfaces, but can be resolved through
   the routes in the Routing Table that can be of both types. IGP =
routes
   and routes to directly connected networks are expected to specify =
the
   outbound interface.

   Note that a BGP route is considered unresolvable not only in
   situations where the router's Routing Table contains no route
   matching the BGP route's NEXT_HOP. Mutually recursive routes (routes
   resolving each other or themselves), also fail the resolvability
   check.

   It is also important that implementations do not consider feasible
   routes that would become unresolvable if they were installed in the
   Routing Table even if their NEXT_HOPs are resolvable using the
   current contents of the Routing Table (an example of such routes
   would be mutually recursive routes). This check ensures that a BGP
   speaker does not install in the Routing Table routes that will be
   removed and not used by the speaker. Therefore, in addition to local
   Routing Table stability, this check also improves behavior of the
   protocol in the network.

   Whenever a BGP speaker identifies a route that fails the
   resolvability check because of mutual recursion, an error message
   should be logged.






Expiration Date July 2002                                      =0C[Page =
48]





RFC DRAFT                                                   January =
2002


9.1.2.2 Breaking Ties (Phase 2)


   In its Adj-RIBs-In a BGP speaker may have several routes to the same
   destination that have the same degree of preference. The local
   speaker can select only one of these routes for inclusion in the
   associated Loc-RIB. The local speaker considers all routes with the
   same degrees of preference, both those received from internal peers,
   and those received from external peers.

   The following tie-breaking procedure assumes that for each candidate
   route all the BGP speakers within an autonomous system can ascertain
   the cost of a path (interior distance) to the address depicted by =
the
   NEXT_HOP attribute of the route, and follow the same route selection
   algorithm.

   The tie-breaking algorithm begins by considering all equally
   preferable routes to the same destination, and then selects routes =
to
   be removed from consideration. The algorithm terminates as soon as
   only one route remains in consideration.  The criteria must be
   applied in the order specified.

   Several of the criteria are described using pseudo-code. Note that
   the pseudo-code shown was chosen for clarity, not efficiency. It is
   not intended to specify any particular implementation. BGP
   implementations MAY use any algorithm which produces the same =
results
   as those described here.

      a) Remove from consideration all routes which are not tied for
      having the smallest number of AS numbers present in their AS_PATH
      attributes. Note, that when counting this number, an AS_SET =
counts
      as 1, no matter how many ASs are in the set, and that, if the
      implementation supports [13], then AS numbers present in segments
      of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in
      the count of AS numbers present in the AS_PATH.

      b) Remove from consideration all routes which are not tied for
      having the lowest Origin number in their Origin attribute.

      c) Remove from consideration routes with less-preferred
      MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
      between routes learned from the same neighboring AS. Routes which
      do not have the MULTI_EXIT_DISC attribute are considered to have
      the lowest possible MULTI_EXIT_DISC value.

      This is also described in the following procedure:

            for m =3D all routes still under consideration



Expiration Date July 2002                                      =0C[Page =
49]





RFC DRAFT                                                   January =
2002


                for n =3D all routes still under consideration
                    if (neighborAS(m) =3D=3D neighborAS(n)) and (MED(n) =
< MED(m))
                        remove route m from consideration

      In the pseudo-code above, MED(n) is a function which returns the
      value of route n's MULTI_EXIT_DISC attribute. If route n has no
      MULTI_EXIT_DISC attribute, the function returns the lowest
      possible MULTI_EXIT_DISC value, i.e. 0.

      Similarly, neighborAS(n) is a function which returns the neighbor
      AS from which the route was received.

      d) If at least one of the candidate routes was received from an
      external peer in a neighboring autonomous system, remove from
      consideration all routes which were received from internal peers.

      e) Remove from consideration any routes with less-preferred
      interior cost.  The interior cost of a route is determined by
      calculating the metric to the next hop for the route using the
      Routing Table. If the next hop for a route is reachable, but no
      cost can be determined, then this step should be skipped
      (equivalently, consider all routes to have equal costs).

      This is also described in the following procedure.

            for m =3D all routes still under consideration
                for n =3D all routes in still under consideration
                    if (cost(n) is better than cost(m))
                        remove m from consideration

      In the pseudo-code above, cost(n) is a function which returns the
      cost of the path (interior distance) to the address given in the
      NEXT_HOP attribute of the route.

      f) Remove from consideration all routes other than the route that
      was advertised by the BGP speaker whose BGP Identifier has the
      lowest value.

      g) Prefer the route received from the lowest neighbor address.


9.1.3 Phase 3: Route Dissemination


   The Phase 3 decision function shall be invoked on completion of =
Phase
   2, or when any of the following events occur:

      a) when routes in the Loc-RIB to local destinations have changed



Expiration Date July 2002                                      =0C[Page =
50]





RFC DRAFT                                                   January =
2002


      b) when locally generated routes learned by means outside of BGP
      have changed

      c) when a new BGP speaker - BGP speaker connection has been
      established

   The Phase 3 function is a separate process which completes when it
   has no further work to do. The Phase 3 Routing Decision function
   shall be blocked from running while the Phase 2 decision function is
   in process.

   All routes in the Loc-RIB shall be processed into Adj-RIBs-Out
   according to configured policy. This policy may exclude a route in
   the Loc-RIB from being installed in a particular Adj-RIB-Out.  A
   route shall not be installed in the Adj-Rib-Out unless the
   destination and NEXT_HOP described by this route may be forwarded
   appropriately by the Routing Table. If a route in Loc-RIB is =
excluded
   from a particular Adj-RIB-Out the previously advertised route in =
that
   Adj-RIB-Out must be withdrawn from service by means of an UPDATE
   message (see 9.2).

   Route aggregation and information reduction techniques (see 9.2.2.1)
   may optionally be applied.

   When the updating of the Adj-RIBs-Out and the Routing Table is
   complete, the local BGP speaker shall run the Update-Send process of
   9.2.


9.1.4 Overlapping Routes


   A BGP speaker may transmit routes with overlapping Network Layer
   Reachability Information (NLRI) to another BGP speaker. NLRI overlap
   occurs when a set of destinations are identified in non-matching
   multiple routes. Since BGP encodes NLRI using IP prefixes, overlap
   will always exhibit subset relationships.  A route describing a
   smaller set of destinations (a longer prefix) is said to be more
   specific than a route describing a larger set of destinations (a
   shorted prefix); similarly, a route describing a larger set of
   destinations (a shorter prefix) is said to be less specific than a
   route describing a smaller set of destinations (a longer prefix).

   The precedence relationship effectively decomposes less specific
   routes into two parts:

      - a set of destinations described only by the less specific =
route,
      and



Expiration Date July 2002                                      =0C[Page =
51]





RFC DRAFT                                                   January =
2002


      - a set of destinations described by the overlap of the less
      specific and the more specific routes


   When overlapping routes are present in the same Adj-RIB-In, the more
   specific route shall take precedence, in order from more specific to
   least specific.

   The set of destinations described by the overlap represents a =
portion
   of the less specific route that is feasible, but is not currently in
   use.  If a more specific route is later withdrawn, the set of
   destinations described by the overlap will still be reachable using
   the less specific route.

   If a BGP speaker receives overlapping routes, the Decision Process
   MUST consider both routes based on the configured acceptance policy.
   If both a less and a more specific route are accepted, then the
   Decision Process MUST either install both the less and the more
   specific routes or it MUST aggregate the two routes and install the
   aggregated route, provided that both routes have the same value of
   the NEXT_HOP attribute.

   If a BGP speaker chooses to aggregate, then it MUST add
   ATOMIC_AGGREGATE attribute to the route. A route that carries
   ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the
   NLRI of this route can not be made more specific. Forwarding along
   such a route does not guarantee that IP packets will actually
   traverse only ASs listed in the AS_PATH attribute of the route.


9.2 Update-Send Process


   The Update-Send process is responsible for advertising UPDATE
   messages to all peers. For example, it distributes the routes chosen
   by the Decision Process to other BGP speakers which may be located =
in
   either the same autonomous system or a neighboring autonomous =
system.

   When a BGP speaker receives an UPDATE message from an internal peer,
   the receiving BGP speaker shall not re-distribute the routing
   information contained in that UPDATE message to other internal =
peers,
   unless the speaker acts as a BGP Route Reflector [11].

   As part of Phase 3 of the route selection process, the BGP speaker
   has updated its Adj-RIBs-Out. All newly installed routes and all
   newly unfeasible routes for which there is no replacement route =
shall
   be advertised to its peers by means of an UPDATE message.




Expiration Date July 2002                                      =0C[Page =
52]





RFC DRAFT                                                   January =
2002


   A BGP speaker should not advertise a given feasible BGP route from
   its Adj-RIB-Out if it would produce an UPDATE message containing the
   same BGP route as was previously advertised.

   Any routes in the Loc-RIB marked as unfeasible shall be removed.
   Changes to the reachable destinations within its own autonomous
   system shall also be advertised in an UPDATE message.


9.2.1 Controlling Routing Traffic Overhead


   The BGP protocol constrains the amount of routing traffic (that is,
   UPDATE messages) in order to limit both the link bandwidth needed to
   advertise UPDATE messages and the processing power needed by the
   Decision Process to digest the information contained in the UPDATE
   messages.


9.2.1.1 Frequency of Route Advertisement


   The parameter MinRouteAdvertisementInterval determines the minimum
   amount of time that must elapse between advertisement of routes to a
   particular destination from a single BGP speaker. This rate limiting
   procedure applies on a per-destination basis, although the value of
   MinRouteAdvertisementInterval is set on a per BGP peer basis.

   Two UPDATE messages sent from a single BGP speaker that advertise
   feasible routes to some common set of destinations received from
   external peers must be separated by at least
   MinRouteAdvertisementInterval. Clearly, this can only be achieved
   precisely by keeping a separate timer for each common set of
   destinations. This would be unwarranted overhead. Any technique =
which
   ensures that the interval between two UPDATE messages sent from a
   single BGP speaker that advertise feasible routes to some common set
   of destinations received from external peers will be at least
   MinRouteAdvertisementInterval, and will also ensure a constant upper
   bound on the interval is acceptable.

   Since fast convergence is needed within an autonomous system, this
   procedure does not apply for routes received from other internal
   peers.  To avoid long-lived black holes, the procedure does not =
apply
   to the explicit withdrawal of unfeasible routes (that is, routes
   whose destinations (expressed as IP prefixes) are listed in the
   WITHDRAWN ROUTES field of an UPDATE message).

   This procedure does not limit the rate of route selection, but only



Expiration Date July 2002                                      =0C[Page =
53]





RFC DRAFT                                                   January =
2002


   the rate of route advertisement. If new routes are selected multiple
   times while awaiting the expiration of =
MinRouteAdvertisementInterval,
   the last route selected shall be advertised at the end of
   MinRouteAdvertisementInterval.


9.2.1.2 Frequency of Route Origination


   The parameter MinASOriginationInterval determines the minimum amount
   of time that must elapse between successive advertisements of UPDATE
   messages that report changes within the advertising BGP speaker's =
own
   autonomous systems.


9.2.1.3 Jitter


   To minimize the likelihood that the distribution of BGP messages by =
a
   given BGP speaker will contain peaks, jitter should be applied to =
the
   timers associated with MinASOriginationInterval, Keepalive, and
   MinRouteAdvertisementInterval. A given BGP speaker shall apply the
   same jitter to each of these quantities regardless of the
   destinations to which the updates are being sent; that is, jitter
   will not be applied on a "per peer" basis.

   The amount of jitter to be introduced shall be determined by
   multiplying the base value of the appropriate timer by a random
   factor which is uniformly distributed in the range from 0.75 to 1.0.


9.2.2 Efficient Organization of Routing Information


   Having selected the routing information which it will advertise, a
   BGP speaker may avail itself of several methods to organize this
   information in an efficient manner.


9.2.2.1 Information Reduction


   Information reduction may imply a reduction in granularity of policy
   control - after information is collapsed, the same policies will
   apply to all destinations and paths in the equivalence class.

   The Decision Process may optionally reduce the amount of information
   that it will place in the Adj-RIBs-Out by any of the following



Expiration Date July 2002                                      =0C[Page =
54]





RFC DRAFT                                                   January =
2002


   methods:

      a)   Network Layer Reachability Information (NLRI):

      Destination IP addresses can be represented as IP address
      prefixes. In cases where there is a correspondence between the
      address structure and the systems under control of an autonomous
      system administrator, it will be possible to reduce the size of
      the NLRI carried in the UPDATE messages.

      b)   AS_PATHs:

      AS path information can be represented as ordered AS_SEQUENCEs or
      unordered AS_SETs. AS_SETs are used in the route aggregation
      algorithm described in 9.2.2.2. They reduce the size of the
      AS_PATH information by listing each AS number only once,
      regardless of how many times it may have appeared in multiple
      AS_PATHs that were aggregated.

      An AS_SET implies that the destinations listed in the NLRI can be
      reached through paths that traverse at least some of the
      constituent autonomous systems. AS_SETs provide sufficient
      information to avoid routing information looping; however their
      use may prune potentially feasible paths, since such paths are no
      longer listed individually as in the form of AS_SEQUENCEs. In
      practice this is not likely to be a problem, since once an IP
      packet arrives at the edge of a group of autonomous systems, the
      BGP speaker at that point is likely to have more detailed path
      information and can distinguish individual paths to destinations.


9.2.2.2 Aggregating Routing Information


   Aggregation is the process of combining the characteristics of
   several different routes in such a way that a single route can be
   advertised.  Aggregation can occur as part of the decision process =
to
   reduce the amount of routing information that will be placed in the
   Adj-RIBs-Out.

   Aggregation reduces the amount of information that a BGP speaker =
must
   store and exchange with other BGP speakers. Routes can be aggregated
   by applying the following procedure separately to path attributes of
   like type and to the Network Layer Reachability Information.

   Routes that have the following attributes shall not be aggregated
   unless the corresponding attributes of each route are identical:
   MULTI_EXIT_DISC, NEXT_HOP.



Expiration Date July 2002                                      =0C[Page =
55]





RFC DRAFT                                                   January =
2002


   If the aggregation occurs as part of the update process, routes with
   different NEXT_HOP values can be aggregated when announced through =
an
   external BGP session.

   Path attributes that have different type codes can not be aggregated
   together. Path attributes of the same type code may be aggregated,
   according to the following rules:

      ORIGIN attribute: If at least one route among routes that are
      aggregated has ORIGIN with the value INCOMPLETE, then the
      aggregated route must have the ORIGIN attribute with the value
      INCOMPLETE.  Otherwise, if at least one route among routes that
      are aggregated has ORIGIN with the value EGP, then the aggregated
      route must have the origin attribute with the value EGP. In all
      other case the value of the ORIGIN attribute of the aggregated
      route is IGP.

      AS_PATH attribute: If routes to be aggregated have identical
      AS_PATH attributes, then the aggregated route has the same =
AS_PATH
      attribute as each individual route.

      For the purpose of aggregating AS_PATH attributes we model each =
AS
      within the AS_PATH attribute as a tuple <type, value>, where
      "type" identifies a type of the path segment the AS belongs to
      (e.g. AS_SEQUENCE, AS_SET), and "value" is the AS number. If the
      routes to be aggregated have different AS_PATH attributes, then
      the aggregated AS_PATH attribute shall satisfy all of the
      following conditions:

         - all tuples of type AS_SEQUENCE in the aggregated AS_PATH
         shall appear in all of the AS_PATH in the initial set of =
routes
         to be aggregated.

         - all tuples of type AS_SET in the aggregated AS_PATH shall
         appear in at least one of the AS_PATH in the initial set (they
         may appear as either AS_SET or AS_SEQUENCE types).

         - for any tuple X of type AS_SEQUENCE in the aggregated =
AS_PATH
         which precedes tuple Y in the aggregated AS_PATH, X precedes Y
         in each AS_PATH in the initial set which contains Y, =
regardless
         of the type of Y.

         - No tuple of type AS_SET with the same value shall appear =
more
         than once in the aggregated AS_PATH.

         - Multiple tuples of type AS_SEQUENCE with the same value may
         appear in the aggregated AS_PATH only when adjacent to another
         tuple of the same type and value.



Expiration Date July 2002                                      =0C[Page =
56]





RFC DRAFT                                                   January =
2002


      An implementation may choose any algorithm which conforms to =
these
      rules. At a minimum a conformant implementation shall be able to
      perform the following algorithm that meets all of the above
      conditions:

         - determine the longest leading sequence of tuples (as defined
         above) common to all the AS_PATH attributes of the routes to =
be
         aggregated. Make this sequence the leading sequence of the
         aggregated AS_PATH attribute.

         - set the type of the rest of the tuples from the AS_PATH
         attributes of the routes to be aggregated to AS_SET, and =
append
         them to the aggregated AS_PATH attribute.

         - if the aggregated AS_PATH has more than one tuple with the
         same value (regardless of tuple's type), eliminate all, but =
one
         such tuple by deleting tuples of the type AS_SET from the
         aggregated AS_PATH attribute.

      Appendix 6, section 6.8 presents another algorithm that satisfies
      the conditions and allows for more complex policy configurations.

      ATOMIC_AGGREGATE: If at least one of the routes to be aggregated
      has ATOMIC_AGGREGATE path attribute, then the aggregated route
      shall have this attribute as well.

      AGGREGATOR: All AGGREGATOR attributes of all routes to be
      aggregated should be ignored. The BGP speaker performing the =
route
      aggregation may attach a new AGGREGATOR attribute (see Section
      5.1.7).


9.3 Route Selection Criteria


   Generally speaking, additional rules for comparing routes among
   several alternatives are outside the scope of this document. There
   are two exceptions:

      - If the local AS appears in the AS path of the new route being
      considered, then that new route cannot be viewed as better than
      any other route (provided that the speaker is configured to =
accept
      such routes). If such a route were ever used, a routing loop =
could
      result (see Section 6.3).

      - In order to achieve successful distributed operation, only
      routes with a likelihood of stability can be chosen. Thus, an AS
      must avoid using unstable routes, and it must not make rapid



Expiration Date July 2002                                      =0C[Page =
57]





RFC DRAFT                                                   January =
2002


      spontaneous changes to its choice of route. Quantifying the terms
      "unstable" and "rapid" in the previous sentence will require
      experience, but the principle is clear.

      Care must be taken to ensure that BGP speakers in the same AS do
      not make inconsistent decisions.


9.4 Originating BGP routes

   A BGP speaker may originate BGP routes by injecting routing
   information acquired by some other means (e.g. via an IGP) into BGP.
   A BGP speaker that originates BGP routes shall assign the degree of
   preference to these routes by passing them through the Decision
   Process (see Section 9.1). These routes may also be distributed to
   other BGP speakers within the local AS as part of the update process
   (see Section 9.2). The decision whether to distribute non-BGP
   acquired routes within an AS via BGP or not depends on the
   environment within the AS (e.g. type of IGP) and should be =
controlled
   via configuration.





Appendix 1. Comparison with RFC1771


   There are numerous editorial changes (too many to list here).

   The following list the technical changes:

      Changes to reflect the usages of such features as TCP MD5 [10],
      BGP Route Reflectors [11], BGP Confederations [13], and BGP Route
      Refresh [12].

      Clarification on the use of the BGP Identifier in the AGGREGATOR
      attribute.

      Procedures for imposing an upper bound on the number of prefixes
      that a BGP speaker would accept from a peer.

      The ability of a BGP speaker to include more than one instance of
      its own AS in the AS_PATH attribute for the purpose of inter-AS
      traffic engineering.

      Clarifications on the various types of NEXT_HOPs.




Expiration Date July 2002                                      =0C[Page =
58]





RFC DRAFT                                                   January =
2002


      Clarifications to the use of the ATOMIC_AGGREGATE attribute.

      The relationship between the immediate next hop, and the next hop
      as specified in the NEXT_HOP path attribute.

      Clarifications on the tie-breaking procedures.


Appendix 2. Comparison with RFC1267


   All the changes listed in Appendix 1, plus the following.

   BGP-4 is capable of operating in an environment where a set of
   reachable destinations may be expressed via a single IP prefix.  The
   concept of network classes, or subnetting is foreign to BGP-4.  To
   accommodate these capabilities BGP-4 changes semantics and encoding
   associated with the AS_PATH attribute. New text has been added to
   define semantics associated with IP prefixes. These abilities allow
   BGP-4 to support the proposed supernetting scheme [9].

   To simplify configuration this version introduces a new attribute,
   LOCAL_PREF, that facilitates route selection procedures.

   The INTER_AS_METRIC attribute has been renamed to be =
MULTI_EXIT_DISC.
   A new attribute, ATOMIC_AGGREGATE, has been introduced to insure =
that
   certain aggregates are not de-aggregated. Another new attribute,
   AGGREGATOR, can be added to aggregate routes in order to advertise
   which AS and which BGP speaker within that AS caused the =
aggregation.

   To insure that Hold Timers are symmetric, the Hold Time is now
   negotiated on a per-connection basis. Hold Times of zero are now
   supported.

Appendix 3. Comparison with RFC 1163


   All of the changes listed in Appendices 1 and 2, plus the following.

   To detect and recover from BGP connection collision, a new field =
(BGP
   Identifier) has been added to the OPEN message. New text (Section
   6.8) has been added to specify the procedure for detecting and
   recovering from collision.

   The new document no longer restricts the border router that is =
passed
   in the NEXT_HOP path attribute to be part of the same Autonomous
   System as the BGP Speaker.




Expiration Date July 2002                                      =0C[Page =
59]





RFC DRAFT                                                   January =
2002


   New document optimizes and simplifies the exchange of the =
information
   about previously reachable routes.


Appendix 4. Comparison with RFC 1105


   All of the changes listed in Appendices 1, 2 and 3, plus the
   following.

   Minor changes to the RFC1105 Finite State Machine were necessary to
   accommodate the TCP user interface provided by 4.3 BSD.

   The notion of Up/Down/Horizontal relations present in RFC1105 has
   been removed from the protocol.

   The changes in the message format from RFC1105 are as follows:

      1.  The Hold Time field has been removed from the BGP header and
      added to the OPEN message.

      2.  The version field has been removed from the BGP header and
      added to the OPEN message.

      3.  The Link Type field has been removed from the OPEN message.

      4.  The OPEN CONFIRM message has been eliminated and replaced =
with
      implicit confirmation provided by the KEEPALIVE message.

      5.  The format of the UPDATE message has been changed
      significantly.  New fields were added to the UPDATE message to
      support multiple path attributes.

      6.  The Marker field has been expanded and its role broadened to
      support authentication.

      Note that quite often BGP, as specified in RFC 1105, is referred
      to as BGP-1, BGP, as specified in RFC 1163, is referred to as
      BGP-2, BGP, as specified in RFC1267 is referred to as BGP-3, and
      BGP, as specified in this document is referred to as BGP-4.


Appendix 5.  TCP options that may be used with BGP


   If a local system TCP user interface supports TCP PUSH function, =
then
   each BGP message should be transmitted with PUSH flag set.  Setting
   PUSH flag forces BGP messages to be transmitted promptly to the



Expiration Date July 2002                                      =0C[Page =
60]





RFC DRAFT                                                   January =
2002


   receiver.

   If a local system TCP user interface supports setting precedence for
   TCP connection, then the BGP transport connection should be opened
   with precedence set to Internetwork Control (110) value (see also
   [6]).

   A local system may protect its BGP sessions by using the TCP MD5
   Signature Option [10].


Appendix 6.  Implementation Recommendations


   This section presents some implementation recommendations.


6.1 Multiple Networks Per Message


   The BGP protocol allows for multiple address prefixes with the same
   path attributes to be specified in one message. Making use of this
   capability is highly recommended. With one address prefix per =
message
   there is a substantial increase in overhead in the receiver. Not =
only
   does the system overhead increase due to the reception of multiple
   messages, but the overhead of scanning the routing table for updates
   to BGP peers and other routing protocols (and sending the associated
   messages) is incurred multiple times as well.

   One method of building messages containing many address prefixes per
   a path attribute set from a routing table that is not organized on a
   per path attribute set basis is to build many messages as the =
routing
   table is scanned. As each address prefix is processed, a message for
   the associated set of path attributes is allocated, if it does not
   exist, and the new address prefix is added to it.  If such a message
   exists, the new address prefix is just appended to it. If the =
message
   lacks the space to hold the new address prefix, it is transmitted, a
   new message is allocated, and the new address prefix is inserted =
into
   the new message. When the entire routing table has been scanned, all
   allocated messages are sent and their resources released.  Maximum
   compression is achieved when all  the destinations covered by the
   address prefixes share a common set of path attributes making it
   possible to send many address prefixes in one 4096-byte message.

   When peering with a BGP implementation that does not compress
   multiple address prefixes into one message, it may be necessary to
   take steps to reduce the overhead from the flood of data received
   when a peer is acquired or a significant network topology change



Expiration Date July 2002                                      =0C[Page =
61]





RFC DRAFT                                                   January =
2002


   occurs. One method of doing this is to limit the rate of updates.
   This will eliminate the redundant scanning of the routing table to
   provide flash updates for BGP peers and other routing protocols. A
   disadvantage of this approach is that it increases the propagation
   latency of routing information.  By choosing a minimum flash update
   interval that is not much greater than the time it takes to process
   the multiple messages this latency should be minimized. A better
   method would be to read all received messages before sending =
updates.


6.2  Processing Messages on a Stream Protocol


   BGP uses TCP as a transport mechanism.  Due to the stream nature of
   TCP, all the data for received messages does not necessarily arrive
   at the same time. This can make it difficult to process the data as
   messages, especially on systems such as BSD Unix where it is not
   possible to determine how much data has been received but not yet
   processed.

   One method that can be used in this situation is to first try to =
read
   just the message header. For the KEEPALIVE message type, this is a
   complete message; for other message types, the header should first =
be
   verified, in particular the total length. If all checks are
   successful, the specified length, minus the size of the message
   header is the amount of data left to read. An implementation that
   would "hang" the routing information process while trying to read
   from a peer could set up a message buffer (4096 bytes) per peer and
   fill it with data as available until a complete message has been
   received.


6.3 Reducing route flapping


   To avoid excessive route flapping a BGP speaker which needs to
   withdraw a destination and send an update about a more specific or
   less specific route SHOULD combine them into the same UPDATE =
message.


6.4 BGP Timers


   BGP employs five timers: ConnectRetry, Hold Time, KeepAlive,
   MinASOriginationInterval, and MinRouteAdvertisementInterval The
   suggested value for the ConnectRetry timer is 120 seconds.  The
   suggested value for the Hold Time is 90 seconds.  The suggested =
value
   for the KeepAlive timer is 1/3 of the Hold Time.  The suggested =
value



Expiration Date July 2002                                      =0C[Page =
62]





RFC DRAFT                                                   January =
2002


   for the MinASOriginationInterval is 15 seconds.  The suggested value
   for the MinRouteAdvertisementInterval is 30 seconds.

   An implementation of BGP MUST allow the Hold Time timer to be
   configurable, and MAY allow the other timers to be configurable.



6.5 Path attribute ordering


   Implementations which combine update messages as described above in
   6.1 may prefer to see all path attributes presented in a known =
order.
   This permits them to quickly identify sets of attributes from
   different update messages which are semantically identical.  To
   facilitate this, it is a useful optimization to order the path
   attributes according to type code.  This optimization is entirely
   optional.


6.6 AS_SET sorting


   Another useful optimization that can be done to simplify this
   situation is to sort the AS numbers found in an AS_SET.  This
   optimization is entirely optional.


6.7 Control over version negotiation


   Since BGP-4 is capable of carrying aggregated routes which cannot be
   properly represented in BGP-3, an implementation which supports =
BGP-4
   and another BGP version should provide the capability to only speak
   BGP-4 on a per-peer basis.


6.8 Complex AS_PATH aggregation


   An implementation which chooses to provide a path aggregation
   algorithm which retains significant amounts of path information may
   wish to use the following procedure:

      For the purpose of aggregating AS_PATH attributes of two routes,
      we model each AS as a tuple <type, value>, where "type" =
identifies
      a type of the path segment the AS belongs to (e.g.  AS_SEQUENCE,
      AS_SET), and "value" is the AS number.  Two ASs are said to be =
the



Expiration Date July 2002                                      =0C[Page =
63]





RFC DRAFT                                                   January =
2002


      same if their corresponding <type, value> tuples are the same.

      The algorithm to aggregate two AS_PATH attributes works as
      follows:

         a) Identify the same ASs (as defined above) within each =
AS_PATH
         attribute that are in the same relative order within both
         AS_PATH attributes.  Two ASs, X and Y, are said to be in the
         same order if either:
            - X precedes Y in both AS_PATH attributes, or - Y precedes =
X
            in both AS_PATH attributes.

         b) The aggregated AS_PATH attribute consists of ASs identified
         in (a) in exactly the same order as they appear in the AS_PATH
         attributes to be aggregated. If two consecutive ASs identified
         in (a) do not immediately follow each other in both of the
         AS_PATH attributes to be aggregated, then the intervening ASs
         (ASs that are between the two consecutive ASs that are the
         same) in both attributes are combined into an AS_SET path
         segment that consists of the intervening ASs from both AS_PATH
         attributes; this segment is then placed in between the two
         consecutive ASs identified in (a) of the aggregated attribute.
         If two consecutive ASs identified in (a) immediately follow
         each other in one attribute, but do not follow in another, =
then
         the intervening ASs of the latter are combined into an AS_SET
         path segment; this segment is then placed in between the two
         consecutive ASs identified in (a) of the aggregated attribute.

      If as a result of the above procedure a given AS number appears
      more than once within the aggregated AS_PATH attribute, all, but
      the last instance (rightmost occurrence) of that AS number should
      be removed from the aggregated AS_PATH attribute.


Security Considerations


   BGP supports the ability to authenticate BGP messages by using BGP
   authentication. The authentication could be done on a per peer =
basis.
   In addition, BGP supports the ability to authenticate its data =
stream
   by using [10]. This authentication could be done on a per peer =
basis.
   Finally, BGP could also use IPSec to authenticate its data stream.
   Among the mechanisms mentioned in this paragraph, [10] is the most
   widely deployed.







Expiration Date July 2002                                      =0C[Page =
64]





RFC DRAFT                                                   January =
2002


References


   [1] Mills, D., "Exterior Gateway Protocol Formal Specification",
   RFC904, April 1984.

   [2] Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET
   Backbone", RFC1092, February 1989.

   [3] Braun, H-W., "The NSFNET Routing Architecture", RFC1093, =
February
   1989.

   [4] Postel, J., "Transmission Control Protocol - DARPA Internet
   Program Protocol Specification", RFC793, September 1981.

   [5] Rekhter, Y., and P. Gross, "Application of the Border Gateway
   Protocol in the Internet", RFC1772, March 1995.

   [6] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
   Specification", RFC791, September 1981.

   [7] "Information Processing Systems - Telecommunications and
   Information Exchange between Systems - Protocol for Exchange of
   Inter-domain Routeing Information among Intermediate Systems to
   Support Forwarding of ISO 8473 PDUs", ISO/IEC IS10747, 1993

   [8] Fuller, V., Li, T., Yu, J., and Varadhan, K., ""Classless Inter-
   Domain Routing (CIDR): an Address Assignment and Aggregation
   Strategy", RFC1519, September 1993.

   [9] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation
   with CIDR", RFC 1518, September 1993.

   [10] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
   Signature Option", RFC2385, August 1998.

   [11] Bates, T., Chandra, R., Chen, E., "BGP Route Reflection - An
   Alternative to Full Mesh IBGP", RFC2796,  April 2000.

   [12] Chen, E., "Route Refresh Capability for BGP-4", RFC2918,
   September 2000.

   [13] Traina, P, McPherson, D., Scudder, J., "Autonomous System
   Confederations for BGP", RFC3065, February 2001.







Expiration Date July 2002                                      =0C[Page =
65]





RFC DRAFT                                                   January =
2002


Editors' Addresses

   Yakov Rekhter
   Juniper Networks
   1194 N. Mathilda Avenue
   Sunnyvale, CA 94089
   email:  [e-mail]

   Tony Li
   Procket Networks
   1100 Cadillac Ct.
   Milpitas, CA 95035
   Email:  [e-mail]






































Expiration Date July 2002                                      =0C[Page =
66]




------_=_NextPart_000_01C281A9.64ABEC00--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA05342 for <[e-mail]>; Fri, 1 Nov 2002 02:36:24 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8888791220; Fri,  1 Nov 2002 02:35:56 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A65B91221; Fri,  1 Nov 2002 02:35:56 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C88CD91220 for <[e-mail]>; Fri,  1 Nov 2002 02:35:54 -0500 (EST)
Received: by segue.merit.edu (Postfix) id AF02A5DF1F; Fri,  1 Nov 2002 02:35:54 -0500 (EST)
Delivered-To: [e-mail]
Received: from sword.6test.edu.cn (unknown [202.38.99.37]) by segue.merit.edu (Postfix) with SMTP id 4856E5DE1A for <[e-mail]>; Fri,  1 Nov 2002 02:35:53 -0500 (EST)
Received: (qmail 54054 invoked from network); 1 Nov 2002 07:29:40 -0000
Received: from unknown (HELO sword) (166.111.65.214) by 202.38.99.37 with SMTP; 1 Nov 2002 07:29:40 -0000
Date: Fri, 1 Nov 2002 15:37:42 +0800
From: "Qiu Jian" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Why MinRouteAdverInterval is recommended 30
Organization: CERNET
X-mailer: Foxmail 4.1 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id CAA05342

Hello, idr

    I am a graduate student and hope you kindly give
me some help.
	I have a question on MinRouteAdverInterval:
    Why MinRouteAdverInterval is recommended to
 be 30 seconds? 
    Is it right to say that the Maximal Propagation 
Delay in Internet is almost less than 30 seconds, 
so MinRouteAdverInterval is set to 30 seconds to 
guarantte the furthest route change can be caught 
before sending the relevant update?
    Thank you very much!
Have a nice day!
 				

¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Qiu Jian
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡[e-mail]
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-11-01