Subject: Comments 11-20

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 Dec 2002 16:27:07 -0500

Siva

Again, thanks for all the comments.
Here's the summary of 11-20

comment:

11 - no consensus, no text supplied  
	
    note: usage varies from my understanding
	    of common usage.

12 - consensus, no text supplied 
     see comment 9 and proposed text below.

13a - no consensus, see alternate text 
13b - no consensus, implementation specific detail

14 - no consensus, disagree with comment
	policy issues, outside scope of document
	
15 - no consensus, see alternative text.
16 - no consensus, see my proposed text.  

	You did not propose text 
      See alternate text for events 13-17
	Also note, that I consider that
	events 13 and 14 should go to 
	optional.

17 - consensus, agree to change in text. 
18 - agree needs to be fixed, see my alternative text.
19 - further clarity needed,
	 please respond to question

20 - agree, text will be changed

So, review the comments and let me know.

Comments 21-30 in the next message.  Thanks for
working so hard on the comments. 

Sue 
 
=====================

11) Event 10 (Hold timer)

  We use the hold timer for two purposes

  * Waiting for an open message (with a default value of 240 seconds)
  * Waiting for Keepalives (with a default value of 90 seconds)

  Can we use two different timers (or at least call them two different
  timer events) ?

Siva: I do not believe that most implementatios
      utilize two timers.  Can you indicate implementations
	that do? 

=======================================================================
12) Event 12

> Event12: DelayBGP Open timer expires [changed]
> 
>	   Definition: A timer that delays sending of the BGP
>	               Open message for n seconds after the
>                       Transport connection has been completed.=

>The Definition seems to better define what the timer is, rather than =
> what
> its expiry means. Can we change it to reflect this ?

new text:  see comment on 9 on Timer definition,
	     and earlier change.

Event 12: An event generated when the Delay BGP Open timer expires.
=========================================

13) Event 13, 14 definition

> Event13: Transport Connection Indication & valid remote peer[changed]
>
>	   Definition: Event indicating that TCP connection
>                       request with a valid source IP address and TCP
>                       port, and valid destination IP address
>                       and TCP Port.  The definition of
>                       invalid Source, and invalid Destination=
>                       IP address is left to the implementation.

a) How about changing this slighty to:
%	   Definition: Event indicating receiving a TCP connection
%                       request with a valid source IP address and TCP
%                       port, and valid destination IP address=
%                       and TCP Port.  The definition of invalid
My completion of  your sentence: 
			 	source, and invalid destination IP address
				is left to the implementation. 

How about:
	Definition: Event indicating the reception of a TCP connection
			request with a valid source IP address and TCP 
			port, and valid destination IP address and
			TCP Port.  The definition of invalid source address
			and port and invalid destination address
			is left to the implementation. 

Please comment if you agree with this change. 

b) Is it correct that Destination IP address validation is used when we
do not wish to accept BGP connections on one of the local IP addresses
(either because we wish to accept such addresses on only our loopback
interfaces, or because the address to which we received the connection
was not the optimal interface with which to speak to the sender) ? If
so, can we add this to the description ?

No, this is an implementation dependent change. 
=================================================================================

14) Event 13,14

> Event13: Transport Connection Indication & valid remote peer[changed]
>
>	   Definition: Event indicating that transport
>                       Request valid source IP address and TCP=20
>                       port, and valid destination IP address=20
>                       and TCP Port.  The definition of=20
>                       invalid Source, and invalid Destination=20
>                       IP address is left to the implementation.
> 
> a) I am unclear as to what validation of source and destination port =
> mean.
> 
> The source port's value should be of no concern to connection =
> receipient system.

	The definition of "valid" is an implementation policy issue. 
	Validating is the process of checking to make sure it is valid
	for the implementation's policy.  

> The destination port cannot be invalid, since BGP would not receive the
> connection request in such a situation.

	Again, this is a policy issue.  We are providing hooks for
	policy to be engaged.  Policy is outside the scope of this
	document. 

> b) I think it will be useful to state what we consider to be an invalid
> IP address.

	Again, it is policy issue which is implementation dependent. 

====================
15) Event 17

> Event17: TCP connection fails

> This event can occur even when the transport connection is closed by
> the other end. Since this does not reflect a 'failure ', can we change
> the event name to
> 
> % Event17: TCP connection termination

Discussion:  It both terminates from the remote site
		 and can "timeout" - fail. 

Suggestions? I can use "disconnect", what do you think. 

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

16) Events related to BGP Messages

Can we make the definition style across these events consistent ?

thanks for the comment.
proposed text below, please agree on it.

proposed text replacement
------------------------
    Event13: TCP connection indication and valid remote peer
   
           Definition: Event indicating the local system reception of 
		       a TCP connection request with a valid source
                       IP address and TCP port, and valid destination
                       IP address and TCP Port. The definition of
                       invalid source, and invalid destination 
                       IP address is left to the implementation.

                       BGP's destination port SHOULD be port 
                       179 as defined by IANA.
   
                       TCP connection request is denoted by
                       the local system receiving a TCP SYN.
   
           Status:     Mandatory (Optional) 

    Event14: RCV TCP connection indication with invalid source or 
             destination
   
           Definition: Event indicating the local system reception of
		       a TCP connection request with either 
                       an invalid source address or port
                       number or an invalid destination 
                       address or port number. 

                       BGP destination port  number SHOULD be 179
                       as defined by IANA.
  
                       Again, a TCP connection request 
                       denoted by local system receiving a TCP
                       SYN.
   
           Status:     Mandatory (Optional) 
   	
    Event15: TCP connection request sent received an ACK.
   
           Definition: Event indicating the Local system's request
                       to establish a TCP connection to the remote
                       peer. 
   
                       The local system's TCP session sent a TCP
                       SYN, and received a TCP SYN, ACK pair of
                       messages, and Sent a TCP ACK.
   
           Status:     Mandatory
   
    Event16: TCP connection confirmed
   
           Definition: Event indicates that the local system receiving
		       a confirmation that the TCP connection has 
                       been established by the remote site. 
   
                       The remote peer's TCP engine sent a TCP SYN.
                       The local peer's TCP engine sent a SYN, ACK
                       pair, and now has received a final ACK.
   
           Status:     Mandatory
   
    Event17: TCP connection fails 
   
           Definition: Event indicates that the local system has
                       received a TCP connection failure notice.
   
                       The remote BGP peer's TCP machine could have
                       sent a FIN.  The local peer would respond
                       with a FIN-ACK. Another alternative is that
                       the local peer indicated a timeout in the
                       TCP session and downed the connection.
   
           Status:     Mandatory

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

17) Event 19 Definition

> Event19: BGPOpen with BGP Delay Open Timer running [changed]
>
>           Definition: An event indicating that a valid Open=20
>                       Message has been successful=20
>                       established for a peer that is=20
>                       currently delaying the sending of an=20
>                       BGP Open message.=20

The definition appears a little fragmented. How about:

% Definition: An event indicating that a valid OPEN
%             Message has been received for a peer
%             that has a successfully established
%             transport connection and is currently
%             delaying the seending of a BGP open
%             message

agreed, changed in text.  I will send out definition
text for review in a separate message. 
==============================================================
18) Event 22 Definition

a)=20

> Event22: Open collision discard
>
>           Definition: An event generated administratively=20
>                       when a connection Collision has been=20
>                       detected while processing an incoming =20
>                       Open message. This connection has been=20

Isn't this event 'automatically' generated, since it is a system
generated event ?=20

response: How this generated is implementation specific.  The
          "administratively" is to cover policy.  

b)

>                       Event 22 is an administrative could=20
>                       occur if FSM is implemented as two=20
>

The word event is missing. How about

%                       Event 22 is an automatic event that
%                       could occur if FSM is implemented as two=20

I've re-written the whole definition.  What do you think about:

   Event22: Open collision dump
   
           Definition: An event generated administratively
                       when a connection collision has been 
                       detected while processing an incoming  
                       OPEN message and this connection has been 
                       selected to disconnected. See Section 
                       6.8 for more information on collision
                       detection.  
   
                       Event22 is an administrative based only
		           implementation specific policy. This 
		           Event may occur if the FSM is implemented
		           as two linked state machines.  
   
Please confirm that you like this. 

====================================
19) FSM Description: ConnectRetry Count

> The Connect Retry count is updated by the FSM but never used. In the
> absence of peer oscillation damping, will this be used to stop
> connection establishment attempts after a certain maximum number ?

	Yes, this is either implementation specific or
	is it based on the peer oscillation damping draft. 

> Can we include the use of this counter in some place ?

	Connect retry counter 
		1) Will be utilized by the peer oscillation damping drat.
		2) Will be included in bgp-4-mibv2-xx.  
			I just check and I didn't find it.

Do you still want text in the main 

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

20) Handling Event 7 (Auto Stop) to Idle State processing:

The handling of Event 7 is missing from the Idle State processing. Can
we add this ? How about replacing

> An manual stop event (Event2) is ignored in the Idle state.

with

% Manual stop (Event 2) and Auto stop (Event 7) events are ignored
% in the Idle state

Good catch, we'll add that in the text.  Sorry it got dropped
on the last revision.

Agreed

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

---

From: "Sivananda Ramnath - CTD, Chennai." <[email-masked]>
Date: Tue, 10 Dec 2002 23:41:06 +0530

Hello,

    Revised summary:

    11 - No consensus, but current text can stand as is
         any comments from others ?

    12 - text changed, potential consensus

    13a - text changed, potential consensus
    13b - no change, potential consensus
    14 - additional comments, no consensus
        Note: No consensus on one part only
    15 - Consensus, author's choice.
    16 - Agree to your comments.
         Have clarified original comment,
         proposed some text.
    17 - consensus
    18 - text revised, potential consensus
    19 - no change, potential consensus
    20 - text changed, potential consensus

> 20 - agree, text will be changed

   Implementations can certainly use a single timer, since at any time
   at most only one of these two timers will need to be running.

   The reason for the comment is that conceptually these are two
   different timers:

   One is a standard (or configurable) value, and is used to wait for an
   Open Message.

   The other is negotiated, and is used to wait for Keepalives.

   I feel that representing these as two different events will make the
   state machine look better. Of course, nothing prevents an implementation
   from achieving this by using the same timer, or any other means as long
   the same effect is realized; so existing implementations will not be
   affected in any fashion.

   I am not very particular on this issue, since things will work fine
   with the current means as well, do others have any comments on
   modeling this as two separate events in the state machine ?

> =========

  Ok.
  Can we add any text on the need or use of a Delay Open ?

> Please comment if you agree with this change.

  This looks good.
 
> No, this is an implementation dependent change. 

  Ok. Again, if there are any validations that are considered
  desirable, adding this to the draft text as a suggestion to
  implementers would be useful.

  We can leave things as is if you feel that such details should
  be left out of the draft.

> ===================

> 	for the implementation's policy.  

    Ok.

> 	policy to be engaged.  Policy is outside the scope of this

   Isn't this more than just a policy issue ? It seems difficult
   to identify a connection destined to a port other than to
   the one on which BGP is running as an error event for BGP.
   So, I don't understand how a policy can be applied in this
   regard.

> 	Again, it is policy issue which is implementation dependent. 

    Ok.

  That looks fine too. I don't know what the best words
  to describe this are. Also, the description for this
  event does a good job of explaining this, so either
  the original text (connection fails) or your suggestion
  (disconnect) can be used.
  This really should not have been raised as a comment. :-)

  Yes, the text below looks fine.

  I should have phrased the original comment much better, I was
  referring to consistency across the following: Events 18, 19,
  20, 21 vs. Events 23, 24, 25, 26, 27.

  This is a very minor issue, so not making these changes is fine
  too. The way the latter events are described
  are different from the former. I suggest adopting the style for
  Events 23-27 for Events 18-21.

  As per this, the following changes would have to be made:

>       Event18: BGPOpen
>
>              Definition:  An event indicating that a valid Open
>                  message has been received.

    with 

%       Event18: BGPOpen
%
%              Definition:  An event is generated when a valid Open
%                           message has been received.

>       Event19: BGPOpen with BGP Delay Open Timer running
>
>              Definition: An event indicating that a valid Open
>                          message has been successful
>                          established for a peer that is
>                          currently delaying the sending of an
>                          BGP Open message.

   with

%       Event19: BGPOpen with BGP Delay Open Timer running
%
%              Definition: An event is generated when a valid Open
%                          message has been received for a peer that
%                          is currently delaying the sending of a
%                          BGP Open message.

>       Event20: BGPHeaderErr
>
>           Definition: BGP message header is not valid.

   with

%       Event20: BGPHeaderErr
%
%           Definition: An event is generated when a received BGP
%                       message header is not valid.

>       Event21: BGPOpenMsgErr
>
>           Definition: An BGP Open message has been received
>                          with errors.

    with

%       Event21: BGPOpenMsgErr
%
%           Definition: An event is generated when BGP Open message 
%                       with errors has been received.

> proposed text replacement

  Ok.

  Agreed.

  We can leave the main text as is.

> we'll add that in the text.

  Ok.

Siva
([email-masked])

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 12 Dec 2002 22:14:39 -0000

Comments  ** in line

Tom Petch [email-masked]

-----Original Message-----
From: Sivananda Ramnath - CTD, Chennai. <[email-masked]>
To: Susan Hares <[email-masked]>; Yakov Rekhter
<[email-masked]>;[email-masked] <[email-masked]>
Cc: Venu Kumar G - CTD, Chennai. <[email-masked]>
Date: 10 December 2002 18:09
Subject: RE: Comments 11-20

>         any comments from others ?

** these are two distinct timers, two distinct events (KeepAlive 11
and Hold 10) so keep the existing text
>    12 - text changed, potential consensus
** Open Delay timer in any new text please

>    13b - no change, potential consensus

**I found and find
** Transport Connection Indication & valid remote peer
**verbose and clumsy to read and write and suggested/suggest
** 13 Transport connection valid indication
** 14 Transport connection invalid indication
**at most, even cutting the names down to three words if possible.
** There remains plenty of scope for verbosity in the textual
description although I think we should beware of nailing it down too
tightly.  eg Invalid in a security conscious system might come to mean
this address has been added to a black list on account of its recent
malicious behaviour, perhaps dynamically blocking some source port
numbers on account of denial of service attacks.  While valid in a lax
implementation could mean anything goes, even port 179.  I am ok with
the existing description.

>         Have clarified original comment,
** Open Delay timer in any new text please
>    17 - consensus
** Open Delay timer in any new text please

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 12 Dec 2002 22:13:53 -0000

Comments  ** in line

-----Original Message-----
From: Sivananda Ramnath - CTD, Chennai. <[email-masked]>
To: Susan Hares <[email-masked]>; Yakov Rekhter

**I found and find