Subject: Tentative Agenda for 12/13/01
From: Susan Hares <[email-masked]>
To: [email-masked]
Cc: [email-masked], yakov Rekhter <[email-masked]>
Date: Fri, 30 Nov 2001 17:31:43 -0500

idr people the current agenda for IDR is short:

1) IDR charter [Sue Hares]
2) IDR-16 base document [Sue Hares]
3) IDR MIBs - [Jeff Haas]
4) IDR document status [Sue Hares]

I will post the slides for the meeting on the IETF web
site and another web site so you can preview the
meeting notes by 12/7.

Please let Yakov or I know if there are any other
agenda items.

Sue

Date: Thu, 29 Nov 2001 17:06:02 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Dynamic Capabilities draft and Route Refresh and the FSM
Cc: yakov Rekhter <[email-masked]>
Sender: [email-masked]

--=====================_38210213==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

This note has 4 issues about the FSM in IDR draft/

1) FSM wording will be added

The input from the IDR mail list I have received is to add the FSM
wording to the IDR document.    I have submitted the words to Yakov
as one of the document editors.

The concerns with FSM are:

"John Scudder" - who away from work for an extended period and has not
                  been able to comment.

"Enke Chen"  - who had lists of questions on the FSM which I answered

"Dennis Ferguson" - who said improve it beyond the current text into a better
                             state machine to take care of the "connection 
collision".
                                Dennis did not send any additional comments 
on better text.

On Dennis point, I would need to change the connection collision text or get
suggestions from Dennis to continue in any meaningful way.    If people want
to suggest changes to the collision detection text or the FSM, I'll be glad
to work with anyone on that wording.

2) Appendix B replacement with State Machine

I'd further like comments on the format of the Appendix B representation
of the state machine.  I'm planning to use a format similar to appendix B
that I used in my original comment.

Please send comments to me privately or to Yakov or to the mail group.
I'll take comments until next Monday (12/3/01).   After Monday, I'll post a 
new
appendix B to the mail group.

3) State machine and new drafts -
         Is the following list of drafts that need FSM harmonization
        represent the full list for the IP v4 list?

As we have now added the FSM back into the base draft, it is my understanding
we need to add text in the following RFCs and drafts  for the FSM:

         a) Dynamic Capabilities  (draft-ietf-idr-dynamic-cap-00.txt)
                 [Capability message needs to be added to state machine]

         b) and Capabilities Advertisement with BGP-4  (RFC 2842)
                 [subcodes upon NOTIFICATION with CEASE after OPEN with
                    Dynamic capabilities need to alter state machine.   My
             understanding is that given this Cease subcode, this spec.
             indicates that you do not use the "hold-down" function described
             in the Idle state.]

         c) Route Refresh (RFC 2918)  [Refresh message received in 
Established state]

         d) Graceful restart [draft-ietf-idr-restart-01.txt]
                 [State transitions upon termination of connection and 
start-up.]

         e) Subcodes for BGP  Cease Notification [ 
draft-ietf-idr-cease-subcode-00.txt]

         Has text with:

 >It is recommended that a BGP speaker implement a backoff mechanism in 
re-trying a BGP >connection after the speaker receives a Cease NOTIFICATION 
message with subcode of >"Administratively Shutdown", or "Peer 
Unconfigured", or "Connection Rejected". An >implementation may impose an 
upper bound on the number of consecutive automatic retries.    >Once this 
bound is reached, the implementation would stop re-trying any BGP 
connections >until some administrative intervention.

This text from the subcodes draft either pre-dates the back-off
language from the idr draft or it must be harmonized with that
"back-off" language.   A simple solution would be to remove this
text from the subcodes draft.

I would appreciate feedback from the authors and the IDR mail group on these
drafts or any other drafts that are impacted by the proposed FSM changes.

4)  What FSM problems does the IP V6 draft impact

     Do any of the IP v6 drafts need specific FSM interaction?

         1) Alain Durand - router-id draft -- for IP v6
         2) MPBGP v6 with link local versus Site local -

         My understand

Note:  RFC 2547 is specifically not listed above.  We will tackle the FSM for
            RFC 2547 as a second pass.

Sue Hares
[email-masked]

--=====================_38210213==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font face="Courier New, Courier">This note has 4 issues about the FSM in
IDR draft/<br>
<br>
1) FSM wording will be added<br>
<br>
The input from the IDR mail list I have received is to add the FSM <br>
wording to the IDR document.&nbsp;&nbsp;&nbsp; I have submitted the words
to Yakov<br>
as one of the document editors.<br>
<br>
The concerns with FSM are:<br>
<br>
&quot;John Scudder&quot; - who away from work for an extended period and
has not<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
been able to comment. <br>
<br>
&quot;Enke Chen&quot;&nbsp; - who had lists of questions on the FSM which
I answered<br>
<br>
&quot;Dennis Ferguson&quot; - who said improve it beyond the current text
into a better<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
state machine to take care of the &quot;connection collision&quot;.<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Dennis did not send any additional comments on better text.<br>
<br>
On Dennis point, I would need to change the connection collision text or
get<br>
suggestions from Dennis to continue in any meaningful
way.&nbsp;&nbsp;&nbsp; If people want<br>
to suggest changes to the collision detection text or the FSM, I'll be
glad<br>
to work with anyone on that wording.<br>
<br>
2) Appendix B replacement with State Machine <br>
<br>
I'd further like comments on the format of the Appendix B
representation<br>
of the state machine.&nbsp; I'm planning to use a format similar to
appendix B<br>
that I used in my original comment. <br>
<br>
Please send comments to me privately or to Yakov or to the mail
group.&nbsp;&nbsp; <br>
I'll take comments until next Monday (12/3/01).&nbsp;&nbsp; After Monday,
I'll post a new <br>
appendix B to the mail group.<br>
<br>
3) State machine and new drafts -&nbsp; <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Is the
following list of drafts that need FSM harmonization<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; represent the full list for the IP
v4 list? <br>
<br>
As we have now added the FSM back into the base draft, it is my
understanding<br>
we need to add text in the following RFCs and drafts&nbsp; for the
FSM:<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>a) Dynamic
Capabilities&nbsp; (draft-ietf-idr-dynamic-cap-00.txt)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>[Capability
message needs to be added to state machine]<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>b) and
Capabilities Advertisement with BGP-4&nbsp; (RFC 2842)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>[subcodes
upon NOTIFICATION with CEASE after OPEN with<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;
Dynamic capabilities need to alter state machine.&nbsp;&nbsp; My <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
understanding is that given this Cease subcode, this spec. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
indicates that you do not use the &quot;hold-down&quot; function
described<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the
Idle state.]<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>c) Route
Refresh (RFC 2918)&nbsp; [Refresh message received in Established
state]<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>d)
Graceful restart [draft-ietf-idr-restart-01.txt]<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>[State
transitions upon termination of connection and start-up.]<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>e)
Subcodes for BGP&nbsp; Cease Notification [
draft-ietf-idr-cease-subcode-00.txt]<br>
<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Has text
with:<br>
<br>
&gt;It is recommended that a BGP speaker implement a backoff mechanism in
re-trying a BGP &gt;connection after the speaker receives a Cease
NOTIFICATION message with subcode of &gt;&quot;Administratively
Shutdown&quot;, or &quot;Peer Unconfigured&quot;, or &quot;Connection
Rejected&quot;. An &gt;implementation may impose an upper bound on the
number of consecutive automatic retries.&nbsp;&nbsp;&nbsp; &gt;Once this
bound is reached, the implementation would stop re-trying any BGP
connections &gt;until some administrative intervention. <br>
<br>
This text from the subcodes draft either pre-dates the back-off<br>
language from the idr draft or it must be harmonized with that<br>
&quot;back-off&quot; language.&nbsp;&nbsp; A simple solution would be to
remove this<br>
text from the subcodes draft. <br>
<br>
I would appreciate feedback from the authors and the IDR mail group on
these<br>
drafts or any other drafts that are impacted by the proposed FSM
changes.<br>
<br>
<br>
4)&nbsp; What FSM problems does the IP V6 draft impact<br>
<br>
&nbsp;&nbsp;&nbsp; Do any of the IP v6 drafts need specific FSM
interaction? <br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>1) Alain
Durand - router-id draft -- for IP v6<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>2) MPBGP
v6 with link local versus Site local -<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>My
understand<br>
<br>
<br>
Note:&nbsp; RFC 2547 is specifically not listed above.&nbsp; We will
tackle the FSM for<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;
RFC 2547 as a second pass.&nbsp;&nbsp; <br>
<br>
<br>
<br>
Sue Hares<br>
[email-masked]</font><br>
</html>

--=====================_38210213==_.ALT--

Date: Wed, 28 Nov 2001 09:38:41 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: [[email-masked]: I-D ACTION:draft-ietf-idr-bgp4-mib-08.txt]
Sender: [email-masked]

MIB implementors,

This revision of the BGP MIB is targeted for last call.  Due to the
time constraints, the last call will not take place at this IETF.
Please review this MIB and comment during the MIB section of IDR.

There will also be discussion on the MIBv2 which didn't quite make
it in prior to the I-D cutoff.  The current version, to be
published as an I-D when submissions are permitted again, will be
posted to IDR to allow for comment.

----- Forwarded message from [email-masked] -----

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, S. Willis, J. Burruss, J. Chu
	Filename	: draft-ietf-idr-bgp4-mib-08.txt
	Pages		: 33
	Date		: 21-Nov-01
	
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.

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

----- End forwarded message -----

-- 
Jeff Haas 
NextHop Technologies

Reply-To: "Manav Bhatia" <[email-masked]>
From: "Manav Bhatia" <[email-masked]>
To: <[email-masked]>
Subject: draft-ietf-idr-bgp-dpa-04.txt 
Date: Wed, 28 Nov 2001 08:32:04 +0530
Organization: Samsung India Operations
Sender: [email-masked]

Hi,
Can anybody please tell me as to what is the current status of
draft-ietf-idr-bgp-dpa-04.txt ?

Regards,
Manav

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Date: Tue, 27 Nov 2001 10:59:02 -0500
From: Jeffrey Haas <[email-masked]>
To: Mareline Sheldon <[email-masked]>
Cc: [email-masked]
Subject: Re: Path Attributes
Sender: [email-masked]

>From http://www.iana.org/assignments/bgp-parameters
  11       DPA                                  [Chen]
  12       ADVERTISER                        [RFC1863]
  13       RCID_PATH / CLUSTER_ID            [RFC1863]

On Tue, Nov 27, 2001 at 08:49:23PM +0530, Mareline Sheldon wrote:
> Can anybody please tell me as to what do the following BGP Attribute type
> codes 11,12,13 stand for ?

I don't believe any is deploying implementations that implement
these attributes.

-- 
Jeff Haas 
NextHop Technologies

From: "Mareline Sheldon" <[email-masked]>
To: <[email-masked]>
Subject: Path Attributes
Date: Tue, 27 Nov 2001 20:49:23 +0530
Sender: [email-masked]

Can anybody please tell me as to what do the following BGP Attribute type
codes 11,12,13 stand for ?

Regards,
Mary

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Date: Wed, 21 Nov 2001 16:39:25 -0500 (EST)
From: [email-masked]
To: [email-masked]
Subject: BGP Security Analysis
Cc: [email-masked]
Sender: [email-masked]

Some of you may remember a draft I wrote starting a couple of years ago
that talked about the vulnerabilities in BGP and desribed several possible
security solutions and their costs.  That draft went through four versions
and was presented at some of the idr meetings.

For several reasons (promises to a couple of IESG people and others,
the recent CERT report mentioning increasing concern about routing
protocols attacks, the IAB BGP architecture report's security
considerations section, etc.), I've decided to try to resurrect this
work.

So here's the draft, just submitted to internet-drafts, but I think
just maybe they're busy.  :-)

--Sandy

P.S.  I just received a message at 4:20 saying they were sorry but the
5pm deadline had passed before my message was received.  (?)

---------------------------------------------------------------------

Network Working Group                                      Sandra Murphy
INTERNET DRAFT                                                  NAI Labs
draft-ietf-murphy-bgp-secr-04.txt                          November 2001

                         BGP Security Analysis

Status of this Memo

This document is an Internet-Draft and is subject to 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/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

Abstract

BGP, along with a host of other infrastructure protocols designed before
the Internet environment became perilous, is designed with little
consideration for protection of the information it carries.  There are
no mechanisms in BGP to protect against attacks that modify, delete,
forge, or replay data, any of which has the potential to disrupt overall
network routing behavior.

This internet draft discusses some of the security issues with BGP
routing data dissemination, and possible security solutions and the
costs of those solutions.  This internet draft does not discuss security
issues with forwarding of packets.

Murphy                      Expires: May 2001                   [Page 1]

INTERNET DRAFT            BGP Security Analysis            November 2001

Table of Contents

 Status of this Memo ..............................................    1
 Abstract .........................................................    1
1 Introduction ....................................................    4
2 Vulnerabilities and Risks .......................................    6
3 Possible Protections ............................................    6
3.1 Threats from outsiders ........................................    6
3.1.1 IP level protection .........................................    7
3.1.2 TCP level protection ........................................    7
3.2 Threats from BGP peers ........................................    8
3.3 Origination Protection ........................................    8
3.4 Origination and Adjacency Protection ..........................    9
3.5 Sign Originating AS and AS_PATH ...............................   10
3.5.1 Remaining Issues ............................................   11
3.6 Filtering .....................................................   13
4 Security Costs ..................................................   14
4.1 Protecting the Peer-Peer Link .................................   14
4.2 Origination Protection ........................................   14
4.3 Origination and Adjacency Protection ..........................   15
4.4 Origination and AS_PATH Protection ............................   15
4.5 Rely on Registries ............................................   16
5 Security Considerations .........................................   16
6 References ......................................................   16
7 Author's Address ................................................   17
A Appendix A - Vulnerabilities and Risks ..........................   18
A.1 OPEN ..........................................................   18
A.2 KEEPALIVE .....................................................   18
A.3 NOTIFICATION ..................................................   18
A.4 UPDATE ........................................................   18
A.4.1 Unfeasible Routes Length, Total Path Attribute Length .......   18
A.4.2 Withdrawn Routes ............................................   19
A.4.3 Path Attributes .............................................   19
 Attribute Flags, Attribute Type Codes, Attribute Length ..........   19
 ORIGIN ...........................................................   19
 AS_PATH ..........................................................   20
 Originating Routes ...............................................   20
 NEXT_HOP .........................................................   21
 MULTI_EXIT_DISC ..................................................   21
 LOCAL_PREF .......................................................   21
 ATOMIC_AGGREGATE .................................................   22
 AGGREGATOR .......................................................   22
A.4.4 NLRI ........................................................   22

Murphy                      Expires: May 2001                   [Page 2]

INTERNET DRAFT            BGP Security Analysis            November 2001

Murphy                      Expires: May 2001                   [Page 3]

INTERNET DRAFT            BGP Security Analysis            November 2001

1.  Introduction

The inter-domain routing protocol BGP was created when the Internet
environment had not yet reached the present contentious state.
Consequently, the BGP protocol was not designed with protection against
deliberate or accidental errors causing disruptions of routing behavior.

We here discuss the vulnerabilities of BGP, based on the BGP RFC [1] and
on [2].  Readers are expected to be familiar with the BGP RFC and the
behavior of BGP.  We propose several different security solutions to
protect these vulnerabilities and discuss the benefits derived from each
solution and its cost.

It is clear that the Internet is vulnerable to attack through its
routing protocols.  BGP is no exception.  Faulty, misconfigured or
deliberately malicious sources can disrupt overall Internet behavior by
injecting bogus routing information into the BGP distributed routing
database (by modifying, forging, or replaying BGP packets).  The same
methods can also be used to disrupt local and overall network behavior
by breaking the distributed communication of information between BGP
peers.  The sources of bogus information can be either outsiders or true
BGP peers.

Under the present BGP design, cryptographic authentication of the peer-
peer communication is not mandated.  As a TCP/IP protocol, BGP is
subject to all the TCP/IP attacks, like IP spoofing, session stealing,
etc.  Any outsider can inject believable BGP messages into the
communication between BGP peers and thereby inject bogus routing
information or break the peer to peer connection.  Any break in the peer
to peer communication has a ripple effect on routing that can be wide
spread.  Furthermore, outsider sources can also disrupt communications
between BGP peers by breaking their TCP connection with spoofed RST
packets.  Outsider sources of bogus BGP information can reside anywhere
in the world.

BGP speakers themselves can inject bogus routing information, either by
masquerading as information from any other legitimate BGP speaker, or by
distributing unauthentic routing information as themselves.
Historically, misconfigured and faulty routers have been responsible for
widespread disruptions in the Internet.

Bogus routing information can have many different effects on routing
behavior.  If the bogus information removes routing information for a
particular network, that network can become unreachable for the portion
of the Internet that accepts the bogus information.  If the bogus

Murphy                      Expires: May 2001                   [Page 4]

INTERNET DRAFT            BGP Security Analysis            November 2001

information changes the route to a network, then packets destined for
that network may be forwarded by a sub-optimal path, or a path that does
not follow the expected policy, or a path that will not forward the
traffic.  As a consequence, traffic to that network could be delayed by
a longer than necessary path.  The network could become unreachable from
areas where the bogus information is accepted.  Traffic might also be
forwarded along a path that permits some adversary a view of the data.
If the bogus information makes it appear that an autonomous system
originates a network when it does not, then packets for that network may
not be deliverable for the portion of the Internet that accepts the
bogus information.  A false announcement that an autonomous systems
originates a network may also fragment aggregated address blocks in
other parts of the Internet and cause routing problems for other
networks.

The damage that might result from these attacks are:

     starvation: data traffic destined for a node is forwarded to a part
     of the network that cannot deliver it,

     network congestion: more data traffic is forwarded through some
     portion of the network than would otherwise need to carry the
     traffic,

     blackhole: large amounts of traffic are directed to be forwarded
     through one router that cannot handle the increased level of
     traffic and drops many/most/all packets,

     delay: data traffic destined for a node is forwarded along a path
     that is in some way inferior to the path it would otherwise take,

     looping: data traffic is forwarded along a path that loops, so that
     the data is never delivered,

     eavesdrop: data traffic is forwarded through some router or network
     that would otherwise not see the traffic, affording an opportunity
     to see the data,

     partition: some portion of the network believes that it is
     partitioned from the rest of the network when it is not,

     cut: some portion of the network believes that it has no route to
     some network that is in fact connected,

Murphy                      Expires: May 2001                   [Page 5]

INTERNET DRAFT            BGP Security Analysis            November 2001

     churn: the forwarding in the network changes at a rapid pace,
     resulting in large variations in the data delivery patterns (and
     adversely affecting congestion control techniques),

     instability: BGP become unstable so that convergence on a global
     forwarding state is not achieved, and

     overload: the BGP messages themselves become a significant portion
     of the traffic the network carries.

2.  Vulnerabilities and Risks

The risks in BGP arise from three fundamental vulnerabilities:

     no mechanism has been mandated that provides strong protection of
     the integrity, freshness and source authenticity of the messages in
     peer-peer BGP communications.

     no mechanism has been specified to validate the authority of an AS
     to announce NLRI information.

     no mechanism has been specified to ensure the authenticity of the
     AS_PATH announced by an AS.

There are four different BGP message types - OPEN, KEEPALIVE,
NOTIFICATION, and UPDATE.  A discussion of the vulnerabilities arising
from each message and the ability of outsiders or BGP peers to exploit
the vulnerabilities is contained in Appendix A.  To summarize, outsiders
can use bogus OPEN, KEEPALIVE, or NOTIFICATION messages to disrupt the
BGP peer-peer connections and can use bogus UPDATE messages to disrupt
routing.  Outsiders can also disrupt BGP peer-peer connections by
inserting bogus TCP RST packets.  BGP peers themselves are permitted to
break peer-peer connections at any time, and so they cannot be said to
be issuing "bogus" OPEN, KEEPALIVE or NOTIFICATION messages.  However,
BGP peers can disrupt routing by issuing bogus UPDATE messages.  In
particular, bogus ATOMIC_AGGREGATE and AS_PATH attributes and bogus NLRI
in UPDATE messages can disrupt routing.

3.  Possible Protections

3.1.  Threats from outsiders

Outsiders can be prevented from disrupting routing by providing
cryptographic protection of the BGP peer-peer connection.  The
cryptography chosen should protect the source authenticity and integrity

Murphy                      Expires: May 2001                   [Page 6]

INTERNET DRAFT            BGP Security Analysis            November 2001

of the message and should also protect against replay.  As the
protection is only of the peer-peer communications, asymmetric
cryptography is not needed.  Two different protection against spoofing
in the peer-peer connection have been suggested:

     IP level protection as defined by IPSEC [7]

     TCP level protection as defined by [8]

Prevention of IP spoofing completely removes any risk associated with
bogus OPEN, KEEPALIVE, or NOTIFICATION messages, as the only
vulnerabilities from these messages come from outsiders.  It also
protects against all threats from bogus UPDATE messages and from bogus
TCP messages arising from outsiders.

3.1.1.  IP level protection

Protection as specified for the IPSEC [7] can be used to provide
connectionless integrity, data origin authentication, and a anti-replay
service.

3.1.2.  TCP level protection

It is possible to protect the peer-peer connection by applying
cryptographic protection at the TCP level to provide connectionless
integrity and data origin authentication.  This has been in use with
some vendors for some time as specified in [8].  Note, however, that the
protections specified in [8] were put in place some time ago.  The IPSEC
protections have advanced since that time.  In particular, the
protections of [8] use MD5 directly, where the IPSEC protections mandate
the use of HMAC-MD5 because of recently publicized concerns of
collisions in MD5.  Also, [8] does not have the provisions for anti-
reply found in IPSEC.  The TCP sequence numbers do provide some
protection against replay. But as some packets, notably a RST packet,
need only be within the receive window to be accepted, the TCP sequence
number protection is not complete.  Finally, [8] has no provisions for
multiple keys to be used in rekeying.  As these are pairwise keys used
for long-lived sessions, the inability to specify multiple keys may not
cause operational difficulties.

Although the TCP level protection specified in [8] has deficiencies when
compared with the protection of IPSEC [7], it is vastly preferable to a
unprotected connection.  If IPSEC is not available, then the TCP level
protection of [8] should definitely be used.  When IPSEC is available,
IPSEC is preferable.  One or the other must be used.

Murphy                      Expires: May 2001                   [Page 7]

INTERNET DRAFT            BGP Security Analysis            November 2001

3.2.  Threats from BGP peers

Protection of the communication between BGP peers does nothing to
protect against errors introduced by the BGP speakers themselves.  BGP
speakers can introduce bogus routing information, e.g., invalid
AS_PATHs, false origination announcements of NLRI, etc., at any time.
Furthermore, detecting the BGP source of bogus information (if and when
the bogus-ness is detected) can be difficult if not impossible.

There are several possible solutions to prevent a BGP speaker from
inserting bogus information in its advertisements to its peers.

 (1)   Origination Protection: sign the originating AS.

 (2)   Origination and Adjacency Protection: sign the originating AS and
       predecessor information.

 (3)   Origination and Route Protection: sign the originating AS, and
       nest signatures of AS_PATHs to the number of consecutive bad
       routers you want to prevent from causing damage.

 (4)   Filtering: rely on a registry to verify the AS_PATH and NLRI
       originating AS.

The first three solutions are implemented within the protocol exchanges.
The last solution is an operational protection and leaves the protocol
messages unchanged.

3.3.  Origination Protection

It would be beneficial to authenticate the AS that first advertises a
route to a NLRI.  This could be done by including a new path attribute
which would contain the originating AS number and the originating AS's
digital signature [4] of the AS number plus the NLRI advertised.  A
digital signature (as opposed to a message integrity check using a
shared secret) is preferable because the number and identities of all
eventual recipients are not known and because non-repudiation would be
desired.  If routing was disturbed by the presence of this
advertisement, then the culprit could be determined.

If an infra-structure exists representing ownership of network
addresses, then the owner as well as the originator could sign.  This
signature would indicate that the AS was authorized by the owner to
originate the network.  A BGP speaker receiving a protected origination
could verify taht the origination was legitimate.

Murphy                      Expires: May 2001                   [Page 8]

INTERNET DRAFT            BGP Security Analysis            November 2001

If routes are aggregated by a BGP speaker and the aggregated route
advertised, then the idea of "originator" and "owner" become less
useful.  There might be several "originators" and "owners" represented
among the aggregated routes.  The AGGREGATOR field should be mandatory
and an aggregating BGP speaker should append its signature of the
AGGREGATOR field and the aggregated NLRI.  Unfortunately, aggregation
prevents identification of the specific culprit should it be discovered
that a network is being originated incorrectly.

This protection does not ensure that the AS_PATH is authentic or
current.

3.4.  Origination and Adjacency Protection

Reference [3] suggests several different types of cryptographic
protection of BGP.  The suggested protection against possibly faulty BGP
speakers introduces some link state topology information (as in OSPF
[5]) that can be used to verify AS_PATHs.

To obviate the need to trust BGP speakers regarding NLRI information not
specific to their own AS, [3] suggests adding the following information
to the UPDATE message in new path attributes:

-    a sequence number for the UPDATE

-    the AS originating the information (either the aggregator or the
     originator of a direct route) and

-    the "predecessor" of the originating AS (i.e., the neighbor to
     which the NLRI is first advertised).

This information is digitally signed by the BGP originator along with
the NLRI, the ATOMIC_AGGREGATE, the ORIGIN, and the AGGREGATOR fields of
the UPDATE message.  The signature and the predecessor information must
be included as the route in the UPDATE message propagates across the
network, i.e., it is transitive.

This information distributes a bit of link state topology information,
concerning just the last hop before the destination network's AS, into
the usual BGP distance vector (some say "path vector") protocol.  Each
BGP speaker will propogate this "predecessor" information.  Any BGP
speaker could use the signed predecessor information received to verify
that each of the adjacencies represented in an AS_PATH is legitimate.
That is, when a segment of an AS_PATH is a sequence, each adjacent pair
in the sequence could be verified to correspond to a received signed

Murphy                      Expires: May 2001                   [Page 9]

INTERNET DRAFT            BGP Security Analysis            November 2001

predecessor tuple.

The protection provided by the signed predecessor information becomes
more difficult to use past an aggregation point where a BGP speaker
advertises a less specific route which includes the originated NLRI.  In
particular, the rules for verifying an AS_PATH containing a segment that
is a set would be either very lenient or very complex.

While this predecessor information assures that each adjacency in a
sequence of an AS_PATH is valid, it does not ensure that the AS_PATH as
a whole is valid.  Each AS's decision regarding routes it will advertise
and traffic it will transit is individual and totally unconstrained.
The fact that a valid path of ASs exists to a destination does not
ensure that the corresponding AS_PATH is valid.  This mechanism also
does not assure that any information which comes from one router alone
(LOCAL_PREF, NEXT_HOP, AGGREGATOR, etc.)  is accurate.  A router, then,
can still falsely announce that its neighbor should be forwarded the
traffic for an NLRI.

3.5.  Sign Originating AS and AS_PATH

A protection against possibly faulty BGP speakers that does provide some
assurance that the AS_PATH is valid is described in [9].  The protection
requires digital signatures of nested prefixes of the AS_PATH, carried
in a transitive path attribute.

Each BGP speaker would receive signed route information (including the
AS_PATH, the ATOMIC_AGGREGATE attribute and NLRI) from its peer.  The
signature represents permission from the peer for the speaker to
advertise the route.  After making its routing decision, the BGP speaker
would augment the chosen AS_PATH with its own AS and sign the resulting
route (NLRI + AS_PATH) and ATOMIC_AGGREGATE.  The BGP speaker would pass
to its peers the augmented AS_PATH, its signature, and the signature it
received from its peer which covers the received AS_PATH.  The neighbor
receiving this information can verify that the received AS_PATH was
indeed constructed from an authorized path, by verifying the signature
of the BGP speaker's peer over the tail of the received AS_PATH.  The
BGP speaker's signature will be passed on by the neighbor to provide
similar assurance that it constructed its advertised AS_PATH
legitimately.

A BGP speaker could snip out a suffix of the data it received as well as
the associated signatures and pass those on as the proof that its
AS_PATH was based on reality.  To prevent this, the signatures generated
must cover not only the route information but the intended receiver as

Murphy                      Expires: May 2001                  [Page 10]

INTERNET DRAFT            BGP Security Analysis            November 2001

well.

This procedure as described protects against one consecutive faulty
router in the path.  If it is desired to protect against more than one
possibly faulty routers in the path, then the procedure can be nested
arbitrarily.  To protect against K consecutive faulty routers, each
router would receive signed AS_PATH information from its neighbor along
with K signatures of the preceding K BGP speakers in the path, each
successive signature covering a shorter suffix of the AS_PATH.  It would
pass on a newly constructed AS_PATH along with its own signature, its
neighbor's signature and K-1 of the included nested signatures.

For example, consider a case where it was decided to protect against two
faulty BGP speakers.  Suppose AS1 receives an AS_PATH from AS2 of 'AS2
AS3 AS4 ... ASk'.  (In this discussion as well as the next,
ATOMIC_AGGREGATE would be included in the signature, but is omitted for
brevity.)  Then AS1 should also receive AS2's signature of "AS1, 'AS2
AS3 ... ASk', NLRI" as well as AS3's signature of "AS2, 'AS3 ... ASk',
NLRI" and AS4's signature of "AS3, 'AS4 ... ASk', NLRI".  AS1 would
verify the authenticity of AS2's route by verifying the authorizing
signatures from AS3 and AS4.

AS1 uses AS2's signature in authorizing its own announcements.  AS1
would compute a path as 'AS1 AS2 AS3 ... ASk', and pass to its neighbor
AS0 this path along with its signature of "AS0, 'AS1 AS2 AS3 ... ASk',
NLRI" and the authorizing signatures of AS2 and AS3.

Because the intended recipient is included in the signature, each BGP
speaker with N peers generates N signatures for each route announced,
one for each peer.

This discussion is predicated on the use of asymmetric cryptography.
Each autonomous system would be required to possess an asymmetric key
pair.  The public key would have to be accessible to all recipients of
the digital signature.  The private key would have to be available to
all BGP speakers in the autonomous system, but protected from exposure.

3.5.1.  Remaining Issues

This scheme becomes more complicated when one of the BGP speakers
performs aggregation of a set of routes.  To assure recipients of the
validity of the aggregated route, it would be necessary to pass on the
text and signatures of each of the aggregated component routes.  This
means an enormous increase in transmission bandwidth at each aggregation
point and a similar increase in verification time at each verification

Murphy                      Expires: May 2001                  [Page 11]

INTERNET DRAFT            BGP Security Analysis            November 2001

point's peers.  This cost would not have to be passed on to further
neighbors further than K (the nesting level of signatures) hops away,
but it does violate the spirit of aggregation.  Alternatively, an
aggregation point could be treated as another type of origination point,
and signatures and verification would stop at that point.
Unfortunately, that provides a mechanism for malicious BGP peers to
announce bogus routes, simply by claiming to have aggregated the
information.  Aggregation also prevents identification of the specific
culprit should it be discovered that a network is being originated in
error.

Neither this scheme nor the Origination and Adjacency Protection assures
that the received route is the best route the peer could have computed.
In particular, it does not guard against a peer that does not announce
the best result of its decision process - for example, a peer that
replays previous updates instead of forwarding a withdrawal, or does not
change its announcements when it receives withdrawn routes, or replays
withdrawal information after a route is reestablished, or replays an
update after having forwarded a withdrawal.  These are a matter for the
internal correct operation of the router and cannot be precluded by
authentication or authorization protection.  This mechanism also does
not assure that any information which comes from one router alone
(LOCAL_PREF, NEXT_HOP, AGGREGATOR, etc.)  is accurate.  With these
fields, a router can still falsely announce that its neighbor should be
forwarded the traffic for an NLRI.

The verification process chooses the key to use based on the AS's
mentioned in the AS_PATH.  If implementations do not verify that the
peer BGP speaker prepended its own AS to the AS_PATH, i.e. if a BGP
speaker might pass on an AS_PATH in which it's own AS is not the first
in the PATH, then the AS's mentioned in the AS_PATH are not necessarily
the AS's that produced the signature.  In that case, this verification
process could be using the wrong key.  This signature scheme would have
to be complicated by requiring either

     - that the sender's AS be included in the UPDATE message and the
     signature (so that the verification process could find the
     appropriate key for the signature)

     - or that each sender know the private key of the first AS in the
     AS_PATH (so that the signature and verification processes would be
     using the same key).

Sharing keys between AS's makes those AS's indistinguishable to the
cryptography; the second alternative design should only be chosen with

Murphy                      Expires: May 2001                  [Page 12]

INTERNET DRAFT            BGP Security Analysis            November 2001

that caution clearly understood.

3.6.  Filtering

The Internet registries can provide data that will help to assure that
AS_PATHS and NLRI origination data are authorized.  If the data
registered in the Internet registries is available, then an NLRI
origination can be verified against the registry.  Also, peering
information in the registry can be used to verify that the AS_PATH as a
whole was valid.

The assurance provided by this protection would rely on the registry
data being:

     complete:  AS's that do not register their peering relationships or
     assigned networks would hamper the ability to protect the BGP data.

     accurate:  AS's must register peering relationships that exactly
     match their policies.  If the peering relationships are described
     too broadly, bogus routes will pass the filter.  If the peering
     relationships are described too narrowly, legitimate routes will
     fail.

     timely: Additions and changes to the registry data must be
     communicated to the AS's in a timely manner.

     secure: The registries must be known to ensure the authenticity,
     integrity and authorization of provided information while in
     storage and in transmission to an AS.

The assurance provided by this protection relies on the openness of the
data recorded in the registries.  To be truly useful, each autonomous
system's policy would have to be recorded in the registry, in order that
the AS_PATH as a whole can be verified to be valid.  Information about
policy, however, can be sensitive to an autonomous system and not openly
available to every other autonomous system.  Any restrictions on the
availability of information stored in the registry will restrict its
applicability as a protection mechanism.

Filtering based on the registries can also not ensure the authenticity
of the received routes.  The registries currently contain permitted
routes, not necessarily the current forwarding routes.  If, for example,
an AS will accept the same network from multiple peer, with one route to
serve as a backup, filtering based on the registry would not be able to
distinguish which is the route currently in use.

Murphy                      Expires: May 2001                  [Page 13]

INTERNET DRAFT            BGP Security Analysis            November 2001

4.  Security Costs

Choosing the protection to apply in any situation depends on the
perception of the risk of attack, of the damage that can result, of the
benefits derived from providing the protection, and of the cost of
providing the protection.  This section discusses the cost of each of
the protection options mentioned above.

4.1.  Protecting the Peer-Peer Link

The cost of this protection is the processing required for the
cryptography and the need to establish and manage the cryptographic
keys.  The cryptography need not be computationally expensive; HMAC or
similar algorithms can be used.  Shared secret keys are adequate for
this protection, as the protection applies only to the communication
between peers, so the key management cost is low.  A separate key must
be used for each BGP peering.  Using one key for multiple peerings even
at a peering point reduces the level of protection that is provided.

This level of protection is low cost and protects against the vast
number of outsiders who pose a threat.

4.2.  Origination Protection

The cost of signing the originating AS of each route is the cost of the
processing required for the cryptography -- generating and verifying
digital signatures -- as well as the need to establish and manage the
cryptographic keys.  For digital signatures, establishing and managing
the cryptographic keys means providing a public key infrastructure to
generate an asymmetric key pair for each autonomous system and to
distribute and maintain certifications of the public keys associated
with each autonomous system.

While the key distribution and signature generation and verification
provides for authentication and integrity of the messages, there is also
a need to ensure the authorization of the origination.  This requires
another infrastructure that would provide certifications of the
authority of an AS to originate a route to a network.

The infrastructures required for authentication of AS messages and for
authorization of origination information might be colocated.  The
establishment and secure operation of the security infrastructure as
well as the cost of secure communication with the infrastructure are
additional costs of this technique.

Murphy                      Expires: May 2001                  [Page 14]

INTERNET DRAFT            BGP Security Analysis            November 2001

4.3.  Origination and Adjacency Protection

This scheme requires the same public key infrastructure and origination
infrastructure as is needed for Origination Protection  It also requires
that each adjacency for a BGP speaker be signed (the "predecessor"
information) and transmitted along with an AS_PATH.  Essentially, each
BGP speaker must announce its peers, something that does not currently
occur in the BGP protocol.

Each BGP speaker must compute one signature for each NLRI in each UPDATE
message transmitted and must verify one signature for each NLRI in each
UPDATE message received.  Each UPDATE message must be separately signed
because the mechanism described in [3] includes a sequence number, the
Withdrawn Routes and the Unfeasible Route Length fields, so the
information to be signed changes with each message.  (These fields are
protected from outsiders by the peer-peer communication protection and
so do not need to be digitally signed.  If only the NLRI,
ATOMIC_AGGREGATE and predecessor information were signed each time, then
the signature might not have to be computed with each new UPDATE
message, i.e., AS_PATH changes would not induce new signature
computations.)

The signed predecessor information in each route must be stored by the
recipient indefinitely.  Each route received must be verified by
comparison to the store of predecessor information previously received
in UPDATE messages from all AS sources.

4.4.  Origination and AS_PATH Protection

The operational cost of this scheme is described in detail in [10].

This scheme requires the same public key infrastructure and origination
infrastructure as is needed for Origination Protection.

For each UPDATE message received, K signatures (where K is the level of
protection desired from consecutive faulty routers) must be verified.

For each UPDATE message transmitted, one signature must be computed for
each NLRI per recipient.  As discussed before, prevention of cut and
paste attacks requires that the signature include the recipient, so
computing one signature per AS_PATH and NLRI announced is insufficient.

The signatures contained in an UPDATE must be retained for all received
routes in case the route is ever chosen and announced to the peers.
This increases the size of the routing tables.

Murphy                      Expires: May 2001                  [Page 15]

INTERNET DRAFT            BGP Security Analysis            November 2001

For efficiency in situations where route flapping is occuring, withdrawn
AS_PATHs and their signatures could be retained.  This would mean that
new announcements of flapped routes still retained would not require new
signature verifications.

4.5.  Rely on Registries

The cost of relying on registries would vary considerably depending on
the protection provided to the information in storage and in transit.
Any latency, above that caused by the use of cryptography, would depend
on the mechanism used to transmit the registry information (e.g.,
anything from frequent complete download to real-time query and
response).

5.  Security Considerations

This entire memo is about security considerations.

6.  References

[1]  Y. Rekhter and T. Li,  "A Border Gateway Protocol 4 (BGP-4)",
     RFC1771, March 1995.

[2]  Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)", work
     in progress, November 2001.  available as
     <<draft-ietf-idr-bgp4-15.txt>> at Internet-Draft shadow sites.

[2]  B. Smith and J.J. Garcia-Luna-Aceves, "Securing the Border Gateway
     Routing Protocol", Proc. Global Internet'96, London, UK, 20-21
     November 1996.

[3]  Bruce Schneier.  Applied Cryptography Protocols, Algorithms, and
     Source Code in C, John Wiley & Sons, Inc 1994.

[4]  John Moy, "OSPF Version 2", RFC 1583, March 1994.

[5]  C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy and C. Orange,
     "Routing Policy System Security", RFC 2725,  December, 1999.

[7]  S. Kent and  R.Atkinson, "Security Architecture for the Internet
     Protocol", RFC2401, November 1998.

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

Murphy                      Expires: May 2001                  [Page 16]

INTERNET DRAFT            BGP Security Analysis            November 2001

[10] S.Kent, C.Lynn, and K. Seo, "Secure Border Gateway Protocol
     (Secure-BGP)", IEEE Journal on Selected Areas in Communications,
     Vol. 18, No. 4, April 2000, pp. 582-592.

[10] S. Kent, C. Lynn, J. Mikkelson, and K. Seo, "Secure Border Gateway
     Protocol (S-BGP) -- Real World Performance and Deployment Issues",
     Proceedings of the IEEE Network and Distributed System Security
     Symposium (NDSS 2000), February 2000.

7.  Author's Address

Sandra Murphy
Network Associates, Inc.
NAI Labs
3060 Washington Road
Glenwood, MD  21738
EMail: [email-masked]

Murphy                      Expires: May 2001                  [Page 17]

INTERNET DRAFT            BGP Security Analysis            November 2001

A.  Appendix A - Vulnerabilities and Risks

Each message introduces certain different vulnerabilities and risks:

A.1.  OPEN

Because receipt of a new OPEN message in the Established state will
cause the close of the BGP peering session and thereby induce the
release of all resources and deletion of all associated routes, the
ability to spoof this message can lead to a severe disruption of
routing.

A.2.  KEEPALIVE

Receipt of a KEEPALIVE message when the peering connection is in the
OpenSent state can lead to a failure to establish a connection.  The
ability to spoof this message is a vulnerability.  To exploit this
vulnerability deliberately, the KEEPALIVE must be carefully timed in the
sequence of messages exchanged between the peers; otherwise, it causes
no damage.

A.3.  NOTIFICATION

Receipt of a NOTIFICATION message will cause the close of the BGP
peering session and thereby induce the release of all resources and
deletion of all associated routes.  Therefore, the ability to spoof this
message can lead to a severe disruption of routing.

A.4.  UPDATE

The Update message carries the routing information.  The ability to
spoof any part of this message can lead to a disruption of routing.

A.4.1.  Unfeasible Routes Length, Total Path Attribute Length

There is a vulnerability arising from the ability to modify these
fields.  If a length is modified, the message is not likely to parse
properly, resulting in an error, the transmission of a NOTIFICATION
message and the close of the connection.  As a true BGP speaker is
always able to close a connection at any time, this vulnerability
represents an additional risk only when the source is a non-BGP speaker,
i.e., it presents no additional risk from BGP sources.

Murphy                      Expires: May 2001                  [Page 18]

INTERNET DRAFT            BGP Security Analysis            November 2001

A.4.2.  Withdrawn Routes

An outsider could cause the elimination of existing legitimate routes by
forging or modifying this field.  An outsider could also cause the
elimination of reestablished routes by replaying this withdrawal
information from earlier packets.

A BGP speaker could "falsely" withdraw feasible routes using this field.
However, as the BGP speaker is authoritative for the routes it will
announce, it is allowed to withdraw any previously announced routes that
it wants.  As the receiving BGP speaker will only withdraw routes
associated with the sending BGP speaker, there is no opportunity for a
BGP speaker to withdraw another BGP speaker's routes.  Therefore, there
is no additional risk from BGP peers via this field.

A.4.3.  Path Attributes

The path attributes present many different vulnerabilities and risks.

Attribute Flags, Attribute Type Codes, Attribute Length

A BGP peer or an outsider could modify the attribute length or attribute
type (flags and type codes) so they did not reflect the attribute values
that followed.  If the flags were modified, the flags and type code
could become incompatible (i.e., a mandatory attribute marked as
partial), or a optional attribute could be interpreted as a mandatory
attribute or vice versa.  If the type code were modified,  the attribute
value could be interpreted as if it were the data type and value of a
different attribute.

The most likely result from modifying the attribute length, flags, or
type code would be a parse error of the UPDATE message.  A parse error
would cause the transmission of a NOTIFICATION message and the close of
the connection.  As a true BGP speaker is always able to close a
connection at any time, this vulnerability represents an additional risk
only when the source is an outsider, i.e., it presents no additional
risk from a BGP peer.

ORIGIN

This field indicates whether the information was learned from IGP or EGP
information.  If the route is used in inter-AS multicast routing, a
value of INCOMPLETE may be used.  This field is not used in making
routing decisions, so there are no vulnerabilities arising from this
field, either from BGP peers or outsiders.

Murphy                      Expires: May 2001                  [Page 19]

INTERNET DRAFT            BGP Security Analysis            November 2001

AS_PATH

A BGP peer or outsider could announce an AS_PATH that was not accurate
for the associated NLRI.  Forwarding for the NLRI associated with the
AS_PATH could potentially be induced to follow a sub-optimal path, a
path that did not follow some intended policy, or even a path that would
not forward the traffic.  If the path would not forward the traffic, the
NLRI would become unreachable for that portion of the Internet that
accepted the false path.  If much traffic is mis-directed, some routers
and transit networks along the announced route could become flooded with
the mis-directed traffic.

It is not clear how far an inaccurate AS_PATH could deviate from the
true AS_PATH.  It may be that the first AS in the AS_PATH, at least,
must be a legal hop.  The RFC states that a BGP speaker prepends its own
AS to an AS_PATH before announcing it to a neighbor.  If the BGP speaker
must prepend its own AS, then a BGP speaker that produced a bogus
AS_PATH could end up receiving the traffic for the associated NLRI.
This could be desirable if the error was deliberate and the intent was
to receive traffic that would not otherwise be received.  Receiving the
mis-routed traffic could be undesirable for the faulty BGP speaker if it
were not prepared to handle the extra (mis-routed) traffic.  So,
requiring a BGP peer to prepend its own AS to the AS_PATH, might
encourage or discourage it from inventing an arbitrary AS_PATH,
depending on its resources and intent.

If BGP peers need not prepend its own AS (or implementations do not
ensure that this is done), then a malicious BGP peer could announce a
path that begins with the AS of any BGP speaker with little impact on
itself.

Whether such an arbitrary AS_PATH is a vulnerability would depend on
whether BGP implementations check the AS_PATH (to see if the first AS is
the neighbor) and would catch the error.  If there are legitimate
situations in which a BGP speaker could pass an AS_PATH to a neighbor
without putting its own AS at the head of the AS_PATH, then there is no
way for implementations to detect totally bogus AS_PATHs.

Originating Routes

A special case of announcing a false AS_PATH occurs when the AS_PATH
advertises a direct connection to a specific network address.  An BGP
peer or outsider could disrupt routing to the network(s) listed in the
NLRI field by falsely advertising a direct connection to the network.
The NLRI would become unreachable to the portion of the network that

Murphy                      Expires: May 2001                  [Page 20]

INTERNET DRAFT            BGP Security Analysis            November 2001

accepted this false route, unless the ultimate AS on the AS_PATH
undertook to tunnel the packets it was forwarded for this NLRI on toward
their true destination AS by a valid path.  But even when the packets
are tunneled to the correct destination AS, the route followed may not
be optimal or may not follow the intended policy.  Additionally, routing
for other networks in the Internet could be affected if the false
advertisement fragmented an aggregated address block, forcing the
routers to handle (issue UPDATES, store, manage) the multiple fragments
rather than the single aggregate.  False originations for multiple
addresses can result in routers and transit networks along the announced
route to become flooded with mis-directed traffic.

NEXT_HOP

The NEXT_HOP attribute defines the IP address of the border router that
should be used as the next hop when forwarding the NLRI listed in the
UPDATE message.  If the recipient is an external peer, then the
recipient and the NEXT_HOP address must share a subnet.  It is clear
that an outsider modifying this field could disrupt the forwarding of
traffic between the two AS's.

In the case that the recipient of the message is an external peer of an
AS and the route was learned from another peer AS (this is one of two
forms of "third party" NEXT_HOP), then the BGP speaker advertising the
route has the opportunity to direct the recipient to forward traffic to
a BGP speaker at the NEXT_HOP addresss.  This affords the opportunity to
direct traffic at a router that may not be able to continue forwarding
the traffic.  It is unclear whether this would also require the
advertising BGP speaker to construct an AS_PATH mentioning the NEXT_HOP
external peer's AS.

MULTI_EXIT_DISC

The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted
between inter-AS BGP peers.  While the MULTI_EXIT_DISC received from an
inter-AS peer may be propagated within an AS, it may not be propagated
to other AS's.  Consequently, this field is only used in making routing
decisions internal to one AS.  Modifying this field, whether by an
outsider or an BGP peer, could influence routing within an AS to be sub-
optimal, but the effect should be limited in scope.

LOCAL_PREF

The LOCAL_PREF attribute must be included in all messages with internal
peers and excluded from messages with external peers.  Consequently,

Murphy                      Expires: May 2001                  [Page 21]

INTERNET DRAFT            BGP Security Analysis            November 2001

modification of the LOCAL_PREF could effect the routing process within
the AS only.  Note that there is no requirement in the BGP RFC that the
LOCAL_PREF be consistent among the internal BGP speakers of an AS.  As
BGP peers are free to choose the LOCAL_PREF as they wish, modification
of this field is a vulnerability with respect to outsiders only.

ATOMIC_AGGREGATE

The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way
has received a more specific and a less specific route to the NLRI and
installed the aggregated route.  This route cannot be de-aggregated
because it is not certain that the route to more specific prefixes will
follow the listed AS_PATH.  Consequently, BGP speakers receiving a route
with ATOMIC_AGGREGATE are restricted from making the NLRI any more
specific.  Removing the ATOMIC_AGGREGATE attribute would remove the
restriction, possibly causing traffic intended for the more specific
NLRI to be routed incorrectly.   Adding the ATOMIC_AGGREGATE attribute
when no aggregation was done would have little effect, beyond
restricting the un-aggregated NLRI from being made more specific.  This
vulnerability exists whether the source is a BGP peer or an outsider.

AGGREGATOR

This field may be included by a BGP speaker who has computed the routes
represented in the UPDATE message from aggregation of other routes.  The
field contains the AS number and IP address of the last aggregator of
the route.  It is not used in making any routing decisions, so it does
not represent a vulnerability.

A.4.4.  NLRI

By modifying or forging this field, either an outsider or BGP peer
source could cause disruption of routing to the announced network,
overwhelm a router along the announced route, cause data loss when the
announced route will not forward traffic to the announced network, route
traffic by a sub-optimal route, etc.

Murphy                      Expires: May 2001                  [Page 22]

Date: Mon, 19 Nov 2001 23:53:40 -0500
From: Jay Borkenhagen <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-idr-route-oscillation-00.txt
Reply-To: Jay Borkenhagen <[email-masked]>
Sender: [email-masked]

>> At first sight, it looks like a paradox, but it is really not,
>> since the right way of expressing the comparison algo would be:
>> 
>> c < (a < b)  which is != (c < a) < b
>> 
>> i.e., a and b are compared using one attribute, while any of
>> them is compared with c using another.
>> 
>> 2. Thinking about this further, one could say that the preference
>> level of a specific route depends on the presence of another
>> route (i.e., b > c if a is present, but b < c if a is not
>> there).

Yep.  This also implies that withdrawal of a non-best route can cause
a new best route to be chosen, and that can happen even without any
information hiding by confederations or route reflection.  (This seems
non-intuitive, but I don't think it's problematic.)

						Jay B.

-- 
  Jay Borkenhagen     [email-masked]

Date: Fri, 16 Nov 2001 20:11:10 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: section 9 comments, redux
Sender: [email-masked]

Please find some updated comments regarding section 9.  This has
gone through a few rounds off-list with some of the people that
had commented on it previously.  In particular: Dan Pei, Russ White,
Ed Crabbe.

I believe this incorporates all of their comments.

----

: 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.
: 
:    The selection process is formalized by defining a function that takes
:    the attribute of a given route as an argument and returns a non-
:    negative integer denoting the degree of preference for the route.

Change to:
"The selection process is formalized by defining a function that takes 
 the attribute of a given route as an argument and returns either:

 o A non-negative integer denoting the degree of preference for the route

   - or -

 o 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 internal peers
: 
:       - selection of routes to be advertised to external peers

Change the previous two bullet items to:

"- 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, and MAY also advertise to all
:       the internal peers the routes from external peers that have the
:       highest degree of preference for each distinct destination.

Change to: 
"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
:       external peer, according to the policies contained in the PIB.

Change to:
"peer, according to..."

:       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.
: 
:    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. 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
:    and uses it as the LOCAL_PREF value in any IBGP readvertisement.  The
:    exact nature of this policy information and the computation involved
:    is a local matter. For a route learned from an external peer, the
:    local speaker shall then run the internal update process of 9.2.1 to
:    select and advertise the most preferable route.

Change to:
"For each newly received or replacement feasible route, the local BGP
 speaker shall determine a degree of preference:

 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 present in the Adj-RIBs-In, including those received
:    from both internal and external peers.

Change to:
"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
:    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.
: 
: 
: 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.
: 
: 
: 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 = all routes still under consideration
:                 for n = all routes still under consideration
:                     if (neighborAS(m) == 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 = all routes still under consideration
:                 for n = 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.
: 
: 
: 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
: 
:       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 a corresponding
:    entry in the associated Adj-RIBs-Out. Route aggregation and
:    information reduction techniques (see 9.2.4.1) may optionally be
:    applied.

Change to:
"All routes in the Loc-RIB shall be procesed 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.

 Route aggregation and information reduction techniques (see 9.2.4.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 external update process
:    of 9.2.2.

Change to:
"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.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.
:    Rules for information exchange between BGP speakers located in
:    different autonomous systems are given in 9.2.2; rules for
:    information exchange between BGP speakers located in the same
:    autonomous system are given in 9.2.1.
: 
:    Distribution of routing information between a set of BGP speakers,
:    all of which are located in the same autonomous system, is referred
:    to as internal distribution.
: 
: 
: 9.2.1 Internal Updates
: 
: 
:    The Internal update process is concerned with the distribution of
:    routing information to internal peers.
: 
:    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].
: 
:    When a BGP speaker receives a new route from an external peer, it
:    MUST advertise that route to all other internal peers by means of an
:    UPDATE message if this route will be installed in its Loc-RIB
:    according to the route selection rules in 9.1.2.
: 
:    When a BGP speaker receives an UPDATE message with a non-empty
:    WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all
:    routes whose destinations were carried in this field (as IP
:    prefixes).  The speaker shall take the following additional steps:
: 
:       1) if the corresponding feasible route had not been previously
:       advertised, then no further action is necessary
: 
:       2) if the corresponding feasible route had been previously
:       advertised, then:
: 
:          i) If a new route for the same NLRI is selected for
:          advertisement, then the BGP speaker shall advertise the
:          replacement route
: 
:          ii) if a replacement route is not available for advertisement,
:          then the BGP speaker shall include the destinations of the
:          unfeasible route (in form of IP prefixes) in the WITHDRAWN
:          ROUTES field of an UPDATE message, and shall send this message
:          to each peer to whom it had previously advertised the
:          corresponding feasible route.
: 
: 
:    All feasible routes which are advertised shall be placed in the
:    appropriate Adj-RIBs-Out, and all unfeasible routes which are
:    advertised shall be removed from the Adj-RIBs-Out after the
:    corresponding update messages have been sent.
: 
: 9.2.2 External Updates
: 
: 
:    The external update process is concerned with the distribution of
:    routing information to external peers.  As part of Phase 3 route
:    selection process, the BGP speaker has updated its Adj-RIBs-Out and
:    its Routing Table. All newly installed routes and all newly
:    unfeasible routes for which there is no replacement route shall be
:    advertised to external peers by means of UPDATE message.
: 
:    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 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.

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

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 16 Nov 2001 15:16:09 -0500
From: Jeffrey Haas <[email-masked]>
To: Sue Hares <[email-masked]>, [email-masked]
Subject: FSM thoughts
Sender: [email-masked]

The following are observations on the current BGP MIB as it
applies to the FSM.  Please consider how the MIB or the FSM text
would need to be adjusted, if at all:

The bgpPeerAdminStatus object is documented as follows:

        bgpPeerAdminStatus OBJECT-TYPE
            SYNTAX     INTEGER {
                stop(1),
                start(2)
            }       
            MAX-ACCESS read-write
            STATUS     current
            DESCRIPTION
                "The desired state of the BGP connection.

                 A transition from 'stop' to 'start' will cause the BGP
                 Start Event to be generated.
                    
                 A transition from 'start' to 'stop' will cause the BGP
                 Stop Event to be generated.
                
                 This parameter can be used to restart BGP peer
                 connections.  Care should be used in providing write
                 access to this object without adequate authentication."

This implies that aside from being an event, stop and start are
also states.  If you are "start"ed, periodic start events, according
to the above text, would be accomplished by toggling the internal
state of the FSM to stop and then start again.

The FSM text implies that you just send a start event.

One potential answer to this is to make an object that notes the
status of the FSM as a whole - i.e. it is "enabled" or "disabled"
and reserve "start" and "stop" as actual events.  Thus, MIB-wise,
we have a FSM Status object which is read-only and a FSM event
of "start" and "stop" which are write-only.

Comments?

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 16 Nov 2001 11:32:14 -0500
From: Jeffrey Haas <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-idr-route-oscillation-00.txt
Sender: [email-masked]

On Thu, Nov 15, 2001 at 03:21:47PM -0800, Alex Zinin wrote:
> >      2. Something like we discussed already---propagate all available
> >         paths in the MED group to all decision makers so that
> >         the route presence condition is satisfied.

It is sufficient to simply distribute all BEST meds for an AS to
your reflection agents.

There are a couple ways this could be done.  Each with their own problem.

-- 
Jeff Haas 
NextHop Technologies

From: Randy Bush <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: Inclusion of FSM in draft 
Date: Thu, 15 Nov 2001 16:59:38 -0800
Sender: [email-masked]

> In the discussion on the FSM it is important to keep in mind the
> main goal of the current efforts on the BGP4 draft. The main goal
> is to reconcile the draft with the the code that has been implemented
> and deployed in the Internet. 

in such a way that a new implementor could successfully implement a
compatible product from the rfc

randy

Date: Thu, 15 Nov 2001 15:21:47 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: [email-masked]
Subject: Re: draft-ietf-idr-route-oscillation-00.txt
Sender: [email-masked]

Since we've touched this topic again,
below is some notes I scratched last week
for those who're interested. These are just
quick thoughts, I haven't reread them myself
yet, so no flames. Comments are welcome though.

>   1. As indicated in the document, the cause of the problem
>      is in the fact that not all routers have the same information
>      to base the best-path decision on. On the other hand, in
>      pure DV protocols it is ok, because of the absolute nature
>      of route comparison, i.e.
> 
>         a < b < c  => a < c
>   
>      In the BGP case, the above is not true. E.g., from the example
>      in the doc:
> 
>       a:    6 100    0         13
>       b:    6 100    1          4
>       c:   10 100   10          5
> 
> 
>       Here, c < a < b, logically, one would derive c < b
> 
>       however, this is not true:
> 
>       b:    6 100    1          4
>       c:   10 100   10          5
> 
>       here, b < c
>       
> 
>       At first sight, it looks like a paradox, but it is really not,
>       since the right way of expressing the comparison algo would be:
> 
>        c < (a < b)  which is != (c < a) < b
> 
>       i.e., a and b are compared using one attribute, while any of
>       them is compared with c using another.
> 
>   2. Thinking about this further, one could say that the preference
>      level of a specific route depends on the presence of another
>      route (i.e., b > c if a is present, but b < c if a is not
>      there).
> 
>      This works ok if either of the two conditions is true:
> 
>        1) all routers in the BGP mesh have all potential paths,
>           i.e., iBGP mesh is full
> 
>        2) paths from a single MED-group (i.e., paths from the same
>           nbr'ing AS and present MED attr) are never "split" btw
>           multiple BGP speaker from the best-path decision
>           perspective. For example, suppose we have the following
>           set of paths:
> 
>                 AS_PATH  MED
>              a: 10 100   0 \
>              b: 10 100   5 /
>              c: 20 100   3 \
>              d: 20 100   6 /
>              e: 30 100   -
>              f: 40 100   -
> 
>           The MED groups are {a,b} and {c,d}. Also suppose we
>           have the topology as in Figure 1 of the doc.
>           As soon each MED group is "terminated" by one RR,
>           we're fine, because best path decisions within the
>           MED group are made having complete information and
>           even though not all paths in the MED group are propagated
>           to other RR's, all BGP speakers converge on correct
>           paths (note that if we propagated all paths within
>           the MED group, other routers would make the same
>           decision within the MED group as the terminating one).
> 
>           Note that the above condition is not met in the example
>           given in the doc, hence the problem.
> 
>   3. Given 1 and 2 above, we could add the following potential
>      methods to solve the problem to those mentioned in the doc.
> 
>      1. Fix the best path selection algo.
>         This would essentially mean use MED only as the tie breaker
>         when there's more than one best path from the same nbr AS
>         and with the same IGP cost. This would turn c < (a < b)
>         to true (c < a < b) => (c < b) and the proto would converge
>         _always_. On the other hand, this would essentially make
>         MED useless, as it would work as a tie-breaker only,
>         not insisting on choosing a path within a MED group before
>         applying other tie-breakers as it is done today.
> 
>      2. Something like we discussed already---propagate all available
>         paths in the MED group to all decision makers so that
>         the route presence condition is satisfied.
> 
>      3. Administratively make sure that BGP sessions with a single
>         AS are not split between clusters, i.e., make sure that
>         paths from one MED group are "terminated" at a single RR.
>      
>    Thinking about this, the problem is caused by the fact that the
>    main assumption about MED application---that all paths in a MED
>    group are finally available for the decision maker---is not held
>    true in the cases where sessions with the same AS are terminated
>    in different clusters. We could try to solve this in the protocol
>    itself using 1 or 2 (or some other means), or we could document
>    this properly in the related BGP documents, which is what I'm
>    leaning towards so far...

-- 
Alex Zinin

Thursday, November 15, 2001, 2:06:09 PM, Jeffrey Haas wrote:

> On Thu, Nov 15, 2001 at 04:50:17PM -0500, Ju, Yu wrote:
>> After reading the draft, I realized that oscillation was caused by
>> inconsistent view of BGP speakers. 

> RFC1863 gave a mechanism that allowed all of the routes to be
> distributed.  It also seems to have served as the basis for
> route reflection.

> But as Tony notes later, it doesn't scale well.

Date: Thu, 15 Nov 2001 17:06:09 -0500
From: Jeffrey Haas <[email-masked]>
To: "Ju, Yu" <[email-masked]>
Cc: "'Yakov Rekhter'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-ietf-idr-route-oscillation-00.txt
Sender: [email-masked]

On Thu, Nov 15, 2001 at 04:50:17PM -0500, Ju, Yu wrote:
> After reading the draft, I realized that oscillation was caused by
> inconsistent view of BGP speakers. 

RFC1863 gave a mechanism that allowed all of the routes to be
distributed.  It also seems to have served as the basis for
route reflection.

But as Tony notes later, it doesn't scale well.

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 15 Nov 2001 14:04:18 -0800
From: Ben Black <[email-masked]>
To: Tony Li <[email-masked]>
Cc: "Ju, Yu" <[email-masked]>, "'Yakov Rekhter'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-ietf-idr-route-oscillation-00.txt
Sender: [email-masked]

Wouldn't sending ALL the routes mean sending multiple routes for
the same prefix?  I was not aware BGP had a facility for
distinguishing between different routs for the same prefix from
a single peer.

Ben

On Thu, Nov 15, 2001 at 01:53:21PM -0800, Tony Li wrote:
> 
> 
> Reflecting all routes defeats the scalability win of limiting the scope of
> information.
> 
> Tony
> 
> 
> Ju, Yu writes:
>  | Yakov,
>  | 
>  | After reading the draft, I realized that oscillation was caused by
>  | inconsistent view of BGP speakers. 
>  | With IBGP fully meshed, a BGP speaker sends a BGP route learnt from EBGP
>  | session to all IBGP speakers. However, this property is not perserved by
>  | route reflection and confedration. In route reflection, a RR only reflects
>  | the best BGP route if that route is learnt from an IBGP session. If this
>  | rule is changed so that RR reflects all the BGP routes learnt from an IBGP
>  | session, then all the BGP speakers will have the same view and make the same
>  | choice just like a fully meshed IBGP network. Then oscillation wouldn't
>  | occur at the first place.
>  | 
>  | What am I missing?
>  | 
>  | Yu
>  | > -----Original Message-----
>  | > From: Yakov Rekhter [mailto:[email-masked]]
>  | > Sent: Monday, November 12, 2001 1:52 PM
>  | > To: [email-masked]
>  | > Cc: [email-masked]
>  | > Subject: draft-ietf-idr-route-oscillation-00.txt
>  | > 
>  | > 
>  | > Rob,
>  | > 
>  | > The IDR WG would like to ask the IESG to advance
>  | > draft-ietf-idr-route-oscillation-00.txt to an Informational RFC.
>  | > 
>  | > Yakov.
>  | > 

From: Tony Li <[email-masked]>
Date: Thu, 15 Nov 2001 13:53:21 -0800
To: "Ju, Yu" <[email-masked]>
Cc: "'Yakov Rekhter'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: draft-ietf-idr-route-oscillation-00.txt
Sender: [email-masked]

Reflecting all routes defeats the scalability win of limiting the scope of
information.

Tony

Ju, Yu writes:
 | Yakov,
 | 
 | After reading the draft, I realized that oscillation was caused by
 | inconsistent view of BGP speakers. 
 | With IBGP fully meshed, a BGP speaker sends a BGP route learnt from EBGP
 | session to all IBGP speakers. However, this property is not perserved by
 | route reflection and confedration. In route reflection, a RR only reflects
 | the best BGP route if that route is learnt from an IBGP session. If this
 | rule is changed so that RR reflects all the BGP routes learnt from an IBGP
 | session, then all the BGP speakers will have the same view and make the same
 | choice just like a fully meshed IBGP network. Then oscillation wouldn't
 | occur at the first place.
 | 
 | What am I missing?
 | 
 | Yu
 | > -----Original Message-----
 | > From: Yakov Rekhter [mailto:[email-masked]]
 | > Sent: Monday, November 12, 2001 1:52 PM
 | > To: [email-masked]
 | > Cc: [email-masked]
 | > Subject: draft-ietf-idr-route-oscillation-00.txt
 | > 
 | > 
 | > Rob,
 | > 
 | > The IDR WG would like to ask the IESG to advance
 | > draft-ietf-idr-route-oscillation-00.txt to an Informational RFC.
 | > 
 | > Yakov.
 | > 

From: "Ju, Yu" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: draft-ietf-idr-route-oscillation-00.txt
Date: Thu, 15 Nov 2001 16:50:17 -0500
Sender: [email-masked]

Yakov,

After reading the draft, I realized that oscillation was caused by
inconsistent view of BGP speakers. 
With IBGP fully meshed, a BGP speaker sends a BGP route learnt from EBGP
session to all IBGP speakers. However, this property is not perserved by
route reflection and confedration. In route reflection, a RR only reflects
the best BGP route if that route is learnt from an IBGP session. If this
rule is changed so that RR reflects all the BGP routes learnt from an IBGP
session, then all the BGP speakers will have the same view and make the same
choice just like a fully meshed IBGP network. Then oscillation wouldn't
occur at the first place.

What am I missing?

Yu
> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Monday, November 12, 2001 1:52 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: draft-ietf-idr-route-oscillation-00.txt
> 
> 
> Rob,
> 
> The IDR WG would like to ask the IESG to advance
> draft-ietf-idr-route-oscillation-00.txt to an Informational RFC.
> 
> Yakov.
> 

Date: Wed, 14 Nov 2001 17:53:19 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Jeffrey Haas <[email-masked]>
Cc: Susan Hares <[email-masked]>, [email-masked], Yakov Rekhter <[email-masked]>
Subject: Re: FSM changes for the Draft-15
Sender: [email-masked]

Jeff,

> Traditionally (and my biggest argument to do it this way), we
> should document the states (noting the start state),
> the transition function and make sure that its deterministic.
> By that I mean that "do nothing/ignore" is simply a transition to
> the same state.

Agree with the last statement about "ignore" (I hope my suggestion
did not sound contrary). Regarding the rest of the para above, it wasn't
clear to me whether you were against documenting the events.

> Additionally, I don't think anything as documented have any "in actions".
> Do you disagree?

Depends on how you look at it. The idea behind in-actionc is to
identify those performed regardless of the prev state, event
and other conditions. For example, (reading Sue's new version
of the text), we always do the following when going to Connect:

 - start ConnectRetry timer
 - initiate transport connection to the peer
 - listen for an incoming one
 
I think I could identify similar sets for Idle and IdleHold.

> Documenting "state actions" would be a nice thing, but potentially
> dangerous.  For example, it would be nice to document what happens
> in the magic box marked "Established" but that goes beyond what
> most people want to see - i.e. events on the wire.

It is dangerous if we try to document everything (e.g., update
processing), which is not necessary. Only things related to
the FSM operation should be mentioned, for example, generation
of the timer expiration events. Another approach would be
to describe the timer itself and say it generates event Foo.
FSM action description would give a clue on how Foo is processed
in different states.

> A good argument to avoid documenting the black boxes is the
> extension mess we'd get into by trying to extend the contents of
> those boxes for all BGP extensions such as route refresh, graceful
> restart, etc.  By focusing on some basic internal events that are
> required to get a pair of bgp speakers peering and then focusing
> on events to keep that peering up we avoid limiting implementations
> by over-specifying the internals.

Don't get me wrong. I'm not suggesting to transform the whole
BGP spec to an FSM description (which would be unrealistic, btw).
My point is---since we're touching the FSM part, let's
try to improve the description to be more FSM-like.

Alex.

Date: Wed, 14 Nov 2001 15:43:09 -0500
To: Yakov Rekhter <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: Inclusion of FSM in draft 
Cc: [email-masked]
Sender: [email-masked]

Yakov:

Just to clarify -- since the FSM has been implemented in the Internet,
does this mean you think we need to include the depth that Dennis indicates
or the current depth of explanation I've proposed?

As I noted to Alex, I'll be glad to expand the basic format to include 
these things.
Our goal had been to match the current implementations.   I would like to
hear if people feel the existing call collision text is unclear or problematic?

Sue

At 08:34 AM 11/14/2001 -0800, Yakov Rekhter wrote:
>Eric,
>
> > Dennis,
> >
> >     It would be unusual (and very hard) indeed to describe any non-trivial
> > protocol in terms of a single state machine.  In BGP, it seems to me, one
> > reasonable breakdown of the protocol might be one single state machine
> > for the peer relationship and many small state machines for currently
> > advertised routes.  In this case, the complexity of the protocol will not
> > be reflected by the complexity of the state machine descriptions, but by
> > the sheer numbers of simultaneously running state machines.
> >
> >     But, in the case of current advertised routes, it may not be as 
> useful to
> > describe the interactions in terms of state machines.
> >
> >     Do you think that it would be useful to add a state machine definition
> > for dealing with route advertisements?
>
>In the discussion on the FSM it is important to keep in mind the
>main goal of the current efforts on the BGP4 draft. The main goal
>is to reconcile the draft with the the code that has been implemented
>and deployed in the Internet.
>
>Yakov.

Date: Wed, 14 Nov 2001 12:05:35 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: Inclusion of FSM in draft
Sender: [email-masked]

On Wed, Nov 14, 2001 at 10:38:40AM -0500, Eric Gray wrote:
>     Do you think that it would be useful to add a state machine definition
> for dealing with route advertisements?

As Yakov notes, this is out of scope of the current effort.
But it is probably worth discussing afterwards.  We _will_ want
a BGP-5 one of these days - it would be helpful to know what
people dislike about bgp-4. :-)

-- 
Jeff Haas 
NextHop Technologies

To: [email-masked]
Subject: Re: Inclusion of FSM in draft 
Date: Wed, 14 Nov 2001 08:34:54 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Eric,

> Dennis,
> 
>     It would be unusual (and very hard) indeed to describe any non-trivial
> protocol in terms of a single state machine.  In BGP, it seems to me, one
> reasonable breakdown of the protocol might be one single state machine
> for the peer relationship and many small state machines for currently
> advertised routes.  In this case, the complexity of the protocol will not
> be reflected by the complexity of the state machine descriptions, but by
> the sheer numbers of simultaneously running state machines.
> 
>     But, in the case of current advertised routes, it may not be as useful to
> describe the interactions in terms of state machines.
> 
>     Do you think that it would be useful to add a state machine definition
> for dealing with route advertisements?

In the discussion on the FSM it is important to keep in mind the
main goal of the current efforts on the BGP4 draft. The main goal
is to reconcile the draft with the the code that has been implemented
and deployed in the Internet. 

Yakov.

Date: Wed, 14 Nov 2001 11:15:34 -0500
From: Jeffrey Haas <[email-masked]>
To: Yu Zhang <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP Identifier
Sender: [email-masked]

On Thu, Nov 08, 2001 at 04:33:38PM -0800, Yu Zhang wrote:
> I wonder whether a BGP router can establish sessions
> with two BGP routers with same BGP identifier?

Sure.  How else will you peer with the same router on different
interfaces?

> If not, what shall the BGP router do in case it
> receives OPEN messages with the same BGP identifier
> from different BGP peers?

If you have some means outside of the protocol to know if a
Identifier is acceptible or not, you could send the appropriate
NOTIFICATION (subcode 3).

> Yu

-- 
Jeff Haas 
NextHop Technologies

Date: Wed, 14 Nov 2001 10:38:40 -0500
From: Eric Gray <[email-masked]>
To: Dennis Ferguson <[email-masked]>
Cc: Susan Hares <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Inclusion of FSM in draft
Sender: [email-masked]

Dennis,

    It would be unusual (and very hard) indeed to describe any non-trivial
protocol in terms of a single state machine.  In BGP, it seems to me, one
reasonable breakdown of the protocol might be one single state machine
for the peer relationship and many small state machines for currently
advertised routes.  In this case, the complexity of the protocol will not
be reflected by the complexity of the state machine descriptions, but by
the sheer numbers of simultaneously running state machines.

    But, in the case of current advertised routes, it may not be as useful to
describe the interactions in terms of state machines.

    Do you think that it would be useful to add a state machine definition
for dealing with route advertisements?

You wrote:

> Sue,
>
> > The Question is:   Should the BGP document contain a FSM?
> >
> > The current tally of the people wishing the FSM includes:
> >       - operators,
> >       - 3 or 4 different implementations of BGP, and
> >       - general company from IDR.
> >
> > We've not heard from John Scudder who suggested to remove the FSM.
> > I've received questions on the FSM from Enke.
> >
> > I'd love to hear from others on whether the FSM should be included in
> > the BGP spec.
>
> The reasons I've never valued the FSM in this specification are
>
> - It really only describes how neighbours get connected and disconnected, a
>   topic which is a miniscule part of the protocol as a whole.  The
>   vast bulk of the BGP protocol, and BGP complexity, is in the processing
>   of UPDATE messages.  The latter topic is covered by pages and pages of
>   procedural description in the text, but is reduced to a one-liner (restart
>   the hold timer) in the FSM description of the protocol.  The FSM hence
>   tells you relatively little of importance about the BGP protocol, even
>   though the formality of its presentation might mislead one into thinking
>   otherwise, and it has always seemed to me that if you could manage to
>   deduce how to process an UPDATE message from the descriptive text then
>   the same text is almost certainly more than adequate to figure out how
>   to get the peers connected.
>
> - The FSM not only deals with a small subset of the protocol, but it
>   also entirely leaves out the real-life tricky bits of that subset.
>   For example, connection collision resolution requires you to have
>   two connections to the same peer open until you can figure out which
>   one to close, yet there are no states in the FSM which admit this as
>   a possibility.  In Connect state there is a difference in what you
>   need to do if the transport connection which "succeeds" is the outgoing
>   connection or an independent incoming connection, yet the FSM makes
>   no distinction.  The FSM might work the way it is if both ends of every
>   connection used port 179, but this requirement is unstated, doesn't
>   match deployed code and is in fact impractical with just about every
>   TCP implementation I know of.  It is hence possible for a new incoming
>   transport connection to "succeed" in just about any state, but the FSM
>   makes no acknowledgement of this possibility, let alone indicating what
>   one should do in these cases.
>
> I don't think your fixes to the FSM do much to fix its omissions.  Really
> fixing it requires a fair bit of work, especially since FSMs are, in
> general, not space efficient protocol descriptions.  If it were truly
> fixed it would be fine with me, but the way it is now you still have to
> rely on the descriptive text to figure out how to write connection code
> which covers the corner cases and I'm not sure that anyone who could
> figure out what to do with UPDATE messages using that same text would
> find this relatively minor bit of deduction especially challenging.  A
> really good FSM would make this easier to get right without thinking but
> this is such a minor part of the protocol, the bulk of which is impossible
> to get right without thinking, that I'm not sure the lack of that FSM
> would have much effect on the likelyhood of writing a successful
> implementation.
>
> So I guess my opinions are:
>
> - An FSM which distinguished between incoming and outgoing transport
>   connections and dealt with collisions as suggested in the text would
>   be okay with me, though I'm not sure the implementability of the spec
>   is impaired without it.
>
> - The FSM the way it is now, even after your changes, still leaves out
>   the tricky stuff.  The spec would be better off without it since this
>   at least wouldn't mislead readers into believing that there is no tricky
>   stuff.
>
> Dennis

--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

To: Susan Hares <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Inclusion of FSM in draft 
Date: Tue, 13 Nov 2001 14:57:47 -0800
From: Dennis Ferguson <[email-masked]>
Sender: [email-masked]

Sue,

> The Question is:   Should the BGP document contain a FSM?
> 
> The current tally of the people wishing the FSM includes:
> 	- operators,
> 	- 3 or 4 different implementations of BGP, and
> 	- general company from IDR.
> 
> We've not heard from John Scudder who suggested to remove the FSM.
> I've received questions on the FSM from Enke.
> 
> I'd love to hear from others on whether the FSM should be included in
> the BGP spec.

The reasons I've never valued the FSM in this specification are

- It really only describes how neighbours get connected and disconnected, a
  topic which is a miniscule part of the protocol as a whole.  The
  vast bulk of the BGP protocol, and BGP complexity, is in the processing
  of UPDATE messages.  The latter topic is covered by pages and pages of
  procedural description in the text, but is reduced to a one-liner (restart
  the hold timer) in the FSM description of the protocol.  The FSM hence
  tells you relatively little of importance about the BGP protocol, even
  though the formality of its presentation might mislead one into thinking
  otherwise, and it has always seemed to me that if you could manage to
  deduce how to process an UPDATE message from the descriptive text then
  the same text is almost certainly more than adequate to figure out how
  to get the peers connected.

- The FSM not only deals with a small subset of the protocol, but it
  also entirely leaves out the real-life tricky bits of that subset.
  For example, connection collision resolution requires you to have
  two connections to the same peer open until you can figure out which
  one to close, yet there are no states in the FSM which admit this as
  a possibility.  In Connect state there is a difference in what you
  need to do if the transport connection which "succeeds" is the outgoing
  connection or an independent incoming connection, yet the FSM makes
  no distinction.  The FSM might work the way it is if both ends of every
  connection used port 179, but this requirement is unstated, doesn't
  match deployed code and is in fact impractical with just about every
  TCP implementation I know of.  It is hence possible for a new incoming
  transport connection to "succeed" in just about any state, but the FSM
  makes no acknowledgement of this possibility, let alone indicating what
  one should do in these cases.

I don't think your fixes to the FSM do much to fix its omissions.  Really
fixing it requires a fair bit of work, especially since FSMs are, in
general, not space efficient protocol descriptions.  If it were truly
fixed it would be fine with me, but the way it is now you still have to
rely on the descriptive text to figure out how to write connection code
which covers the corner cases and I'm not sure that anyone who could
figure out what to do with UPDATE messages using that same text would
find this relatively minor bit of deduction especially challenging.  A
really good FSM would make this easier to get right without thinking but
this is such a minor part of the protocol, the bulk of which is impossible
to get right without thinking, that I'm not sure the lack of that FSM
would have much effect on the likelyhood of writing a successful
implementation.

So I guess my opinions are:

- An FSM which distinguished between incoming and outgoing transport
  connections and dealt with collisions as suggested in the text would
  be okay with me, though I'm not sure the implementability of the spec
  is impaired without it.

- The FSM the way it is now, even after your changes, still leaves out
  the tricky stuff.  The spec would be better off without it since this
  at least wouldn't mislead readers into believing that there is no tricky
  stuff.

Dennis

Date: Tue, 13 Nov 2001 15:34:52 -0500
From: Jeffrey Haas <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Susan Hares <[email-masked]>, [email-masked], Yakov Rekhter <[email-masked]>
Subject: Re: FSM changes for the Draft-15
Sender: [email-masked]

Traditionally (and my biggest argument to do it this way), we
should document the states (noting the start state),
the transition function and make sure that its deterministic.
By that I mean that "do nothing/ignore" is simply a transition to
the same state.

Additionally, I don't think anything as documented have any "in actions".
Do you disagree?

Documenting "state actions" would be a nice thing, but potentially
dangerous.  For example, it would be nice to document what happens
in the magic box marked "Established" but that goes beyond what
most people want to see - i.e. events on the wire.

A good argument to avoid documenting the black boxes is the
extension mess we'd get into by trying to extend the contents of
those boxes for all BGP extensions such as route refresh, graceful
restart, etc.  By focusing on some basic internal events that are
required to get a pair of bgp speakers peering and then focusing
on events to keep that peering up we avoid limiting implementations
by over-specifying the internals.

On Fri, Nov 09, 2001 at 01:56:29PM -0800, Alex Zinin wrote:
> 8.2 BGP Session States
> 
> For each state, give a generic description, something like
> the following:
> 
>  State       : <state-name>
>  Description : <short description>
>  Valid events: <list of events expected and processed in this state,
>                 others should be ignored>
>  In actions  : <list of actions _always_ performed when
>                 transitioning to the state>
>  Out actions : <list of actions _always_ performed when
>                 transitioning from the state>
>  State actions: <list of actions performed (e.g. periodically) while
>                 in this state>
>                 
> 8.3 BGP FSM Definition
> 
>  FSM State : <one or many states>
>  FSM Event : <one or many events>
>  Next state: <new state if always the same>
>  Actions   : <list of state/event-specific actions and state
>               transitions if condition-dependent>
> 
> I'll take a look at the files you sent as well.
> 
> Alex.
> 
> 
> 

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 13 Nov 2001 15:28:07 -0500
From: Jeffrey Haas <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: Alex Zinin <[email-masked]>, [email-masked], Yakov Rekhter <[email-masked]>
Subject: Re: FSM changes for the Draft-15
Sender: [email-masked]

On Mon, Nov 12, 2001 at 11:02:21AM -0500, Susan Hares wrote:
> I'd be glad to go and translate the state table document to your format, but
> I'd like some additional feedback whether this will be acceptable at this
> stage of the IDR document.

Normative text is what we're shooting for in the spec.  The tables
and diagram makes it easier to follow things - and documents completeness
of the state machine.

Having the table as part of the appendix may make sense.

> Sue

-- 
Jeff Haas 
NextHop Technologies

To: [email-masked]
Cc: [email-masked]
Subject: things to discuss at the meeting
Date: Tue, 13 Nov 2001 12:20:51 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

Please send suggestions for the agenda items.

Yakov.

Date: Tue, 13 Nov 2001 14:02:08 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: idr-post
Sender: [email-masked]

This came up in a few e-mails sent to me:

In order to send e-mail to [email-masked], you must also be 
subscribed to [email-masked].  Otherwise, posts will be
silently dropped.

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 13 Nov 2001 11:36:47 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: Inclusion of FSM in draft
Sender: [email-masked]

On Tue, Nov 13, 2001 at 10:07:10AM -0500, Susan Hares wrote:
> The Question is:   Should the BGP document contain a FSM?

I would suggest to IDR that this issue, regardless of how you feel
about it, is too important to leave to "silence of the masses".

Please, please comment on this, even if only to Yakov and Sue.

> Sue Hares

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 13 Nov 2001 10:07:10 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Inclusion of FSM in draft
Cc: [email-masked]
Sender: [email-masked]

The Question is:   Should the BGP document contain a FSM?

The current tally of the people wishing the FSM includes:
	- operators,
	- 3 or 4 different implementations of BGP, and
	- general company from IDR.

We've not heard from John Scudder who suggested to remove the FSM.
I've received questions on the FSM from Enke.

I'd love to hear from others on whether the FSM should be included in
the BGP spec.

Sue Hares

Date: Tue, 13 Nov 2001 10:04:08 -0500
From: Jeffrey Haas <[email-masked]>
To: David Margulis <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP Capability codes in the  'Vendor Specific' range (rfc 2842)
Sender: [email-masked]

On Tue, Nov 13, 2001 at 02:26:28PM +0200, David Margulis wrote:
> My question is: how to ensure uniqueness of the private code in this
> range ?

Not in the spec, unfortunately. :-(

> Two possible approaches come to my mind:
> 	1. there is some mechanism for that, out of IANA ( vendors
> mentatin a public list of already used codes in this range)
> 	2. Value ( of the TLV of that type ) is used for uniqueness  (
> seems to me weird approach )

The simplest approach would have been to request an Enterprise number from
IANA (used for SNMP) and use this to disambiguate things.

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 13 Nov 2001 09:38:00 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: David Margulis <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP Capability codes in the  'Vendor Specific' range (rfc 2842)
Sender: [email-masked]

The third option would be to use this range for experimental
things, or things that won't ever be adopted, just trying to keep
a list of what things have and haven't been used before. Once
some capability that is being deployed in a 'vendor specific' or
'experimental' way becomes widely deployed or a standard, it
can/should be moved to the iana controlled range, so it's
assigned a number.

:-)

Russ

On Tue, 13 Nov 2001, David Margulis wrote:

> I have a question regarding the Vendor Specific (range 128-255)
> Capability codes.
> My understanding is that codes, in this range are not assigned by IANA.
> 
> My question is: how to ensure uniqueness of the private code in this
> range ?
> Two possible approaches come to my mind:
> 	1. there is some mechanism for that, out of IANA ( vendors
> mentatin a public list of already used codes in this range)
> 	2. Value ( of the TLV of that type ) is used for uniqueness  (
> seems to me weird approach )
> 
> 
> 
> 
>  
> 
> 

_____________________________
[email-masked] <>< Grace Alone

content-class: urn:content-classes:message
Subject: BGP Capability codes in the  'Vendor Specific' range (rfc 2842)
Date: Tue, 13 Nov 2001 14:26:28 +0200
From: "David Margulis" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I have a question regarding the Vendor Specific (range 128-255)
Capability codes.
My understanding is that codes, in this range are not assigned by IANA.

My question is: how to ensure uniqueness of the private code in this
range ?
Two possible approaches come to my mind:
	1. there is some mechanism for that, out of IANA ( vendors
mentatin a public list of already used codes in this range)
	2. Value ( of the TLV of that type ) is used for uniqueness  (
seems to me weird approach )

 

Date: Mon, 12 Nov 2001 14:15:09 -0800
From: [email-masked]
To: Susan Hares <[email-masked]>
Cc: [email-masked], jeffrey Haas <[email-masked]>, Yakov Rekhter <[email-masked]>
Subject: Re: FSM changes for the Draft-15
Sender: [email-masked]

Sue,

> You are suggesting modifying this text:
> 
>          Upon entering the Idle Hold state, if the IdleHoldTimer exceeds 
> the local limit the "Keep Idle" flag is set.
> 
> 
>          Upon entering the Idle Hold state, if  IdleHoldtimer > 
> IdleHoldTimerMax, the local system
>          should:
>                  - generate a syslog event and
>                  - set the "Keep Idle" flag.

Sorry for the confusion.  Yes, that text would be fine.

Andrew

To: [email-masked]
Cc: [email-masked]
Subject: draft-ietf-idr-route-oscillation-00.txt
Date: Mon, 12 Nov 2001 10:52:20 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Rob,

The IDR WG would like to ask the IESG to advance
draft-ietf-idr-route-oscillation-00.txt to an Informational RFC.

Yakov.

Date: Mon, 12 Nov 2001 13:16:18 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: FSM word changes with bars
Sender: [email-masked]

--=====================_3897314==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Idle state:

Initially BGP is in the 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.

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

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 = 2**(ConnectRetryCnt)*60
| -     Increment ConnectRetryCnt by 1,
| -     Set connect retry timer to zero,
| -     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.
[Note: Jeff Haas thinks that operators would want manual start to do 
something different.]

In response to any other event (initiated by the system or operator), the 
local system:
| -     IdleHoldtimer = 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 = 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.

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 = 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 = 0,
| -     Connect retry timer = 0, and
| -     transition to Idle state.

| If any other NOTIFICATION is received, the local system:
| -     IdleHoldtimer = 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 = 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 = 2**(ConnectRetryCnt)*60
| -     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 = 2**(ConnectRetryCnt)*60
| -     Increments ConnectRetryCnt by 1,
| -     Sets the co nnect 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 = 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,
| -     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 = 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 = 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 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 = 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 = 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:
| -     sends a NOTIFICATION with Cease,
| -     sets IdleHoldtimer = 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 = 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
| -     deletes all routes.

--=====================_3897314==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<b>Idle state: <br>
<br>
</b><font face="Times New Roman, Times">Initially BGP is in the Idle
state.&nbsp;&nbsp; <br>
<br>
</font><font face="Times New Roman, Times" color="#FF0000">| A manual
start event is a start event initiated by an operator.&nbsp; An automatic
start event is a start |<br>
| event generated by the system.<br>
<br>
</font><font face="Times New Roman, Times">In this state BGP refuses all
incoming BGP connections.&nbsp; No resources are allocated to the
peer.&nbsp;&nbsp;&nbsp; In | response to a Start event
(</font><font face="Times New Roman, Times" color="#FF0000">manual or
automatic</font><font face="Times New Roman, Times">), the local
system:</font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">initializes
all BGP resources, </font>
</dl>
</dl><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">starts
the ConnectRetry timer, <br>
</font><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">initiates
a transport connection to the other BGP peer, <br>
</font><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">listens
for a connection that may be initiated by the remote BGP peer, and<br>
</font><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">changes
its state to connect.<br>
<br>
The exact value of the ConnectRetry timer is a local matter, but it
should be sufficiently large to allow TCP
initialization.</font><font face="Times New Roman, Times" color="#FF0000">&nbsp;&nbsp;
<br>
<br>
</font><font face="Times New Roman, Times">Any other event received in
the IDLE state, is ignored.<br>
<br>
<b>IdleHold state:<br>
<br>
</b></font><font face="Times New Roman, Times" color="#FF0000">| The
IdleHold state keeps the system in “Idle” mode until a certain time
period has passed or an <br>
| operator intervenes to manually restart the connection.&nbsp;&nbsp;
This “IdleHold timeout” prevents <br>
| persistent flapping of a BGP peering session. <br>
<br>
| Upon entering the Idle Hold state, if the IdleHoldTimer exceeds the
local limit the “Keep Idle” flag<br>
|&nbsp; is set.&nbsp;&nbsp;&nbsp; <br>
<br>
| Upon receiving a Manual start, the local system:<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">clears
the IdleHoldtimer, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">clears
“keep Idle” flag<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">initializes
all BGP resources, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">starts
the ConnectRetry timer,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">initiates
a transport connection to the other BGP peer,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">listens
for a connection that may be initiated by the remote BGPPeer, and<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">changes
its state to connect.<br>
<br>
|&nbsp; Upon receiving a IdleHoldtimer expired event, the local system
checks to see that the Keep Idle <br>
| |&nbsp; is set.&nbsp; If the Keep Idle flag is set, the system stays in
the “Idle Hold” state. <br>
|&nbsp; If the Keep Idle flag is not set, the local system: <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">clears
the IdleHoldtimer, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">and
transitions the state to Idle. <br>
<br>
| Getting out of the IdleHoldstate requires either operator intervention
via a manual start or the <br>
|&nbsp; IdleHoldtimer to expire with the “Keep Idle” flag to be clear.
<br>
<br>
| Any other event received in the IdleHold state is ignored.<br>
<br>
</font><font face="Times New Roman, Times"><b>Connect State:<br>
<br>
</b>In this state, BGP is waiting for the transport protocol connection
to be completed.<br>
<br>
If the transport connection succeeds, the local system:</font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">clears
the ConnectRetry timer, </font>
</dl>
</dl><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">completes
initialization,<br>
</font><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">send
an Open message to its peer,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">set
Hold timer to a large value,&nbsp; and <br>
</font><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">changes
its state to Open Sent.&nbsp; <br>
<br>
A hold timer value of 4 minutes is suggested.<br>
<br>
If the transport protocol connection fails (e.g., retransmission
timeout), the local system:</font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">restarts
the ConnectRetry timer, </font>
</dl>
</dl><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">continues
to listen for a connection that may be initiated by the remote BGP peer,
and <br>
</font><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">changes
its state to Active. <br>
<br>
In response to the ConnectRetry timer expired event, the local system:
<br>
-&nbsp;&nbsp;&nbsp;&nbsp; restarts the ConnectRetry timer, </font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">initiates
a transport connection to the other BGP peer, </font>
</dl>
</dl><font size=4><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">continues
to listen for a connection that may be initiated by the remote BGP peer,
and<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">stays
in Connect state.<br>
<br>
The start event (manual or automatic) is ignored in the Connect
state.<br>
<br>
</font><font face="Times New Roman, Times" color="#FF0000">| In response
to any other event (initiated by the system or operator), the local
system:<br>
|
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">IdleHoldtimer
= 2**(ConnectRetryCnt)*60<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Increment
ConnectRetryCnt by 1,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Set
connect retry timer to zero,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Drops
TCP connection, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Releases
all BGP resources, and <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Goes
to IdleHoldstate<br>
<br>
<br>
</font><font face="Times New Roman, Times"><b>Active State:<br>
<br>
</b>In this state BGP is trying to acquire a peer by listening for and
accepting a transport protocol connection.&nbsp; <br>
<br>
If the transport connection succeeds, the local system:</font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">clears
the ConnectRetry timer, </font>
</dl>
</dl><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">completes
the initialization, <br>
</font><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">sends
the Open message to it’s peer, <br>
</font><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">sets
its Hold timer to a large value, <br>
</font><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">and
changes its state to OpenSent.&nbsp; <br>
<br>
A Hold timer value of 4 minutes is suggested.&nbsp; <br>
<br>
In response the ConnectRetry timer expired event, the local
system:</font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">restarts
the ConnectRetry timer,</font>
</dl>
</dl><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">initiates
a transport connection to the other BGP peer,<br>
</font><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">continues
to listen for connection that may be initiated by remote BGP peer, <br>
</font><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">and
changes its state to Connect. <br>
<br>
If the local system does not allow BGP connections with unconfigured
peers, then the local system:</font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">rejects
connections from IP addresses that are not configured peers, </font>
</dl>
</dl><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">and
remains in the Active state.<br>
<br>
| The start events
</font><font face="Times New Roman, Times" color="#FF0000">(initiated by
the system or operator)</font><font face="Times New Roman, Times"> are
ignored in the Active state.<br>
[Note: Jeff Haas thinks that operators would want manual start to do
something different.]<br>
<br>
In response to any other event (initiated by the system or operator), the
local system:</font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">IdleHoldtimer
= 2**(ConnectRetryCnt)*60</font>
</dl>
</dl><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Increment
ConnectRetryCnt by 1,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Set
connect retry timer to zero, and <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Drops
TCP connection, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Releases
all BGP resources,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Goes
to IdleHold state.<br>
<br>
<br>
</font><font face="Times New Roman, Times"><b>Open Sent:<br>
<br>
</b>In this state BGP waits for an Open Message from its peer.&nbsp; When
an OPEN message is received, all fields are check for correctness.&nbsp;
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:</font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">sends
a NOTIFICATION message</font>
</dl>
</dl><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">IdleHoldtimer
= 2**(ConnectRetryCnt)*60<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Increment
ConnectRetryCnt by 1,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Set
connect retry timer to zero, and <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Drops
TCP connection, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Releases
all BGP resources,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Goes
to IdleHold state.<br>
<br>
<br>
</font>| If there are no errors in the OPEN message, the local
system:<br>
<font size=4 color="#FF0000">|&nbsp;
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sends
a KEEPALIVE message and<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
a KeepAlive timer (via the text below)<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">set
the Hold timer according to the negotiated value (see section 4.2), 
<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">set
the state to Open Confirm.<br>
<br>
</font>If the negotiated Hold time value is zero, then the Hold Time
timer and KeepAlive timers are not started.&nbsp;&nbsp; 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.&nbsp;&nbsp; <br>
|&nbsp; (This will <font color="#FF0000">impact </font>UPDATE processing
as described below.)&nbsp; <br>
<br>
If a disconnect NOTIFICATION is received from the underlying transport
protocol, the local system:
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>closes
the BGP connection, 
</dl>
</dl><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>restarts
the Connect Retry timer, <br>
<font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>and
continues to listen for a connection that may be initiated by the remote
BGP peer, and goes into Active state.<br>
<br>
If the Hold Timer expires, the local system:
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>send
a NOTIFICATION message with error code Hold Timer Expired,
</dl>
</dl><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">IdleHoldtimer
= 2**(ConnectRetryCnt)*60<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increment
ConnectRetryCnt by 1,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Set
connect retry timer to zero, and <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
TCP connection, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources, and <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHold state</font>. <br>
<br>
The Start event (manual and automatic) is ignored in the OpenSent
state.<br>
<br>
<font color="#FF0000">| If a NOTIFICATION message is received with a
version error, the local system:<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Closes
the transport connection<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
BGP resources, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">ConnectRetryCnt
= 0, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Connect
retry timer = 0, and<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">transition
to Idle state.<br>
<br>
| If any other NOTIFICATION is received, the local system: <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">IdleHoldtimer
= 2**(ConnectRetryCnt)*60<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increment
ConnectRetryCnt by 1,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Set
connect retry timer to zero, and <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
TCP connection, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHold state.<br>
<br>
| In response to any other event, the local system:<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sends
the NOTFICATION message with Error Code Finite State Machine&nbsp;
Error,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">IdleHoldtimer
= 2**(ConnectRetryCnt)*60<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increment
ConnectRetryCnt by 1,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Set
connect retry timer to zero,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
TCP connection, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources, and <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHold state.<br>
<br>
</font><b>Open Confirm State<br>
<br>
</b>In this state BGP waits for a KEEPALIVE or NOTIFICATION 
message.<br>
<br>
If the local system receives a KEEPALIVE message, it changes its state to
Established.&nbsp; <br>
<br>
<font color="#FF0000">| If the Hold Timer expires before a KEEPALIVE
message is received, the local system:<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">send
the NOTIFICATION message with the error code Hold Timer Expired,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
IdleHoldTimer = 2**(ConnectRetryCnt)*60<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increments
ConnectRetryCnt by 1,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Sets
the connect retry timer to zero,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drop
the TCP connection, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHoldState.<br>
<br>
| If the local system receives a NOTIFICATION message or receives a
disconnect NOTIFICATION <br>
| from the underlying transport protocol, the local system:&nbsp; <br>
</font><font size=4 color="#FF0000">|-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Sets
IdleHold Timer = 2**(ConnectRetryCnt)*60<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increments
ConnectRetryCnt by 1,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Sets
the co nnect retry timer to zero,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
the TCP connection,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHoldstate.<br>
<br>
| In response to the Stop event initiated by the system, the local
system:<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sends
the NOTIFICATION message with Cease,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
IdleHoldtimer = 2**(ConnectRetryCnt)*60<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increments
ConnectRetryCnt by 1,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Sets
the Connect retry timer to zero,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
the TCP connection, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHoldstate.<br>
<br>
<br>
</font><font color="#FF6600">| In response to a Stop event initiated by
the operator, the local system: <br>
|
</font><font size=4 color="#FF6600">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF6600">sends
the NOTIFICATION message with Cease, <br>
</font><font size=4 color="#FF6600">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF6600">releases
all BGP resources<br>
</font><font size=4 color="#FF6600">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF6600">sets
the ConnectRetryCnt to zero<br>
</font><font size=4 color="#FF6600">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF6600">sets
the connect retry timer to 0<br>
</font><font size=4 color="#FF6600">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF6600">transitions
to Idle state.<br>
<br>
</font>The Start event is ignored in the OpenConfirm state.<br>
<br>
<font color="#FF6600">| In response to any other event, the local
system:<br>
|
</font><font size=4 color="#FF6600">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF6600">sends
a NOTIFICATION with a code of Finite State Machine Error,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
IdleHoldtimer = 2**(ConnectRetryCnt)*60<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increments
ConnectRetryCnt by 1,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Sets
the Connect retry timer to zero,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
the TCP connection, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHoldstate.<br>
<br>
</font><b>Established State:<br>
<br>
</b>In the Established state BGP can exchange UPDATE, NOTFICATION, and
KEEPALIVE messages with its peer.<br>
<br>
If the local system receives an UPDATE or KEEPALIVE message, it restarts
its Hold Timer, if the negotiated Hold Time value is non-zero.&nbsp;
<br>
<br>
<font color="#FF6600">| If the local system receives a NOTIFICATION
message or a disconnect from the underlying | transport protocol,
it:<br>
</font>|&nbsp; -&nbsp;&nbsp;&nbsp; <font color="#FF0000">sets
IdleHoldtimer = 2**(ConnectRetryCnt)*60, <br>
|
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increments
ConnectRetryCnt by 1,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Sets
the Connect retry timer to zero,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
the TCP connection, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources, and&nbsp;&nbsp; <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHoldstate.<br>
<br>
</font>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:
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>sends
a NOTIFICATION message with Update error,
</dl>
</dl><font size=4 color="#FF0000">|
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
IdleHoldtimer = 2**(ConnectRetryCnt)*60<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increments
ConnectRetryCnt by 1,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Sets
the Connect retry timer to zero,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
the TCP connection, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources, and <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHoldstate.<br>
</font><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
</font>If the Hold timer expires, the local system:
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>sends
a NOTIFICATION message with Error Code Hold Timer Expired,
</dl>
</dl><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
IdleHoldtimer = 2**(ConnectRetryCnt)*60<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increments
ConnectRetryCnt by 1,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Sets
the connect retry timer to zero,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
the TCP connection,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources,&nbsp; <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHold state.<br>
<br>
</font>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.<br>
<br>
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.<br>
<br>
<font color="#FF0000">| In response to the Stop event initiated by the
system (automatic), the local system:<br>
|
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sends
a NOTIFICATION with Cease, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
IdleHoldtimer = 2**(ConnectRetryCnt)*60<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">increments
ConnectRetryCnt by 1,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
the connect retry timer to zero,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">drops
the TCP connection, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">releases
all BGP resources, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">goes
to IdleHold state, and <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">deletes
all routes.<br>
<br>
| An example automatic stop event is exceeding the number of prefixes for
a given peer and the local <br>
|&nbsp; system automatically disconnecting the peer.<br>
<br>
| In response to a stop event initiated by an operator:<br>
|
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">release
all resources (including deleting all routes),<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">set
ConnectRetryCnt to zero (0),<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">set
connect retry timer to zero (0), and<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">transition
to the Idle.<br>
<br>
| The Start event is ignored in the Established state.<br>
<br>
| In response to any other event, the local system:<br>
|
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sends
a NOTIFICATION message with Error Code Finite State Machine Error,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
IdleHoldtimer = 2**(ConnectRetryCnt)*60<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">increments
ConnectRetryCnt by 1,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
the connect retry timer to zero,<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">drops
the TCP connection, <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">releases
all BGP resources<br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">goes
to IdleHoldstate, and <br>
</font><font size=4 color="#FF0000">|
-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">deletes
all routes.<br>
<br>
</font><br>
</html>

--=====================_3897314==_.ALT--

Date: Mon, 12 Nov 2001 10:58:30 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Re: FSM changes for the Draft-15
Cc: Susan Hares <[email-masked]>, [email-masked], jeffrey Haas <[email-masked]>, Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Andrew:

Thanks for your comments.

>I agree that having a decription of the state machine in the protocol spec
>is desireable.  Thank you for comming up with a more detailed version than is
>currently in Section 8.  The description in Section 8 is sufficent for
>those who have extensive BGP experience, but your verion will make it
>much easier for people with less BGP experience to implement BGP.

Thank you.   I suspect given the implementations I've seen some
implementors do needs this help.

>Comments on the FSM:
>
>IdleHold:
>
>This state seems implicit in section 8 the way it is currently written
>(defining the exponential backoff timer in the case of an automatic start
>event), so making it explicit is a good idea.

glad you like it.

>Active:
>
> > The start events (initiated by the system or operator) are ignored in 
> the Active state.
> > [Note: Jeff Haas thinks that operators would want manual start to do 
> something different.]
>
>Currently, if an operator wants to restart the ConnectRetry timer in an
>attempt to bring up a BGP session now, they shutdown/clear the session
>which transitions things back to idle, clears all the counters, and restarts
>the process.  There is some overhead associated with this, but I think it
>is an acceptable solution, so leaving Active defined as it is, with starts
>ignored is fine.

thanks for the input.

>--------
>
>I would suggest an additon:
>
>- In line with the current spec which states: "An implementation MAY
>impose a configurable upper bound on that time [the IdleHoldtimer].  Once
>the upper bound is reached, the speaker shall no longer automatically
>generate the Start event for the peer."
>
>Add something mentioning this configurable maximum, for example:
>
>  IdleHoldtimer = 2**(ConnectRetryCnt)*60
>  If IdleHoldtimer > IdleHoldTimerMax; generate a syslog event (vendor 
> specifc)
>  Set KeepIdle flag
>  Transition to IdleHold state

You are suggesting modifying this text:

         Upon entering the Idle Hold state, if the IdleHoldTimer exceeds 
the local limit the "Keep Idle" flag is set.

         Upon entering the Idle Hold state, if  IdleHoldtimer > 
IdleHoldTimerMax, the local system
         should:
                 - generate a syslog event and
                 - set the "Keep Idle" flag.

Please confirm.

Sue

Date: Mon, 12 Nov 2001 11:02:21 -0500
To: Alex Zinin <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: FSM changes for the Draft-15
Cc: Susan Hares <[email-masked]>, [email-masked], jeffrey Haas <[email-masked]>, Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Alex:

The files I sent use a table format for this approach.   I was planning to
provide an accompanying document with this information in it.
We are just trying to correct the specification, I went with the 2nd 
document idea
as a "compromise"

I'd be glad to go and translate the state table document to your format, but
I'd like some additional feedback whether this will be acceptable at this
stage of the IDR document.

Sue

At 01:56 PM 11/9/2001 -0800, Alex Zinin wrote:

>Sue,
>
> > I'd like 2nd to ask that the working group accepts this FSM rewrite.
>
> > I've re-written the state machine to be a bit cleaner in text.
> > The Idle state had two sub-states so I cleaned this up by making each
> > of these states a different text (Idle and Idle Hold)
>
> > Here are changes to the draft-15 FSM to make the FSM a bit clear.
>
>If we are to make the FSM textual description in the spec more or less
>meaningful, I suggest we take some time and fix the section using
>the following approach:
>
>8. BGP Finite State machine.
>
>8.1 BGP FSM Events
>
>For each event:
>
>  Event       : <event-name>
>  Description : <short-description>
>  Generation  : <conditions when the event is generated>
>
>8.2 BGP Session States
>
>For each state, give a generic description, something like
>the following:
>
>  State       : <state-name>
>  Description : <short description>
>  Valid events: <list of events expected and processed in this state,
>                 others should be ignored>
>  In actions  : <list of actions _always_ performed when
>                 transitioning to the state>
>  Out actions : <list of actions _always_ performed when
>                 transitioning from the state>
>  State actions: <list of actions performed (e.g. periodically) while
>                 in this state>
>
>8.3 BGP FSM Definition
>
>  FSM State : <one or many states>
>  FSM Event : <one or many events>
>  Next state: <new state if always the same>
>  Actions   : <list of state/event-specific actions and state
>               transitions if condition-dependent>
>
>I'll take a look at the files you sent as well.
>
>Alex.

Date: Mon, 12 Nov 2001 10:52:47 -0500
To: Eric Gray <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: FSM changes for the Draft-15
Cc: Susan Hares <[email-masked]>, Eric W Gray <[email-masked]>, [email-masked]
Sender: [email-masked]

Eric:

>Why do you distinguish manual and automatic start?  I do not believe
>that the BGP implementation will be able to distinguish the two types,
>so why assert an artificial distinction?  Or, are you referring to expiry
>of the IdleHoldTimer as an automatic start?

The original text below distinguishes between these two types.
The automatic restart is set in many implementations to keep trying to
connect to the remote user.   A CLI command or an SNMP mib variable
could also do this action.

Idle Hold timer is the time indicated in the *** section.  An automatic
start is also described below.

Text start:
============
          If a BGP speaker detects an error, it shuts down the connection
          and changes its state to Idle. Getting out of the Idle state
          requires generation of the Start event.  If such an event is
          generated automatically, then persistent BGP errors may result
          in persistent flapping of the speaker.
*****
         To avoid such a
          condition it is recommended that Start events should not be
          generated immediately for a peer that was previously
          transitioned to Idle due to an error. For a peer that was
          previously transitioned to Idle due to an error, the time
          between consecutive generation of Start events, if such events
          are generated automatically, shall exponentially increase. The
          value of the initial timer shall be 60 seconds.
***
         The time shall
          be doubled for each consecutive retry. An implementation MAY
          impose a configurable upper bound on that time. Once the upper
          bound is reached, the speaker shall no longer automatically
          generate the Start event for the peer.

------------------

>The Active and Connect states seem to be begging for a connection
>collision.  There is no arbitration process described below in handling
>an Open message when in Open sent - it just drops the connection.  I
>think it might be reasonable for the implementation to determine at
>that point which peer should be establishing the connection and drop
>it only if the local peer is not the one that should be making it.
>
>Additional comments in-line with abridged text below...

Can you give an example for each state: Active and Connect on how connection
collission could occur?

> >
> >
> > ----------------------
> > Idle state:
> >
> > Initially BGP is in the 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.
>
>A possibly irrelevant observation.  :-)
>
> >
> >
> > [...]
> >
> > Upon entering the Idle Hold state, if the IdleHoldTimer exceeds the local
> > limit the "Keep Idle" flag is set.
>
>When you say 'IdleHoldTimer exceeds the local limit' do you mean
>the elapsed time, or the timeout value of the IdleHoldTimer?

See the earlier text.   The Local limit is a configuration variable set by the
local system (aka the user).

> >
> >
> > Upon receiving a Manual start, the local system:
> > -       clears the IdleHoldtimer,
>
>Do you mean 'resets the IdleHoldTimer', or 'stops the IdleHoldTimer'?

clears - sets to zero and stops.

> >
> > -       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.
>
>Is this what you mean by an automatic start?  If so, what constitutes
>generating a 'Start event'?

Code in BGP automatically tries to reconnect every "n" seconds.   This is an
automatic start event.   A manual start event is when the operator goes to
the terminal and says "connect now"!!!

> >
> >
> > [...]
> >
> > 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,
>
>'Stops the ConnectRetry timer'?

Stops and sets to zero.   (We can go to stops and sets to zero.)

> >
> > [...]
> >
> > 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 = 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.
>
>I think it might be reasonable for the implementation to determine at
>this point which peer should be establishing the connection and drop
>it only if the local peer is not the one that should be making it.

This may be reasonable, but I tried to stay with the original text.
How about if we do this in two stages: fix the current state machine.
Do the things which are reasonable = 2nd version.

> >
> >
> > [...]
> >
> > If a NOTIFICATION message is received with a version error, the local
> > system:
> > -       Closes the transport connection
> > -       Releases BGP resources,
> > -       ConnectRetryCnt = 0,
> > -       Connect retry timer = 0, and
> > -       transition to Idle state.
>
>This makes the most sense if the local implementation is not able to
>regress to an earlier version.  I don't know about BGP implementations
>in general, but in using versioning with other protocols, the most likely
>cause of a version error is when a forward version tries to communicate
>with a backward version.  However, it is often the case that a forward
>version has some ability to regress.

My understanding is this text will aid in the version negotiation.   I welcome
other comments.   I must admit it is both a clarification and an addition.
I included it because most FSM are currently handling version negotiation
a little different.

Any comments on version negotiation would be helpful from the idr list here.
=
> >
> >
> > [...]
> >
> >
> > 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:
> > -       sends a NOTIFICATION with Cease,
> > -       sets IdleHoldtimer = 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.
>
>Deletes routes learned from this peer?  Why was this step not included
>with all the other events that cause the peer to leave the Established state?

In all other states except Established, no routes should exist.

This is the base text and the graceful restart.   As soon as we get the 
base text
done, we would have to modify it for graceful restart.

> >
> >
> > [...]
> >
> > In response to any other event, the local system:
> > -       sends a NOTIFICATION message with Error Code Finite State Machine
> > Error,
> > -       sets IdleHoldtimer = 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
> > -       deletes all routes.
>
>Same question here...

See above.

Great questions.    You're on my review list!!

Sue

Date: Mon, 12 Nov 2001 10:59:30 -0500
To: Joe Abley <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: FSM changes - the colored text version
Cc: Susan Hares <[email-masked]>, [email-masked]
Sender: [email-masked]

I'll resend with bars.

Sue

At 11:27 AM 11/9/2001 -0500, Joe Abley wrote:
>Hi Susan,
>
>On Wed, Nov 07, 2001 at 04:34:56PM -0500, Susan Hares wrote:
> > Here's a set of text with Red color on those FSM words
> > that have changed.
>
>Just thought I'd mention -- there is no "red" encoded in your message.
>You might like to try ASCII change indicators (like "|" bars in the
>left margin or something) since they are generally readable by
>everybody.
>
>
>Joe

Date: Mon, 12 Nov 2001 10:19:15 -0500
To: Enke Chen <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: FSM changes for the Draft-15 
Cc: Susan Hares <[email-masked]>, [email-masked], jeffrey Haas <[email-masked]>, Yakov Rekhter <[email-masked]>, [email-masked]
Sender: [email-masked]

--=====================_9674761==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Enke:

Perhaps you would care to review the additional documents I sent for
the specifics of the states and the actions.    I included two additional
bodies of work for you to answer the question of what's broken:

1) red-line text for the actual text. - this shows where the text was changed
2) State machine table with actions.

I have repeated the highlights here.

To summarize:

1) By your own admission and John Scudders, the state machine text
     needed work.   Your comment was to remove it because fixing was
     too difficult.

2)  I've not added a new state, I've encode the two sub-states in idle
       to two full states.  The mixing of the idle states does not allow the
       operator to know what's really happening by MIB or SNMP query of
       the state of the connection.

       If a machine is in "hold down" due to an automatic condition, the
       state machine should tell you -- not leave the operator guessing what
       part of Idle state.

3) Why is the question raised now

> > I would like to first ask the working group if they want to remove the
> > state machine or take fixes to the State machine.  I really think we
> > should take fixes so we do not have interoperability issues.
>
>Not sure why this question is raised as Draft-15 contains a section on
>"BGP Finite State Machine" (Section 8), and no one has suggested removing
>it in the previous or the current Last Call.

As I indicated last August, I felt the state machine should be fixed.   As 
a response
to the current Last Call, I submitted alternative text fixing the text in 
the state machine
text.

>Could you  what exactly are the problems with the current text of
>Section 8?

As you and John Scudder agreed in August, the text is unclear.   The state 
machine
had 23 actions/events allowed with 6 states, one of which (Idle) had two 
sub-states.
The Idle sub-state text waved its hands at the questions of what should 
happen between
automatic versus manual operator intervention.

Problems and changes:

1)  I simply cleaned up the text by adding something each implementation 
with the ability
to "automatically" terminate the connections would require.  The addition 
of the
"Idle Hold" state provides the operator with a clean way to determine which
portion of the Idle state they are in.

2) encode the concept of "manual" left by the Idle text below
3) fixed a problem in the Connect state where the Hold time was not being
     set  during the "transport connection succeeds" function prior to
     going to Open Sent.   It used to say:

          If the transport protocol connection succeeds, the local system
          clears the ConnectRetry timer, completes initialization, sends
          an OPEN message to its peer, and changes its state to OpenSent.
Fix:

         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.

4) Made a special exception on Open messages with the version error
     to allow this to by-pass the automatic hold down in Idle Hold state.

         It is my understanding that current implementations treat the 
version errors
         in a slightly different way.   Please comment on this action.

5)  Allow for "manual" intervention - operators and others to get a connection
      out of the Idle state.   The manual intervention can be via SNMP MIB or
      CLI.    This manual intervention is implied, but unclear in the 
earlier IDLE text.

  The text in the Established state of:

          In response to the Stop event (initiated by either system or
          operator), the local system sends a NOTIFICATION message with
          Error Code Cease and changes its state to Idle.

Was changed to:
         In response to the stop event initiated by the system (automatic), 
the local system:
         - sends a NOTFICATION with Cease,
           - sets IdleHoldTimer = 2**(ConnectRetryCnt)*60  [formula in Idle 
text]
         - sets 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.

6) Edit into each state the specific actions indicated in the "idle text" :

The draft-15 section 8  has text in  Idle state of:

          If a BGP speaker detects an error, it shuts down the connection
          and changes its state to Idle. Getting out of the Idle state
          requires generation of the Start event.  If such an event is
          generated automatically, then persistent BGP errors may result
          in persistent flapping of the speaker.  To avoid such a
          condition it is recommended that Start events should not be
          generated immediately for a peer that was previously
          transitioned to Idle due to an error. For a peer that was
          previously transitioned to Idle due to an error, the time
          between consecutive generation of Start events, if such events
          are generated automatically, shall exponentially increase. The
          value of the initial timer shall be 60 seconds. The time shall
          be doubled for each consecutive retry. An implementation MAY
          impose a configurable upper bound on that time. Once the upper
          bound is reached, the speaker shall no longer automatically
          generate the Start event for the peer.

Why now:
-----------------

>I failed to see why we need the new states (which by the way would make all
>the depolyed implementations non compliant).

This standard is at "Draft" and we are entertaining implementation comments
on the rest of the draft to match current practice.

The actual operation of the hold down feature idle state in automatic or manual
  mode is unclear.  The operators have no way to determine what portion of
the "Idle" state the connection is in.   The concept of specifying that 
once the
upper bound has been reached, the speaker shall no longer automatically
generate the Start event for the peer indicates a state within a state.

Any implementation support 'automatic' transitions must "guess" at whether
this state has been reached.

Let me know if you have additional questions,

Sue Hares

--=====================_9674761==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Enke:<br>
<br>
Perhaps you would care to review the additional documents I sent 
for<br>
the specifics of the states and the actions.&nbsp;&nbsp;&nbsp; I included
two additional<br>
bodies of work for you to answer the question of what's broken:<br>
<br>
1) red-line text for the actual text. - this shows where the text was
changed<br>
2) State machine table with actions.<br>
<br>
I have repeated the highlights here.<br>
<br>
To summarize:<br>
<br>
1) By your own admission and John Scudders, the state machine text<br>
&nbsp;&nbsp;&nbsp; needed work.&nbsp;&nbsp; Your comment was to remove it
because fixing was<br>
&nbsp;&nbsp;&nbsp; too difficult.<br>
<br>
2)&nbsp; I've not added a new state, I've encode the two sub-states in
idle<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to two full states.&nbsp; The mixing of
the idle states does not allow the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; operator to know what's really happening
by MIB or SNMP query of&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the state of the connection.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If a machine is in &quot;hold down&quot;
due to an automatic condition, the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; state machine should tell you -- not leave
the operator guessing what<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; part of Idle state.<br>
<br>
3) Why is the question raised now<br>
<br>
<blockquote type=cite class=cite cite>&gt; I would like to first ask the
working group if they want to remove the<br>
&gt; state machine or take fixes to the State machine.&nbsp; I really
think we<br>
&gt; should take fixes so we do not have interoperability issues.<br>
<br>
Not sure why this question is raised as Draft-15 contains a section on
<br>
&quot;BGP Finite State Machine&quot; (Section 8), and no one has
suggested removing<br>
it in the previous or the current Last Call.</blockquote><br>
As I indicated last August, I felt the state machine should be
fixed.&nbsp;&nbsp; As a response<br>
to the current Last Call, I submitted alternative text fixing the text in
the state machine<br>
text.&nbsp; <br>
<br>
<blockquote type=cite class=cite cite>Could you&nbsp; what exactly are
the problems with the current text of<br>
Section 8?</blockquote><br>
As you and John Scudder agreed in August, the text is
unclear.&nbsp;&nbsp; The state machine<br>
had 23 actions/events allowed with 6 states, one of which (Idle) had two
sub-states.<br>
The Idle sub-state text waved its hands at the questions of what should
happen between<br>
automatic versus manual operator intervention.&nbsp;&nbsp; <br>
<br>
Problems and changes: <br>
<br>
1)&nbsp; I simply cleaned up the text by adding something each
implementation with the ability<br>
to &quot;automatically&quot; terminate the connections would
require.&nbsp; The addition of the<br>
&quot;Idle Hold&quot; state provides the operator with a clean way to
determine which<br>
portion of the Idle state they are in. <br>
<br>
2) encode the concept of &quot;manual&quot; left by the Idle text
below<br>
3) fixed a problem in the Connect state where the Hold time was not
being<br>
&nbsp;&nbsp;&nbsp; set&nbsp; during the &quot;transport connection
succeeds&quot; function prior to<br>
&nbsp;&nbsp;&nbsp; going to Open Sent.&nbsp;&nbsp; It used to say:<br>
<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the transport
protocol connection succeeds, the local system<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clears the ConnectRetry
timer, completes initialization, sends<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an OPEN message to its
peer, and changes its state to OpenSent.<br>
Fix: <br>
<br>
<font face="Times New Roman, Times"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>If
the transport connection succeeds, the local system:</font>
<dl>
<dl><font face="Times New Roman, Times" size=4>
<dd>-</font><font face="Times New Roman, Times">clears the ConnectRetry
timer, </font>
</dl>
</dl><font size=4><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;
- </font><font face="Times New Roman, Times">completes
initialization,<br>
</font><font size=4><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;
- </font><font face="Times New Roman, Times">send an Open message to its
peer,<br>
</font><font size=4 color="#FF0000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;
- </font><font face="Times New Roman, Times" color="#FF0000">set Hold
timer to a large value,&nbsp; and <br>
</font><font face="Times New Roman, Times"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;
- changes its state to Open Sent.&nbsp; <br>
<br>
</font>4) Made a special exception on Open messages with the version
error<br>
&nbsp;&nbsp;&nbsp; to allow this to by-pass the automatic hold down in
Idle Hold state.<br>
&nbsp;&nbsp; <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>It is my
understanding that current implementations treat the version errors<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>in a
slightly different way.&nbsp;&nbsp; Please comment on this action.<br>
<br>
5)&nbsp; Allow for &quot;manual&quot; intervention - operators and others
to get a connection<br>
&nbsp;&nbsp;&nbsp;&nbsp; out of the Idle state.&nbsp;&nbsp; The manual
intervention can be via SNMP MIB or<br>
&nbsp;&nbsp;&nbsp;&nbsp; CLI.&nbsp;&nbsp;&nbsp; This manual intervention
is implied, but unclear in the earlier IDLE text.<br>
<br>
&nbsp;The text in the Established state of:<br>
<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In response to the Stop
event (initiated by either system or<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; operator), the local
system sends a NOTIFICATION message with<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Error Code Cease and
changes its state to Idle.<br>
<br>
Was changed to:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In response to the stop event
initiated by the system (automatic), the local system:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>- sends a
NOTFICATION with Cease,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - sets
IdleHoldTimer = 2**(ConnectRetryCnt)*60&nbsp; [formula in Idle 
text]<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>- sets
connect retry timer to zero,<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>- drops
the TCP connection,<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>- releases
all BGP resources,<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>- goes to
IdleHold state, and<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>- deletes
all routes.<br>
<br>
<font face="Times New Roman, Times"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>An
example automatic stop event is exceeding the number of prefixes for a
given peer <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>and the
local system automatically disconnecting the peer.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>In
response to a stop event initiated by an operator:</font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">release
all resources (including deleting all routes),</font>
</dl>
</dl><font size=4><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;
-&nbsp;&nbsp; </font><font face="Times New Roman, Times">set
ConnectRetryCnt to zero (0),<br>
</font><font face="Times New Roman, Times" size=4><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;
-&nbsp;&nbsp; </font><font face="Times New Roman, Times">set connect
retry timer to zero (0), and<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-&nbsp;&nbsp;&nbsp;&nbsp; transition to the Idle.<br>
<br>
</font>6) Edit into each state the specific actions indicated in the
&quot;idle text&quot; : <br>
<br>
The draft-15 section 8&nbsp; has text in&nbsp; Idle state of:<br>
<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If a BGP speaker detects
an error, it shuts down the connection<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and changes its state to
Idle. Getting out of the Idle state<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; requires generation of
the Start event.&nbsp; If such an event is<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; generated automatically,
then persistent BGP errors may result<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in persistent flapping
of the speaker.&nbsp; To avoid such a<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; condition it is
recommended that Start events should not be<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; generated immediately
for a peer that was previously<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transitioned to Idle due
to an error. For a peer that was<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; previously transitioned
to Idle due to an error, the time<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; between consecutive
generation of Start events, if such events<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; are generated
automatically, shall exponentially increase. The<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; value of the initial
timer shall be 60 seconds. The time shall<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; be doubled for each
consecutive retry. An implementation MAY<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; impose a configurable
upper bound on that time. Once the upper<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bound is reached, the
speaker shall no longer automatically<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; generate the Start event
for the peer.<br>
<br>
Why now:<br>
-----------------<br>
<br>
<blockquote type=cite class=cite cite>I failed to see why we need the new
states (which by the way would make all<br>
the depolyed implementations non compliant).</blockquote><br>
This standard is at &quot;Draft&quot; and we are entertaining
implementation comments<br>
on the rest of the draft to match current
practice.&nbsp;&nbsp;&nbsp;&nbsp; <br>
<br>
The actual operation of the hold down feature idle state in automatic or
manual<br>
&nbsp;mode is unclear.&nbsp; The operators have no way to determine what
portion of<br>
the &quot;Idle&quot; state the connection is in.&nbsp;&nbsp; The concept
of specifying that once the<br>
upper bound has been reached, the speaker shall no longer
automatically<br>
generate the Start event for the peer indicates a state within a
state.<br>
<br>
Any implementation support 'automatic' transitions must &quot;guess&quot;
at whether<br>
this state has been reached.&nbsp; <br>
<br>
<br>
Let me know if you have additional questions,<br>
<br>
<br>
Sue Hares<br>
<br>
<br>
</html>

--=====================_9674761==_.ALT--

Date: Mon, 12 Nov 2001 09:18:45 -0500
To: Ben Black <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: FSM changes for the Draft-15
Cc: Yakov Rekhter <[email-masked]>, Susan Hares <[email-masked]>, [email-masked]
Sender: [email-masked]

Ben:

>I find this statement offensive and contrary to the philosophy of the IETF.
>This is an open list, and anyone with a good idea should be able to contribute
>it.  If you'd like a closed list restricted to BGP implementors, by all means
>set it up and decide behind closed doors how the protocols will evolve, but
>don't announce on an open IETF list that you can only contribute if you work
>for a vendor.

I think we need votes from all operators (Enterprise, ISP, Exchange, etc...).

>I agree with Randy: The problem with the BGP specification has always been a
>lack of rigor, not an excess of specificity.  Will removal of the FSM from the
>draft serve to improve interoperability and quality of implementation?

We have found in our conformance testing that the lack of a working FSM
gives some real problems in interoperability of implementations.   The 
quality of the
state machine will be improved when implementations have a correct state 
machine.

Please refer to the associated state machine documents.

Sue Hares

Date: Mon, 12 Nov 2001 09:39:07 -0500
To: Yakov Rekhter <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: FSM changes for the Draft-15 
Cc: Susan Hares <[email-masked]>, [email-masked]
Sender: [email-masked]

Yakov:

I believe we need comments from operators (Enterprise, ISP,  Exchange point)
as well as developers.

Sue

At 07:48 PM 11/7/2001 -0800, Yakov Rekhter wrote:
>Sue,
>
> > At the last IDR meeting in London, John Scudder proposed that
> > we cut the State machine. I objected to this removal since "no state 
> machine"
> > means interoperability problems between BGP implementations.
> > If router vendor A  changes their implementation (or puts a bug) in the 
> state
> > machine there is no "standard" to hold them to.
> >
> > I would like to first ask the working group if they want to remove the
> > state machine or take fixes to the State machine.  I really think we
> > should take fixes so we do not have interoperability issues.
>
>I would especially encourage folks who are * BGP implementors* to comment
>on whether they feel they really need the state machine in the spec.
>
>Yakov.

Date: Mon, 12 Nov 2001 09:14:09 -0500
To: Yakov Rekhter <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: FSM changes for the Draft-15 
Cc: Susan Hares <[email-masked]>, [email-masked]
Sender: [email-masked]

Yakov:

My vote also comes from a implementor.

Sue

At 07:48 PM 11/7/2001 -0800, Yakov Rekhter wrote:
>Sue,
>
> > At the last IDR meeting in London, John Scudder proposed that
> > we cut the State machine. I objected to this removal since "no state 
> machine"
> > means interoperability problems between BGP implementations.
> > If router vendor A  changes their implementation (or puts a bug) in the 
> state
> > machine there is no "standard" to hold them to.
> >
> > I would like to first ask the working group if they want to remove the
> > state machine or take fixes to the State machine.  I really think we
> > should take fixes so we do not have interoperability issues.
>
>I would especially encourage folks who are * BGP implementors* to comment
>on whether they feel they really need the state machine in the spec.
>
>Yakov.

Date: Mon, 12 Nov 2001 09:11:21 -0500
To: "Wayne F. Tackabury" <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: FSM changes - the colored text version
Cc: Susan Hares <[email-masked]>, [email-masked]
Sender: [email-masked]

Wayne:

Operator intervention was intended to include mib-2 setting as well
as setting by CLI or other means.

Automatic is based on a rule set.

Does this clarifying things?

Sue

At 05:30 PM 11/7/2001 -0500, Wayne F. Tackabury wrote:
>Hi Susan...
>
>I might just loosen the words "operator intervention" when it comes to 
>starting/advancing the state machine.  As this draft will be moving 
>forward as we advance the BGP mib-2, the configuration features of that 
>might imply such intervention is "automatic" as a result of activation 
>from the SNMP agent instrumentation.  Now, we have a lot of details to 
>work out here, but I'd like to not make it look like there was a parallel 
>draft which precluded this.  Perhaps "operator intervention or management 
>agent activation"?
>
>Regards,
>Wayne
>

Date: Fri, 9 Nov 2001 13:56:29 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Susan Hares <[email-masked]>
Cc: [email-masked], jeffrey Haas <[email-masked]>, Yakov Rekhter <[email-masked]>
Subject: Re: FSM changes for the Draft-15
Sender: [email-masked]

Sue,

> I'd like 2nd to ask that the working group accepts this FSM rewrite.

> I've re-written the state machine to be a bit cleaner in text.
> The Idle state had two sub-states so I cleaned this up by making each
> of these states a different text (Idle and Idle Hold)

> Here are changes to the draft-15 FSM to make the FSM a bit clear.

If we are to make the FSM textual description in the spec more or less
meaningful, I suggest we take some time and fix the section using
the following approach:

8. BGP Finite State machine.

8.1 BGP FSM Events

For each event:

 Event       : <event-name>
 Description : <short-description>
 Generation  : <conditions when the event is generated>

8.2 BGP Session States

For each state, give a generic description, something like
the following:

 State       : <state-name>
 Description : <short description>
 Valid events: <list of events expected and processed in this state,
                others should be ignored>
 In actions  : <list of actions _always_ performed when
                transitioning to the state>
 Out actions : <list of actions _always_ performed when
                transitioning from the state>
 State actions: <list of actions performed (e.g. periodically) while
                in this state>
                
8.3 BGP FSM Definition

 FSM State : <one or many states>
 FSM Event : <one or many events>
 Next state: <new state if always the same>
 Actions   : <list of state/event-specific actions and state
              transitions if condition-dependent>

I'll take a look at the files you sent as well.

Alex.

Date: Fri, 9 Nov 2001 13:07:39 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Susan Hares <[email-masked]>
Cc: [email-masked], jeffrey Haas <[email-masked]>, Yakov Rekhter <[email-masked]>
Subject: Re: FSM changes for the Draft-15
Sender: [email-masked]

Susan,

> I would like to first ask the working group if they want to remove the
> state machine or take fixes to the State machine.  I really think we
> should take fixes so we do not have interoperability issues.

I do not believe removing the FSM is an option. In fact, this
would make the spec useless. Unless this is exactly the goal,
I'd say let's fix it.

Alex.

Date: Thu, 8 Nov 2001 22:38:31 -0500 (EST)
From: Pedro Ferreira <[email-masked]>
SUBJECT: Which of these
To: undisclosed-recipients: ;
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0095_013E2295.933295B0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Now consider the utility function for two goods
	
u(x) = x11/3 + x22/3.

Assume that the prices of both goods are equal to 1.  Show that this utility function satisfied both properties suggested in part (d), where good 1 is the basic good and good 2 is the fancy good.  

Does the more general utility function 
	
u(x) = x1(  + x2(

satisfy those same properties for all prices so long as 0 < ( < ( < 1?

3.
------=_NextPart_000_0095_013E2295.933295B0
Content-Type: application/octet-stream; name="utility.bat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="utility.bat"

------=_NextPart_000_0095_013E2295.933295B0--

Date: Thu, 8 Nov 2001 16:33:38 -0800 (PST)
From: Yu Zhang <[email-masked]>
Subject: BGP Identifier
To: [email-masked]
Sender: [email-masked]

Hi,

I wonder whether a BGP router can establish sessions
with two BGP routers with same BGP identifier?

If not, what shall the BGP router do in case it
receives OPEN messages with the same BGP identifier
from different BGP peers?

Thanks.

Yu

__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

Date: Thu, 8 Nov 2001 15:41:50 -0800
From: [email-masked]
To: Susan Hares <[email-masked]>
Cc: [email-masked], jeffrey Haas <[email-masked]>, Yakov Rekhter <[email-masked]>
Subject: Re: FSM changes for the Draft-15
Sender: [email-masked]

> At the last IDR meeting in London, John Scudder proposed that
> we cut the State machine.   I objected to this removal since "no state machine"
> means interoperability problems between BGP implementations.
> If router vendor A  changes their implementation (or puts a bug) in the state
> machine there is no "standard" to hold them to.
> 
> I would like to first ask the working group if they want to remove the
> state machine or take fixes to the State machine.  I really think we
> should take fixes so we do not have interoperability issues.

I agree that having a decription of the state machine in the protocol spec
is desireable.  Thank you for comming up with a more detailed version than is
currently in Section 8.  The description in Section 8 is sufficent for
those who have extensive BGP experience, but your verion will make it
much easier for people with less BGP experience to implement BGP.

> I'd like 2nd to ask that the working group accepts this FSM rewrite.
> 
> I've re-written the state machine to be a bit cleaner in text.
> The Idle state had two sub-states so I cleaned this up by making each
> of these states a different text (Idle and Idle Hold)

Comments on the FSM:

IdleHold:

This state seems implicit in section 8 the way it is currently written 
(defining the exponential backoff timer in the case of an automatic start 
event), so making it explicit is a good idea.

Active:

> The start events (initiated by the system or operator) are ignored in the Active state.
> [Note: Jeff Haas thinks that operators would want manual start to do something different.]

Currently, if an operator wants to restart the ConnectRetry timer in an
attempt to bring up a BGP session now, they shutdown/clear the session 
which transitions things back to idle, clears all the counters, and restarts
the process.  There is some overhead associated with this, but I think it
is an acceptable solution, so leaving Active defined as it is, with starts
ignored is fine.

--------

I would suggest an additon:

- In line with the current spec which states: "An implementation MAY
impose a configurable upper bound on that time [the IdleHoldtimer].  Once
the upper bound is reached, the speaker shall no longer automatically
generate the Start event for the peer."

Add something mentioning this configurable maximum, for example:

 IdleHoldtimer = 2**(ConnectRetryCnt)*60
 If IdleHoldtimer > IdleHoldTimerMax; generate a syslog event (vendor specifc)
 Set KeepIdle flag
 Transition to IdleHold state

Andrew

Date: Thu, 8 Nov 2001 12:27:05 -0800 (PST)
From: Edward Crabbe <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Susan Hares <[email-masked]>, [email-masked]
Subject: Re: FSM changes for the Draft-15
Sender: [email-masked]

echo.

	-ed

> Yakov,
> 
>     I would MUCH rather hear them comment on the accuracy of the state
> machine, than whether or not they need it in the specification.  As has been
> established previously, many of those who are "BGP implementors" tend
> to be satisfied with what is already in the specification while those who
> would like to become "BGP implementors" are of a different mind.
> 

Date: Thu, 08 Nov 2001 16:49:50 +0100
From: Antal Sasvari <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: [email-masked]
Subject: Re: FSM changes for the Draft-15
Sender: [email-masked]

Eric,

I fully agree with you. I began to study BGP this summer, and I was a bit surprised,
how unclear the Decision Process, and some other parts are given in RFC 1771. Perhabs
people, who implemented BGP during the last years, know, what the text wants to say,
but I think the RFC should DEFINE the protocol, as clear as it is possible, so that
anyone will be able to create an implementation which interoperates with the others.

Antal

Eric Gray wrote:

> Yakov,
>
>     I would MUCH rather hear them comment on the accuracy of the state
> machine, than whether or not they need it in the specification.  As has been
> established previously, many of those who are "BGP implementors" tend
> to be satisfied with what is already in the specification while those who
> would like to become "BGP implementors" are of a different mind.
>
> You wrote:
>
> > Sue,
> >
> > > At the last IDR meeting in London, John Scudder proposed that
> > > we cut the State machine. I objected to this removal since "no state machine"
> > > means interoperability problems between BGP implementations.
> > > If router vendor A  changes their implementation (or puts a bug) in the state
> > > machine there is no "standard" to hold them to.
> > >
> > > I would like to first ask the working group if they want to remove the
> > > state machine or take fixes to the State machine.  I really think we
> > > should take fixes so we do not have interoperability issues.
> >
> > I would especially encourage folks who are * BGP implementors* to comment
> > on whether they feel they really need the state machine in the spec.
> >
> > Yakov.
>
> --
> Eric Gray (mailto:[email-masked])
> http://www.mindspring.com/~ewgray

Date: Thu, 08 Nov 2001 10:28:07 -0500
From: Eric Gray <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Susan Hares <[email-masked]>, [email-masked]
Subject: Re: FSM changes for the Draft-15
Sender: [email-masked]

Yakov,

    I would MUCH rather hear them comment on the accuracy of the state
machine, than whether or not they need it in the specification.  As has been
established previously, many of those who are "BGP implementors" tend
to be satisfied with what is already in the specification while those who
would like to become "BGP implementors" are of a different mind.

You wrote:

> Sue,
>
> > At the last IDR meeting in London, John Scudder proposed that
> > we cut the State machine. I objected to this removal since "no state machine"
> > means interoperability problems between BGP implementations.
> > If router vendor A  changes their implementation (or puts a bug) in the state
> > machine there is no "standard" to hold them to.
> >
> > I would like to first ask the working group if they want to remove the
> > state machine or take fixes to the State machine.  I really think we
> > should take fixes so we do not have interoperability issues.
>
> I would especially encourage folks who are * BGP implementors* to comment
> on whether they feel they really need the state machine in the spec.
>
> Yakov.

--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

Date: Thu, 8 Nov 2001 13:41:27 +0000
From: David Ball <[email-masked]>
To: Ben Black <[email-masked]>
Cc: [email-masked]
Subject: Re: FSM changes for the Draft-15
Sender: [email-masked]

On Wed, Nov 07, 2001, Ben Black wrote:
> > 
> > I would especially encourage folks who are * BGP implementors* to comment
> > on whether they feel they really need the state machine in the spec.
> > 
> 
> I find this statement offensive and contrary to the philosophy of the IETF.
> This is an open list, and anyone with a good idea should be able to contribute
> it.  If you'd like a closed list restricted to BGP implementors, by all means
> set it up and decide behind closed doors how the protocols will evolve, but
> don't announce on an open IETF list that you can only contribute if you work
> for a vendor.

I fail to see how encouraging a certain group to comment prohibits
anyone else from doing so.

	David

-- 
David Ball
<[email-masked]>

To: Susan Hares <[email-masked]>
Cc: [email-masked], jeffrey Haas <[email-masked]>, Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: FSM changes for the Draft-15 
Date: Wed, 07 Nov 2001 21:50:54 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Sue,

> Date: Wed, 07 Nov 2001 16:33:54 -0500
> To: [email-masked]
> From: Susan Hares <[email-masked]>
> Subject: FSM changes for the Draft-15 
> Cc: jeffrey Haas <[email-masked]>,
> 	Yakov Rekhter <[email-masked]>
> Mime-Version: 1.0
> 
> 
> At the last IDR meeting in London, John Scudder proposed that
> we cut the State machine.   I objected to this removal since "no state machine"
> means interoperability problems between BGP implementations.
> If router vendor A  changes their implementation (or puts a bug) in the state
> machine there is no "standard" to hold them to.
> 
> I would like to first ask the working group if they want to remove the
> state machine or take fixes to the State machine.  I really think we
> should take fixes so we do not have interoperability issues.

Not sure why this question is raised as Draft-15 contains a section on 
"BGP Finite State Machine" (Section 8), and no one has suggested removing
it in the previous or the current Last Call.

> 
> I'd like 2nd to ask that the working group accepts this FSM rewrite.
> 
> I've re-written the state machine to be a bit cleaner in text.
> The Idle state had two sub-states so I cleaned this up by making each
> of these states a different text (Idle and Idle Hold)

Could you clarify what exactly are the problems with the current text of
Section 8?

I failed to see why we need the new states (which by the way would make all
the depolyed implementations non compliant).

-- Enke

> 
> Here are changes to the draft-15 FSM to make the FSM a bit clear.
> 
> I will post a color version of this text for people who want to see what 
> text is new.
> I'll also post a word document and htm file with a state table for each
> of these states.
> 
> Thanks,
> 
> Sue Hares
> desk: (734)222-1610
> main: (734)222-1600
> 
> [email-masked]
> 
> ----------------------
> Idle state:
> 
> Initially BGP is in the 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.
> 
> 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.
> 
> 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 = 2**(ConnectRetryCnt)*60
> -       Increment ConnectRetryCnt by 1,
> -       Set connect retry timer to zero,
> -       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.
> [Note: Jeff Haas thinks that operators would want manual start to do 
> something different.]
> 
> In response to any other event (initiated by the system or operator), the 
> local system:
> -       IdleHoldtimer = 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 = 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.
> 
> 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 = 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 = 0,
> -       Connect retry timer = 0, and
> -       transition to Idle state.
> 
> If any other NOTIFICATION is received, the local system:
> -       IdleHoldtimer = 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 = 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 = 2**(ConnectRetryCnt)*60
> -       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 = 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 = 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,
> -       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 = 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 = 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 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 = 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 = 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:
> -       sends a NOTIFICATION with Cease,
> -       sets IdleHoldtimer = 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 = 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
> -       deletes all routes.
> 
> 

Date: Wed, 7 Nov 2001 21:31:27 -0800
From: Ben Black <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Susan Hares <[email-masked]>, [email-masked]
Subject: Re: FSM changes for the Draft-15
Sender: [email-masked]

On Wed, Nov 07, 2001 at 07:48:13PM -0800, Yakov Rekhter wrote:
> 
> I would especially encourage folks who are * BGP implementors* to comment
> on whether they feel they really need the state machine in the spec.
> 

I find this statement offensive and contrary to the philosophy of the IETF.
This is an open list, and anyone with a good idea should be able to contribute
it.  If you'd like a closed list restricted to BGP implementors, by all means
set it up and decide behind closed doors how the protocols will evolve, but
don't announce on an open IETF list that you can only contribute if you work
for a vendor.

I agree with Randy: The problem with the BGP specification has always been a
lack of rigor, not an excess of specificity.  Will removal of the FSM from the
draft serve to improve interoperability and quality of implementation?

Ben

To: Susan Hares <[email-masked]>
Cc: [email-masked]
Subject: Re: FSM changes for the Draft-15 
Date: Wed, 07 Nov 2001 19:48:13 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Sue,

> At the last IDR meeting in London, John Scudder proposed that
> we cut the State machine. I objected to this removal since "no state machine"
> means interoperability problems between BGP implementations.
> If router vendor A  changes their implementation (or puts a bug) in the state
> machine there is no "standard" to hold them to.
> 
> I would like to first ask the working group if they want to remove the
> state machine or take fixes to the State machine.  I really think we
> should take fixes so we do not have interoperability issues.

I would especially encourage folks who are * BGP implementors* to comment
on whether they feel they really need the state machine in the spec.

Yakov.

From: Randy Bush <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: [email-masked]
Subject: Re: FSM changes for the Draft-15 
Date: Wed, 07 Nov 2001 17:03:35 -0800
Sender: [email-masked]

> I would like to first ask the working group if they want to remove the
> state machine or take fixes to the State machine.

removing, as opposed to adding, formal rigor would seem to require a bit
more explanation than i have heard.

randy

Date: Wed, 07 Nov 2001 16:39:52 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: FSM background documents - Word attached.  HTML attached
Sender: [email-masked]

--=====================_11077658==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

here's the Table that is the background for the FSM text.
Please send anycomments to me at [email-masked].

This text is supportive and not normative.

Sue Hares
--=====================_11077658==_
Content-Type: application/msword; name="statemt.doc";
 x-mac-type="42494E41"; x-mac-creator="4D535744"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="statemt.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAfAAAAAAAAAAA
EAAAfgAAAAEAAAD+////AAAAAHsAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
--=====================_11077658==_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="statemt.htm"

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office"
xmlns:w=3D"urn:schemas-microsoft-com:office:word"
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-1252=
">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"./statemt_files/filelist.xml">
<title>Event</title>
<!--[if gte mso 9]><xml>
 <o:DocumentProperties>
  <o:Author>Sue Hares</o:Author>
  <o:LastAuthor>Sue Hares</o:LastAuthor>
  <o:Revision>2</o:Revision>
  <o:TotalTime>291</o:TotalTime>
  <o:LastPrinted>2001-11-07T18:38:00Z</o:LastPrinted>
  <o:Created>2001-11-07T19:54:00Z</o:Created>
  <o:LastSaved>2001-11-07T19:54:00Z</o:LastSaved>
  <o:Pages>5</o:Pages>
  <o:Words>892</o:Words>
  <o:Characters>5086</o:Characters>
  <o:Company>NextHop Technologies, Inc.</o:Company>
  <o:Lines>42</o:Lines>
  <o:Paragraphs>10</o:Paragraphs>
  <o:CharactersWithSpaces>6245</o:CharactersWithSpaces>
  <o:Version>9.4402</o:Version>
 </o:DocumentProperties>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;
	mso-font-charset:2;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:0 268435456 0 0 -2147483648 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	color:red;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
@list l0
	{mso-list-id:313948469;
	mso-list-type:hybrid;
	mso-list-template-ids:1758788012 67698689 67698703 67698693 67698689=
 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.25in;
	mso-level-number-position:left;
	margin-left:.25in;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level2
	{mso-level-tab-stop:.75in;
	mso-level-number-position:left;
	margin-left:.75in;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:1.25in;
	mso-level-number-position:left;
	margin-left:1.25in;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l1
	{mso-list-id:552161381;
	mso-list-type:hybrid;
	mso-list-template-ids:-198542166 67698703 67698713 67698715 67698703=
 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
	{mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2
	{mso-list-id:2073120514;
	mso-list-type:hybrid;
	mso-list-template-ids:1984049682 67698703 67698713 67698715 67698703=
 67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
	{mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
</head>

<body lang=3DEN-US style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal>BGP State machine in table format:</p>

<p class=3DMsoNormal><![if=
 !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=3DMsoNormal>The table below has Events by States.<span
style=3D"mso-spacerun: yes">=A0 </span>In each entry of the table, the first=
 entry
in the box is the new state.<span style=3D"mso-spacerun: yes">=A0 </span>The=
 second
entry is the set of actions.<span style=3D"mso-spacerun: yes">=A0=A0=
 </span>Each
action is either specified (such as Ignore) or it given a Letter (such as B)
which is described at the end of the table.</p>

<p class=3DMsoNormal><![if=
 !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=3DMsoNormal>For example,<span style=3D"mso-spacerun: yes">=A0=
 </span>If an
Automatic start event occurs in the Idle state, the local system performs=
 the
actions listed under =93A=94 and goes to the Connect state.<span
style=3D"mso-spacerun: yes">=A0=A0 </span>The actions under the letter A=
 are: </p>

<p class=3DMsoNormal><![if=
 !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
A<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>initialize
all BGP resources<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>start
Connect retry timer<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>3.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>initiate
transport connection to BGP peer<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>4.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>listen
for connection set-up by remote BGP peer<o:p></o:p></span></p>

<p class=3DMsoNormal><![if=
 !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=3DMsoNormal><![if=
 !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=3DMsoNormal><![if=
 !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<table border=3D1 cellspacing=3D0 cellpadding=3D0=
 style=3D'border-collapse:collapse;
 border:none;mso-border-alt:solid windowtext .5pt;mso-padding-alt:0in 5.4pt=
 0in 5.4pt'>
 <thead>
  <tr>
   <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
   padding:0in 5.4pt 0in 5.4pt'>
   <p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><span
   style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><o:p></o:p></span></=
p>
   </td>
   <td width=3D492 colspan=3D7 valign=3Dtop=
 style=3D'width:369.0pt;border:solid windowtext .5pt;
   border-left:none;mso-border-left-alt:solid windowtext .5pt;padding:0in=
 5.4pt 0in 5.4pt'>
   <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>State
   (New state/action)<o:p></o:p></span></p>
   </td>
  </tr>
  <tr>
   <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
   border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in=
 5.4pt 0in 5.4pt'>
   <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Event<o:p></o:p></span=
></p>
   </td>
   <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:
   none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
   mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
   padding:0in 5.4pt 0in 5.4pt'>
   <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
   Hold<o:p></o:p></span></p>
   </td>
   <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:
   none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
   mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
   padding:0in 5.4pt 0in 5.4pt'>
   <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle<o:p></o:p></span>=
</p>
   </td>
   <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
   border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
   mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
   padding:0in 5.4pt 0in 5.4pt'>
   <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Connect<o:p></o:p></sp=
an></p>
   </td>
   <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
   none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
   mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
   padding:0in 5.4pt 0in 5.4pt'>
   <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Open
   sent<o:p></o:p></span></p>
   </td>
   <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:
   none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
   mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
   padding:0in 5.4pt 0in 5.4pt'>
   <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Active<o:p></o:p></spa=
n></p>
   </td>
   <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
   none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
   mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
   padding:0in 5.4pt 0in 5.4pt'>
   <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Open
   <o:p></o:p></span></p>
   <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Confirm<o:p></o:p></sp=
an></p>
   </td>
   <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
   border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
   mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
   padding:0in 5.4pt 0in 5.4pt'>
   <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Established<o:p></o:p>=
</span></p>
   </td>
  </tr>
 </thead>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Manual<o:p></o:p></spa=
n></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Start<o:p></o:p></span=
></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Connect
  / B<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Connect<o:p></o:p></sp=
an></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>/B<o:p></o:p></span></=
p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Connect/<o:p></o:p></s=
pan></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Open<o:p></o:p></span>=
</p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Sent/<o:p></o:p></span=
></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Active/<o:p></o:p></sp=
an></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Open
  <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Confirm/<o:p></o:p></s=
pan></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Established/<o:p></o:p=
></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Auto
  <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Start<o:p></o:p></span=
></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Connect/
  A<o:p></o:p></span></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Connect/<o:p></o:p></s=
pan></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Open<o:p></o:p></span>=
</p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Sent/<o:p></o:p></span=
></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Active/<o:p></o:p></sp=
an></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Open<o:p></o:p></span>=
</p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Confirm/<o:p></o:p></s=
pan></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Established/<o:p></o:p=
></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold timer<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Expired
  and value under ceiling<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle/<o:p></o:p></span=
></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>A<o:p></o:p></span></p=
>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle/<o:p></o:p></span=
></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>FSM
  error<o:p></o:p></span></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>D
  <o:p></o:p></span></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  error)<o:p></o:p></span></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>D<span
  style=3D"mso-spacerun: yes">=A0 </span>(FSM error)<o:p></o:p></span></p>
  <p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><span
  style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><o:p></o:p></span></p=
>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  error)<o:p></o:p></span></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>E
  <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  error)<o:p></o:p></span></p>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold timer &amp; timer over ceiling<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D <o:p></o:p></span></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  error)<o:p></o:p></span></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>D
  <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  error)<o:p></o:p></span></p>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>E
  <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  error)<o:p></o:p></span></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>E
  <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  error)<o:p></o:p></span></p>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>TCP<o:p></o:p></span><=
/p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Connect
  <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>succeeds<o:p></o:p></s=
pan></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(sent
  TCP)<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle/<o:p></o:p></span=
></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Open
  sent / F <o:p></o:p></span></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span style=3D'font-size:10.0pt;mso-bidi-font-size:12=
.0pt'>Idle
  Hold/ E (FSM error)<o:p></o:p></span></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Open
  sent / <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>F<o:p></o:p></span></p=
>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E<span style=3D"mso-spacerun: yes">=A0 </span>(FSM error)=
 <o:p></o:p></span></p>
  <p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><span
  style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><o:p></o:p></span></p=
>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><span
  style=3D"mso-spacerun: yes">=A0</span>E (FSM Error)<o:p></o:p></span></p>
  <p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><span
  style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><o:p></o:p></span></p=
>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>TCP
  connect failed<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle/<o:p></o:p></span=
></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Active
  /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>G<o:p></o:p></span></p=
>
  <p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><span
  style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><o:p></o:p></span></p=
>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  error)<o:p></o:p></span></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  hold<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><span
  style=3D"mso-spacerun: yes">=A0</span>/ D<o:p></o:p></span></p>
  <p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><span
  style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><o:p></o:p></span></p=
>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  error)<o:p></o:p></span></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<span style=3D"mso-spacerun: yes">=A0 </span>E (FSM=
 error)<o:p></o:p></span></p>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>TCP
  dis =96connect<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle/
  Ignore<o:p></o:p></span></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D <o:p></o:p></span></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Active
  / O actions<o:p></o:p></span></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>/
  D<o:p></o:p></span></p>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>D<o:p></o:p></span></p=
>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D<o:p></o:p></span></p>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Connect<o:p></o:p></sp=
an></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Retry
  timer expires<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>/
  Ignore<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle/
  Ignore<o:p></o:p></span></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Connect
  / H <o:p></o:p></span></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold<span style=3D"mso-spacerun: yes">=A0 </span>/ E<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  error)<o:p></o:p></span></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Connect
  / H<o:p></o:p></span></p>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E (FSM error)<o:p></o:p></span></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E (FSM error)<o:p></o:p></span></p>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Rcv
  TCP Connect &amp; unconfigured<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Peers
  OK<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<span style=3D"mso-spacerun: yes">=A0 </span>D=
 <o:p></o:p></span></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  Error)<o:p></o:p></span></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Open
  Sent /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>K<o:p></o:p></span></p=
>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E (FSM error)<o:p></o:p></span></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D<o:p></o:p></span></p>
  <p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><span
  style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><o:p></o:p></span></p=
>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Rcv
  TCP connect<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>&amp;
  unconfig<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>peers
  not <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>OK<o:p></o:p></span></=
p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  hold/<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  <p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><span
  style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><o:p></o:p></span></p=
>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D <o:p></o:p></span></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E<o:p></o:p></span></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Active
  / L <o:p></o:p></span></p>
  </td>
  <td width=3D78 valign=3Dtop style=3D'width:58.25pt;border-top:none;border-=
left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E (FSM error)<o:p></o:p></span></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D<o:p></o:p></span></p>
  <p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><span
  style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><o:p></o:p></span></p=
>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Hold
  Timer expires<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/ <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>D<o:p></o:p></span></p=
>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>/
  M (Hold timer expired)<o:p></o:p></span></p>
  <p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><span
  style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><o:p></o:p></span></p=
>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>D<o:p></o:p></span></p=
>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><span
  style=3D"mso-spacerun: yes">=A0</span>(FSM error)<o:p></o:p></span></p>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<span style=3D"mso-spacerun: yes">=A0 </span>M (hold timer=
 expired)<o:p></o:p></span></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>R<span
  style=3D"mso-spacerun: yes">=A0 </span>(hold timer expired)=
 <o:p></o:p></span></p>
  <p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><span
  style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><o:p></o:p></span></p=
>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Open
  recv with good format and header<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<span style=3D"mso-spacerun: yes">=A0 </span>D (FSM=
 error)<o:p></o:p></span></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<span style=3D"mso-spacerun: yes">=A0 </span>N<o:p></o:p></span></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>D
  <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(fsm
  error)<o:p></o:p></span></p>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>/
  E<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  error)<o:p></o:p></span></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>E
  <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  Error)<o:p></o:p></span></p>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Header
  error<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span style=3D'font-size:10.0pt;mso-bidi-font-size:12=
.0pt'>Idle
  Hold/<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  / Ignore<o:p></o:p></span></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D <o:p></o:p></span></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><b><i><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:
  12.0pt'>Idle Hold / I<o:p></o:p></span></i></b></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>D
  <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  error)<o:p></o:p></span></p>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  Error)<o:p></o:p></span></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  old / E<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><![if=
 !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  Error)<o:p></o:p></span></p>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Open
  msg error<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/ Ignore<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  / Ignore<o:p></o:p></span></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D<o:p></o:p></span></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><b><i><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:
  12.0pt'>Idle Hold / J</span></i></b><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:
  12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>D<o:p></o:p></span></p=
>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  error)<o:p></o:p></span></p>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  Error)<o:p></o:p></span></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<span style=3D"mso-spacerun: yes">=A0 </span>E (FSM=
 error)<o:p></o:p></span></p>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Notification
  with version error<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle/
  Ignore<o:p></o:p></span></p>
  <p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><span
  style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><o:p></o:p></span></p=
>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D<o:p></o:p></span></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  / C<o:p></o:p></span></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/ D<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  error)<o:p></o:p></span></p>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span style=3D'font-size:10.0pt;mso-bidi-font-size:12=
.0pt'>D<o:p></o:p></span></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>D<o:p></o:p></span></p=
>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Open
  collision detected &amp; dump this session<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  / Ignore<o:p></o:p></span></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold<span style=3D"mso-spacerun: yes">=A0 </span>/ D <span=
 style=3D"mso-spacerun:
  yes">=A0</span><o:p></o:p></span></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  hold / S<o:p></o:p></span></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>D<o:p></o:p></span></p=
>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  error)<o:p></o:p></span></p>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<span style=3D"mso-spacerun: yes">=A0 </span>E (FSM=
 Error)<o:p></o:p></span></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>E
  (FSM Error)<o:p></o:p></span></p>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Keep-<o:p></o:p></span=
></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>alive<o:p></o:p></span=
></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Timer
  expires<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  / Ignore<o:p></o:p></span></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  Error) <o:p></o:p></span></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  error)<o:p></o:p></span></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>(FSM
  error)<o:p></o:p></span></p>
  <p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><span
  style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><o:p></o:p></span></p=
>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Open
  Confirm/ Q<o:p></o:p></span></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Established/
  <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Q<o:p></o:p></span></p=
>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Keep-alive
  message <o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/ Ignore<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  / Ignore<o:p></o:p></span></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<span style=3D"mso-spacerun: yes">=A0 </span>D<o:p></o:p></span></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E (FSM error)<o:p></o:p></span></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>D
  <o:p></o:p></span></p>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Established<o:p></o:p>=
</span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>P<o:p></o:p></span></p=
>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Established/
  <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>P<o:p></o:p></span></p=
>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Update
  message<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / Ignore<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  / <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D<o:p></o:p></span></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /E (FSM error)<o:p></o:p></span></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D<o:p></o:p></span></p>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E (FSM error)<o:p></o:p></span></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Established
  / Process Update<o:p></o:p></span></p>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><span
  style=3D"mso-spacerun: yes">=A0</span>Notifi-cation<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Received<o:p></o:p></s=
pan></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D<o:p></o:p></span></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D <o:p></o:p></span></p>
  <p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><span
  style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><o:p></o:p></span></p=
>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D<o:p></o:p></span></p>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>D<o:p></o:p></span></p=
>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / d<o:p></o:p></span></p>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Update
  message error<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/ Ignore<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle/
  Ignore<o:p></o:p></span></p>
  </td>
  <td width=3D72 valign=3Dtop style=3D'width:.75in;border-top:none;border-le=
ft:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D<o:p></o:p></span></p>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E<o:p></o:p></span></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D<o:p></o:p></span></p>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / E<o:p></o:p></span></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>U<o:p></o:p></span></p=
>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Manual
  stop<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  /<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>C<o:p></o:p></span></p=
>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle/<o:p></o:p></span=
></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>C<o:p></o:p></span></p=
>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle/<o:p></o:p></span=
></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>C<o:p></o:p></span></p=
>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle/<o:p></o:p></span=
></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>C<o:p></o:p></span></p=
>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  / <o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>C<o:p></o:p></span></p=
>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  / c<o:p></o:p></span></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  / c<o:p></o:p></span></p>
  </td>
 </tr>
 <tr>
  <td width=3D67 valign=3Dtop style=3D'width:.7in;border:solid windowtext=
 .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt=
 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Auto
  stop<o:p></o:p></span></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Ignore<o:p></o:p></spa=
n></p>
  </td>
  <td width=3D60 valign=3Dtop=
 style=3D'width:45.0pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/<o:p></o:p></span></p>
  <p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><span
  style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><o:p></o:p></span></p=
>
  </td>
  <td width=3D72 valign=3Dtop=
 style=3D'width:.75in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold/<o:p></o:p></span></p>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>D<o:p></o:p></span></p=
>
  </td>
  <td width=3D65 valign=3Dtop=
 style=3D'width:48.95pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold /<span style=3D"mso-spacerun: yes">=A0 </span>S<o:p></o:p></span></p>
  </td>
  <td width=3D61 valign=3Dtop=
 style=3D'width:45.8pt;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / D<o:p></o:p></span></p>
  </td>
  <td width=3D78 valign=3Dtop=
 style=3D'width:58.25pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext=
 .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / S<o:p></o:p></span></p>
  </td>
  <td width=3D96 valign=3Dtop=
 style=3D'width:1.0in;border-top:none;border-left:none;
  border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid=
 windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Idle
  Hold / S<o:p></o:p></span></p>
  <p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><span
  style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><o:p></o:p></span></p=
>
  </td>
 </tr>
</table>

<p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><![if=
 !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></p>

<span style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:"Times=
 New Roman";
mso-fareast-font-family:"Times New=
 Roman";mso-ansi-language:EN-US;mso-fareast-language:
EN-US;mso-bidi-language:AR-SA'><br clear=3Dall=
 style=3D'mso-special-character:line-break;
page-break-before:always'>
</span>

<p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;mso-bidi-font-size:12.0=
pt'>Actions<o:p></o:p></span></p>

<p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><![if=
 !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
A<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>initialize
all BGP resources<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>start
Connect retry timer<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>3.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>initiate
transport connection to BGP peer<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>4.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>listen
for connection set-up by remote BGP peer<o:p></o:p></span></p>

<p class=3DMsoNormal><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><![if=
 !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
B<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>ConnectRetryCnt
set to 0<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
A<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
C<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>release
all BGP resources<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>ConnectRetryCnt
set to 0<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>3.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>connect
retry timer =3D 0 <o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action<span
style=3D"mso-spacerun: yes">=A0 </span>D<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>IDLE
hold time =3D 2**(connectRetryCnt)*60<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>ConnectRetryCnt
=3D+1<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>3.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>connect
retry timer =3D 0<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>4.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Delete
BGP resources<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>5.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Drop
TCP connection<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
E<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Send
Notification (FSM Error)<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
D<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
F<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>clear
ConnectRetry timer<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>complete
BGP initialization<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>3.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>send
Open message<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>4.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Hold
timer =3D Large value (4 minutes<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
G<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>restart
ConnectRetry timer<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>listen
for BGP peer connection<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
H<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>restart
ConnectRetry timer<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>start
TCP connection<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>3.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>listen
for TCP connection<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
I<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Send
Notification with BGP Header Error<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
D<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action<span
style=3D"mso-spacerun: yes">=A0 </span>J<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Send
Notification with Open message error<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
D<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
K<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>IP
address unconfigured turns into temporary peer entry<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
F<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
L<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>reject
TCP connection<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
M<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Send
Notification with Hold Timer Expired<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
D<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
N<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Send
KEEPALIVE message<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>If
negotiated Hold time value is non, zero <o:p></o:p></span></p>

<p class=3DMsoNormal=
 style=3D'margin-left:1.25in;text-indent:-.25in;mso-list:l0 level3 lfo3;
tab-stops:list 1.25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Wingdings'>=A7<span style=3D'font:7.0p=
t "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>set
Keepalive timer<o:p></o:p></span></p>

<p class=3DMsoNormal=
 style=3D'margin-left:1.25in;text-indent:-.25in;mso-list:l0 level3 lfo3;
tab-stops:list 1.25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Wingdings'>=A7<span style=3D'font:7.0p=
t "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Hold
timer reset to negotiated Hold time value (section=
 4.2)<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>3.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>if
negotiated Hold time value is zero,<o:p></o:p></span></p>

<p class=3DMsoNormal=
 style=3D'margin-left:1.25in;text-indent:-.25in;mso-list:l0 level3 lfo3;
tab-stops:list 1.25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Wingdings'>=A7<span style=3D'font:7.0p=
t "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>reset
Keepalive timer<o:p></o:p></span></p>

<p class=3DMsoNormal=
 style=3D'margin-left:1.25in;text-indent:-.25in;mso-list:l0 level3 lfo3;
tab-stops:list 1.25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Wingdings'>=A7<span style=3D'font:7.0p=
t "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>reset
Hold timer<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>4.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>If
value of Autonomous System field is the same as the local Autonomous system
number, set the connection is an internal connection; otherwise it is
=93enternal=94.<span style=3D"mso-spacerun: yes">=A0 </span>(This impacts=
 Update
processing)<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
O<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Close
BGP connection<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>restart
ConnectRetry Timer<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>3.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>continue
listening for BGP connection<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
P<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Restart
Hold timer<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
Q<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Send
Keepalive message<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>restart
KEEPALIVE timer<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
R<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Send
notification with Hold timer expired<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
T<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
S<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Send
Notification with Cease<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
T<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
T<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
D<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Delete
routes<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in;mso-list:=
l0 level1 lfo3;
tab-stops:list .25in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Symbol'>=B7<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
U<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>1.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Send
notification with Update error <o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.75in;text-indent:-.25in;mso-list:=
l0 level2 lfo3;
tab-stops:list .75in'><![if !supportLists]><span style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'>2.<span style=3D'font:7.0pt "Times New=
 Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span=
 style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'>Action
T<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span=
 style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'><![if=
 !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span=
 style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt'><![if=
 !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></p>

</div>

</body>

</html>

--=====================_11077658==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

--=====================_11077658==_--

Date: Wed, 07 Nov 2001 16:34:56 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: FSM changes - the colored text version
Sender: [email-masked]

--=====================_10783455==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Here's a set of text with Red color on those FSM words
that have changed.

Sue

--------------

Idle state:

Initially BGP is in the 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.

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.

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 = 2**(ConnectRetryCnt)*60
-       Increment ConnectRetryCnt by 1,
-       Set connect retry timer to zero,
-       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.
[Note: Jeff Haas thinks that operators would want manual start to do 
something different.]

In response to any other event (initiated by the system or operator), the 
local system:
-       IdleHoldtimer = 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 = 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.

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 = 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 = 0,
-       Connect retry timer = 0, and
-       transition to Idle state.

If any other NOTIFICATION is received, the local system:
-       IdleHoldtimer = 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 = 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 = 2**(ConnectRetryCnt)*60
-       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 = 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 = 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,
-       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 = 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 = 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 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 = 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 = 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:
-       sends a NOTIFICATION with Cease,
-       sets IdleHoldtimer = 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 = 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
-       deletes all routes.

--=====================_10783455==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Here's a set of text with Red color on those FSM words<br>
that have changed.<br>
<br>
<br>
Sue<br>
<br>
--------------<br>
<br>
<b>Idle state: <br>
<br>
</b><font face="Times New Roman, Times">Initially BGP is in the Idle
state.&nbsp;&nbsp; <br>
<br>
</font><font face="Times New Roman, Times" color="#FF0000">A manual start
event is a start event initiated by an operator.&nbsp; An automatic start
event is a start event generated by the system.<br>
<br>
</font><font face="Times New Roman, Times">In this state BGP refuses all
incoming BGP connections.&nbsp; No resources are allocated to the
peer.&nbsp;&nbsp;&nbsp; In response to a Start event
(</font><font face="Times New Roman, Times" color="#FF0000">manual or
automatic</font><font face="Times New Roman, Times">), the local
system:</font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">initializes
all BGP resources, </font><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">starts
the ConnectRetry timer, </font><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">initiates
a transport connection to the other BGP peer, </font>
</dl>
</dl><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">listens
for a connection that may be initiated by the remote BGP peer, and<br>
</font><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">changes
its state to connect.<br>
<br>
The exact value of the ConnectRetry timer is a local matter, but it
should be sufficiently large to allow TCP
initialization.</font><font face="Times New Roman, Times" color="#FF0000">&nbsp;&nbsp;
<br>
<br>
</font><font face="Times New Roman, Times">Any other event received in
the IDLE state, is ignored.<br>
<br>
<b>IdleHold state:<br>
<br>
</b></font><font face="Times New Roman, Times" color="#FF0000">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.&nbsp;&nbsp; This “IdleHold timeout” prevents persistent
flapping of a BGP peering session. <br>
<br>
Upon entering the Idle Hold state, if the IdleHoldTimer exceeds the local
limit the “Keep Idle” flag is set.&nbsp;&nbsp;&nbsp; <br>
<br>
Upon receiving a Manual start, the local system:</font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">clears
the IdleHoldtimer, </font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">clears
“keep Idle” flag</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">initializes
all BGP resources, </font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">starts
the ConnectRetry timer,<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">initiates
a transport connection to the other BGP peer,<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">listens
for a connection that may be initiated by the remote BGPPeer, and<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">changes
its state to connect.<br>
<br>
Upon receiving a IdleHoldtimer expired event, the local system checks to
see that the Keep Idle flag is set.&nbsp; If the Keep Idle flag is set,
the system stays in the “Idle Hold” state. <br>
If the Keep Idle flag is not set, the local system: </font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">clears
the IdleHoldtimer, </font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">and
transitions the state to Idle. <br>
<br>

</dl>
</dl>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. <br>
<br>
Any other event received in the IdleHold state is ignored.<br>
<br>
</font><font face="Times New Roman, Times"><b>Connect State:<br>
<br>
</b>In this state, BGP is waiting for the transport protocol connection
to be completed.<br>
<br>
If the transport connection succeeds, the local system:</font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">clears
the ConnectRetry timer, </font><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">completes
initialization,</font><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">send
an Open message to its peer,</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">set
Hold timer to a large value,&nbsp; and </font><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">changes
its state to Open Sent.&nbsp; <br>
<br>

</dl>
</dl>A hold timer value of 4 minutes is suggested.<br>
<br>
If the transport protocol connection fails (e.g., retransmission
timeout), the local system:</font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">restarts
the ConnectRetry timer, </font><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">continues
to listen for a connection that may be initiated by the remote BGP peer,
and </font><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">changes
its state to Active. <br>
<br>

</dl>
</dl>In response to the ConnectRetry timer expired event, the local
system: <br>
-&nbsp;&nbsp;&nbsp;&nbsp; restarts the ConnectRetry timer, </font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">initiates
a transport connection to the other BGP peer, </font>
</dl>
</dl><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">continues
to listen for a connection that may be initiated by the remote BGP peer,
and</font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">stays
in Connect state.<br>
<br>

</dl>
</dl>The start event (manual or automatic) is ignored in the Connect
state.<br>
<br>
</font><font face="Times New Roman, Times" color="#FF0000">In response to
any other event (initiated by the system or operator), the local
system:</font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">IdleHoldtimer
= 2**(ConnectRetryCnt)*60</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Increment
ConnectRetryCnt by 1,</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Set
connect retry timer to zero,</font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Drops
TCP connection, <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Releases
all BGP resources, and <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Goes
to IdleHoldstate<br>
<br>
<br>
</font><font face="Times New Roman, Times"><b>Active State:<br>
<br>
</b>In this state BGP is trying to acquire a peer by listening for and
accepting a transport protocol connection.&nbsp; <br>
<br>
If the transport connection succeeds, the local system:</font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">clears
the ConnectRetry timer, </font><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">completes
the initialization, </font><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">sends
the Open message to it’s peer, </font>
</dl>
</dl><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">sets
its Hold timer to a large value, <br>
</font><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">and
changes its state to OpenSent.&nbsp; <br>
<br>
A Hold timer value of 4 minutes is suggested.&nbsp; <br>
<br>
In response the ConnectRetry timer expired event, the local
system:</font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">restarts
the ConnectRetry timer,</font><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">initiates
a transport connection to the other BGP peer,</font><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">continues
to listen for connection that may be initiated by remote BGP peer,
</font>
</dl>
</dl><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">and
changes its state to Connect. <br>
<br>
If the local system does not allow BGP connections with unconfigured
peers, then the local system:</font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">rejects
connections from IP addresses that are not configured peers,
</font><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">and
remains in the Active state.<br>
<br>

</dl>
</dl>The start events
</font><font face="Times New Roman, Times" color="#FF0000">(initiated by
the system or operator)</font><font face="Times New Roman, Times"> are
ignored in the Active state.<br>
[Note: Jeff Haas thinks that operators would want manual start to do
something different.]<br>
<br>
In response to any other event (initiated by the system or operator), the
local system:</font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">IdleHoldtimer
= 2**(ConnectRetryCnt)*60</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Increment
ConnectRetryCnt by 1,</font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Set
connect retry timer to zero, and </font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Drops
TCP connection, </font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Releases
all BGP resources,<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Goes
to IdleHold state.<br>
<br>
<br>
</font><font face="Times New Roman, Times"><b>Open Sent:<br>
<br>
</b>In this state BGP waits for an Open Message from its peer.&nbsp; When
an OPEN message is received, all fields are check for correctness.&nbsp;
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:</font>
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times">sends
a NOTIFICATION message</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">IdleHoldtimer
= 2**(ConnectRetryCnt)*60</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Increment
ConnectRetryCnt by 1,</font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Set
connect retry timer to zero, and <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Drops
TCP connection, <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Releases
all BGP resources,<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Times New Roman, Times" color="#FF0000">Goes
to IdleHold state.<br>
<br>
<br>
</font>If there are no errors in the OPEN message, the local system:
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sends
a KEEPALIVE message and</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
a KeepAlive timer (via the text
below)</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">set
the Hold timer according to the negotiated value (see section 4.2),
</font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">set
the state to Open Confirm.<br>
<br>
</font>If the negotiated Hold time value is zero, then the Hold Time
timer and KeepAlive timers are not started.&nbsp;&nbsp; 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.&nbsp;&nbsp; (This will
<font color="#FF0000">impact </font>UPDATE processing as described
below.)&nbsp; <br>
<br>
If a disconnect NOTIFICATION is received from the underlying transport
protocol, the local system:
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>closes
the BGP connection, <font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>restarts
the Connect Retry timer, <font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>and
continues to listen for a connection that may be initiated by the remote
BGP peer, and goes into Active state.<br>
<br>

</dl>
</dl>If the Hold Timer expires, the local system:
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>send
a NOTIFICATION message with error code Hold Timer
Expired,<font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">IdleHoldtimer
= 2**(ConnectRetryCnt)*60</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increment
ConnectRetryCnt by 1,</font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Set
connect retry timer to zero, and <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
TCP connection, <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources, and <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHold state</font>. <br>
<br>
The Start event (manual and automatic) is ignored in the OpenSent
state.<br>
<br>
<font color="#FF0000">If a NOTIFICATION message is received with a
version error, the local system:</font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Closes
the transport connection</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
BGP resources, </font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">ConnectRetryCnt
= 0, </font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Connect
retry timer = 0, and<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">transition
to Idle state.<br>
<br>
If any other NOTIFICATION is received, the local system: </font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">IdleHoldtimer
= 2**(ConnectRetryCnt)*60</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increment
ConnectRetryCnt by 1,</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Set
connect retry timer to zero, and </font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
TCP connection, <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources,<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHold state.<br>
<br>
In response to any other event, the local system:</font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sends
the NOTFICATION message with Error Code Finite State Machine&nbsp;
Error,</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">IdleHoldtimer
= 2**(ConnectRetryCnt)*60</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increment
ConnectRetryCnt by 1,</font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Set
connect retry timer to zero,<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
TCP connection, <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources, and <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHold state.<br>
<br>
</font><b>Open Confirm State<br>
<br>
</b>In this state BGP waits for a KEEPALIVE or NOTIFICATION 
message.<br>
<br>
If the local system receives a KEEPALIVE message, it changes its state to
Established.&nbsp; <br>
<br>
<font color="#FF0000">If the Hold Timer expires before a KEEPALIVE
message is received, the local system:</font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">send
the NOTIFICATION message with the error code Hold Timer
Expired,</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
IdleHoldTimer =
2**(ConnectRetryCnt)*60</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increments
ConnectRetryCnt by 1,</font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Sets
the connect retry timer to zero,<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drop
the TCP connection, <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources,<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHoldState.<br>
<br>
If the local system receives a NOTIFICATION message or receives a
disconnect NOTIFICATION from the underlying transport protocol, the local
system:&nbsp; </font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Sets
IdleHold Timer =
2**(ConnectRetryCnt)*60</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increments
ConnectRetryCnt by 1,</font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Sets
the connect retry timer to zero,</font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
the TCP connection,</font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources,<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHoldstate.<br>
<br>
In response to the Stop event initiated by the system, the local
system:</font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sends
the NOTIFICATION message with 
Cease,</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
IdleHoldtimer =
2**(ConnectRetryCnt)*60</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increments
ConnectRetryCnt by 1,</font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Sets
the Connect retry timer to zero,<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
the TCP connection, <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources, <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHoldstate.<br>
<br>
<br>
</font><font color="#FF6600">In response to a Stop event initiated by the
operator, the local system: </font>
<dl>
<dl><font size=4 color="#FF6600">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF6600">sends
the NOTIFICATION message with Cease,
</font><font size=4 color="#FF6600">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF6600">releases
all BGP resources</font><font size=4 color="#FF6600">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF6600">sets
the ConnectRetryCnt to zero</font>
</dl>
</dl><font size=4 color="#FF6600">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF6600">sets
the connect retry timer to 0<br>
</font><font size=4 color="#FF6600">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF6600">transitions
to Idle state.<br>
<br>
</font>The Start event is ignored in the OpenConfirm state.<br>
<br>
<font color="#FF6600">In response to any other event, the local
system:</font>
<dl>
<dl><font size=4 color="#FF6600">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF6600">sends
a NOTIFICATION with a code of Finite State Machine
Error,</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
IdleHoldtimer =
2**(ConnectRetryCnt)*60</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increments
ConnectRetryCnt by 1,</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Sets
the Connect retry timer to zero,</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
the TCP connection, </font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources, <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHoldstate.<br>
<br>
</font><b>Established State:<br>
<br>
</b>In the Established state BGP can exchange UPDATE, NOTFICATION, and
KEEPALIVE messages with its peer.<br>
<br>
If the local system receives an UPDATE or KEEPALIVE message, it restarts
its Hold Timer, if the negotiated Hold Time value is non-zero.&nbsp;
<br>
<br>
<font color="#FF6600">If the local system receives a NOTIFICATION message
or a disconnect from the underlying transport protocol, it:<br>
</font>-&nbsp;&nbsp;&nbsp; <font color="#FF0000">sets IdleHoldtimer =
2**(ConnectRetryCnt)*60, </font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increments
ConnectRetryCnt by 1,</font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Sets
the Connect retry timer to zero,</font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
the TCP connection, </font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources, and&nbsp;&nbsp; <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHoldstate.<br>
<br>
</font>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:
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>sends
a NOTIFICATION message with Update error,<font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
IdleHoldtimer =
2**(ConnectRetryCnt)*60</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increments
ConnectRetryCnt by 1,</font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Sets
the Connect retry timer to zero,<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
the TCP connection, <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources, and <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHoldstate.<br>
</font><font size=4>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
</font>If the Hold timer expires, the local system:
<dl>
<dl><font size=4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>sends
a NOTIFICATION message with Error Code Hold Timer
Expired,<font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
IdleHoldtimer = 2**(ConnectRetryCnt)*60</font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Increments
ConnectRetryCnt by 1,<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Sets
the connect retry timer to zero,<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Drops
the TCP connection,<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Releases
all BGP resources,&nbsp; <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">Goes
to IdleHold state.<br>
<br>
</font>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.<br>
<br>
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.<br>
<br>
<font color="#FF0000">In response to the Stop event initiated by the
system (automatic), the local system:</font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sends
a NOTIFICATION with Cease, </font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
IdleHoldtimer =
2**(ConnectRetryCnt)*60</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">increments
ConnectRetryCnt by 1,</font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
the connect retry timer to zero,<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">drops
the TCP connection, <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">releases
all BGP resources, <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">goes
to IdleHold state, and <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">deletes
all routes.<br>
<br>
An example automatic stop event is exceeding the number of prefixes for a
given peer and the local system automatically disconnecting the
peer.<br>
<br>
In response to a stop event initiated by an operator:</font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">release
all resources (including deleting all
routes),</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">set
ConnectRetryCnt to zero (0),</font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">set
connect retry timer to zero (0), and</font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">transition
to the Idle.<br>
<br>

</dl>
</dl>The Start event is ignored in the Established state.<br>
<br>
In response to any other event, the local system:</font>
<dl>
<dl><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sends
a NOTIFICATION message with Error Code Finite State Machine
Error,</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
IdleHoldtimer =
2**(ConnectRetryCnt)*60</font><font size=4 color="#FF0000">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">increments
ConnectRetryCnt by 1,</font>
</dl>
</dl><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">sets
the connect retry timer to zero,<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">drops
the TCP connection, <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">releases
all BGP resources<br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">goes
to IdleHoldstate, and <br>
</font><font size=4 color="#FF0000">-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font color="#FF0000">deletes
all routes.<br>
<br>
</font><br>
</html>

--=====================_10783455==_.ALT--

Date: Wed, 07 Nov 2001 16:33:54 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: FSM changes for the Draft-15 
Cc: jeffrey Haas <[email-masked]>, Yakov Rekhter <[email-masked]>
Sender: [email-masked]

At the last IDR meeting in London, John Scudder proposed that
we cut the State machine.   I objected to this removal since "no state machine"
means interoperability problems between BGP implementations.
If router vendor A  changes their implementation (or puts a bug) in the state
machine there is no "standard" to hold them to.

I would like to first ask the working group if they want to remove the
state machine or take fixes to the State machine.  I really think we
should take fixes so we do not have interoperability issues.

I'd like 2nd to ask that the working group accepts this FSM rewrite.

I've re-written the state machine to be a bit cleaner in text.
The Idle state had two sub-states so I cleaned this up by making each
of these states a different text (Idle and Idle Hold)

Here are changes to the draft-15 FSM to make the FSM a bit clear.

I will post a color version of this text for people who want to see what 
text is new.
I'll also post a word document and htm file with a state table for each
of these states.

Thanks,

Sue Hares
desk: (734)222-1610
main: (734)222-1600

[email-masked]

----------------------
Idle state:

Initially BGP is in the 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.

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.

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 = 2**(ConnectRetryCnt)*60
-       Increment ConnectRetryCnt by 1,
-       Set connect retry timer to zero,
-       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.
[Note: Jeff Haas thinks that operators would want manual start to do 
something different.]

In response to any other event (initiated by the system or operator), the 
local system:
-       IdleHoldtimer = 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 = 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.

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 = 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 = 0,
-       Connect retry timer = 0, and
-       transition to Idle state.

If any other NOTIFICATION is received, the local system:
-       IdleHoldtimer = 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 = 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 = 2**(ConnectRetryCnt)*60
-       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 = 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 = 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,
-       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 = 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 = 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 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 = 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 = 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:
-       sends a NOTIFICATION with Cease,
-       sets IdleHoldtimer = 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 = 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
-       deletes all routes.

Date: Tue, 6 Nov 2001 17:52:48 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: MIB question - atomic aggregate
Sender: [email-masked]

MIB implementors,

draft-08 of the BGP MIB (version 1) is about to be released.
The following text is somewhat ambiguous.  Please clarify what
your implementations do:

        bgp4PathAttrAtomicAggregate OBJECT-TYPE
            SYNTAX     INTEGER {
                           lessSpecificRouteNotSelected(1), 
                           lessSpecificRouteSelected(2)
                       }
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION
                    "Whether or not a system has selected
                     a less specific route without
                     selecting a more specific route."
            ::= { bgp4PathAttrEntry 9 }

This could be read as "the local system" - i.e. it is a calculated value -
or "a remote system" - i.e. some peer has set ATOMIC_AGGREGATE on their
route.

-- 
Jeff Haas 
NextHop Technologies

Date: Mon, 5 Nov 2001 12:10:46 -0500
From: Jeffrey Haas <[email-masked]>
To: Russ White <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-15, section 9 suggestions
Sender: [email-masked]

On Fri, Nov 02, 2001 at 09:18:10AM -0500, Russ White wrote:
> Why not just: "The selection process is formalized by defining a
> function that take the attribute of a given route as an argument
> and returns a non-negative integer denoting the degree of
> preference for the route. A preference of 0 indicates the route
> should not be considered in the next phase of route selection."

As I've had pointed out to me a couple of times, we shouldn't
dictate implementation decisions. :-)

> Same meaning, but kill off the duplicate 'return.'

Removed.

> Why not just: "If the BGP speaker is in the forwarding
> path...." Which implies that this route is in the speaker's
> rib. Or be more explicit, and state that if this route is
> installed in the speaker's rib.

Because a 3-rd party nexthop may be advertised in which case
"In Loc-Rib" or "in the Routing Table" isn't sufficient.

> Russ

-- 
Jeff Haas 
NextHop Technologies

To: Edward Crabbe <[email-masked]>
Cc: Dan Pei <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: draft-15, section 9 suggestions
From: Kaarthik Sivakumar <[email-masked]>
Date: 02 Nov 2001 16:47:19 -0500
Lines: 30
Sender: [email-masked]

Hi Ed

>>> "EC" == Edward Crabbe <[email-masked]> writes:
EC> Kaarthik,

EC> This was my initial reaction too, but a withdraw must be sent so that
EC> ibgp peers who had this route advertised to them will think 
EC> it is still valid if/when the current best route is
EC> with withdrawn.  

Agreed. Also Dan Pei's reply about LOCAL_PREF resulting in the best
route being chosen differently in different iBGP peers also shows that
this requires a WITHDRAW of the eBGP route.

EC> This was formerly handled as follows:

EC> 9.2.1;2,ii:

EC> ii) if a replacement route is not available for advertisement,
EC>          then the BGP speaker shall include the destinations of the
EC>          unfeasible route (in form of IP prefixes) in the WITHDRAWN
EC>          ROUTES field of an UPDATE message, and shall send this message
EC>          to each peer to whom it had previously advertised the
EC>          corresponding feasible route.

EC> As DanP pointed out to me, this section is no longer in existance
EC> due to the removal of internal/external distintion in the
EC> proposed text.

Kaarthik

To: Dan Pei <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, <[email-masked]>
Subject: Re: draft-15, section 9 suggestions
From: Kaarthik Sivakumar <[email-masked]>
Date: 02 Nov 2001 16:42:10 -0500
Lines: 22
Sender: [email-masked]

Dan,

>>> "DP" == Dan Pei <[email-masked]> writes:
>> Since all iBGP peers are expected to be fully meshed, if a peer
>> receives a better route from its iBGP peer then it can expect that all
>> its iBGP peers have received that better route from the same iBGP
>> peer. So all iBGP peers will then choose the right route and there is
DP>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
DP> I am not sure if this will always happen,  since the local_pref might be
DP> recomputed by other iBGP peers,  according to 9.1.1:

DP>    "If the route is
DP>    learned from an internal peer, either the value of the LOCAL_PREF
DP>    attribute shall be taken as the degree of preference, or the local
DP>    system may compute the degree of preference of the route based on
DP>    preconfigured policy information. Note that the latter (computing the
DP>    degree of preference based on preconfigured policy information) may
DP>    result in formation of persistent routing loops."

Yes, that is true. My mistake..

Kaarthik

From: Greg Mirsky <[email-masked]>
To: "'Kaarthik Sivakumar'" <[email-masked]>, Dan Pei <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: RE: draft-15, section 9 suggestions
Date: Fri, 2 Nov 2001 16:40:52 -0500 
Sender: [email-masked]

Kaathrik,
perhaps you've ment to say "all eBGP speakers expected to be fully meshed".
I can't recall any such requirement or recomendation in regard to iBGP.

	Thanks,
		Greg

-----Original Message-----
From: Kaarthik Sivakumar [mailto:[email-masked]]
Sent: Friday, November 02, 2001 4:16 PM
To: Dan Pei
Cc: Jeffrey Haas; [email-masked]
Subject: Re: draft-15, section 9 suggestions

Hi Dan

>>> "DP" == Dan Pei <[email-masked]> writes:
>> On Fri, Nov 02, 2001 at 01:28:53AM -0800, Dan Pei wrote:
>> > Also, I am worrying about the following problem:
>> >
>> > A speaker has advertised an eBGP route to its iBGP peers, but later the
>> > speaker chooses a new route learned from an iBGP peer, the speaker
shall
>> > send a withdraw message to withraw the old eBGP route.

DP> sorry, what I tried to say is that the speaker shall send a withdraw
DP> message to its IBGP PEERS to withdraw the eBGP route it advertised
before,
DP> since the speaker has chosen a route learned from an iBGP peer and shall
DP> not re-distribute this iBGP route.  (Otherwise, other iBGP peers
DP> might still think the old eBGP route still available via this speaker)

Since all iBGP peers are expected to be fully meshed, if a peer
receives a better route from its iBGP peer then it can expect that all
its iBGP peers have received that better route from the same iBGP
peer. So all iBGP peers will then choose the right route and there is
no need to withdraw the eBGP route. Isnt that right?

Kaarthik

Date: Fri, 2 Nov 2001 13:43:24 -0800 (PST)
From: Edward Crabbe <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: draft-15 comments
Sender: [email-masked]

Jeffrey,

> /* Phase 2 */
> Lock all Adj-RIBs-In;
> Select most preferable routes for each destination in all Adj-RIBs-In and
> run tie-breaking process on this set.  This will yield, for each
> destination, one route for each destination.
> 
> Install the selected routes for each destination into Loc-Rib.
> 
> Remove unfeasible routes from Loc-Rib;
> Unlock all Adj-RIBs-In;

I'm not sure what you mean by unfeasible here?

but:  

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

If this is what you mean:
Unfeasible routes should never make it into loc-rib.

ta,
	-ed 

Date: Fri, 2 Nov 2001 13:35:17 -0800 (PST)
From: Dan Pei <[email-masked]>
To: Kaarthik Sivakumar <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, <[email-masked]>
Subject: Re: draft-15, section 9 suggestions
Sender: [email-masked]

Hi, Kaarthik,

On 2 Nov 2001, Kaarthik Sivakumar wrote:

> Hi Dan
>
> DP> sorry, what I tried to say is that the speaker shall send a withdraw
> DP> message to its IBGP PEERS to withdraw the eBGP route it advertised before,
> DP> since the speaker has chosen a route learned from an iBGP peer and shall
> DP> not re-distribute this iBGP route.  (Otherwise, other iBGP peers
> DP> might still think the old eBGP route still available via this speaker)
>
> Since all iBGP peers are expected to be fully meshed, if a peer
> receives a better route from its iBGP peer then it can expect that all
> its iBGP peers have received that better route from the same iBGP
> peer. So all iBGP peers will then choose the right route and there is
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I am not sure if this will always happen,  since the local_pref might be
recomputed by other iBGP peers,  according to 9.1.1:

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

> no need to withdraw the eBGP route. Isnt that right?

Thanks,
---
Dan

Date: Fri, 2 Nov 2001 13:34:12 -0800 (PST)
From: Edward Crabbe <[email-masked]>
To: Kaarthik Sivakumar <[email-masked]>
Cc: Dan Pei <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: draft-15, section 9 suggestions
Sender: [email-masked]

Kaarthik,

> DP> sorry, what I tried to say is that the speaker shall send a withdraw
> DP> message to its IBGP PEERS to withdraw the eBGP route it advertised before,
> DP> since the speaker has chosen a route learned from an iBGP peer and shall
> DP> not re-distribute this iBGP route.  (Otherwise, other iBGP peers
> DP> might still think the old eBGP route still available via this speaker)
> 
> Since all iBGP peers are expected to be fully meshed, if a peer
> receives a better route from its iBGP peer then it can expect that all
> its iBGP peers have received that better route from the same iBGP
> peer. So all iBGP peers will then choose the right route and there is
> no need to withdraw the eBGP route. Isnt that right?

This was my initial reaction too, but a withdraw must be sent so that
ibgp peers who had this route advertised to them will think 
it is still valid if/when the current best route is
with withdrawn.  

This was formerly handled as follows:

9.2.1;2,ii:

ii) if a replacement route is not available for advertisement,
         then the BGP speaker shall include the destinations of the
         unfeasible route (in form of IP prefixes) in the WITHDRAWN
         ROUTES field of an UPDATE message, and shall send this message
         to each peer to whom it had previously advertised the
         corresponding feasible route.

As DanP pointed out to me, this section is no longer in existance
due to the removal of internal/external distintion in the
proposed text.

	-ed

To: Dan Pei <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, <[email-masked]>
Subject: Re: draft-15, section 9 suggestions
From: Kaarthik Sivakumar <[email-masked]>
Date: 02 Nov 2001 16:16:23 -0500
Lines: 23
Sender: [email-masked]

Hi Dan

>>> "DP" == Dan Pei <[email-masked]> writes:
>> On Fri, Nov 02, 2001 at 01:28:53AM -0800, Dan Pei wrote:
>> > Also, I am worrying about the following problem:
>> >
>> > A speaker has advertised an eBGP route to its iBGP peers, but later the
>> > speaker chooses a new route learned from an iBGP peer, the speaker shall
>> > send a withdraw message to withraw the old eBGP route.

DP> sorry, what I tried to say is that the speaker shall send a withdraw
DP> message to its IBGP PEERS to withdraw the eBGP route it advertised before,
DP> since the speaker has chosen a route learned from an iBGP peer and shall
DP> not re-distribute this iBGP route.  (Otherwise, other iBGP peers
DP> might still think the old eBGP route still available via this speaker)

Since all iBGP peers are expected to be fully meshed, if a peer
receives a better route from its iBGP peer then it can expect that all
its iBGP peers have received that better route from the same iBGP
peer. So all iBGP peers will then choose the right route and there is
no need to withdraw the eBGP route. Isnt that right?

Kaarthik

Date: Fri, 2 Nov 2001 12:52:36 -0800 (PST)
From: Dan Pei <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-15, section 9 suggestions
Sender: [email-masked]

Hi, Jeffrey,

On Fri, 2 Nov 2001, Jeffrey Haas wrote:

> On Fri, Nov 02, 2001 at 01:28:53AM -0800, Dan Pei wrote:
> > Also, I am worrying about the following problem:
> >
> > A speaker has advertised an eBGP route to its iBGP peers, but later the
> > speaker chooses a new route learned from an iBGP peer, the speaker shall
> > send a withdraw message to withraw the old eBGP route.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
sorry, what I tried to say is that the speaker shall send a withdraw
message to its IBGP PEERS to withdraw the eBGP route it advertised before,
since the speaker has chosen a route learned from an iBGP peer and shall
not re-distribute this iBGP route.  (Otherwise, other iBGP peers
might still think the old eBGP route still available via this speaker)

>
> Thats fine.  MinRouteAdver dampens the external fluctuations that you'd
> see from this.

Thanks,
--
Dan

Date: Fri, 2 Nov 2001 14:18:33 -0500
From: Jeffrey Haas <[email-masked]>
To: Edward Crabbe <[email-masked]>
Cc: Dan Pei <[email-masked]>, Susan Hares <[email-masked]>, [email-masked]
Subject: Re: draft-15 comments
Sender: [email-masked]

On Thu, Nov 01, 2001 at 03:33:39PM -0800, Edward Crabbe wrote:
> This means that in effect you will be running through phase2
> with the routes for internal update in question regardless of 
> the jump to 9.2.1...

That is correct.

I note that a slight wording change between 1771 and the current draft
implies that we should only run through the decision process but NOT
do the installation in Loc-Rib.

Another wording vaguery (see the pseudo-code I posted) also seems to
imply that we don't do a batch processing of the Adj-RIBs-In, rather
we might do this over for each Adj-RIB-In.
E.g.:
We determine for each new or changed route a degree of preference.
We then check to see if its the new best.
We then send it to internal peers if appropriate at this point.

We probably really meant:
determine for each new or changed route a degree of preference.
When done assigning degree of preference to all the Adj-RIBs-In
then determine the best one and whether we send it.

> you want to make sure the route is at least installed in loc-rib
> prior to advertisement (with the admittedly fairly large assumption
> (at least with some vendors implementations) that the route
> will be installed in the fib soon after) to avoid unpleasant
> loops or blackholes...

The path that takes us there is to proceed through the whole
process for internal advertisements as external.  

The real question is this:
We process the Adj-RIBs-In.  We go through all the work (fewer times
in the optimized case above) of determining which is the best route.
We send the stuff to internal peers, update Adj-RIBs-Out for the
internal peers.

We then proceed to deal with everything again, hopefully having
cached the best-route selected.  We actually select it into Loc-Rib.
We then advertise it into Adj-Ribs-Out to the rest of the external peers.

At the end of this round of things, we _still_ send things to the
external peers.

If we were to process our route queue for our internal peers to
take special effort to converge those first prior to re-advertisement
to external peers, we'd see the benefit at the cost of potentially
starving external peers if we're not careful.  But this isn't what
is documented.

One could argue that by using the same process for each peer type
(internal/external), yes, you would choose the "wrong" route to
advertise to your external peers and send that out.  But if you're
implmenting your MinRouteAdver timer then you should wait that
time prior to sending a new advertisement for that.  In that time,
you should have converged on the right answer no matter what.

Can someone clarify a scenario where receiving your internal updates
sooner would speed things up, especially if you're using a "route flash"
model of running your updates?  My eyes may be clouded by our 
implementation.

> Perhaps further alteration is in order. I had originally thought
> that the text would simply be altered for the sake of clarity.

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 2 Nov 2001 14:29:27 -0500
From: Jeffrey Haas <[email-masked]>
To: Dan Pei <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-15, section 9 suggestions
Sender: [email-masked]

On Fri, Nov 02, 2001 at 01:28:53AM -0800, Dan Pei wrote:
> Also, I am worrying about the following problem:
> 
> A speaker has advertised an eBGP route to its iBGP peers, but later the
> speaker chooses a new route learned from an iBGP peer, the speaker shall
> send a withdraw message to withraw the old eBGP route.

Thats fine.  MinRouteAdver dampens the external fluctuations that you'd
see from this.

You would also end up in this situation on the original model of
"send external updates to internal peers first" depending on the
ordering and delay of messages in your routing system.

> A more general problem: if a replacement route is excluded from being
> installed in a particular Adj-RIB-Out, while the previous feasible route
> has been sent out , a withdraw message shall be sent to the peer
> associated with this Adj-RIB-Out.

That is true, but is a policy decision.
In general, one should apply policy to the Adj-Rib-Out for external
peers and policy that affects internal peers at the Adj-Rib-In->Loc-Rib
side of things.

> So, how about change the beginning of section 9.2 to:

>    All the routes in Loc-RIB newly marked as unfeasible shall be advertised
>    as unfeasible routes to each peer to whom the speaker had previously
>    advertised the corresponding feasible route. These unfeasible routes
>    shall be removed from Adj-RIBs-Out after correspondng UPDATE messages
>    have been sent.
> 
>    Each route newly installed into Loc-RIB but excluded from being
>    installed into one particular Adj-RIB-Out shall be advertised as
>    an unfeasible route to the peer associated with this Adj-RIB-Out, if
>    the speaker had previously advertised the corresponding feasible route
>    to this peer. The previously advertised feasible route shall be removed
>    from Adj-RIBs-Out after correspondng update messages have been sent.

I think this comes back to a private conversation I had with someone
regarding how policy is reflected in the RIB abstraction model.

Routes can be altered at ingress and at egress from the routing system.
This can be represented by changes to the route in the Adj-Rib-In
on ingress.  Policy on routes on import that exclude them from
becoming active simply reflects on the Loc-Rib.
When advertising routes, the changes are made potentially on a per
Adj-Rib-Out basis - and the same goes for policy.

This somewhat implies that the Adj-Rib-Out should have what
we are actually advertising, or the lack of something and that
we need to know if that is reflected in the messages we've actually
sent to the peer.

I'm not sure how to reflect this in the abstraction model.
Ramesh Govindan had some nice comments about these issues in his
old paper on Route Server design.

>    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."
> 
> Thanks,
> ---
> Dan
> 
> 
> 

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 2 Nov 2001 13:27:30 -0500
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-15, suggested changes to collision resolution
Sender: [email-masked]

This will work.  Thanks.

On Fri, Nov 02, 2001 at 10:08:18AM -0800, Yakov Rekhter wrote:
> How about replacing the first three paragraphs in 6.8
> with the following:
> 
>    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 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:
> 
> Yakov.
> 

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 2 Nov 2001 13:22:39 -0500
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-15 comments
Sender: [email-masked]

On Thu, Nov 01, 2001 at 04:47:24PM -0800, Yakov Rekhter wrote:
> Wrong. It is noted in the sentence that immediately preceeds the
> one you quoted above in 4.1:
[...]
> 
> 
> With this in mind, I see no need to copy the sentence from 6.1 here.

My mistake.  Thanks.

> Yakov.

-- 
Jeff Haas 
NextHop Technologies

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-15, suggested changes to collision resolution 
Date: Fri, 02 Nov 2001 10:08:18 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff,

> I'm not precisely happy with the OSI'isms here, but this seems
> a bit better.  Other suggestions?

How about replacing the first three paragraphs in 6.8
with the following:

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

Yakov.

Date: Fri, 2 Nov 2001 11:19:04 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked], [email-masked]
Subject: draft-15, suggested changes to collision resolution
Sender: [email-masked]

I'm not precisely happy with the OSI'isms here, but this seems
a bit better.  Other suggestions?

6.8 Connection collision detection.

   Each BGP peering session is identified by the tuple of the local
   transport address and the remote transport address.

   In order to provide resiliency in the peering sessions between
   two BGP speakers, those speakers may peer with each other over
   multiple transport connections.

   If a pair of BGP speakers try simultaneously to establish a TCP
   connection to each other using the same transport address
   endpoints, then two parallel connections between this pair of
   speakers might well be formed. We refer to this situation as
   connection collision. Clearly, 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 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 for a given BGP peering session tuple
   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, then the
   local system performs the following collision resolution procedure:

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 2 Nov 2001 10:53:50 -0500
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-15 comments
Sender: [email-masked]

Yakov,

On Thu, Nov 01, 2001 at 01:32:36PM -0800, Yakov Rekhter wrote:
> Because I don't understand what is inaccurate (from the technical,
> not editorial point of view) with the current text.

Lets make sure we are on the same page.  The pseudo-code below is
my interpretation of the current specification.  Do you agree?

/* Phase 1 */
For each Adj-RIB-In in Adj-RIBs-In
    Do
	Lock Adj-RIB-In;
        For each Route in Adj-RIB-In
	    Do
		Calculate degree of preference on Route;

		If (Route is from an external peer and 
		    Route is the best route from the tie breaking process)
		    Do
			Distribute route to all internal peers using
			Calculated degree of preference as LOCAL_PREF;

			Set Adj-RIB-Out for internal peers to be Route;
		    Done
	    Done
	Unlock Adj-RIB-In;
    Done

/* Phase 2 */
Lock all Adj-RIBs-In;
Select most preferable routes for each destination in all Adj-RIBs-In and
run tie-breaking process on this set.  This will yield, for each
destination, one route for each destination.

Install the selected routes for each destination into Loc-Rib.

Remove unfeasible routes from Loc-Rib;
Unlock all Adj-RIBs-In;

/* Phase 3 */
Block until Phase 2 is not running;

For each item that has changed in Loc-Rib
    Do
	Update Adj-Ribs-Out;
	Update FIB;
    Done

Distribute changes to Adj-RIBs-Out to external peers

> Yakov.

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 2 Nov 2001 09:18:10 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-15, section 9 suggestions
Sender: [email-masked]

> : 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.
> : 
> :    The selection process is formalized by defining a function that takes
> :    the attribute of a given route as an argument and returns a non-
> :    negative integer denoting the degree of preference for the route.
> 
> Change to:
> "The selection process is formalized by defining a function that takes 
>  the attribute of a given route as an argument and returns either:
> 
>  o A non-negative integer denoting the degree of preference for the route
> 
>    - or -
> 
>  o Returns a value denoting that this route is ineligible to be installed 
>    in LocRib and will be excluded from the next phase of route selection."

Why not just: "The selection process is formalized by defining a
function that take the attribute of a given route as an argument
and returns a non-negative integer denoting the degree of
preference for the route. A preference of 0 indicates the route
should not be considered in the next phase of route selection."

which seems simpler?

If you do go with the wording suggested here, then change the
second bullet to: "A value denoting this route is ineligible to
be installed in the LocRib and will be excluded from the next
phase of route selection."

Same meaning, but kill off the duplicate 'return.'

> :    For each newly received or replacement feasible route, the local BGP
> :    speaker shall determine a degree of preference. 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
> :    and uses it as the LOCAL_PREF value in any IBGP readvertisement.  The
> :    exact nature of this policy information and the computation involved
> :    is a local matter. For a route learned from an external peer, the
> :    local speaker shall then run the internal update process of 9.2.1 to
> :    select and advertise the most preferable route.
> 
> Change to:
> "For each newly received or replacement feasible route, the local BGP
>  speaker shall determine a degree of preference:
> 
>  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.

These should be bullets, rather than paragraphs.

> :    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 present in the Adj-RIBs-In, including those received
> :    from both internal and external peers.
> 
> Change to:
> "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, i.e. they have a non-negative
>  degree of preference."

Which implies that the degree of preference should be negative if
the route shouldn't be used. Since we've already stated that the
degree of preference should be non-negative above, I'd suggest
(as I suggested above) that we use 0 to mean this route is
ineligible.

> :    All routes in the Loc-RIB shall be processed into a corresponding
> :    entry in the associated Adj-RIBs-Out. Route aggregation and
> :    information reduction techniques (see 9.2.4.1) may optionally be
> :    applied.
> 
> Change to:
> "All routes in the Loc-RIB shall be procesed 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.  If the BGP speaker
>  is involved in the forwarding path for a particular route,

Why not just: "If the BGP speaker is in the forwarding
path...." Which implies that this route is in the speaker's
rib. Or be more explicit, and state that if this route is
installed in the speaker's rib.

>  then the 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.
> 
>  Route aggregation and information reduction techniques (see 9.2.4.1)
>  may optionally be applied."
> 
> I am attempting to convey in the first paragraph that it is acceptable
> to have a less specific network present in the FIB that covers a 
> more specific route and has the appropriate NEXT_HOP.

It might be better to just make this explicit....

:-)

Russ

_____________________________
[email-masked] <>< Grace Alone

Date: Fri, 2 Nov 2001 02:09:44 -0800 (PST)
From: Edward Crabbe <[email-masked]>
To: Dan Pei <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: draft-15, section 9 suggestions
Sender: [email-masked]

in the same vein:

9.1

:       c) Phase 3 is invoked after the Loc-RIB has been modified. It is
:       responsible for disseminating routes in the Loc-RIB to each
:       external peer, according to the policies contained in the PIB.
        ^^^^^^^^
:       Route aggregation and information reduction can optionally be
:       performed within this phase.

> ...
> 
> >    As part of Phase 3 route selection process, the BGP speaker has
>                         ^^^^^^^^^^ phase 3 route dissemination process?
> 
> >    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 external peers by means of UPDATE message.
>                             ?????? we also need to send to internal peers?

Date: Thu, 1 Nov 2001 19:31:10 -0500
From: Jeffrey Haas <[email-masked]>
To: Russ White <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: draft-15 comments
Sender: [email-masked]

On Thu, Nov 01, 2001 at 04:13:15PM -0500, Russ White wrote:
> Wouldn't bgp speakers imply the underlying tcp connection/etc.?
> Why not?

+-----+    +-----+
| R1  |====| R2  |
|     |====|     |
+-----+    +-----+

R1 and R2 peer with each other over two separate external links
(thus R1 is in AS1 and R2 is in AS2).

R1 and R2 are both BGP speakers.
Typically, R1 and R2 do not run separate instances of BGP for each link,
i.e. we're talking about two speakers, not four.

There are two network endpoints for each of the two peering sessions.
A collision could happen on each of them.
The collision resolution shouldn't be looking at all peering
sessions between the two boxes - rather it should be paying attention
to the ones at the same network endpoints.

> Russ

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 2 Nov 2001 01:28:53 -0800 (PST)
From: Dan Pei <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: <[email-masked]>
Subject:  Re: draft-15, section 9 suggestions
Sender: [email-masked]

Jeffrey,
	some comments on the last change in your message:

On Thu, 1 Nov 2001, Jeffrey Haas wrote:
...

> "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 route selection process, the BGP speaker has
                        ^^^^^^^^^^ phase 3 route dissemination process?

>    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 external peers by means of UPDATE message.
                            ?????? we also need to send to internal peers?

Also, withdrawn message shall be sent only to "each peer to whom it had
previously advertised the corresponding feasible route".

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

Also, I am worrying about the following problem:

A speaker has advertised an eBGP route to its iBGP peers, but later the
speaker chooses a new route learned from an iBGP peer, the speaker shall
send a withdraw message to withraw the old eBGP route.

A more general problem: if a replacement route is excluded from being
installed in a particular Adj-RIB-Out, while the previous feasible route
has been sent out , a withdraw message shall be sent to the peer
associated with this Adj-RIB-Out.

So, how about change the beginning of section 9.2 to:

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

   A BGP speaker shall not re-distribute the routing information contained
   in the UPDATE message received from an internal peer to other internal
   peers, unless the speaker acts as a BGP Route Reflector [11].

   As part of Phase 3 route dissemination process, the BGP speaker has
   updated its Adj-RIBs-Out and its Routing table.

   All the routes newly installed into Adj-RIBs-Out shall be advertised
   to corresponding peers by means of UPDATE message.

   All the routes in Loc-RIB newly marked as unfeasible shall be advertised
   as unfeasible routes to each peer to whom the speaker had previously
   advertised the corresponding feasible route. These unfeasible routes
   shall be removed from Adj-RIBs-Out after correspondng UPDATE messages
   have been sent.

   Each route newly installed into Loc-RIB but excluded from being
   installed into one particular Adj-RIB-Out shall be advertised as
   an unfeasible route to the peer associated with this Adj-RIB-Out, if
   the speaker had previously advertised the corresponding feasible route
   to this peer. The previously advertised feasible route shall be removed
   from Adj-RIBs-Out after correspondng update messages have been sent.

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

Thanks,
---
Dan

Date: Thu, 1 Nov 2001 18:02:46 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: draft-15, section 9 suggestions
Sender: [email-masked]

Apologies for the length of this message.  I am supplying all sections
from draft-15 that are being updated to provide in-depth context for
the changes.

I'm attempting to address three specific issues here:
1. Policy must allow routes to not be selected into LocRib from
   Adj-Ribs-In and similarly from LocRib to Adj-Ribs-Out.
2. When the BGP speaker is participating in the forwarding path,
   it must not place anything in Adj-Ribs-Out unless LocRib matches
   the active route in the Routing Table.  The Routing Table is
   distinct from the FIBs.
3. There is no need for an "internal updates" section.

: 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.
: 
:    The selection process is formalized by defining a function that takes
:    the attribute of a given route as an argument and returns a non-
:    negative integer denoting the degree of preference for the route.

Change to:
"The selection process is formalized by defining a function that takes 
 the attribute of a given route as an argument and returns either:

 o A non-negative integer denoting the degree of preference for the route

   - or -

 o Returns 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 internal peers
: 
:       - selection of routes to be advertised to external peers

Change the previous two bullet items to:

"- 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, and MAY also advertise to all
:       the internal peers the routes from external peers that have the
:       highest degree of preference for each distinct destination.

Change to: 
"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
:       external 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.
: 
:    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. 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
:    and uses it as the LOCAL_PREF value in any IBGP readvertisement.  The
:    exact nature of this policy information and the computation involved
:    is a local matter. For a route learned from an external peer, the
:    local speaker shall then run the internal update process of 9.2.1 to
:    select and advertise the most preferable route.

Change to:
"For each newly received or replacement feasible route, the local BGP
 speaker shall determine a degree of preference:

 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 present in the Adj-RIBs-In, including those received
:    from both internal and external peers.

Change to:
"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, i.e. they have a non-negative
 degree of preference."

:    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
:    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.
: 
: 
: 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.
: 
: 
: 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 = all routes still under consideration
:                 for n = all routes still under consideration
:                     if (neighborAS(m) == 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 = all routes still under consideration
:                 for n = 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.
: 
: 
: 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
: 
:       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 a corresponding
:    entry in the associated Adj-RIBs-Out. Route aggregation and
:    information reduction techniques (see 9.2.4.1) may optionally be
:    applied.

Change to:
"All routes in the Loc-RIB shall be procesed 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.  If the BGP speaker
 is involved in the forwarding path for a particular route,
 then the 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.

 Route aggregation and information reduction techniques (see 9.2.4.1)
 may optionally be applied."

I am attempting to convey in the first paragraph that it is acceptable
to have a less specific network present in the FIB that covers a 
more specific route and has the appropriate NEXT_HOP.

:    When the updating of the Adj-RIBs-Out and the Routing Table is
:    complete, the local BGP speaker shall run the external update process
:    of 9.2.2.

Change to:
"When the updaing 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.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.
:    Rules for information exchange between BGP speakers located in
:    different autonomous systems are given in 9.2.2; rules for
:    information exchange between BGP speakers located in the same
:    autonomous system are given in 9.2.1.
: 
:    Distribution of routing information between a set of BGP speakers,
:    all of which are located in the same autonomous system, is referred
:    to as internal distribution.
: 
: 
: 9.2.1 Internal Updates
: 
: 
:    The Internal update process is concerned with the distribution of
:    routing information to internal peers.
: 
:    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].
: 
:    When a BGP speaker receives a new route from an external peer, it
:    MUST advertise that route to all other internal peers by means of an
:    UPDATE message if this route will be installed in its Loc-RIB
:    according to the route selection rules in 9.1.2.
: 
:    When a BGP speaker receives an UPDATE message with a non-empty
:    WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all
:    routes whose destinations were carried in this field (as IP
:    prefixes).  The speaker shall take the following additional steps:
: 
:       1) if the corresponding feasible route had not been previously
:       advertised, then no further action is necessary
: 
:       2) if the corresponding feasible route had been previously
:       advertised, then:
: 
:          i) If a new route for the same NLRI is selected for
:          advertisement, then the BGP speaker shall advertise the
:          replacement route
: 
:          ii) if a replacement route is not available for advertisement,
:          then the BGP speaker shall include the destinations of the
:          unfeasible route (in form of IP prefixes) in the WITHDRAWN
:          ROUTES field of an UPDATE message, and shall send this message
:          to each peer to whom it had previously advertised the
:          corresponding feasible route.
: 
: 
:    All feasible routes which are advertised shall be placed in the
:    appropriate Adj-RIBs-Out, and all unfeasible routes which are
:    advertised shall be removed from the Adj-RIBs-Out after the
:    corresponding update messages have been sent.
: 
: 9.2.2 External Updates
: 
: 
:    The external update process is concerned with the distribution of
:    routing information to external peers.  As part of Phase 3 route
:    selection process, the BGP speaker has updated its Adj-RIBs-Out and
:    its Routing Table. All newly installed routes and all newly
:    unfeasible routes for which there is no replacement route shall be
:    advertised to external peers by means of UPDATE message.
: 
:    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 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 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 external peers by means of UPDATE message.

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

-- 
Jeff Haas 
NextHop Technologies

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-15 comments 
Date: Thu, 01 Nov 2001 16:47:24 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff,

> On Wed, Oct 31, 2001 at 04:38:36PM -0800, Yakov Rekhter wrote:
> > > : 4.1 Message Header Format
> > > 
> > > [...]
> > > 
> > > :          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.
> > > 
> > > Pullup from Section 6.1
> > > 
> > > "The Marker field should be all ones if the OPEN messages carried
> > > no authentication information."
> > 
> > what is exactly the problem here ?
> 
> The only spot in draft-15 where the marker is noted as all-1's in
> the absence of authentication is in the message header error handling.

Wrong. It is noted in the sentence that immediately preceeds the
one you quoted above in 4.1:

     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
         between a pair of BGP peers, and to authenticate incoming BGP
         messages.

With this in mind, I see no need to copy the sentence from 6.1 here.

Yakov.

Date: Thu, 1 Nov 2001 15:33:39 -0800 (PST)
From: Edward Crabbe <[email-masked]>
To: Dan Pei <[email-masked]>
Cc: Susan Hares <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: draft-15 comments
Sender: [email-masked]

Dan,

> The internal updates are required to be sent in Phase 1(9.1.1), which
> jumps to 9.2.1 to send the update "if this route will be installed in its
> Loc-RIB according to the route selection rules in 9.1.2(which is phase
> 2)".
> 
> It seems to me that the internal update is sent out before the route is
> actually installed in Loc-RIB(in Phase 2). Since anyway the selection
> rules in phase 2 is run, the only difference here seems to be the
> overhead to install the route into Loc-RIB.

This means that in effect you will be running through phase2
with the routes for internal update in question regardless of 
the jump to 9.2.1...

I don't believe this wording is dangerous in the sense you imply,
simply a bit cumbersome.

> And it seems to me  there might be some potential danger to advertise a
> route before the speaker really install it, although I donot have a
> concrete example right now.

you want to make sure the route is at least installed in loc-rib
prior to advertisement (with the admittedly fairly large assumption
(at least with some vendors implementations) that the route
will be installed in the fib soon after) to avoid unpleasant
loops or blackholes...

> But we can definitely keep the original draft text if it reflects the
> practice, provided we improve the text to be clearer.

Perhaps further alteration is in order. I had originally thought
that the text would simply be altered for the sake of clarity.

Date: Thu, 1 Nov 2001 14:37:59 -0800 (PST)
From: Dan Pei <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, <[email-masked]>
Subject: Re: draft-15 comments
Sender: [email-masked]

Susan,

> Dan and Jeff:
>
> Are we really sure that internal updates and external updates are
> in the same position?
>
> Is it common practice that internal and external updates occur
> at the same time instead of  internal 1st and then external?
>
> The original thoughts on BGP indicated convergence problems would
> occur if that ordering were common.  The experimentation results
> indicate a mixed bag.  Perhaps Yakov has more comments.

I definitely agree on that sending internal updates before sending
external update will help convergence within one AS. But what's confusing
to me in the draft text is the exact time when internal updates are sent:

The internal updates are required to be sent in Phase 1(9.1.1), which
jumps to 9.2.1 to send the update "if this route will be installed in its
Loc-RIB according to the route selection rules in 9.1.2(which is phase
2)".

It seems to me that the internal update is sent out before the route is
actually installed in Loc-RIB(in Phase 2). Since anyway the selection
rules in phase 2 is run, the only difference here seems to be the
overhead to install the route into Loc-RIB.

And it seems to me  there might be some potential danger to advertise a
route before the speaker really install it, although I donot have a
concrete example right now.

Are there any other practical reasons to send internal update in phase
one, instead of sending it in phase 3(but before sending external update)?

But we can definitely keep the original draft text if it reflects the
practice, provided we improve the text to be clearer.

Thanks,

--
Dan

Date: Thu, 01 Nov 2001 15:52:57 -0500
To: Dan Pei <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: draft-15 comments
Cc: Jeffrey Haas <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Dan and Jeff:

Are we really sure that internal updates and external updates are
in the same position?

Is it common practice that internal and external updates occur
at the same time instead of  internal 1st and then external?

The original thoughts on BGP indicated convergence problems
would occur if that ordering were common.   The experimentation
results indicate a mixed bag.   Perhaps Yakov has more comments.

The same comments will transfer to the rest of the text.

Sue

At 11:48 AM 11/1/2001 -0800, Dan Pei wrote:
>Jeffrey,
>
> > : 9.1.1 Phase 1: Calculation of Degree of Preference
> >
> > [...]
> >
> > :    is a local matter. For a route learned from an external peer, the
> > :    local speaker shall then run the internal update process of 9.2.1 to
> > :    select and advertise the most preferable route.
> >
> > 9.2.1 says goto 9.1.2 rules.  Why do we even jump here?
> > This point was brought up before.
> > Why aren't we fixing it?
>
>Maybe because it will be a not-so-small change to fix it.:-)
>
>I would agree with your suggestion in one of your ealier message:
>
>"I believe we are going to end up with a new draft that moves internal
>updates to the same spot as external updates. "
>
>
>If people also agree with this, here are the things in my mind that need
>to be changed to achieve that:
>
>1. combine 9.2.1(Internal Updates) and 9.2.2(External Updates) into one
>section, with a rule that an route learned from internal peer shall never
>be re-distributed to other internal peers.
>(exact text to be proposed:-) )
>
>2. Section 9.1:
>....
>
>|    ... 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.
>what if there is a tie?
>
>changed to:
>     followed by the choice of the best one according to the route
>     selection rules in 9.1.2.
>
>
>|   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 internal peers
>|
>|      - selection of routes to be advertised to external peers
>
>combine above two into:
>        - selection of routes to be advertised to internal and external
>          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,
>
>remove the rest of a)?
>
>|.... and MAY also advertise to all
>|      the internal peers the routes from external peers that have the
>|      highest degree of preference for each distinct destination.
>|
>|      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
>|      external peer, according to the policies contained in the PIB.
>change to:
>        peer, according to the policies contained in the PIB. Note that
>        an route learned from internal peer shall never be re-distributed
>        to other internal peers unless the speaker acts as a BGP Route
>        Reflector [11].
>
>|      Route aggregation and information reduction can optionally be
>|      performed within this phase.
>
>
>3. remove the last sentence of section 9.1.1:
>
>"For a route learned from an external peer, the
>    local speaker shall then run the internal update process of 9.2.1 to
>    select and advertise the most preferable route."
>
>
>4. last sentence of section 9.1.3:
>
>|   When the updating of the Adj-RIBs-Out and the Routing Table is
>|   complete, the local BGP speaker shall run the external update process
>|   of 9.2.2.
>
>change to:
>
>    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.
>
>
>5.
>
>|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.
>|   Rules for information exchange between BGP speakers located in
>|   different autonomous systems are given in 9.2.2; rules for
>|   information exchange between BGP speakers located in the same
>|   autonomous system are given in 9.2.1.
>|
>|   Distribution of routing information between a set of BGP speakers,
>|   all of which are located in the same autonomous system, is referred
>|   to as internal distribution.
>
>change to:
>
>    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.
>
>    An route learned from internal peer shall never be re-distributed
>    to other internal peers unless the local speaker acts as a BGP Route
>    Reflector [11].
>
>
>
>Thanks,
>
>---
>Dan

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-15 comments 
Date: Thu, 01 Nov 2001 13:32:36 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff,

> :    is a local matter. For a route learned from an external peer, the
> :    local speaker shall then run the internal update process of 9.2.1 to
> :    select and advertise the most preferable route.
> 
> 9.2.1 says goto 9.1.2 rules.  Why do we even jump here?
> This point was brought up before.  Why aren't we fixing it?

Because I don't understand what is inaccurate (from the technical,
not editorial point of view) with the current text.

Yakov.

Date: Thu, 1 Nov 2001 16:13:15 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: draft-15 comments
Sender: [email-masked]

> > > > > : 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. We refer to this situation as
> >  connection collision. Clearly, one of these connections must be
> >  closed.
> 
> "BGP speakers" isn't sufficient because it doesn't address
> the different network layer endpoints.

Wouldn't bgp speakers imply the underlying tcp connection/etc.?
Why not?

:-)

Russ

_____________________________
[email-masked] <>< Grace Alone

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-15 comments 
Date: Thu, 01 Nov 2001 12:24:25 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff,

> Yakov,
> 
> On Thu, Nov 01, 2001 at 11:14:47AM -0800, Yakov Rekhter wrote:
> > > > > : 4.1 Message Header Format
> > > > > Pullup from Section 6.1
> > > > > 
> > > > > "The Marker field should be all ones if the OPEN messages carried
> > > > > no authentication information."
> > 
> > Do you want me to repeat the same sentence here (in 4.1) ?
> 
> Yes. :-)

Ok, I'll repeat it.

> > > It is also present in 4.3(e) (second section)
> > 
> > yes.
> 
> And its going to be removed?

yes.

> > > > > : 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. We refer to this situation as
> >  connection collision. Clearly, one of these connections must be
> >  closed.
> 
> "BGP speakers" isn't sufficient because it doesn't address the
> different network layer endpoints.
> 
> I'm still looking for suggested wording.  I'll ask around in-house as well.

Ok, but bear in mind that you need to provide the appropriate
wording no late than Nov 14.

Yakov.

Date: Thu, 1 Nov 2001 14:54:59 -0500
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-15 comments
Sender: [email-masked]

Yakov,

On Thu, Nov 01, 2001 at 11:14:47AM -0800, Yakov Rekhter wrote:
> > > > : 4.1 Message Header Format
> > > > Pullup from Section 6.1
> > > > 
> > > > "The Marker field should be all ones if the OPEN messages carried
> > > > no authentication information."
> 
> Do you want me to repeat the same sentence here (in 4.1) ?

Yes. :-)

> > It is also present in 4.3(e) (second section)
> 
> yes.

And its going to be removed?

> > > > : 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. We refer to this situation as
>  connection collision. Clearly, one of these connections must be
>  closed.

"BGP speakers" isn't sufficient because it doesn't address the
different network layer endpoints.

I'm still looking for suggested wording.  I'll ask around in-house as well.

> Yakov.

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 1 Nov 2001 11:48:24 -0800 (PST)
From: Dan Pei <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-15 comments
Sender: [email-masked]

Jeffrey,

> : 9.1.1 Phase 1: Calculation of Degree of Preference
>
> [...]
>
> :    is a local matter. For a route learned from an external peer, the
> :    local speaker shall then run the internal update process of 9.2.1 to
> :    select and advertise the most preferable route.
>
> 9.2.1 says goto 9.1.2 rules.  Why do we even jump here?
> This point was brought up before.
> Why aren't we fixing it?

Maybe because it will be a not-so-small change to fix it.:-)

I would agree with your suggestion in one of your ealier message:

"I believe we are going to end up with a new draft that moves internal
updates to the same spot as external updates. "

If people also agree with this, here are the things in my mind that need
to be changed to achieve that:

1. combine 9.2.1(Internal Updates) and 9.2.2(External Updates) into one
section, with a rule that an route learned from internal peer shall never
be re-distributed to other internal peers.
(exact text to be proposed:-) )

2. Section 9.1:
....

|    ... 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.
what if there is a tie?

changed to:
    followed by the choice of the best one according to the route
    selection rules in 9.1.2.

|   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 internal peers
|
|      - selection of routes to be advertised to external peers

combine above two into:
       - selection of routes to be advertised to internal and external
         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,

remove the rest of a)?

|.... and MAY also advertise to all
|      the internal peers the routes from external peers that have the
|      highest degree of preference for each distinct destination.
|
|      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
|      external peer, according to the policies contained in the PIB.
change to:
       peer, according to the policies contained in the PIB. Note that
       an route learned from internal peer shall never be re-distributed
       to other internal peers unless the speaker acts as a BGP Route
       Reflector [11].

|      Route aggregation and information reduction can optionally be
|      performed within this phase.

3. remove the last sentence of section 9.1.1:

"For a route learned from an external peer, the
   local speaker shall then run the internal update process of 9.2.1 to
   select and advertise the most preferable route."

4. last sentence of section 9.1.3:

|   When the updating of the Adj-RIBs-Out and the Routing Table is
|   complete, the local BGP speaker shall run the external update process
|   of 9.2.2.

change to:

   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.

5.

|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.
|   Rules for information exchange between BGP speakers located in
|   different autonomous systems are given in 9.2.2; rules for
|   information exchange between BGP speakers located in the same
|   autonomous system are given in 9.2.1.
|
|   Distribution of routing information between a set of BGP speakers,
|   all of which are located in the same autonomous system, is referred
|   to as internal distribution.

change to:

   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.

   An route learned from internal peer shall never be re-distributed
   to other internal peers unless the local speaker acts as a BGP Route
   Reflector [11].

Thanks,

---
Dan

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-15 comments 
Date: Thu, 01 Nov 2001 11:14:47 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff,

> > > : 4.1 Message Header Format
> > > 
> > > [...]
> > > 
> > > :          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.
> > > 
> > > Pullup from Section 6.1
> > > 
> > > "The Marker field should be all ones if the OPEN messages carried
> > > no authentication information."
> > 
> > what is exactly the problem here ?
> 
> The only spot in draft-15 where the marker is noted as all-1's in
> the absence of authentication is in the message header error handling.
> This seems to be an appropriate place to note this.

Do you want me to repeat the same sentence here (in 4.1) ?

> > > : 4.3 UPDATE Message Format
> > > 
> > > [...]
> > > 
> > > :    An UPDATE message is used to advertise a single feasible route to a
> > > :    peer, or to withdraw multiple unfeasible routes from service (see
> > > :    3.1). An UPDATE message may simultaneously advertise a feasible route
> > > 
> > > "advertise feasible routes sharing common path attributes"
> > > 
> > > Without this, we imply that you send one destination in 3.1 and later
> > > we send multiple destinations.
> > 
> > Bear in mind that "the destination is the systems whose IP
> > addresses are reported in the Network Layer Reachability Information
> > (NLRI) field", and the NLRI field could contain one or more prefixes.
> > 
> > With this in mind, what is exactly the problem ?
> 
> : 3.1 Routes: Advertisement and Storage
> : 
> :    For purposes of this protocol a route is defined as a unit of
> :    information that pairs a destination with the attributes of a path to
> :    that destination, where the destination is 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 fields of the same UPDATE message.
> 
> My problem is that "destination" is being overloaded to be a plural.
> This goes against common usage of the word.
> 
> Changing 3.1 as follows would address that concern and make changing 4.3
> unnecessary:
> 
> "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."
> 
> With this text, 4.3's "single feasible route" now includes a definition
> of multiple destinations and matches common usage of destination.
> 
> Is this acceptable?

Yes.

> 
> > > LOCAL_PREF is listed as "mandatory" throughout the document but
> > > doesn't meet this condition.
> > 
> > I removed "mandatory" from the first sentence in 5.1.5.
> 
> It is also present in 4.3(e) (second section)

yes.

> [version negotiation]
> > Here is the proposed text:
> > 
> >    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
> >    number is greater than the version the remote BGP peer bid, then
> >    the smallest locally supported version number.
> 
> This will work.

ok.

> > > : 6.8 Connection collision detection.
> > > 
> > > [...]
> > > 
> > > I will note that this entire section precluds multiple peering
> > > sessions across different interfaces for purposes of redundancy
> > > or traffic engineering.
> > 
> > Could you point me to the specific text in this section that
> > precludes multiple peering sessions ?
> 
> This is mostly an error of ommission:
> 
> : If a pair of BGP speakers try simultaneously to establish a TCP
> : connection to each other, then two parallel connections between this
> : pair of speakers might well be formed. We refer to this situation as
> : connection collision. Clearly, one of these connections must be
> : closed.
> 
> This implies to me that we are talking about two routers trying
> to establish any TCP connection to each other.  Further on, we only
> talk about using the fact that the speaker is making a connection
> to another speaker and using the BGP Identifier to decide which
> end of the two transport connections to close.
> 
> In practice, what we really mean is that we are establishing one
> or more peering sessions between two BGP speakers.  Each peering
> session will have the same BGP Identifier, however they will
> be distinguishable based on the IP address of each peering session
> endpoint.
> 
> Clearly this applies only when we're talking about peering over
> an interface rather than peering over a loopback and thus
> is probably only applicable to external peering sessions.
> 
> Anyone on IDR have a suggested fix for this section?

How about the following:

 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. We refer to this situation as
 connection collision. Clearly, one of these connections must be
 closed.

Yakov.

Date: Thu, 1 Nov 2001 10:47:43 -0500
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-15 comments
Sender: [email-masked]

On Wed, Oct 31, 2001 at 04:38:36PM -0800, Yakov Rekhter wrote:
> > : 4.1 Message Header Format
> > 
> > [...]
> > 
> > :          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.
> > 
> > Pullup from Section 6.1
> > 
> > "The Marker field should be all ones if the OPEN messages carried
> > no authentication information."
> 
> what is exactly the problem here ?

The only spot in draft-15 where the marker is noted as all-1's in
the absence of authentication is in the message header error handling.
This seems to be an appropriate place to note this.

> > : 4.3 UPDATE Message Format
> > 
> > [...]
> > 
> > :    An UPDATE message is used to advertise a single feasible route to a
> > :    peer, or to withdraw multiple unfeasible routes from service (see
> > :    3.1). An UPDATE message may simultaneously advertise a feasible route
> > 
> > "advertise feasible routes sharing common path attributes"
> > 
> > Without this, we imply that you send one destination in 3.1 and later
> > we send multiple destinations.
> 
> Bear in mind that "the destination is the systems whose IP
> addresses are reported in the Network Layer Reachability Information
> (NLRI) field", and the NLRI field could contain one or more prefixes.
> 
> With this in mind, what is exactly the problem ?

: 3.1 Routes: Advertisement and Storage
: 
:    For purposes of this protocol a route is defined as a unit of
:    information that pairs a destination with the attributes of a path to
:    that destination, where the destination is 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 fields of the same UPDATE message.

My problem is that "destination" is being overloaded to be a plural.
This goes against common usage of the word.

Changing 3.1 as follows would address that concern and make changing 4.3
unnecessary:

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

With this text, 4.3's "single feasible route" now includes a definition
of multiple destinations and matches common usage of destination.

Is this acceptable?

> > LOCAL_PREF is listed as "mandatory" throughout the document but
> > doesn't meet this condition.
> 
> I removed "mandatory" from the first sentence in 5.1.5.

It is also present in 4.3(e) (second section)

[version negotiation]
> Here is the proposed text:
> 
>    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
>    number is greater than the version the remote BGP peer bid, then
>    the smallest locally supported version number.

This will work.

> > : 6.8 Connection collision detection.
> > 
> > [...]
> > 
> > I will note that this entire section precluds multiple peering
> > sessions across different interfaces for purposes of redundancy
> > or traffic engineering.
> 
> Could you point me to the specific text in this section that
> precludes multiple peering sessions ?

This is mostly an error of ommission:

: If a pair of BGP speakers try simultaneously to establish a TCP
: connection to each other, then two parallel connections between this
: pair of speakers might well be formed. We refer to this situation as
: connection collision. Clearly, one of these connections must be
: closed.

This implies to me that we are talking about two routers trying
to establish any TCP connection to each other.  Further on, we only
talk about using the fact that the speaker is making a connection
to another speaker and using the BGP Identifier to decide which
end of the two transport connections to close.

In practice, what we really mean is that we are establishing one
or more peering sessions between two BGP speakers.  Each peering
session will have the same BGP Identifier, however they will
be distinguishable based on the IP address of each peering session
endpoint.

Clearly this applies only when we're talking about peering over
an interface rather than peering over a loopback and thus
is probably only applicable to external peering sessions.

Anyone on IDR have a suggested fix for this section?

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 1 Nov 2001 10:16:25 -0500
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Dan Pei <[email-masked]>, [email-masked]
Subject: Re: draft-15 comments
Sender: [email-masked]

On Thu, Nov 01, 2001 at 06:55:26AM -0800, Yakov Rekhter wrote:
>   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

"follows:"

>   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
>   the NLRI identical to the new route, the new route shall be placed

strike "the" before NLRI?

>   in the Adj-RIB-In. 
> 
>   Once the BGP speaker updates the Adj-RIB-In, the speaker shall run 
>   its Decision Process.

Yes!

> Yakov.

-- 
Jeff Haas 
NextHop Technologies

To: Dan Pei <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: draft-15 comments 
Date: Thu, 01 Nov 2001 06:55:26 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Dan,

> > > : 9. UPDATE Message Handling
> > >
> > > [...]
> > >
> > > :    iii) If the new route has identical path attributes to an earlier
> > > :    route contained in the Adj-RIB-In, and is more specific (see 9.1.4)
> > > :    than the earlier route, no further actions are necessary.
> > >
> > > Then how is it going to end up in LocRib and thus to Adj-Ribs-Out?
> > >
> > > :    v) If the new route is an overlapping route that is less specific
> > > :    (see 9.1.4) than an earlier route contained in the Adj-RIB-In, the
> > > :    BGP speaker shall run its Decision Process on the set of destination
s
> > > :    described only by the less specific route.
> > >
> > > How do we run decision on only the uncovered components?
> ...
> >
> > Please propose the appropriate text that addresses your comments
> > on Section 9.
> 
> My conjecture is that the draft actually requires taking these
> actions(i-iv) in some implicit order.
> 
> BTW, It's clear that i) - v) are specifying whether to run Decision
> Process, and the set of destinations to run Decision Process on. However,
> only v) specifies the set of destinations to run Decision Process on.
> 
> 
> Maybe we could make the conditions of these actions mutual
> exclusive by(if it is right:-):
> 
>         -First deal with the NLRI in the new route itself, run decision
>          process on this NLRI
>                 -if exists in Adj-RIB-In, then replace it,
>                 -otherwise, add it into Adj-RIB-In
> 
>         -Then deal with overlapping NLRI' that is already in Adj-RIB-In
>                 -if NLRI is more specific than NLRI', but same attributes,
>                  no action
> 
>                 -if NLRI is more specific than NLRI', but different
>                 attributes, run decision on (NLRI' - NLRI)?
> 
>                 -if NLRI is less specific than NLRI', but different
>                 attributes,run decision on (NLRI - NLRI')?
> 
>                 -if NLRI is less specific than NLRI', but same attributes,
>                 , no action.

How about if we'll replace i) through v), and the paragraph immediately
before i) with the following two paragraphs:

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

Yakov.