BGP INFORM message

[Yakov Rekhter <[e-mail]>]

Folks,

In response to the attached I got 11 "yes" and 12 "no".

Yakov.
------- Forwarded Message

Date:    Wed, 21 Aug 2002 07:37:21 -0700
From:    Yakov Rekhter <[e-mail]>
To:      [e-mail]
Subject: BGP INFORM message

Folks,

To help determine whether there is a rough consensus for
accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
document, please send an e-mail with either "yes" or "no".
The deadline is August 29.

Yakov.
- ------- Forwarded Message

Date:    Thu, 15 Aug 2002 07:00:49 -0700
From:    Yakov Rekhter <[e-mail]>
To:      [e-mail]
Subject: BGP INFORM message

Folks,

The authors of draft-nalawade-bgp-inform-02.txt would like
to make it the IDR WG document. The deadline for comments
(either positive or negative) on this request is August 29. 

Yakov.
- - ------- Forwarded Message

Date:    Thu, 15 Aug 2002 08:15:30 -0400
From:    [e-mail]
To:      IETF-Announce: ;
Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt

- - - --NextPart

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


	Title		: BGPv4 INFORM message
	Author(s)	: G. Nalawade, J. Scudder, D. Ward
	Filename	: draft-nalawade-bgp-inform-02.txt
	Pages		: 11
	Date		: 14-Aug-02
	
This document defines a new message type, the BGP INFORM
message that communicates Informational data and operational
warnings without resetting the peering session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-nalawade-bgp-inform-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- - - --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- - - --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt

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

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

- - - --OtherAccess--

- - - --NextPart--



- - ------- End of Forwarded Message


- ------- End of Forwarded Message


------- End of Forwarded Message




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA20543 for <[e-mail]>; Fri, 30 Aug 2002 12:09:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F057291324; Fri, 30 Aug 2002 12:09:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B984691327; Fri, 30 Aug 2002 12:09:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 56E0691324 for <[e-mail]>; Fri, 30 Aug 2002 12:09:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3F99A5DDCE; Fri, 30 Aug 2002 12:09:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 620A05DDC4 for <[e-mail]>; Fri, 30 Aug 2002 12:08:59 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7UG8wm36421 for <[e-mail]>; Fri, 30 Aug 2002 09:08:58 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: BGP INFORM message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 30 Aug 2002 09:08:58 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

In response to the attached I got 11 "yes" and 12 "no".

Yakov.
------- Forwarded Message

Date:    Wed, 21 Aug 2002 07:37:21 -0700
From:    Yakov Rekhter <[e-mail]>
To:      [e-mail]
Subject: BGP INFORM message

Folks,

To help determine whether there is a rough consensus for
accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
document, please send an e-mail with either "yes" or "no".
The deadline is August 29.

Yakov.
- ------- Forwarded Message

Date:    Thu, 15 Aug 2002 07:00:49 -0700
From:    Yakov Rekhter <[e-mail]>
To:      [e-mail]
Subject: BGP INFORM message

Folks,

The authors of draft-nalawade-bgp-inform-02.txt would like
to make it the IDR WG document. The deadline for comments
(either positive or negative) on this request is August 29. 

Yakov.
- - ------- Forwarded Message

Date:    Thu, 15 Aug 2002 08:15:30 -0400
From:    [e-mail]
To:      IETF-Announce: ;
Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt

- - - --NextPart

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


	Title		: BGPv4 INFORM message
	Author(s)	: G. Nalawade, J. Scudder, D. Ward
	Filename	: draft-nalawade-bgp-inform-02.txt
	Pages		: 11
	Date		: 14-Aug-02
	
This document defines a new message type, the BGP INFORM
message that communicates Informational data and operational
warnings without resetting the peering session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-nalawade-bgp-inform-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- - - --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- - - --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt

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

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

- - - --OtherAccess--

- - - --NextPart--



- - ------- End of Forwarded Message


- ------- End of Forwarded Message


------- End of Forwarded Message



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA07697 for <[e-mail]>; Fri, 30 Aug 2002 05:32:30 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 326DA91318; Fri, 30 Aug 2002 05:32:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31C9091319; Fri, 30 Aug 2002 05:32:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 855AD91318 for <[e-mail]>; Fri, 30 Aug 2002 05:31:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5A6AB5DDAE; Fri, 30 Aug 2002 05:31:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by segue.merit.edu (Postfix) with ESMTP id 2989F5DDA6 for <[e-mail]>; Fri, 30 Aug 2002 05:31:56 -0400 (EDT)
Received: from tom3 (usermg23.uk.uudial.com [62.188.122.9]) by colossus.systems.pipex.net (Postfix) with SMTP id 34C5A16000715; Fri, 30 Aug 2002 10:28:48 +0100 (BST)
Message-ID: <002c01c25007$3e9a7be0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>, "Susan Hares" <[e-mail]>
Cc: "yakov Rekhter" <[e-mail]>, <[e-mail]>, <[e-mail]>, "randy Bush" <[e-mail]>
Subject: Re: Words - in ASCII text
Date: Fri, 30 Aug 2002 10:25:49 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

Thinking some more, TCP SYN, SYN-ACK, SYN packets can carry data such
as an OPEN message ie events 13, 15, 16 can also be events 18, 19 etc;
should we cater for this?

If not, I think we should include a note to the effect that we are
not.




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA14610 for <[e-mail]>; Thu, 29 Aug 2002 17:40:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A32AD9130C; Thu, 29 Aug 2002 17:36:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D06591311; Thu, 29 Aug 2002 17:36:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4336C9130C for <[e-mail]>; Thu, 29 Aug 2002 17:34:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2658F5DF04; Thu, 29 Aug 2002 17:34:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id D14F55DEED for <[e-mail]>; Thu, 29 Aug 2002 17:34:53 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1AYLZ>; Thu, 29 Aug 2002 17:34:53 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Tom Petch'" <[e-mail]>, idr <[e-mail]>, Susan Hares <[e-mail]>
Cc: yakov Rekhter <[e-mail]>, [e-mail], [e-mail], randy Bush <[e-mail]>
Subject: RE: Words - in ASCII text
Date: Thu, 29 Aug 2002 17:34:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I agree.  To make things understandable, the terms should be exactly
consistent, and as specific as required, but not any more specific (except
for [typical] examples) than that.  If multiple terms for the same item are
already in common use (as is unfortunately the case sometimes), then this
should be explained in a definitions section, but otherwise the document
should still be consistent.


-$0.01


-----Original Message-----
From: Tom Petch [mailto:[e-mail]] 
Sent: Thursday, August 29, 2002 5:01 PM
To: idr; Susan Hares
Cc: yakov Rekhter; [e-mail]; [e-mail]; randy Bush
Subject: Re: Words - in ASCII text

I like the idea of writing this in terms of an abstract transport with
the TCP specific mapping specified separately in which case I suggest
amending the remaining 11 references to 'drop the TCP connection' to
'drop the transport connection' (or perhaps disconnect rather than
drop).  I believe strongly that consistent use of language is crucial
to make a document as abstract as this as easy to assimilate as
possible - it is for me - so every reference to eg event 14 should be
precisely the
same; using slightly different terminology in different places may
convey a lack of clarity in the underlying thinking when that is not
at all the case.

And perhaps

>
>
>8.2.3) Tranport Message based (13-16)
>
>  Event13: Transport Connection Indication & valid remote
peer[changed]


(do we need valid remote peer?)
>
Definition: A transport Connection request with a valid transport
address has been received.

For TCP, the destination port should be port 179 as defined by IANA.
The definition of valid Source and Destination  IP address is left to
the implementation.
>
Event14: Transport Connection Indication and Invalid transport address
[changed]
>
Definition: A Transport connection request with an invalid transport
address has been received .

For TCP, the destination port  number should be 179 as defined  by
IANA.
The definition of valid Source and Destination  IP address is left to
the implementation.
>
>
Event15/Event16:
I have problems here; the idea of the two half-duplex connections
being established by a SYN and an ACK is peculiar to TCP and I do not
have an abstract term for it :-(
>
>  Event17: Transport connection fails [changed]
>
>            Definition: This BGP peer receives a transport
>        connection failure notice.  This
>        connection notice could be caused by a
>        Transport disconnect message or a
>        Timeout in the transport session.


In the abstract, disconnect is all is needed as that covers a TCP
timeout.  I would prefer terminates to fails since fails has overtones
that may not be apppropriate.

>
>8.2) Description of FSM
>
>
>Idle state
>
>   The exact value of the ConnectRetry timer is a local
>   matter, but it should be sufficiently large to allow

the initialisation of a transport connection
>
>
>  If a transport indication is received for valid connection
>  [Event 13] or transport Request Acknowledgement [Event 15]
>  is received, or a transport connect confirm [Event 16] is
>  received

a second transport conneciton may be in progress.  This second
connection

> is tracked per the Call Collision
>  processing (section 6.8) until an OPEN message is received.
>


A transport connection indication with an invalid transport
address[Event 14] is ignored.
>  If a Transport Failure [Event17], 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,
>        [Action O in the FSM table]
>        - and goes into Active state.
>
>
>
>
>  In the event of

a transport connection indication[Event 13]  or transport

>  connection succeeding [Event 15 or Event 16] while in Open
>  Confirm, the local system needs to track the 2nd
>  connection.
>
>  If a transport connection is attempted with an invalid transport
address [Event
>  14], the local system will ignore the second connection
>  attempt.
>




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA13469 for <[e-mail]>; Thu, 29 Aug 2002 17:05:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3F42B9121D; Thu, 29 Aug 2002 17:05:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F1F591301; Thu, 29 Aug 2002 17:05:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9FC239121D for <[e-mail]>; Thu, 29 Aug 2002 17:05:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8C58A5DED1; Thu, 29 Aug 2002 17:05:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by segue.merit.edu (Postfix) with ESMTP id 3FB895DECD for <[e-mail]>; Thu, 29 Aug 2002 17:05:04 -0400 (EDT)
Received: from tom3 (usercp77.uk.uudial.com [62.188.156.106]) by colossus.systems.pipex.net (Postfix) with SMTP id ED70C160007A0; Thu, 29 Aug 2002 22:04:38 +0100 (BST)
Message-ID: <03ae01c24f9f$49fe6b80$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>, "Susan Hares" <[e-mail]>
Cc: "yakov Rekhter" <[e-mail]>, <[e-mail]>, <[e-mail]>, "randy Bush" <[e-mail]>
Subject: Re: Words - in ASCII text
Date: Thu, 29 Aug 2002 22:01:04 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

I like the idea of writing this in terms of an abstract transport with
the TCP specific mapping specified separately in which case I suggest
amending the remaining 11 references to 'drop the TCP connection' to
'drop the transport connection' (or perhaps disconnect rather than
drop).  I believe strongly that consistent use of language is crucial
to make a document as abstract as this as easy to assimilate as
possible - it is for me - so every reference to eg event 14 should be
precisely the
same; using slightly different terminology in different places may
convey a lack of clarity in the underlying thinking when that is not
at all the case.

And perhaps

>
>
>8.2.3) Tranport Message based (13-16)
>
>  Event13: Transport Connection Indication & valid remote
peer[changed]


(do we need valid remote peer?)
>
Definition: A transport Connection request with a valid transport
address has been received.

For TCP, the destination port should be port 179 as defined by IANA.
The definition of valid Source and Destination  IP address is left to
the implementation.
>
Event14: Transport Connection Indication and Invalid transport address
[changed]
>
Definition: A Transport connection request with an invalid transport
address has been received .

For TCP, the destination port  number should be 179 as defined  by
IANA.
The definition of valid Source and Destination  IP address is left to
the implementation.
>
>
Event15/Event16:
I have problems here; the idea of the two half-duplex connections
being established by a SYN and an ACK is peculiar to TCP and I do not
have an abstract term for it :-(
>
>  Event17: Transport connection fails [changed]
>
>            Definition: This BGP peer receives a transport
>        connection failure notice.  This
>        connection notice could be caused by a
>        Transport disconnect message or a
>        Timeout in the transport session.


In the abstract, disconnect is all is needed as that covers a TCP
timeout.  I would prefer terminates to fails since fails has overtones
that may not be apppropriate.

>
>8.2) Description of FSM
>
>
>Idle state
>
>   The exact value of the ConnectRetry timer is a local
>   matter, but it should be sufficiently large to allow

the initialisation of a transport connection
>
>
>  If a transport indication is received for valid connection
>  [Event 13] or transport Request Acknowledgement [Event 15]
>  is received, or a transport connect confirm [Event 16] is
>  received

a second transport conneciton may be in progress.  This second
connection

> is tracked per the Call Collision
>  processing (section 6.8) until an OPEN message is received.
>


A transport connection indication with an invalid transport
address[Event 14] is ignored.
>  If a Transport Failure [Event17], 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,
>        [Action O in the FSM table]
>        - and goes into Active state.
>
>
>
>
>  In the event of

a transport connection indication[Event 13]  or transport

>  connection succeeding [Event 15 or Event 16] while in Open
>  Confirm, the local system needs to track the 2nd
>  connection.
>
>  If a transport connection is attempted with an invalid transport
address [Event
>  14], the local system will ignore the second connection
>  attempt.
>





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA17820 for <[e-mail]>; Wed, 28 Aug 2002 17:29:27 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BFCA291205; Wed, 28 Aug 2002 17:28:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 838219129E; Wed, 28 Aug 2002 17:28:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0FBDB91205 for <[e-mail]>; Wed, 28 Aug 2002 17:28:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EA9E35DE32; Wed, 28 Aug 2002 17:28:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id A287C5DD92 for <[e-mail]>; Wed, 28 Aug 2002 17:28:56 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1ATY9>; Wed, 28 Aug 2002 17:28:56 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Abarbanel, Benjamin'" <[e-mail]>, "'Susan Hares'" <[e-mail]>
Cc: yakov Rekhter <[e-mail]>, [e-mail]
Subject: RE: Working Group last call
Date: Wed, 28 Aug 2002 17:28:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I agree, it seems to have no merit.  Maybe I missed it?

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Wednesday, August 28, 2002 3:15 PM
To: 'Susan Hares'; Abarbanel, Benjamin
Cc: yakov Rekhter; [e-mail]
Subject: RE: Working Group last call

Sue:

  I don't have version 2 or 3 of your draft, so I can't comment. Only thing
that
stands out in version 1 is, Actions that could/should Restart the Hold Timer
should not be limited to just KeepAlive and Update messages but any session
non-destructive BGP message (e.g Capability, Inform, etc.). I thought we had
a round on this on the list and I am not sure what the decision was?

IMHO, if a router restarts its Hold Timer upon reception of any session
non-destructive message, it can still communicate correctly with an old
router that
does not support this capability. It just means that a KeepAlive or Update
are
not the only messages preventing the session from expiring. The new router
could still send keepAlive in the absence of any Update message. So the
previous
issue on the list over this for phasing has no merits.


Ben

> -----Original Message-----
> From: Susan Hares [mailto:[e-mail]]
> Sent: Wednesday, August 28, 2002 12:51 PM
> To: Abarbanel, Benjamin
> Cc: 'Susan Hares'; yakov Rekhter; [e-mail]
> Subject: RE: Working Group last call
> 
> 
> Ben:
> 
> 1st - be glad to do the work in progress document.
> 2nd - could you send me any specific changes to the document today.
> 
> Sue
> 
> At 03:22 PM 8/26/2002 -0400, Abarbanel, Benjamin wrote:
> >Sue:
> >   While your draft is in "work in progress" state, would it 
> be possible
> >for you to include the "current version key changes section" 
> that you made.
> >That way we know if our issues are getting addressed.
> >
> >Regards,
> >Ben
> >
> > > -----Original Message-----
> > > From: Susan Hares [mailto:[e-mail]]
> > > Sent: Monday, August 26, 2002 2:12 PM
> > > To: yakov Rekhter
> > > Cc: [e-mail]
> > > Subject: Working Group last call
> > >
> > >
> > >
> > >
> > > We are starting a working group last call on the
> > > FSM words for the draft-18.  These were sent out by Bill Fenner
> > > in July at the IETF.  I have received comments on the
> > > state machine draft, but I have not received any comments on
> > > these words.
> > >
> > > Please send any comments on the attached words to the IDR
> > > mail group.  I will send the words in the next message as well.
> > >
> > >
> > >
> > > Please send any comments on the state machine document:
> > >
> > > http://www.ietf.org/internet-drafts/draft-hares-bgp-statemt-01.txt
> > >
> > > to me.  I have distributed to some individuals a -02 version.
> > > I will be sending to the Internet draft -03 to the IETF 
> secretary for
> > > posting.  Could anyone who has specific text changes send it by
> > > Tuesday evening?  I'll be sending in the draft to the 
> IETF secretary
> > > on Wed am.
> > >
> > > We will be focusing on discussing the FSM words for the 
> next 2 weeks.
> > >
> > > Sue
> > >
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA13400 for <[e-mail]>; Wed, 28 Aug 2002 15:15:06 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C5F229129E; Wed, 28 Aug 2002 15:14:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 97855912B9; Wed, 28 Aug 2002 15:14:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7B6399129E for <[e-mail]>; Wed, 28 Aug 2002 15:14:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 59D8C5DE16; Wed, 28 Aug 2002 15:14:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id CFF0A5DD92 for <[e-mail]>; Wed, 28 Aug 2002 15:14:39 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA28585; Wed, 28 Aug 2002 15:14:37 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA06148; Wed, 28 Aug 2002 15:14:38 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <RHFRBL2K>; Wed, 28 Aug 2002 15:14:35 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Susan Hares'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: yakov Rekhter <[e-mail]>, [e-mail]
Subject: RE: Working Group last call
Date: Wed, 28 Aug 2002 15:14:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Sue:

  I don't have version 2 or 3 of your draft, so I can't comment. Only thing
that
stands out in version 1 is, Actions that could/should Restart the Hold Timer
should not be limited to just KeepAlive and Update messages but any session
non-destructive BGP message (e.g Capability, Inform, etc.). I thought we had
a round on this on the list and I am not sure what the decision was?

IMHO, if a router restarts its Hold Timer upon reception of any session
non-destructive message, it can still communicate correctly with an old
router that
does not support this capability. It just means that a KeepAlive or Update
are
not the only messages preventing the session from expiring. The new router
could still send keepAlive in the absence of any Update message. So the
previous
issue on the list over this for phasing has no merits.


Ben

> -----Original Message-----
> From: Susan Hares [mailto:[e-mail]]
> Sent: Wednesday, August 28, 2002 12:51 PM
> To: Abarbanel, Benjamin
> Cc: 'Susan Hares'; yakov Rekhter; [e-mail]
> Subject: RE: Working Group last call
> 
> 
> Ben:
> 
> 1st - be glad to do the work in progress document.
> 2nd - could you send me any specific changes to the document today.
> 
> Sue
> 
> At 03:22 PM 8/26/2002 -0400, Abarbanel, Benjamin wrote:
> >Sue:
> >   While your draft is in "work in progress" state, would it 
> be possible
> >for you to include the "current version key changes section" 
> that you made.
> >That way we know if our issues are getting addressed.
> >
> >Regards,
> >Ben
> >
> > > -----Original Message-----
> > > From: Susan Hares [mailto:[e-mail]]
> > > Sent: Monday, August 26, 2002 2:12 PM
> > > To: yakov Rekhter
> > > Cc: [e-mail]
> > > Subject: Working Group last call
> > >
> > >
> > >
> > >
> > > We are starting a working group last call on the
> > > FSM words for the draft-18.  These were sent out by Bill Fenner
> > > in July at the IETF.  I have received comments on the
> > > state machine draft, but I have not received any comments on
> > > these words.
> > >
> > > Please send any comments on the attached words to the IDR
> > > mail group.  I will send the words in the next message as well.
> > >
> > >
> > >
> > > Please send any comments on the state machine document:
> > >
> > > http://www.ietf.org/internet-drafts/draft-hares-bgp-statemt-01.txt
> > >
> > > to me.  I have distributed to some individuals a -02 version.
> > > I will be sending to the Internet draft -03 to the IETF 
> secretary for
> > > posting.  Could anyone who has specific text changes send it by
> > > Tuesday evening?  I'll be sending in the draft to the 
> IETF secretary
> > > on Wed am.
> > >
> > > We will be focusing on discussing the FSM words for the 
> next 2 weeks.
> > >
> > > Sue
> > >
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA08594 for <[e-mail]>; Wed, 28 Aug 2002 12:51:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DC44091212; Wed, 28 Aug 2002 12:51:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE4869121A; Wed, 28 Aug 2002 12:51:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B2B291212 for <[e-mail]>; Wed, 28 Aug 2002 12:50:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 50FE95DE18; Wed, 28 Aug 2002 12:50:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id BFD315DDD4 for <[e-mail]>; Wed, 28 Aug 2002 12:50:58 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7SGovx80114; Wed, 28 Aug 2002 12:50:57 -0400 (EDT) (envelope-from [e-mail])
Received: from SKH.nexthop.com ([64.211.218.13]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7SGos180106; Wed, 28 Aug 2002 12:50:54 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 28 Aug 2002 12:50:44 -0400
To: "Abarbanel, Benjamin" <[e-mail]>
From: Susan Hares <[e-mail]>
Subject: RE: Working Group last call
Cc: "'Susan Hares'" <[e-mail]>, yakov Rekhter <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail] re.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Ben:

1st - be glad to do the work in progress document.
2nd - could you send me any specific changes to the document today.

Sue

At 03:22 PM 8/26/2002 -0400, Abarbanel, Benjamin wrote:
>Sue:
>   While your draft is in "work in progress" state, would it be possible
>for you to include the "current version key changes section" that you made.
>That way we know if our issues are getting addressed.
>
>Regards,
>Ben
>
> > -----Original Message-----
> > From: Susan Hares [mailto:[e-mail]]
> > Sent: Monday, August 26, 2002 2:12 PM
> > To: yakov Rekhter
> > Cc: [e-mail]
> > Subject: Working Group last call
> >
> >
> >
> >
> > We are starting a working group last call on the
> > FSM words for the draft-18.  These were sent out by Bill Fenner
> > in July at the IETF.  I have received comments on the
> > state machine draft, but I have not received any comments on
> > these words.
> >
> > Please send any comments on the attached words to the IDR
> > mail group.  I will send the words in the next message as well.
> >
> >
> >
> > Please send any comments on the state machine document:
> >
> > http://www.ietf.org/internet-drafts/draft-hares-bgp-statemt-01.txt
> >
> > to me.  I have distributed to some individuals a -02 version.
> > I will be sending to the Internet draft -03 to the IETF secretary for
> > posting.  Could anyone who has specific text changes send it by
> > Tuesday evening?  I'll be sending in the draft to the IETF secretary
> > on Wed am.
> >
> > We will be focusing on discussing the FSM words for the next 2 weeks.
> >
> > Sue
> >




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA01823 for <[e-mail]>; Tue, 27 Aug 2002 19:12:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 768DD912C3; Tue, 27 Aug 2002 19:08:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09617912D2; Tue, 27 Aug 2002 19:08:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1925E912C3 for <[e-mail]>; Tue, 27 Aug 2002 19:04:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 04B735DD94; Tue, 27 Aug 2002 19:04:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id 43BC65DD92 for <[e-mail]>; Tue, 27 Aug 2002 19:03:59 -0400 (EDT)
Received: from [192.168.42.10] (ch2-dhcp136-109.cisco.com [161.44.136.109]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA17602; Tue, 27 Aug 2002 19:03:26 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a0db991b5021a7b@[192.168.42.10]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Tue, 27 Aug 2002 19:00:48 -0400
To: Tian Fang <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: One case is missing in confederation RFC 3065
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 5:24 PM -0400 8/27/02, Tian Fang wrote:
>In rfc 3065, "Autonomous System Confederations for BGP", Page 5, 
>case 6.1. C), the case "the first path segment of the AS_PATH is of 
>type AS_CONFED_SET" is missing. I think we should handle it as same 
>as case 6.1. C) 1), only with the difference that AS_CONFED_SEQUENCE 
>can't follow AS_CONFED_SET.

This will be fixed in the forthcoming revision.

Regards,

--John


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA28149 for <[e-mail]>; Tue, 27 Aug 2002 17:26:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7336F9120D; Tue, 27 Aug 2002 17:26:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F0DA9129D; Tue, 27 Aug 2002 17:26:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0C3E99120D for <[e-mail]>; Tue, 27 Aug 2002 17:25:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E86C35DDF7; Tue, 27 Aug 2002 17:25:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mail2.hyperchip.com (mail2.hyperchip.com [216.94.112.4]) by segue.merit.edu (Postfix) with ESMTP id 8A5BA5DDBE for <[e-mail]>; Tue, 27 Aug 2002 17:25:59 -0400 (EDT)
Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail2.hyperchip.com with esmtp (Exim 3.22 #1) id 17jnqZ-0001zH-00 for [e-mail]; Tue, 27 Aug 2002 17:25:59 -0400
Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id <R4TPJBGH>; Tue, 27 Aug 2002 17:24:14 -0400
Message-ID: <[e-mail]>
From: Tian Fang <[e-mail]>
To: [e-mail]
Subject: One case is missing in confederation RFC 3065
Date: Tue, 27 Aug 2002 17:24:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24E10.1796D780"
Sender: [e-mail]
Precedence: bulk

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

------_=_NextPart_001_01C24E10.1796D780
Content-Type: text/plain;
	charset="iso-8859-1"

In rfc 3065, "Autonomous System Confederations for BGP", Page 5, case 6.1.
C), the case "the first path segment of the AS_PATH is of type
AS_CONFED_SET" is missing. I think we should handle it as same as case 6.1.
C) 1), only with the difference that AS_CONFED_SEQUENCE can't follow
AS_CONFED_SET.

Regards,
Tian Fang




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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>One case is missing in confederation RFC 3065</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>In rfc 3065, &quot;Autonomous System Confederations =
for BGP&quot;, Page 5, case 6.1. C), the case &quot;the first path =
segment of the AS_PATH is of type AS_CONFED_SET&quot; is missing. I =
think we should handle it as same as case 6.1. C) 1), only with the =
difference that AS_CONFED_SEQUENCE can't follow =
AS_CONFED_SET.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Tian Fang</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C24E10.1796D780--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA05401 for <[e-mail]>; Mon, 26 Aug 2002 15:23:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7259C91247; Mon, 26 Aug 2002 15:22:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A0189124C; Mon, 26 Aug 2002 15:22:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C92B91247 for <[e-mail]>; Mon, 26 Aug 2002 15:22:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7D3E25DEFB; Mon, 26 Aug 2002 15:22:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 078935DE25 for <[e-mail]>; Mon, 26 Aug 2002 15:22:57 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA14761; Mon, 26 Aug 2002 15:22:54 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA04064; Mon, 26 Aug 2002 15:22:56 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <RHFQ9ZTS>; Mon, 26 Aug 2002 15:22:55 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Susan Hares'" <[e-mail]>, yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: RE: Working Group last call
Date: Mon, 26 Aug 2002 15:22:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Sue:
  While your draft is in "work in progress" state, would it be possible
for you to include the "current version key changes section" that you made.
That way we know if our issues are getting addressed.  

Regards,
Ben

> -----Original Message-----
> From: Susan Hares [mailto:[e-mail]]
> Sent: Monday, August 26, 2002 2:12 PM
> To: yakov Rekhter
> Cc: [e-mail]
> Subject: Working Group last call
> 
> 
> 
> 
> We are starting a working group last call on the
> FSM words for the draft-18.  These were sent out by Bill Fenner
> in July at the IETF.  I have received comments on the
> state machine draft, but I have not received any comments on 
> these words.
> 
> Please send any comments on the attached words to the IDR
> mail group.  I will send the words in the next message as well.
> 
> 
> 
> Please send any comments on the state machine document:
> 
> http://www.ietf.org/internet-drafts/draft-hares-bgp-statemt-01.txt
> 
> to me.  I have distributed to some individuals a -02 version.
> I will be sending to the Internet draft -03 to the IETF secretary for
> posting.  Could anyone who has specific text changes send it by
> Tuesday evening?  I'll be sending in the draft to the IETF secretary
> on Wed am.
> 
> We will be focusing on discussing the FSM words for the next 2 weeks.
> 
> Sue
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA03038 for <[e-mail]>; Mon, 26 Aug 2002 14:14:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 424C991257; Mon, 26 Aug 2002 14:13:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1EA091259; Mon, 26 Aug 2002 14:13:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 22ED391257 for <[e-mail]>; Mon, 26 Aug 2002 14:13:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0D00C5DEE9; Mon, 26 Aug 2002 14:13:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 161A15DD93 for <[e-mail]>; Mon, 26 Aug 2002 14:13:39 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7QIDXb12555; Mon, 26 Aug 2002 14:13:33 -0400 (EDT) (envelope-from [e-mail])
Received: from SKH.nexthop.com ([64.211.218.13]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7QIDT112538; Mon, 26 Aug 2002 14:13:29 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 26 Aug 2002 14:13:14 -0400
To: [e-mail]
From: Susan Hares <[e-mail]>
Subject: Words - in ASCII text
Cc: yakov Rekhter <[e-mail]>, [e-mail], [e-mail], randy Bush <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Note: (this is version 5 of the changes to
        the text.)

8.0	BGP Finite State Machine


This section specifies the BGP operation in terms of a
Finite State Machine (FSM).  The section falls into 2
parts:

     1)	Description of Events for the State machine (section
         8.1
     2)	Description of the FSM (section 8.2)

Session Attributes required for each connection are;

    1)	state
    2)	Connect Retry timer
    3)	Hold timer
    4)	Hold time
    5)	Keepalive timer

8.1 Events for the BGP FSM

8.1.1   Administrative Events (events 1-5)

Please note that only Event 1 (manual start) and Event 2
(manual stop) are mandatory administrative events. All
other administrative events are optional.

  Event1: Manual start

	   Definition: Administrator manually starts peer
                        connection
	   Status: 	Mandatory

  Event2: Manual stop

	   Definition: Local system administrator manually
                        stops the peer connection.

	   Status: 	mandatory
	

  Event3: Automatic Start

  	   Definition: Local system automatically starts the
                        BGP peer session

	   Status:     Optional depending on local system

  Event4: Manual start with passive Transport Establishment

	   Definition: Administrator manually start the peer
                        Connection, but has the passive flag
                        enabled.  The passive flag indicates
                        that the peer will listen prior to
                        establishing the connection.

	   Status:     Optional depending on local system
		

  Event5: Automatic start with passive Transport establishment

	  Definition:  Local system automatically starts the
                        BGP session with the passive flag
                        enabled.  The passive flag indicates
                        that the peer will listen prior to
                        establishing a connection.

	  Status:      Optional depending on local system use
		       of a passive connection.

  Event6: Automatic start with bgp_stop_flap option set

	   Definition: Local system automatically starts the
                        BGP peer session with persistent peer
                        oscillation damping enabled.  The exact
                        method of damping persistent peer
                        oscillations is left up to the
                        implementation.   These methods of
                        damping persistent BGP adjacency
                        flapping are outside the scope of this
                        document.


            Status: 	Optional, used only if the bgp peer has
	  	        Enabled a method of damping persistent
		        BGP peer flapping.


  Event7: Auto stop

	   Definition: Local system automatically stops the
                        BGP peer session.
	
	   Status:     Optional depending on local system


8.1.2 Timer Events (events 8-11)

  Event8:  idle Hold timer expires

            Definition: Idle Hold timer expires.  The Idle
                        Hold Timer is only used when persistent
                        BGP oscillation damping functions are
                        enabled.

            Status: 	Optional.  Used when persistent
			BGP peer oscillation damping functions
			are enabled.



  Event9: connect retry timer expires

            Definition: An event triggered by the expiration of
                        the ConnectRetry timer.

	   Status:     Mandatory

  Event10: hold time expires

	   Definition: An event generated when the HoldTimer
                        expires.

	   Status:     Mandatory

  Event11: keepalive timer expires

	   Definition: A periodic event generated due to the
                        expiration of the KeepAlive Timer.

	   Status:     Mandatory

  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.

	   status:     Optional

8.2.3) Tranport Message based (13-16)

  Event13: Transport Connection Indication & valid remote peer[changed]

	   Definition: Event indicating that transport
                        Request 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.


	   Status:     Mandatory

  Event14: RCV Transport Connection Indication and Invalid Source or
           Destination [changed]

            Definition: Transport request received 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.

	    Status: 	 Mandatory
	
  Event15: Transport Connection request sent received an ACK.

            Definition: Local system's request to establish a transport
		       Connection to the remote side received
		       an ACK.


	    Status:    Mandatory

  Event16: Transport Connection Confirmed [changed]

	   Definition: The local system has received a Confirmation that
                        the transport connection has been established by
		       the remote site.

	  Status:      Mandatory

  Event17: Transport connection fails [changed]

            Definition: This BGP peer receives a transport
		       connection failure notice.  This
		       connection notice could be caused by a
		       Transport disconnect message or a
		       Timeout in the transport session.

                        If this connection is using TCP, 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


8.1.4 BGP Messages (18-27)

  Event18: BGPOpen

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

	   Status: 	Mandatory

  Event19: BGPOpen with BGP Delay Open Timer running [changed]

            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.

	    Status:    Optional

  Event20: BGPHeaderErr

	   Definition: BGP message header is not valid.

	   Status:     Mandatory

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

	   Status: 	Mandatory


  Event22: Open collision discard

            Definition: An event generated administratively
                        when a connection Collision has been
                        detected while processing an incoming
                        Open message. This connection has been
                        selected to disconnected.  See section
                        6.8 for more information on collision
	               detection.

                        Event 22 is an administrative could
                        occur if FSM is implemented as two
                        linked state machines.

	  Status:      Optional

  Event23: NotifMsgVerErr

	    Definition: An event is generated when a
                         NOTIFICIATION message with "version
                         error" is received.

	    Status:     Mandatory

  Event24: NotifMsg

	    Definition: An event is generated when a
                         NOTIFICATION messages is received and
                         the error code is anything but 	
			"version error".

	     Status:	Mandatory
		
  Event25: KeepAliveMsg

	    Definition: An event is generated when a KEEPALIVE
			Message is received.

		Status: Mandatory

  Event26: UpdateMsg

	    Definition: An event is generated when a valid
			Update Message is received.

		Status: Mandatory

  Event27: UpdateMsgErr

	    Definition: An event is generated when an invalid
			Update message is received.

		Status:	Mandatory


8.2) Description of FSM


Idle state

    Initially BGP is in the Idle state.

    In this state BGP refuses all incoming BGP connections.  No
    resources are allocated to the peer.    In response to a
    manual start event(Event1) or an automatic start
    event(Event3), the local system
       -	initializes all BGP resources,
       -	sets the Connect retry counter to zero
       -	starts the ConnectRetry timer with initial value,
       -	initiates a transport connection to the other BGP
         peer,
       -	listens for a connection that may be initiated by
         the remote BGP peer, and
         [Action A in the FSM table]
       -	changes its state to connect.

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

   In response to a manual start event with the passive Transport
   flag (Event 4) or automatic start with the passive Transport flag
   (Event 5), the local system:
       -	initializes all BGP resources,
       -	sets the connect retry count to zero,
       -	start the Connect Retry timer with initial value,
       -	listens for a connection that may be initiated by
         the remote peer
         [Action B in the FSM table]
       -	changes its state to Active.

   The exact value of the ConnectRetry timer is a local
   matter, but it should be sufficiently large to allow TCP
   initialization.

   If a persistent BGP peer oscillation damping function is
   enabled, two additional events may occur within Idle state:
       -	Automatic start with bgp_stop_flap set [Event6],
       -	Idle Hold Timer expired [Event 8].

   The method of preventing persistent BGP peer oscillation is
   outside the scope of this document.

   Any other events [Events 9-27] received in the Idle state,
   are noted by the MIB processing as FSM Errors [action V]
   and the local peer stays in the Idle State.


Connect State:

   In this state, BGP is waiting for the transport protocol
   connection to be completed.

   If the transport connection succeeds [Event 15 or
   Event 16], the local system checks the "Delay Open
   Flag".  If the Delay Open flag is set, the local system:
      -	clears the ConnectRetry timer,
      -	set the BGP Open Delay timer to the initial
         value.
         [Action ZZ in FSM table]

   If the Delay Open flag is not set, the local system:
      - clears the ConnectRetry timer,
      - completes BGP initialization
      - send an Open message to its peer,
      - sets Hold timer to a large value,
      - Change the state to Open Sent
    [Action H in the FSM table]

   A hold timer value of 4 minutes is suggested.

   If the Open Delay timer expires [Event 12] in the connect
   state,
      - send an Open message to its peer,
      - set the Hold timer to a large value,
	[Action H in the FSM Table], and
      - change the state to Open Sent.

   If the BGP port receives a Transport connection indication
   [Event 13], the Transport connection is processed (actions AA or
   AB in the FSM table) and the connection remains
   in the connected state.

   If the transport connection receives an Transport indication
   that is invalid or unconfigured. [Event 14]:
      - the transport connection is rejected.
	[Action L in the FSM table]

   If the transport connection fails (timeout or transport
   disconnect) [Event17], the local system:
       - restarts the ConnectRetry timer,
       - continues to listen for a connection that may be
         initiated by the remote BGP peer, and
      [Action G in the FSM table]
       - changes its state to Active.


   If an Open is received with the BGP Delay Open timer is
   running [Event 19], the local system:
	- clears the connect retry timer (cleared to zero),
	- completes the BGP initialization,
	- Stops and clears the BGP Open Delay timer
	- Sends an Open message

	[Action H in the FSM table], and
	- changes its state to Open Confirm.


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

  A manual stop event[Event2], the local system:
        - drops the transport connection,
        - releases all BGP resources,
        - sets connect retry count to zero
        - resets the connect retry timer (sets to zero)
       [Action Z in the FSM table]
        - goes to Idle state.

   In response to the ConnectRetry timer expired event(Event
   9), the local system:
       - Sets the MIB FSM error information with ConnectRetry
         expired,
       - drops the transport connection
       - 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
       [Action O in the FSM table]
       - stays in Connect state.

  In response to any other events [Events 7-8, 10-11, 18, 20-
  27] the local system:
      - resets the connect retry timer (sets to zero),
      - drops the Transport connection,
      - release all BGP resources,
      - increments the ConnectRetryCnt by 1,
      - [optionally] performs bgp peer oscillation damping, and
      [Action D in the FSM table],
      - goes to Idle state.


Active State:

  In this state BGP is trying to acquire a peer by listening
  for and accepting a transport protocol connection.

  A transport connection succeeds [Event 15 or Event 16], the
  local system: process the transport connection flags
	- If the BGP delay open flag is set:
           o clears the ConnectRetry timer,
           o completes the BGP initialization,
           o sets the BGP delay Open timer
          [Action ZZ]

         - If the BGP delay open flag is not set:
           o clears the ConnectRetry timer,
           o completes the BGP initialization,
           o sends the Open message to it's peer,
           o sets its Hold timer to a large value,
          [Action H in the FSM table]
           and changes its state to OpenSent.

  A Hold timer value of 4 minutes is suggested.

  If the local system receives a valid Transport Indication
  [Event 13], the local system processes the Transport flags
   (actions aa or ab in FSM section 2.3.4).

  If the local system receives a Transport indication
  that is invalid for this connection [Event 14]:
       - the transport connection is rejected
         [Action L in the FSM table]

  If the local system receives a Transport connection
  failed [Event 17] (timeout or receives Transport
  disconnect), the local system will:
	- set Transport disconnect in the MIB reason code,
	- restart ConnectRetry timer (with initial value)
	- release all BGP resources
	- Acknowledge the drop of Transport connection if
           transport disconnect (If TCP, send a FIN ACK),
	- Increment ConnectRetryCnt by 1,
	- perform the BGP peer oscillation damping process [2]
	[Action Y in the FSM table]

  If the local system has the Delay Open timer expired [event
  12] local system:
         - clears the Connect Retry timer (set to zero),
	- stops and clears the Delay Open timer (set to zero)
         - completes the BGP initialization,
         - sends the Open message to it's remote peer,
         - sets it's Hold timer to a large value,
         [Action H in the FSM table]
         - and set the state to Open Confirm.

  A Hold timer value of 4 minutes is also suggested for this
  state transition.

  If an Open is received with the BGP Delay Open timer is
  running [Event 19], the local system
	- clears the connect retry timer (cleared to zero),
	- Stops and clears the BGP Open Delay timer
	- completes the BGP initialization,
	- Stops and clears the BGP Open Delay timer
	- Sends an Open message
	- Set the Hold timer to a large value (4 minutes),
	[Action H in the FSM table], and
	- changes its state to Open Confirm.


  In response the ConnectRetry timer expired event[Event9],
  the local system:
         - restarts the ConnectRetry timer (with initial value),
         - initiates a transport connection to the other BGP
           peer,
         - Continues to listen for transport connection that may be
           initiated by remote BGP peer,
         [Action F in the FSM table]
	- and changes its state to Connect.


  The start events [Event1, 3-6] are ignored in the Active
  state.

  A manual stop event[Event2], the local system:
         - Sets the administrative down in the MIB reason code,
	- Sends a notification with a Cease,
	- If any BGP routes exist, delete the routes
	- release all BGP resources,
	- drops the Transport connection,
         - sets connect retry count to zero
         - resets the connect retry timer (sets to zero)
         [Action S in the FSM table]
         - goes to Idle state.

  In response to any other event (Events 7-8, 10-11,18, 20-
  27), the local system:
         - stores the MIB information to indicate appropriate
           error [FSM for Events 7-8, 10-11, 18, 20-27]
         - reset the connect retry timer (sets to zero),
         - release all BGP resources,
	- drops the transport connection,
         - increments the ConnectRetryCnt by one,
         - optionally performs BGP peer oscillation damping,
   	  [Action D in FSM table],
	- and goes to the idle state


Open Sent:

  In this state BGP waits for an Open Message from its peer.

  When an OPEN message is received, all fields are checked
  for correctness.  If there are no errors in the OPEN message
  [Event 18] the local system:
        - resets the BGP Delay timer to zero,
        - reset BGP Connect Timer to zero,
        - sends a KEEPALIVE message and
        - sets a KeepAlive timer (via the text below)
        - sets the Hold timer according to the negotiated value
          (see section 4.2), and
          [Action N in the FSM table]
        - sets 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 the BGP message header checking [Event20] or OPEN message
  check detects an error (see Section 6.2)[Event21], the local system:
        - sends a NOTIFICATION message with appropriate error
          code,
        - reset the connect retry timer (sets to zero),
        - if there are any routes associated with the BGP session,
	 delete these routes
        - release all BGP resources,
        - drop the transport session
        - increments the ConnectRetryCnt by 1,
        - bgp peer oscillation damping process,
        [Actions I, J in FSM table, depending on error],
        - and goes to the Idle state.

  Collision detection mechanisms (section 6.8) need to be
  applied when a valid BGP Open is received [Event 18 or
  Event 19].  Please refer to section 6.8 for the details of
  the comparison. An administrative collision detect is when
  BGP implementation determines my means outside the scope of
  this document that a connection collision has occurred.

  If a connection in Open Sent is determined to be the
  connection that must be closed, an administrative collision
  detect [Event 22] is signaled to the state machine. If such
  an administrative collision detect dump [Event 22] is
  received in Open Sent, the local system:
        - sets MIB state information to
          collision detect closure,
        - send a NOTIFICATION with a CEASE
        - resets the connect retry timer,
        - release all BGP resources,
        - drop the transport connection,
        - increments ConnectRetryCnt by 1,
        - performs any BGP peer oscillation damp process, and
        [Action R in the FSM],
        - enters Idle state.


   If a NOTIFICATION message is received with a version
   error[Event23], Notification message without version number
   [Event 24], the local system:
        - resets the connect retry timer (sets to zero)
        - drops the Transport connection,
        - releases all BGP resources,
        - increments the ConnectRetryCnt by 1
        - process any BGP peer oscillation damping,
	[Action Y]
        - and sets the state to Idle.


  The Start events [Event1, 3-6] are ignored in the OpenSent
  state.

   If a manual stop event [Event 2] is issued in Open sent
  state, the local system:
	- Sets administrative down reason in MIB reason,
	- sends the Notification with a cease,
	- if BGP routes exists, delete the routes,
	- Release all BGP resources,
	- Drops the Transport connection,
	- set ConnectRetryCnt to zero,
	- resets the Connect Retry timer (set to zero),
	[Action S in the FSM table], and
	- transitions to the Idle state.

   If an automatic stop event [Event 7] is issued in Open sent
   state, the local system:
	- Sets administrative down reason in MIB reason,
	- sends the Notification with a cease,
	- if any routes are associated with te BGP session,
	  delete the routes,
	- release all the BGP resources
	- Drops the Transport connection,
	- increments the ConnectRetryCnt by 1,
	- BGP peer oscillation process [2]
	[Action C in the FSM table], and
	- transitions to the Idle state.

  If the Hold Timer expires[Event 10], the local system:
        - set Hold timer expired in MIB Error reason code,
        - send a NOTIFICATION message with error code Hold
          Timer Expired,
        - reset the connect retry timer (sets to zero),
        - releases all BGP resources,
        - drops the Transport connection,
        - increments the ConnectRetryCnt by 1
          [Action K in the FSM table], and
	- transitions to the Idle state.


  If a transport indication is received for valid connection
  [Event 13] or transport Request Acknowledgement [Event 15]
  is received, or a transport connect confirm [Event 16] is
  received a second TCP session may be in progress.  This
  second TCP session is tracked per the Call Collision
  processing (section 6.8) until an OPEN message is received.

  A TCP connection for an invalid port [Event 14] is ignored.

  If a Transport Failure [Event17], 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,
        [Action O in the FSM table]
        - and goes into Active state.


  In response to any other event [Events 8-9, 11-12, 19, 25-27],
   the local system:
	- sends the NOTIFICATION with the Error Code Finite
           state machine error,
         - resets the connect retry timer (sets to zero),
	- releases all BGP resources
         - drops the Transport connection,
         - increments the ConnectRetryCnt by 1,
         - process any bgp peer oscillation damping[2]
         [Action E in the FSM table],
         - and sets the state to idle.


Open Confirm State

  In this state BGP waits for a KEEPALIVE or NOTIFICATION
  message.

  If the local system receives a KEEPALIVE message[Event 25],
         - restarts the Hold timer,
           [Action P in the FSM table], and
         - changes its state to Established.


  If the local system receives a NOTIFICATION message [event
  23-24] or receives a TCP Disconnect [event 17] from the
  underlying transport protocol, the local system:
         - sets the appropriate MIB information for FSM error,
         - resets the connect retry timer (sets the timer to
           zero),
	- releases all BGP resources,
         - drops the TCP connection,
         - increments the ConnectRetryCnt by 1,
         [Action Y in the FSM table],
         - and sets the state to idle.

  Any start event [Event1, 3-6] is ignored in the OpenConfirm
  state.

  In response to a manual stop event[Event 2] initiated by
  the operator, the local system:
	- set Administrative down in MIB Reason code,
         - sends the NOTIFICATION message with Cease,
	- if any BGP routes, dete the routes
         - releases all BGP resources,
	- drop the transport connection,
         - sets the ConnectRetryCnt to zero
         - sets the connect retry timer to zero
         [Action S in the FSM table]
         - transitions to Idle state.

  In response to the Automatic stop event initiated by the
  system[event 7], the local system:
         - sets the MIB entry for this peer to administratively
           down,
         - sends the NOTIFICATION message with Cease,
	- connect retry timer reset (set to zero)
	- If any BGP routes exist, delete the routes,
	- release all BGP resources,
         - drops the transport connection,
         - increments the ConnectRetryCnt by 1,
         [Action C in the FSM table], and
         - transitions to the Idle State.

  If the Hold Timer expires before a KEEPALIVE message is
  received [event10], the local system:
         - set the MIB reason to Hold time expired,
         - send the NOTIFICATION message with the error code
           set to Hold Time Expired,
         - resets the connect retry timer (sets the timer to to
           zero),
	- releases all BGP resources,
         - drops the transport connection,
         - increments the ConnectRetryCnt by 1
           [Action K in the FSM table],
         - and sets the state to Idle.


  If the local system receives a KEEPALIVE timer expires
  event [Event 11], the system:
         - sends a KEEPALIVE message,
         - restarts the Keepalive timer
         [Action Q the in FSM table],and
         - remains in Open Confirmed state.

  In the event of TCP establishment [Event 13], or TCP
  connection succeeding [Event 15 or Event 16] while in Open
  Confirm, the local system needs to track the 2nd
  connection.

  If a TCP connection is attempted to an invalid port [Event
  14], the local system will ignore the second connection
  attempt.

  If an OPEN message is received, all fields are check for
  correctness.  If the BGP message header checking [Event20]
  or OPEN message check detects an error (see Section
  6.2)[Event21], [the local system:
         - sends a NOTIFICATION message with appropriate error
           code,
         - resets the connect retry timer (sets the timer to
           zero),
         - releases all BGP resources,
         - drops the TCP connection,
         - increments the ConnectRetryCnt by 1,
         - runs the BGP peer oscillation damping process [2]
        [Actions I, J, in the FSM table depending on the error]
         - and goes to the Idle state.

  If the Open messages is valid [Event 18], the collision
  detect function is processed per section 6.8.  If this
  connection is to be dropped due to call collision, the
  local system:
         - sets the Call Collision cease in the MIB reason
          code,
         - sends a Notification with a Cease
         - resets the Connect timer (set to zero),
	- releases all BGP resources,
	- Drops the TCP connection (send TCP FIN),
	- increments the ConnectRetryCnt by 1, and
	- performs any BGP peer oscillation damping process [2].
	[action


  If during the processing of another Open message, the BGP
  implementation determines my means outside the scope of
  this document that a connection collision has occurred and
  this connection is to be closed, the local system will
  issue a call collision dump [Event 22].  When the local
  system receives a call collision dump event [Event 22], the
  local system:
         - Sets the MIB FSM variable to indicate collision
           detected and dump connection.
         - send a NOTIFICATION with a CEASE
         - deletes all routes associated with connection,
         - resets the connect retry timer,
         - releases all BGP resources
         - drops all TCP connection,
         - increments the ConnectRetryCnt by 1,
         - and performs any BGP peer oscillation damping,
         [Action R in the FSM table],
         - enters Idle state.

  In response to any other event [Events 8-9, 12, 19, 26-27],
  the local system:
         - sends a NOTIFICATION with a code of Finite State
           Machine Error,
         - resets the connect retry timer (sets to zero)
         - drops the TCP connection,
         - releases all BGP resources,
         - increments the ConnectRetryCnt by 1,
         - performs any BGP peer oscillation damping,
         [Action E in the FSM table], and
         - transitions to Idle state.


Established State:

  In the Established state BGP can exchange UPDATE,
  NOTFICATION, and KEEPALIVE messages with its peer.

  If the local system receives an UPDATE message [Event26],
  the local system will:
	- process the update packet
	- restarts its Hold timer, if the negotiated Hold Time
           value is non-zero.
	[Action W in the FSM table], and
	- remain in the Established state.


  If the local system receives a NOTIFICATION message
  [Event23 or Event24] or a disconnect [Event17] from the
  underlying transport protocol, it:
	- sets the appropriate error code in MIB reason code,
	- if any BGP routes exist, delete all BGP routes,
         - resets the connect retry timer (sets to zero),
         - releases all the BGP resources,
	- drops the TCP connection,
	- increments the ConnectRetryCnt by 1, and
        [Action T in the FSM table]
	- Goes to the Idle state.


  If the local system receives a Keepalive message
  [Event 25], the local system will:
         - restarts its Hold Timer, if the negotiated Hold Time
           value is non-zero.
        [Action P in the FSM table], and
	- remain in the Established state.

  If the local system receives an UPDATE message, and the
  Update message error handling procedure (see Section 6.3)
  detects an error [Event27], the local system:
        - sends a NOTIFICATION message with Update error,
        - resets the connect retry timer (sets to zero),
        - drops the TCP connection,
        - releases all BGP resources,
        - increments the ConnectRetryCnt by 1
        - performs any BGP peer oscillation damping
       [Action U in FSM table],
        - and goes to Idle state.


  Any start event (Event 1, 3-6) is ignored in the
  Established state.

  In response to a manual stop event (initiated by an
  operator)[Event2]:
         - sets the Administrative stop in MIB reason code,
	- sends the NOTIFICATION message with Cease,
         - if BGP routes exist, delete the BGP routes,
         - release BGP resources,
	- drop TCP connection,
         - set ConnectRetryCnt to zero (0),
         - reset connect retry timer to zero (0), and
         [Action S in FSM table]
         - transition to the Idle.

  In response to an automatic stop event initiated by the
  system (automatic) [Event7], the local system:
      - sets Administrative Stop in MIB Reason code,
      - sends a NOTIFICATION with Cease,
      - resets the connect retry timer (sets to zero)
      - deletes all routes associated with bgp peer session,
      - releases all BGP resources,
      - drops the transport connection,
      - increments the ConnectRetryCnt by 1,
      - performs any BGP peer oscillation damping, and
      [Action C in FSM table]
      - transitions to the idle state.

  An example automatic stop event is exceeding the number of
  prefixes for a given peer and the local system
  automatically disconnecting the peer.


  If the Hold timer expires [Event10], the local system:
       - sends a NOTIFICATION message with Error Code Hold
         Timer Expired,
       - resets the connect retry timer (sets to zero),
       - releases all BGP resources,
       - drops the TCP connection,
       - increments the ConnectRetryCnt by 1,
       -	performs any BGP peer oscillation damping,
       [Action M in FSM table]
       - and goes to Idle state.

  If the KeepAlive timer expires [Event11], the local system
  sends a KEEPALIVE message, it restarts its KeepAlive timer,
  unless the negotiated Hold Time value is zero [Action Q].

  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.


  A transport connection indication [Event 13] received
  for a valid port will cause the 2nd connection to be
  tracked.  A transport connection indications for
  invalid port [Event 14], will be ignored.

  In response to a Transport connection succeeds [Event 15
  or Event 16], the 2nd connection shall be tracked until
  it sends an OPEN message.

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

      - send a NOTIFICATION with a CEASE
      - deletes all routes associated with connection,
      - resets the connect retry timer,
      - if any BGP routes, delete the routes,
      - release all BGP resources,
      - drops the transport connection,
      - increments ConnectRetryCnt by 1,
      - and performs any BGP peer oscillation damping,
     [Action R in the FSM table],
      - and enters the Idle state


  In response to any other event [Events 8-9,12, 19-21] the
  local system:
      - sends a NOTIFICATION message with Error Code Finite
        State Machine Error,
      - deletes all routes associated with BGP peer session,
      - resets the connect retry timer (sets to zero)
      - releases all BGP resources,
      - drops the TCP connection,
      - increments the ConnectRetryCnt by 1,
      - performs any BGP peer oscillation damping, and
      [Action E in FSM table],
      - transitions to Idle.




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA03005 for <[e-mail]>; Mon, 26 Aug 2002 14:13:27 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3296191255; Mon, 26 Aug 2002 14:12:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA52691257; Mon, 26 Aug 2002 14:12:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D22091255 for <[e-mail]>; Mon, 26 Aug 2002 14:12:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DC9F35DEE9; Mon, 26 Aug 2002 14:12:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 436D85DD93 for <[e-mail]>; Mon, 26 Aug 2002 14:12:50 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7QICl412470; Mon, 26 Aug 2002 14:12:47 -0400 (EDT) (envelope-from [e-mail])
Received: from SKH.nexthop.com ([64.211.218.13]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7QICh112461; Mon, 26 Aug 2002 14:12:43 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 26 Aug 2002 14:12:28 -0400
To: yakov Rekhter <[e-mail]>
From: Susan Hares <[e-mail]>
Subject: Working Group last call
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_16514035==_"
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

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



We are starting a working group last call on the
FSM words for the draft-18.  These were sent out by Bill Fenner
in July at the IETF.  I have received comments on the
state machine draft, but I have not received any comments on these words.

Please send any comments on the attached words to the IDR
mail group.  I will send the words in the next message as well.



Please send any comments on the state machine document:

http://www.ietf.org/internet-drafts/draft-hares-bgp-statemt-01.txt

to me.  I have distributed to some individuals a -02 version.
I will be sending to the Internet draft -03 to the IETF secretary for
posting.  Could anyone who has specific text changes send it by
Tuesday evening?  I'll be sending in the draft to the IETF secretary
on Wed am.

We will be focusing on discussing the FSM words for the next 2 weeks.

Sue
--=====================_16514035==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="FSM-words-05b.txt"



Note: (this is version 5 of the changes to
       the text.) 

8.0	BGP Finite State Machine


This section specifies the BGP operation in terms of a 
Finite State Machine (FSM).  The section falls into 2 
parts:

    1)	Description of Events for the State machine (section 
        8.1
    2)	Description of the FSM (section 8.2)

Session Attributes required for each connection are; 

   1)	state
   2)	Connect Retry timer
   3)	Hold timer
   4)	Hold time
   5)	Keepalive timer

8.1 Events for the BGP FSM

8.1.1   Administrative Events (events 1-5)

Please note that only Event 1 (manual start) and Event 2 
(manual stop) are mandatory administrative events. All 
other administrative events are optional.

 Event1: Manual start 

	   Definition: Administrator manually starts peer
                       connection
	   Status: 	Mandatory

 Event2: Manual stop

	   Definition: Local system administrator manually 
                       stops the peer connection.

	   Status: 	mandatory
	   

 Event3: Automatic Start

 	   Definition: Local system automatically starts the 
                       BGP peer session

	   Status:     Optional depending on local system

 Event4: Manual start with passive Transport Establishment

	   Definition: Administrator manually start the peer
                       Connection, but has the passive flag 
                       enabled.  The passive flag indicates 
                       that the peer will listen prior to 
                       establishing the connection.

	   Status:     Optional depending on local system
		

 Event5: Automatic start with passive Transport establishment

	  Definition:  Local system automatically starts the
                       BGP session with the passive flag 
                       enabled.  The passive flag indicates 
                       that the peer will listen prior to 
                       establishing a connection.

	  Status:      Optional depending on local system use
		       of a passive connection.

 Event6: Automatic start with bgp_stop_flap option set

	   Definition: Local system automatically starts the 
                       BGP peer session with persistent peer 
                       oscillation damping enabled.  The exact 
                       method of damping persistent peer 
                       oscillations is left up to the 
                       implementation.   These methods of 
                       damping persistent BGP adjacency 
                       flapping are outside the scope of this 
                       document.
 

           Status: 	Optional, used only if the bgp peer has 
	  	        Enabled a method of damping persistent
		        BGP peer flapping.


 Event7: Auto stop

	   Definition: Local system automatically stops the
                       BGP peer session.  
	
	   Status:     Optional depending on local system


8.1.2 Timer Events (events 8-11)

 Event8:  idle Hold timer expires 

           Definition: Idle Hold timer expires.  The Idle 
                       Hold Timer is only used when persistent  
                       BGP oscillation damping functions are 
                       enabled.  

           Status: 	Optional.  Used when persistent
			BGP peer oscillation damping functions
			are enabled. 



 Event9: connect retry timer expires

           Definition: An event triggered by the expiration of 
                       the ConnectRetry timer.
  
	   Status:     Mandatory

 Event10: hold time expires

	   Definition: An event generated when the HoldTimer 
                       expires.

	   Status:     Mandatory

 Event11: keepalive timer expires

	   Definition: A periodic event generated due to the 
                       expiration of the KeepAlive Timer. 
 
	   Status:     Mandatory

 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. 

	   status:     Optional

8.2.3) Tranport Message based (13-16) 

 Event13: Transport Connection Indication & valid remote peer[changed]

	   Definition: Event indicating that transport
                       Request 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.


	   Status:     Mandatory

 Event14: RCV Transport Connection Indication and Invalid Source or 
          Destination [changed]

           Definition: Transport request received 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.

	    Status: 	 Mandatory
	
 Event15: Transport Connection request sent received an ACK.

           Definition: Local system's request to establish a transport
		       Connection to the remote side received
		       an ACK.


	    Status:    Mandatory

 Event16: Transport Connection Confirmed [changed]

	   Definition: The local system has received a Confirmation that
                       the transport connection has been established by
		       the remote site. 

	  Status:      Mandatory

 Event17: Transport connection fails [changed]

           Definition: This BGP peer receives a transport
		       connection failure notice.  This
		       connection notice could be caused by a
		       Transport disconnect message or a
		       Timeout in the transport session.

                       If this connection is using TCP, 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


8.1.4 BGP Messages (18-27)

 Event18: BGPOpen

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

	   Status: 	Mandatory

 Event19: BGPOpen with BGP Delay Open Timer running [changed]

           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. 

	    Status:    Optional

 Event20: BGPHeaderErr

	   Definition: BGP message header is not valid.  

	   Status:     Mandatory

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


 Event22: Open collision discard

           Definition: An event generated administratively 
                       when a connection Collision has been 
                       detected while processing an incoming  
                       Open message. This connection has been 
                       selected to disconnected.  See section 
                       6.8 for more information on collision
	               detection.  

                       Event 22 is an administrative could 
                       occur if FSM is implemented as two 
                       linked state machines.  

	  Status:      Optional

 Event23: NotifMsgVerErr

	    Definition: An event is generated when a 
                        NOTIFICIATION message with "version   
                        error" is received.

	    Status:     Mandatory

 Event24: NotifMsg

	    Definition: An event is generated when a 
                        NOTIFICATION messages is received and
                        the error code is anything but 	 
			"version error".

	     Status:	Mandatory
		        
 Event25: KeepAliveMsg

	    Definition: An event is generated when a KEEPALIVE
			Message is received.

		Status: Mandatory

 Event26: UpdateMsg

	    Definition: An event is generated when a valid 
			Update Message is received.

		Status: Mandatory

 Event27: UpdateMsgErr

	    Definition: An event is generated when an invalid
			Update message is received.

		Status:	Mandatory

 
8.2) Description of FSM


Idle state

   Initially BGP is in the Idle state.   

   In this state BGP refuses all incoming BGP connections.  No 
   resources are allocated to the peer.    In response to a 
   manual start event(Event1) or an automatic start 
   event(Event3), the local system 
      -	initializes all BGP resources, 
      -	sets the Connect retry counter to zero
      -	starts the ConnectRetry timer with initial value, 
      -	initiates a transport connection to the other BGP 
        peer, 
      -	listens for a connection that may be initiated by 
        the remote BGP peer, and
        [Action A in the FSM table]
      -	changes its state to connect.

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

  In response to a manual start event with the passive Transport
  flag (Event 4) or automatic start with the passive Transport flag 
  (Event 5), the local system:
      -	initializes all BGP resources,
      -	sets the connect retry count to zero,
      -	start the Connect Retry timer with initial value, 
      -	listens for a connection that may be initiated by 
        the remote peer
        [Action B in the FSM table] 
      -	changes its state to Active.

  The exact value of the ConnectRetry timer is a local 
  matter, but it should be sufficiently large to allow TCP 
  initialization.   

  If a persistent BGP peer oscillation damping function is 
  enabled, two additional events may occur within Idle state:  
      -	Automatic start with bgp_stop_flap set [Event6],
      -	Idle Hold Timer expired [Event 8].

  The method of preventing persistent BGP peer oscillation is 
  outside the scope of this document.

  Any other events [Events 9-27] received in the Idle state, 
  are noted by the MIB processing as FSM Errors [action V]
  and the local peer stays in the Idle State.


Connect State:

  In this state, BGP is waiting for the transport protocol 
  connection to be completed.

  If the transport connection succeeds [Event 15 or 
  Event 16], the local system checks the "Delay Open 
  Flag".  If the Delay Open flag is set, the local system: 
     -	clears the ConnectRetry timer, 
     -	set the BGP Open Delay timer to the initial 
        value.
        [Action ZZ in FSM table]

  If the Delay Open flag is not set, the local system: 
     - clears the ConnectRetry timer, 
     - completes BGP initialization
     - send an Open message to its peer,
     - sets Hold timer to a large value,
     - Change the state to Open Sent 
   [Action H in the FSM table]

  A hold timer value of 4 minutes is suggested.

  If the Open Delay timer expires [Event 12] in the connect 
  state,
     - send an Open message to its peer,
     - set the Hold timer to a large value,
	[Action H in the FSM Table], and
     - change the state to Open Sent. 

  If the BGP port receives a Transport connection indication 
  [Event 13], the Transport connection is processed (actions AA or
  AB in the FSM table) and the connection remains
  in the connected state. 

  If the transport connection receives an Transport indication
  that is invalid or unconfigured. [Event 14]:
     - the transport connection is rejected.
	[Action L in the FSM table]

  If the transport connection fails (timeout or transport
  disconnect) [Event17], the local system:
      - restarts the ConnectRetry timer, 
      - continues to listen for a connection that may be 
        initiated by the remote BGP peer, and
     [Action G in the FSM table]
      - changes its state to Active. 


  If an Open is received with the BGP Delay Open timer is 
  running [Event 19], the local system:
	- clears the connect retry timer (cleared to zero),
	- completes the BGP initialization, 
	- Stops and clears the BGP Open Delay timer
	- Sends an Open message

	[Action H in the FSM table], and
	- changes its state to Open Confirm.


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

 A manual stop event[Event2], the local system:
       - drops the transport connection, 
       - releases all BGP resources,
       - sets connect retry count to zero
       - resets the connect retry timer (sets to zero)
      [Action Z in the FSM table]
       - goes to Idle state.

  In response to the ConnectRetry timer expired event(Event 
  9), the local system: 
      - Sets the MIB FSM error information with ConnectRetry 
        expired, 
      - drops the transport connection 
      - 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
      [Action O in the FSM table]
      - stays in Connect state.

 In response to any other events [Events 7-8, 10-11, 18, 20-
 27] the local system:
     - resets the connect retry timer (sets to zero),
     - drops the Transport connection,
     - release all BGP resources, 
     - increments the ConnectRetryCnt by 1,
     - [optionally] performs bgp peer oscillation damping, and
     [Action D in the FSM table],
     - goes to Idle state.


Active State:

 In this state BGP is trying to acquire a peer by listening 
 for and accepting a transport protocol connection.  

 A transport connection succeeds [Event 15 or Event 16], the 
 local system: process the transport connection flags
	- If the BGP delay open flag is set:
          o clears the ConnectRetry timer, 
          o completes the BGP initialization,
          o sets the BGP delay Open timer
         [Action ZZ]

        - If the BGP delay open flag is not set:
          o clears the ConnectRetry timer,
          o completes the BGP initialization, 
          o sends the Open message to it's peer, 
          o sets its Hold timer to a large value, 
         [Action H in the FSM table]
          and changes its state to OpenSent.  

 A Hold timer value of 4 minutes is suggested.  

 If the local system receives a valid Transport Indication
 [Event 13], the local system processes the Transport flags
  (actions aa or ab in FSM section 2.3.4).  

 If the local system receives a Transport indication
 that is invalid for this connection [Event 14]:
      - the transport connection is rejected
        [Action L in the FSM table]

 If the local system receives a Transport connection
 failed [Event 17] (timeout or receives Transport
 disconnect), the local system will:
	- set Transport disconnect in the MIB reason code,
	- restart ConnectRetry timer (with initial value)
	- release all BGP resources
	- Acknowledge the drop of Transport connection if
          transport disconnect (If TCP, send a FIN ACK),
	- Increment ConnectRetryCnt by 1,
	- perform the BGP peer oscillation damping process [2]
	[Action Y in the FSM table]

 If the local system has the Delay Open timer expired [event 
 12] local system: 
        - clears the Connect Retry timer (set to zero),
	- stops and clears the Delay Open timer (set to zero) 
        - completes the BGP initialization,
        - sends the Open message to it's remote peer,
        - sets it's Hold timer to a large value,
        [Action H in the FSM table]
        - and set the state to Open Confirm.

 A Hold timer value of 4 minutes is also suggested for this 
 state transition.

 If an Open is received with the BGP Delay Open timer is 
 running [Event 19], the local system 
	- clears the connect retry timer (cleared to zero),
	- Stops and clears the BGP Open Delay timer  
	- completes the BGP initialization, 
	- Stops and clears the BGP Open Delay timer
	- Sends an Open message
	- Set the Hold timer to a large value (4 minutes),
	[Action H in the FSM table], and
	- changes its state to Open Confirm.


 In response the ConnectRetry timer expired event[Event9], 
 the local system:
        - restarts the ConnectRetry timer (with initial value),
        - initiates a transport connection to the other BGP 
          peer,
        - Continues to listen for transport connection that may be 
          initiated by remote BGP peer, 
        [Action F in the FSM table]
	- and changes its state to Connect.  


 The start events [Event1, 3-6] are ignored in the Active 
 state.

 A manual stop event[Event2], the local system:
        - Sets the administrative down in the MIB reason code,
	- Sends a notification with a Cease,
	- If any BGP routes exist, delete the routes
	- release all BGP resources, 
	- drops the Transport connection, 
        - sets connect retry count to zero
        - resets the connect retry timer (sets to zero)
        [Action S in the FSM table]
        - goes to Idle state.

 In response to any other event (Events 7-8, 10-11,18, 20-
 27), the local system:
        - stores the MIB information to indicate appropriate 
          error [FSM for Events 7-8, 10-11, 18, 20-27]
        - reset the connect retry timer (sets to zero),
        - release all BGP resources, 
	- drops the transport connection, 
        - increments the ConnectRetryCnt by one,
        - optionally performs BGP peer oscillation damping, 
  	  [Action D in FSM table],
	- and goes to the idle state


Open Sent:

 In this state BGP waits for an Open Message from its peer.  

 When an OPEN message is received, all fields are checked 
 for correctness.  If there are no errors in the OPEN message 
 [Event 18] the local system:
       - resets the BGP Delay timer to zero,
       - reset BGP Connect Timer to zero, 
       - sends a KEEPALIVE message and
       - sets a KeepAlive timer (via the text below)
       - sets the Hold timer according to the negotiated value 
         (see section 4.2), and 
         [Action N in the FSM table]
       - sets 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 the BGP message header checking [Event20] or OPEN message
 check detects an error (see Section 6.2)[Event21], the local system:
       - sends a NOTIFICATION message with appropriate error 
         code, 
       - reset the connect retry timer (sets to zero),
       - if there are any routes associated with the BGP session,
	 delete these routes
       - release all BGP resources,
       - drop the transport session 
       - increments the ConnectRetryCnt by 1, 
       - bgp peer oscillation damping process,  
       [Actions I, J in FSM table, depending on error],
       - and goes to the Idle state.

 Collision detection mechanisms (section 6.8) need to be 
 applied when a valid BGP Open is received [Event 18 or 
 Event 19].  Please refer to section 6.8 for the details of 
 the comparison. An administrative collision detect is when 
 BGP implementation determines my means outside the scope of 
 this document that a connection collision has occurred.   

 If a connection in Open Sent is determined to be the 
 connection that must be closed, an administrative collision 
 detect [Event 22] is signaled to the state machine. If such 
 an administrative collision detect dump [Event 22] is 
 received in Open Sent, the local system:  
       - sets MIB state information to 
         collision detect closure, 
       - send a NOTIFICATION with a CEASE
       - resets the connect retry timer,
       - release all BGP resources,
       - drop the transport connection,
       - increments ConnectRetryCnt by 1,
       - performs any BGP peer oscillation damp process, and
       [Action R in the FSM],
       - enters Idle state.


  If a NOTIFICATION message is received with a version 
  error[Event23], Notification message without version number 
  [Event 24], the local system: 
       - resets the connect retry timer (sets to zero)
       - drops the Transport connection,
       - releases all BGP resources, 
       - increments the ConnectRetryCnt by 1
       - process any BGP peer oscillation damping,
	[Action Y]  
       - and sets the state to Idle.


 The Start events [Event1, 3-6] are ignored in the OpenSent 
 state.

  If a manual stop event [Event 2] is issued in Open sent 
 state, the local system:
	- Sets administrative down reason in MIB reason,
	- sends the Notification with a cease,
	- if BGP routes exists, delete the routes,
	- Release all BGP resources, 
	- Drops the Transport connection, 
	- set ConnectRetryCnt to zero, 
	- resets the Connect Retry timer (set to zero),
	[Action S in the FSM table], and
	- transitions to the Idle state.

  If an automatic stop event [Event 7] is issued in Open sent 
  state, the local system:
	- Sets administrative down reason in MIB reason,
	- sends the Notification with a cease,
	- if any routes are associated with te BGP session,
	  delete the routes, 
	- release all the BGP resources
	- Drops the Transport connection, 
	- increments the ConnectRetryCnt by 1, 
	- BGP peer oscillation process [2]
	[Action C in the FSM table], and
	- transitions to the Idle state.

 If the Hold Timer expires[Event 10], the local system:
       - set Hold timer expired in MIB Error reason code, 
       - send a NOTIFICATION message with error code Hold 
         Timer Expired,
       - reset the connect retry timer (sets to zero),
       - releases all BGP resources,
       - drops the Transport connection, 
       - increments the ConnectRetryCnt by 1
         [Action K in the FSM table], and
	- transitions to the Idle state.


 If a transport indication is received for valid connection 
 [Event 13] or transport Request Acknowledgement [Event 15]
 is received, or a transport connect confirm [Event 16] is
 received a second TCP session may be in progress.  This
 second TCP session is tracked per the Call Collision 
 processing (section 6.8) until an OPEN message is received.

 A TCP connection for an invalid port [Event 14] is ignored. 

 If a Transport Failure [Event17], 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,
       [Action O in the FSM table]
       - and goes into Active state.


 In response to any other event [Events 8-9, 11-12, 19, 25-27], 
  the local system:
	- sends the NOTIFICATION with the Error Code Finite 
          state machine error,
        - resets the connect retry timer (sets to zero),
	- releases all BGP resources
        - drops the Transport connection, 
        - increments the ConnectRetryCnt by 1, 
        - process any bgp peer oscillation damping[2] 
        [Action E in the FSM table],
        - and sets the state to idle.


Open Confirm State

 In this state BGP waits for a KEEPALIVE or NOTIFICATION 
 message.

 If the local system receives a KEEPALIVE message[Event 25], 
        - restarts the Hold timer, 
          [Action P in the FSM table], and
        - changes its state to Established. 


 If the local system receives a NOTIFICATION message [event 
 23-24] or receives a TCP Disconnect [event 17] from the 
 underlying transport protocol, the local system:  
        - sets the appropriate MIB information for FSM error, 
        - resets the connect retry timer (sets the timer to 
          zero),
	- releases all BGP resources, 
        - drops the TCP connection,
        - increments the ConnectRetryCnt by 1, 
        [Action Y in the FSM table],
        - and sets the state to idle.

 Any start event [Event1, 3-6] is ignored in the OpenConfirm 
 state.

 In response to a manual stop event[Event 2] initiated by 
 the operator, the local system: 
	- set Administrative down in MIB Reason code,
        - sends the NOTIFICATION message with Cease, 
	- if any BGP routes, dete the routes
        - releases all BGP resources, 
	- drop the transport connection, 
        - sets the ConnectRetryCnt to zero
        - sets the connect retry timer to zero
        [Action S in the FSM table]
        - transitions to Idle state.

 In response to the Automatic stop event initiated by the 
 system[event 7], the local system:
        - sets the MIB entry for this peer to administratively 
          down, 
        - sends the NOTIFICATION message with Cease,
	- connect retry timer reset (set to zero)
	- If any BGP routes exist, delete the routes,
	- release all BGP resources,
        - drops the transport connection,
        - increments the ConnectRetryCnt by 1, 
        [Action C in the FSM table], and
        - transitions to the Idle State.

 If the Hold Timer expires before a KEEPALIVE message is 
 received [event10], the local system:
        - set the MIB reason to Hold time expired, 
        - send the NOTIFICATION message with the error code 
          set to Hold Time Expired, 
        - resets the connect retry timer (sets the timer to to 
          zero),
	- releases all BGP resources, 
        - drops the transport connection, 
        - increments the ConnectRetryCnt by 1 
          [Action K in the FSM table], 
        - and sets the state to Idle.


 If the local system receives a KEEPALIVE timer expires 
 event [Event 11], the system:
        - sends a KEEPALIVE message,
        - restarts the Keepalive timer 
        [Action Q the in FSM table],and 
        - remains in Open Confirmed state.

 In the event of TCP establishment [Event 13], or TCP 
 connection succeeding [Event 15 or Event 16] while in Open 
 Confirm, the local system needs to track the 2nd 
 connection.  

 If a TCP connection is attempted to an invalid port [Event 
 14], the local system will ignore the second connection 
 attempt.  

 If an OPEN message is received, all fields are check for 
 correctness.  If the BGP message header checking [Event20] 
 or OPEN message check detects an error (see Section 
 6.2)[Event21], [the local system:
        - sends a NOTIFICATION message with appropriate error 
          code, 
        - resets the connect retry timer (sets the timer to 
          zero),
        - releases all BGP resources, 
        - drops the TCP connection,
        - increments the ConnectRetryCnt by 1, 
        - runs the BGP peer oscillation damping process [2]  
       [Actions I, J, in the FSM table depending on the error]
        - and goes to the Idle state.

 If the Open messages is valid [Event 18], the collision 
 detect function is processed per section 6.8.  If this 
 connection is to be dropped due to call collision, the 
 local system:
        - sets the Call Collision cease in the MIB reason 
         code,
        - sends a Notification with a Cease 
        - resets the Connect timer (set to zero),
	- releases all BGP resources,
	- Drops the TCP connection (send TCP FIN),
	- increments the ConnectRetryCnt by 1, and
	- performs any BGP peer oscillation damping process [2].
	[action 


 If during the processing of another Open message, the BGP 
 implementation determines my means outside the scope of 
 this document that a connection collision has occurred and 
 this connection is to be closed, the local system will 
 issue a call collision dump [Event 22].  When the local 
 system receives a call collision dump event [Event 22], the 
 local system:
        - Sets the MIB FSM variable to indicate collision 
          detected and dump connection.
        - send a NOTIFICATION with a CEASE
        - deletes all routes associated with connection,
        - resets the connect retry timer,
        - releases all BGP resources
        - drops all TCP connection,
        - increments the ConnectRetryCnt by 1, 
        - and performs any BGP peer oscillation damping,
        [Action R in the FSM table],
        - enters Idle state.

 In response to any other event [Events 8-9, 12, 19, 26-27], 
 the local system:
        - sends a NOTIFICATION with a code of Finite State 
          Machine Error,
        - resets the connect retry timer (sets to zero)
        - drops the TCP connection,
        - releases all BGP resources, 
        - increments the ConnectRetryCnt by 1, 
        - performs any BGP peer oscillation damping,
        [Action E in the FSM table], and 
        - transitions to Idle state.


Established State:

 In the Established state BGP can exchange UPDATE, 
 NOTFICATION, and KEEPALIVE messages with its peer.

 If the local system receives an UPDATE message [Event26], 
 the local system will:
	- process the update packet
	- restarts its Hold timer, if the negotiated Hold Time 
          value is non-zero.
	[Action W in the FSM table], and
	- remain in the Established state.

 
 If the local system receives a NOTIFICATION message 
 [Event23 or Event24] or a disconnect [Event17] from the 
 underlying transport protocol, it:
	- sets the appropriate error code in MIB reason code,
	- if any BGP routes exist, delete all BGP routes,  
        - resets the connect retry timer (sets to zero), 
        - releases all the BGP resources, 
	- drops the TCP connection,
	- increments the ConnectRetryCnt by 1, and 
       [Action T in the FSM table]   
	- Goes to the Idle state.


 If the local system receives a Keepalive message
 [Event 25], the local system will:
        - restarts its Hold Timer, if the negotiated Hold Time 
          value is non-zero.
       [Action P in the FSM table], and
	- remain in the Established state.

 If the local system receives an UPDATE message, and the 
 Update message error handling procedure (see Section 6.3) 
 detects an error [Event27], the local system:
       - sends a NOTIFICATION message with Update error,
       - resets the connect retry timer (sets to zero),
       - drops the TCP connection,
       - releases all BGP resources, 
       - increments the ConnectRetryCnt by 1 
       - performs any BGP peer oscillation damping
      [Action U in FSM table], 
       - and goes to Idle state.


 Any start event (Event 1, 3-6) is ignored in the 
 Established state.

 In response to a manual stop event (initiated by an 
 operator)[Event2]:
        - sets the Administrative stop in MIB reason code, 
	- sends the NOTIFICATION message with Cease, 
        - if BGP routes exist, delete the BGP routes, 
        - release BGP resources,
	- drop TCP connection, 
        - set ConnectRetryCnt to zero (0),
        - reset connect retry timer to zero (0), and
        [Action S in FSM table]
        - transition to the Idle.

 In response to an automatic stop event initiated by the 
 system (automatic) [Event7], the local system:
     - sets Administrative Stop in MIB Reason code, 
     - sends a NOTIFICATION with Cease,
     - resets the connect retry timer (sets to zero)
     - deletes all routes associated with bgp peer session,
     - releases all BGP resources, 
     - drops the transport connection,   
     - increments the ConnectRetryCnt by 1, 
     - performs any BGP peer oscillation damping, and 
     [Action C in FSM table]
     - transitions to the idle state.

 An example automatic stop event is exceeding the number of 
 prefixes for a given peer and the local system 
 automatically disconnecting the peer.


 If the Hold timer expires [Event10], the local system:
      - sends a NOTIFICATION message with Error Code Hold 
        Timer Expired,
      - resets the connect retry timer (sets to zero),
      - releases all BGP resources, 
      - drops the TCP connection, 
      - increments the ConnectRetryCnt by 1,  
      -	performs any BGP peer oscillation damping,
      [Action M in FSM table] 
      - and goes to Idle state.

 If the KeepAlive timer expires [Event11], the local system 
 sends a KEEPALIVE message, it restarts its KeepAlive timer, 
 unless the negotiated Hold Time value is zero [Action Q].

 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.


 A transport connection indication [Event 13] received
 for a valid port will cause the 2nd connection to be
 tracked.  A transport connection indications for 
 invalid port [Event 14], will be ignored. 
 
 In response to a Transport connection succeeds [Event 15
 or Event 16], the 2nd connection shall be tracked until
 it sends an OPEN message.  

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

     - send a NOTIFICATION with a CEASE
     - deletes all routes associated with connection,
     - resets the connect retry timer,
     - if any BGP routes, delete the routes,
     - release all BGP resources, 
     - drops the transport connection,
     - increments ConnectRetryCnt by 1,
     - and performs any BGP peer oscillation damping,
    [Action R in the FSM table],
     - and enters the Idle state


 In response to any other event [Events 8-9,12, 19-21] the 
 local system:
     - sends a NOTIFICATION message with Error Code Finite 
       State Machine Error,
     - deletes all routes associated with BGP peer session, 
     - resets the connect retry timer (sets to zero)
     - releases all BGP resources,
     - drops the TCP connection,
     - increments the ConnectRetryCnt by 1, 
     - performs any BGP peer oscillation damping, and
     [Action E in FSM table],
     - transitions to Idle.


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


--=====================_16514035==_--



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA02219 for <[e-mail]>; Mon, 26 Aug 2002 13:52:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 698389124C; Mon, 26 Aug 2002 13:52:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 312A191255; Mon, 26 Aug 2002 13:52:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF1779124C for <[e-mail]>; Mon, 26 Aug 2002 13:52:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CC8735DEC0; Mon, 26 Aug 2002 13:52:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id 16D155DD93 for <[e-mail]>; Mon, 26 Aug 2002 13:52:31 -0400 (EDT)
Received: from [192.168.42.10] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA03365; Mon, 26 Aug 2002 13:52:16 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a53b98fd85f3503@[171.69.182.142]>
In-Reply-To: <005e01c24cc9$da653b00$[e-mail]>
References: <005e01c24cc9$da653b00$[e-mail]>
Date: Mon, 26 Aug 2002 13:47:59 -0400
To: lidefeng <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: A draft about BGP protection,Please review
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Since draft-huawei-bgp-protection-md5-00.txt does not protect the 
transport layer, some other form of transport layer protection would 
be required in order to protect against RST attacks and the like.  In 
fact, this is exactly why RFC 2385 style protection was developed as 
a TCP option instead of using the BGP authentication field.

Considering that (a) transport layer protection is required anyway, 
(b) as a subset of its functionality it provides substantially the 
same benefits as application layer protection and (c) it's 
well-deployed already, I don't see the motivation for developing 
application layer protection as your draft describes.

Regards,

--John Scudder

At 2:28 PM +0800 8/26/02, lidefeng wrote:
>hi,
>
>     As to the protection of BGP route information, we propose an 
>efficient mechanism as described
>in draft-huawei-bgp-protection-md5-00.txt.
>    Please reviev it as soon as possible.Thanks
>
>Regards
>
>Li Defeng
>
>
>Attachment converted: JGS TiBook:draft-huawei-bgp-protection-md5 
>(TEXT/R*ch) (000A84F0)



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA01890 for <[e-mail]>; Mon, 26 Aug 2002 13:42:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B1EDE91246; Mon, 26 Aug 2002 13:42:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D8E69124C; Mon, 26 Aug 2002 13:42:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 46E8291246 for <[e-mail]>; Mon, 26 Aug 2002 13:42:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2E46A5DE6E; Mon, 26 Aug 2002 13:42:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 84B635DD93 for <[e-mail]>; Mon, 26 Aug 2002 13:42:12 -0400 (EDT)
Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7QHgCm63674; Mon, 26 Aug 2002 10:42:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id g7QHgBX80795; Mon, 26 Aug 2002 10:42:11 -0700 (PDT) (envelope-from roque)
Date: Mon, 26 Aug 2002 10:42:11 -0700 (PDT)
Message-Id: <[e-mail]>
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: lidefeng <[e-mail]>
Cc: [e-mail]
Subject: A draft about BGP protection,Please review
In-Reply-To: <005e01c24cc9$da653b00$[e-mail]>
References: <005e01c24cc9$da653b00$[e-mail]>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Sender: [e-mail]
Precedence: bulk

lidefeng  writes:

> 3.0 Security Considerations

>     This BGP extension mechanism provides an simple but efficient
> method to protect the security of BGP route information,compared
> with other methods which encrypt the whole BGP message,the impact to
> the performance of route protocol will be sustainable,and in
> contrast to the existing BGP security mechanism such as RFC2385,
> which is from the perspective of the transport layer ,this mechanism
> takes measure on the application layer and do nothing to the
> transport layer.

Li,
RFC 2385 protects you against attacks on the TCP session in addition
to autenticating the BGP data. Causing a valid BGP session to be reset
via attacks at the TCP layer is a very effective DOS attack which is
still possible under your proposal.

Effectivly BGP relies on its transport layer to provide it w/ a
session. Authentication needs to be a property of that session, since
events on the session are so or more important than the data in the
session itself.

Protecting BGP data does not address some of the most important
concerns.

  Pedro.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA28740 for <[e-mail]>; Mon, 26 Aug 2002 12:04:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 11B8991247; Mon, 26 Aug 2002 12:04:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DACFD9125E; Mon, 26 Aug 2002 12:04:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0B3C59124C for <[e-mail]>; Mon, 26 Aug 2002 12:03:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DF7415DE93; Mon, 26 Aug 2002 12:03:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 64F705DD93 for <[e-mail]>; Mon, 26 Aug 2002 12:03:13 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA01332; Mon, 26 Aug 2002 12:03:11 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA28285; Mon, 26 Aug 2002 12:03:12 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <RHFQ9QVA>; Mon, 26 Aug 2002 12:03:11 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Pedro Roque Marques'" <[e-mail]>, Alex Zinin <[e-mail]>
Cc: Randy Bush <[e-mail]>, [e-mail]
Subject: RE: BGP INFORM message
Date: Mon, 26 Aug 2002 12:03:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Pedro:

> 
> It is also not clear to me that the existing -1[6-7] draft is closer
> to 'reality' than RFC 1771, even because 'reality' is hard to pinpoint
> here (depends on implementations, version of such implementations,
> deployment configs, etc). We might just end up trading a set of
> divergences between document and deployment for another.
> 
> I would also caution against attempting to over-specify particular
> areas. With apologies in advance to Sue, which i'm sure put a lot of
> work on it, imho having a detailed state machine doesn't really add
> value. It is imho too close to implementation details and probably
> impossible to verify. As an implementor, i prefer when a spec
> documents what is intended (and why as a bonus) and the minimum
> details necessary to interoperate.
>

If the RFC standard was precise in how to implement the interface between 
peers, there would not be any enterpretations or guess work between 
vendors. The behavior of a given peer would be 100% predictable. If we
document vague or generally non-specific ways of doing things, each vendor 
will do it their way, that will eventually create operational bugs.

I totally disagree with you that divergence will occur due to over 
specification. 

Over specifying a external interface or internal functionality that leads 
to external interface behavior is a GOOD thing, specifying an internal 
or particular vendor way of doing things is BAD. 

Ben

P.S. I rather have discussions on why did you specify it this way, than 
what does this mean in the spec.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA28096 for <[e-mail]>; Mon, 26 Aug 2002 11:44:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 532669124A; Mon, 26 Aug 2002 11:44:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1EDD49124B; Mon, 26 Aug 2002 11:44:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F27E9124A for <[e-mail]>; Mon, 26 Aug 2002 11:44:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 17C165DE93; Mon, 26 Aug 2002 11:44:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 774CC5DD93 for <[e-mail]>; Mon, 26 Aug 2002 11:44:30 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29844; Mon, 26 Aug 2002 11:44:26 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA21539; Mon, 26 Aug 2002 11:44:27 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <RHFQ93N5>; Mon, 26 Aug 2002 11:44:26 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: IDR WG charter
Date: Mon, 26 Aug 2002 11:44:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov and all IDR List Users:

  Is it possible to have two groups active at the same time? 1. The current
group 
which needs to complete active IDR charter tasks as highlighted by Bill
Fenner. 
2. Advance group which wishes to pursue new ideas in improving BGP
technology for
the benefit of the Interdomain Routing across the Internet.

It seems to me that people do not want to entertain new GOOD ideas until
they 
finish old work. This is how we loose momentum in new and hopefully helpfull
technologies that will move us from Point A to Point B. The impact of saying
to someone, we can not accept this draft or idea now because we over booked
with old business tends to discourage further and new creative developments.


If we had a list or a working group for new IDR ideas we could keep the old
work 
and new work from impacting each other. I am sure there are plenty of people
who would not mind persuing this approach if IDR committee agrees to such a
plan.

Thanks in Advance, 
Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Monday, August 26, 2002 10:18 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: IDR WG charter
> 
> 
> Folks,
> 
> Please comment on the revised charter proposed by Bill and Alex
> (see below). The deadline for comments is Sep 10, 2002.
> 
> Sue & Yakov
> ------- Forwarded Message
> 
> Date:    Thu, 22 Aug 2002 16:11:10 -0700
> From:    Bill Fenner <[e-mail]>
> To:      [e-mail]
> Subject: BGP spec and IDR WG charter
> 
> Dear IDR WG,
> 
>   After some consideration, the Routing Area Directors have decided
> not to forward any IDR documents for IESG consideration until the
> base BGP spec update is finished.[*]  Despite the best efforts of all
> involved, the spec update has been taking an incredible amount of
> time.  We take this step in order to focus all possible resources
> of the WG community on the BGP spec update.
> 
>   This may seem like a negative action.  On the contrary, it is
> meant to support the accomplishment of the working group's goals.[**]
> The milestone for the submission of the BGP4 draft to the IESG
> was scheduled for January 2002.
> 
>   Attached is a proposed update for the IDR working group charter.
> Note that we just made up the dates in the goals and milestones,
> and the WG should come up with realistic ones.
> 
>   Bill and Alex
> 
> [*] "finished" means, in this case, WG consensus, WG Last Call,
> AD Review, IETF Last Call, and IESG approval for publication.
> 
> [**] In further support of the goal of having a quality specification
> that reflects current reality, the ADs have been working on assembling
> a team of reviewers that consists primarily of protocol implementors,
> who have committed their time to examine the spec.  We will be
> sending another message to this list explaining the details of how
> this team will do its work.
> 
> - - - -
> 
> The Inter-Domain Routing Working Group is chartered to standardize
> and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
> 1771] capable of supporting policy based routing for TCP/IP internets.
> The objective is to promote the use of BGP-4 to support IP version
> 4 and IP version 6. The working group will continue to work on
> improving the scalability of BGP.
> 
> The current tasks of the WG are limited to:
> 
> - - Revise and clarify the base BGP4 document (RFC 1771). Note that
> RFC 1771 no longer documents existing practice and one goal of the
> update is document existing practice. Determine whether the document
> can be advanced as full Standard or needs to recycle at Proposed
> or Draft Standard.
> 
> - - Submit updated MIBs to accompany the revised base BGP4 document.
> 
> Once these tasks are completed, work will progress on the following:
> 
> - - Review and Evaluate Existing RFCs on AS Confederations and Route
> Reflection. If changes are needed, create and advance revisions.
> 
> - - Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see
> if any changes need to be made based on current Internet practice
> or based on the changes to the current bgp draft. If changes are
> needed, create an revision. Issue the WG Last Call on advancing
> the document to Draft Standard.
> 
> - - Produce an updated MIB for AS Confederations, Route Reflection,
> Communities, Multi-Protocol BGP, etc..
> 
> - - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
> as Draft Standard.
> 
> - - Complete work on an Extended Community Attribute. Develop MIB
> for BGP Extended Communities.
> 
> - - Extend BGP to support a 4-byte AS number, develop plan for
> transitioning to usage of 4-byte AS numbers
> 
> - - Progress along the IETF standards track a BGP-based mechanism
> that allows a BGP speaker to send to its BGP peer a set of route
> filters that the peer would use to constrain/filter its outbound
> routing updates to the speaker. Currently defined in
> draft-ietf-idr-route-filter-03.txt.
> 
> - - Progress along standards track an Outbound Router Filter (ORF)
> type for BGP, that can be used to perform aspath based route
> filtering. The ORF-type will support aspath based route filtering
> as well as regular expression based matching for address groups.
> Currently defined in draft-ietf-idr-aspath-orf-00.txt.
> 
> Tasks for this working group are limited to those listed above;
> new items to be added to the charter must be approved by the IESG.
> 
> Goals and Milestones
> 
> DONE    Submit BGP Capability Advertisement to the IESG
> NOV 02  Submit BGP4 document to IESG.
> DEC 02  Submit updated base BGP4 MIB to IESG.
> MAR 03  Submit extensible BGP MIB to IESG.
> MAR 03  Submit Extended Communities draft to IESG.
> MAR 03  Submit 4-byte AS ID to IESG.
> MAR 03  Initial Draft for RFC2858 (if needed)
> MAR 03  BGP TCP MD5 signatures document to IESG.
> MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.
> 
> ------- End of Forwarded Message
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA27977 for <[e-mail]>; Mon, 26 Aug 2002 11:41:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D027E91249; Mon, 26 Aug 2002 11:41:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C66459124A; Mon, 26 Aug 2002 11:41:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 432B991249 for <[e-mail]>; Mon, 26 Aug 2002 11:41:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1D7485DE93; Mon, 26 Aug 2002 11:41:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 71BDC5DE27 for <[e-mail]>; Mon, 26 Aug 2002 11:41:15 -0400 (EDT)
Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g7QFcNd16409; Mon, 26 Aug 2002 09:38:24 -0600
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
To: Jeffrey Haas <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail], [e-mail]
From: Danny McPherson <[e-mail]>
Reply-To: [e-mail]
Subject: Re: IDR WG charter 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 26 Aug 2002 09:38:23 -0600
Sender: [e-mail]
Precedence: bulk

FWIW, I'm working with John and Paul on updating 3065 and 
a new version should be available within a week or so.  I 
believe I've already addressed both of your chief concerns
below, but I'll have another look to verify.  

The terminology use confusion and other mailing list stuff 
has mostly been addressed as well, I believe.

-danny


> I would like to also propose that we add a specific working group item of
> correcting a serious error in RFC 3065 - Autonomous System
> Confederations for BGP - that makes it impossible to implement
> an interoperable implementation, much less a functional one.
> 
> From the RFC:
> :   When a BGP speaker originates a route:
> [...]
> :   c) the originating speaker shall include its own autonomous system in
> :      an AS_SEQUENCE segment of the AS_PATH attribute of all UPDATE
> :      messages sent to BGP speakers located in neighboring autonomous
> :      systems that are not members of the local confederation.  (In this
> :      case, the autonomous system number of the originating speaker's
> :      member confederation will be the only entry in the AS_PATH
> :      attribute).
> 
> the above MUST read "the originating speaker shall include its own
> CONFEDERATION IDENTIFIER" (emphasis added).
> 
> Additionally, I would *like* clarification text added about 
> the receipt of confederation segments by non-confederation members.
> Ambiguities in this behavior were likely responsible for recent
> issues in the Internet.
> 
> Once we get to this point, we can dig out the text from the mailing
> list last time we went around on this.



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA27768 for <[e-mail]>; Mon, 26 Aug 2002 11:34:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 16ED491258; Mon, 26 Aug 2002 11:34:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 196CC91257; Mon, 26 Aug 2002 11:34:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 238EF9124A for <[e-mail]>; Mon, 26 Aug 2002 11:33:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0AB205DE93; Mon, 26 Aug 2002 11:33:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id EEB885DD93 for <[e-mail]>; Mon, 26 Aug 2002 11:33:28 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7QFXP305468; Mon, 26 Aug 2002 11:33:25 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7QFXF105442; Mon, 26 Aug 2002 11:33:15 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7QFXF010101; Mon, 26 Aug 2002 11:33:15 -0400 (EDT)
Date: Mon, 26 Aug 2002 11:33:15 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: IDR WG charter
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Aug 26, 2002 at 07:18:00AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

As to the working group items I have volunteered to spearhead:

On Mon, Aug 26, 2002 at 07:18:00AM -0700, Yakov Rekhter wrote:
> - - Submit updated MIBs to accompany the revised base BGP4 document.

This is partially awaiting final work on the base BGP document,
particularly the FSM.  Aside from that, there is corrective items
that need to go out.  I will endeavor to have new items submitted
to the [e-mail] by Friday.  I ask the list's attention
for the next day or so to help clarify any remaining issues
expeditiously.

> - - Produce an updated MIB for AS Confederations, Route Reflection,
> Communities, Multi-Protocol BGP, etc..
> 
> - - Complete work on an Extended Community Attribute. Develop MIB
> for BGP Extended Communities.
> 
> - - Extend BGP to support a 4-byte AS number, develop plan for
> transitioning to usage of 4-byte AS numbers

The v2mib covers each of these items.  Again, corrections will be
forthcoming in the next ID, hopefully submitted Friday.

> Once these tasks are completed, work will progress on the following:
> 
> - - Review and Evaluate Existing RFCs on AS Confederations and Route
> Reflection. If changes are needed, create and advance revisions.

I would like to also propose that we add a specific working group item of
correcting a serious error in RFC 3065 - Autonomous System
Confederations for BGP - that makes it impossible to implement
an interoperable implementation, much less a functional one.

>From the RFC:
:   When a BGP speaker originates a route:
[...]
:   c) the originating speaker shall include its own autonomous system in
:      an AS_SEQUENCE segment of the AS_PATH attribute of all UPDATE
:      messages sent to BGP speakers located in neighboring autonomous
:      systems that are not members of the local confederation.  (In this
:      case, the autonomous system number of the originating speaker's
:      member confederation will be the only entry in the AS_PATH
:      attribute).

the above MUST read "the originating speaker shall include its own
CONFEDERATION IDENTIFIER" (emphasis added).

Additionally, I would *like* clarification text added about 
the receipt of confederation segments by non-confederation members.
Ambiguities in this behavior were likely responsible for recent
issues in the Internet.

Once we get to this point, we can dig out the text from the mailing
list last time we went around on this.

> Goals and Milestones
> 
> DONE    Submit BGP Capability Advertisement to the IESG
> NOV 02  Submit BGP4 document to IESG.
> DEC 02  Submit updated base BGP4 MIB to IESG.
> MAR 03  Submit extensible BGP MIB to IESG.
> MAR 03  Submit Extended Communities draft to IESG.
> MAR 03  Submit 4-byte AS ID to IESG.
> MAR 03  Initial Draft for RFC2858 (if needed)
> MAR 03  BGP TCP MD5 signatures document to IESG.
> MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.

I would like to suggest to the AD's that although we can submit
MIBs to cover the various features, the v2 mib should only be
submitted as a complete document AFTER we have completed each of
the work items that it covers.

I don't expect many changes, but this makes procedural sense to 
avoid having to "fix" a published RFC.

I would also like to solicit some help from parties who are aware of
the relevant issues for protecting the BGP transport - either
via md5 or ipsec - to help me document relevant MIB issues.  My initial
opinion is that while these are valuable things, it is out of
scope of the actual protocol and thus should be documented by a MIB
drafted by the transport group (if such things don't already exist)
rather than via IDR.  If our AD's a WG chairs could chime in on this,
it would be appreciated.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA25344 for <[e-mail]>; Mon, 26 Aug 2002 10:19:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5D25991245; Mon, 26 Aug 2002 10:19:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E21179124A; Mon, 26 Aug 2002 10:19:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C20A691244 for <[e-mail]>; Mon, 26 Aug 2002 10:18:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9F6885DDAD; Mon, 26 Aug 2002 10:18:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 311575DD93 for <[e-mail]>; Mon, 26 Aug 2002 10:18:01 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7QEI0m49021; Mon, 26 Aug 2002 07:18:00 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: IDR WG charter
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 26 Aug 2002 07:18:00 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

Please comment on the revised charter proposed by Bill and Alex
(see below). The deadline for comments is Sep 10, 2002.

Sue & Yakov
------- Forwarded Message

Date:    Thu, 22 Aug 2002 16:11:10 -0700
From:    Bill Fenner <[e-mail]>
To:      [e-mail]
Subject: BGP spec and IDR WG charter

Dear IDR WG,

  After some consideration, the Routing Area Directors have decided
not to forward any IDR documents for IESG consideration until the
base BGP spec update is finished.[*]  Despite the best efforts of all
involved, the spec update has been taking an incredible amount of
time.  We take this step in order to focus all possible resources
of the WG community on the BGP spec update.

  This may seem like a negative action.  On the contrary, it is
meant to support the accomplishment of the working group's goals.[**]
The milestone for the submission of the BGP4 draft to the IESG
was scheduled for January 2002.

  Attached is a proposed update for the IDR working group charter.
Note that we just made up the dates in the goals and milestones,
and the WG should come up with realistic ones.

  Bill and Alex

[*] "finished" means, in this case, WG consensus, WG Last Call,
AD Review, IETF Last Call, and IESG approval for publication.

[**] In further support of the goal of having a quality specification
that reflects current reality, the ADs have been working on assembling
a team of reviewers that consists primarily of protocol implementors,
who have committed their time to examine the spec.  We will be
sending another message to this list explaining the details of how
this team will do its work.

- - - -

The Inter-Domain Routing Working Group is chartered to standardize
and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
1771] capable of supporting policy based routing for TCP/IP internets.
The objective is to promote the use of BGP-4 to support IP version
4 and IP version 6. The working group will continue to work on
improving the scalability of BGP.

The current tasks of the WG are limited to:

- - Revise and clarify the base BGP4 document (RFC 1771). Note that
RFC 1771 no longer documents existing practice and one goal of the
update is document existing practice. Determine whether the document
can be advanced as full Standard or needs to recycle at Proposed
or Draft Standard.

- - Submit updated MIBs to accompany the revised base BGP4 document.

Once these tasks are completed, work will progress on the following:

- - Review and Evaluate Existing RFCs on AS Confederations and Route
Reflection. If changes are needed, create and advance revisions.

- - Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see
if any changes need to be made based on current Internet practice
or based on the changes to the current bgp draft. If changes are
needed, create an revision. Issue the WG Last Call on advancing
the document to Draft Standard.

- - Produce an updated MIB for AS Confederations, Route Reflection,
Communities, Multi-Protocol BGP, etc..

- - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
as Draft Standard.

- - Complete work on an Extended Community Attribute. Develop MIB
for BGP Extended Communities.

- - Extend BGP to support a 4-byte AS number, develop plan for
transitioning to usage of 4-byte AS numbers

- - Progress along the IETF standards track a BGP-based mechanism
that allows a BGP speaker to send to its BGP peer a set of route
filters that the peer would use to constrain/filter its outbound
routing updates to the speaker. Currently defined in
draft-ietf-idr-route-filter-03.txt.

- - Progress along standards track an Outbound Router Filter (ORF)
type for BGP, that can be used to perform aspath based route
filtering. The ORF-type will support aspath based route filtering
as well as regular expression based matching for address groups.
Currently defined in draft-ietf-idr-aspath-orf-00.txt.

Tasks for this working group are limited to those listed above;
new items to be added to the charter must be approved by the IESG.

Goals and Milestones

DONE    Submit BGP Capability Advertisement to the IESG
NOV 02  Submit BGP4 document to IESG.
DEC 02  Submit updated base BGP4 MIB to IESG.
MAR 03  Submit extensible BGP MIB to IESG.
MAR 03  Submit Extended Communities draft to IESG.
MAR 03  Submit 4-byte AS ID to IESG.
MAR 03  Initial Draft for RFC2858 (if needed)
MAR 03  BGP TCP MD5 signatures document to IESG.
MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.

------- End of Forwarded Message



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA10117 for <[e-mail]>; Mon, 26 Aug 2002 02:34:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5931591234; Mon, 26 Aug 2002 02:34:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A8FA9123E; Mon, 26 Aug 2002 02:34:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B229491234 for <[e-mail]>; Mon, 26 Aug 2002 02:33:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9BF955DF9C; Mon, 26 Aug 2002 02:33:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mta0 (unknown [61.144.161.2]) by segue.merit.edu (Postfix) with ESMTP id A76B25DE9B for <[e-mail]>; Mon, 26 Aug 2002 02:33:19 -0400 (EDT)
Received: from lidefeng04955 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <[e-mail]> for [e-mail]; Mon, 26 Aug 2002 14:31:29 +0800 (CST)
Date: Mon, 26 Aug 2002 14:28:54 +0800
From: lidefeng <[e-mail]>
Subject: A draft about BGP protection,Please review
To: [e-mail]
Cc: [e-mail]
Message-id: <005e01c24cc9$da653b00$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: multipart/mixed; boundary="Boundary_(ID_PelCQcuoIume4raEodr2eg)"
X-Priority: 3
X-MSMail-priority: Normal
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.

--Boundary_(ID_PelCQcuoIume4raEodr2eg)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7BIT

hi,

    As to the protection of BGP route information, we propose an efficient mechanism as described 
in draft-huawei-bgp-protection-md5-00.txt.
   Please reviev it as soon as possible.Thanks

Regards

Li Defeng

--Boundary_(ID_PelCQcuoIume4raEodr2eg)
Content-type: text/plain; name=draft-huawei-bgp-protection-md5-00.txt
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=draft-huawei-bgp-protection-md5-00.txt

							      Hu Chunzhe							     
				                     Huawei Technologies						    							       
Internet Draft:					             Deng Qiulin							    
Document:                                            Huawei Technologies						    							       
draft-huawei-idr-protection-md5-00.txt 			          Ni Hui							         
Expiration Date: February 2003  		     Huawei Technologies
  							       Li Defeng
  					             Huawei Technologies		    							       


                 BGP Sessions Protection via MD5 Authentication 
                 
                 draft-huawei-idr-protection-md5-00.txt

Status of this Memo 
          
        This document is an Internet-Draft and is in full conformance 
        with all provisions of Section 10 of RFC2026 [RFC-2026], except 
        that the right to produce derivative works is not granted.  
      
        Internet-Drafts are working documents of the Internet 
        Engineering Task Force (IETF), its areas, and its working 
        groups. Note that other groups may also distribute working 
        documents as Internet-Drafts.  
         
        Internet-Drafts are draft documents valid for a maximum of six 
        months and may be updated, replaced, or obsoleted by other 
        documents at any time. It is inappropriate to use Internet- 
        Drafts as reference material or to cite them other than as 
        "work in progress."  
         
        The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt  
        The list of Internet-Draft Shadow Directories can be accessed 
        at http://www.ietf.org/shadow.html.       


Abstract

    This draft describes a BGP Extension to protect the route 
    information on the basis of authentication on the BGP message 
    between BGP speakers,In this mechanism,an addtional Capabilty 
    option(Authentication Code) and random number used for 
    authentication are added to OPEN message,and the Authentication 
    Capability is negotiated between BGP speakers,when they pass the 
    negotiation and setup the Established relationship, all the 
    successive message will be authenticated using MD5 algorithm,with 
    the Marker field in the BGP message substituted with the MD5 digest 
    of the combination including message body.This mechanism can guard 
    against that the BGP message be intercepted and tampered by the 
    attacker.

1.0  Introduction
   
    The security of BGP connection is relatively not very robust,this 
    problem can be understood by investigating the format of BGP OPEN 
    message as following:


Hu & Deng & Ni	BGP Sessions Protection via MD5 Authentication	[Page 1]

Internet Draft	draft-huawei-idr-protection-md5-00.txt       August 2002

   
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                                                               +
    |                           Marker                              |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Length               |      Type     |               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+--+
    |    Version    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     My Autonomous System      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Hold Time           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         BGP Identifier                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Opt Parm Len  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                       Optional Parameters                     |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    In normal situation(without any authentication),all the message 
    headers are composed of the 16-octets all-one Marker.
     
    These messages are vulnerable to attack when the man-in-the-middle 
    intercept and capture the TCP message between two BGP peers,parse 
    off the all-one field and get the BGP messages,then he(she) 
    can destroy the Routing System through handling messages as 
    follows:
     
    (1)Get the BGP route information and attack the system on the 
     basis of the route information in BGP update messages;
    
    (2)Get the BGP information,and change the route information and 
     reput it into the TCP connection,if reput an error message such 
     as message with the wrong length or disordered message,then the 
     BGP error process procedure will disconnect the BGP connection,
     which will result in a route flapping or break-off.If reput an 
     wrong route which will cause the route blackhole, or increase the
     traffic of some routers, make them reset or even worse.
    	
    Such problems can be addressed by authentication on the 
    per-message basis between BGP peers utilizing MD5 Arithmetic and  
    increasing the Authentication Code and the relevant 16-octets 
    random number in Option field of message of OPEN message.The 
    realization procedure is as follows:

Hu & Deng & Ni	BGP Sessions Protection via MD5 Authentication	[Page 2]

Internet Draft	draft-huawei-idr-protection-md5-00.txt       August 2002
    
    (1)In section 4.1 of rfc 1771, Optional Parameters field may 
    contain a list of optional parameters, where each parameter is 
    encoded as a <Parameter Type, Parameter Length, Parameter Value> 
    triplet.

         0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
        |  Parm. Type   | Parm. Length  |  Parameter Value (variable)
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
     This paper provides Authentication Information in this parameter,
     Parameter Type is defined as 1,the Parameter Value field contains
     a 1-octet Authentication Code followed by a variable length 
     Authentication Data.
        0 1 2 3 4 5 6 7 8
        +-+-+-+-+-+-+-+-+
        |  Auth. Code   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                     |
        |              Authentication Data                    |
        |                                                     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
    (2)This paper define Auth. Code as 1(can TBD) to specify the 
    authentication mechanism on the basis of MD5 Algorithm,and 
    Authentication Data field is 16-octets fixed-length random number 
    produced by the BGP speaker which send the OPEN message during BGP 
    peer establishment(BGP speaker1 in figure 1),and this 16-octets 
    random number is used in the succeeding authentications on the 
    per-message basis.
   
    (3)BGP speaker receiving the OPEN message with Authentication 
    Information(BGP speaker2 in figure 1) will determine that if the 
    message Authentication Capability based on MD5 algorithm can be 
    supported,the normal KEEPALIVE message(the Marker field of the 
    messageis composed of 16 octets all-one) will be send to BGP 
    speaker1 if such Capability is supported.     

    (4)If the message Authentication Capability based on MD5 algorithm 
    can't be supported by BGP speaker2,BGP speaker1 will receive the 
    normal NOTIFICATION message(the Marker field of the messageis 
    composed of 16 octets all-one) with the Error Subcode set to 
    Unsupported Optional Parameter. In this case the BGP speaker1 
    shouldn't attempt to re-establish a BGP connection with the BGP 
    speaker2.    
   
    (5)In situation specified in (3),the two BGP speakers will reach 
    Established state,there will be some message exchanges between 
    them, before BGP speaker1 send the message to BGP speaker2, it will 
    compute the 16 octets MD5 digest of combination of such fields as 
    message type(OPEN,value:1),password(shared between BGP speaker1, 
    BGP speaker2),16 octets random Authentication Data and MSG1(the part 
    in the message to be sent excluding 16-octets marker):


Hu & Deng & Ni	BGP Sessions Protection via MD5 Authentication	[Page 3]

Internet Draft	draft-huawei-idr-protection-md5-00.txt       August 2002
        
      MD5 digest1 = MD5(message type(OPEN)+ password + 16 octets 
                     Authentication Data + MSG1 ).
                     
    then BGP speaker1 then replace the 16 octets marker with the MD5
    digest1 derived above,After received the message sent by BGP 
    speaker1,BGP speaker2 will compute MD5 digest with the same 
    combination(message type(OPEN,value:1),password(shared between 
    BGP speaker1, BGP speaker2),16 octets random Authentication Data 
    and MSG2(the part in the message received excluding 16-octets 
    marker))
      MD5 digest2 = MD5(message type(OPEN)+ password + 16 octets 
                     Authentication Data + MSG2 ).
    
    If the 16 octets MD5 digest2 equals the 16 octets marker in the 
    received message, then the message pass the authentication,
    otherwise will drop the message and logging this message is 
    proposed for attack analysis.If the passwords of both sides are 
    configured differently,all the messages can't pass the 
    authentication all the time,BGP FSM will consider that no message 
    is received. Then after Hold Timer,BGP speaker will disconnect the 
    BGP neighbor,release the relevant resource,transition the 
    neighbor's state to IDLE.
                       
    In the light of MD5 Algorithm,only the condition that the password 
    when computing MD5 digest2 is the same as the password computing 
    MD5 digest1 AND the condition that MSG1 is the same as MSG2 are 
    both meeted,MD5 digest1 will be the same as MD5 digest2
    
    
 +-+-+-+--+    OPEN message:capability negotiation          +-+-+-+--+
 |        |      and carry Authentication Word 		    |        |
 |        | ----------------------------------------------> | BGP    |    					           
 |        |   KEEPALIVE message:Acknowledge the capability  |        | 
 | BGP    |     of message-based Authentication             |speaker2|  
 |        | <---------------------------------------------- |        |
 |speaker1|   UPDATE/KEEPALIVE/NOTIFICATION message         |        | 	
 |        |  	  with replaced message header		    |        |  	
 |        |  ---------------------------------------------->|        |
 |        |	                     			    |        |	
 +-+-+-+--+ 						    +-+-+-+--+
     
   Figure 1: BGP neighbor establishment with MD5 authentication in 
             OPEN message.
   
    The above procedure is stressed on one side of Authentication,where 
    BGP speaker2 is authentication side,and BGP speaker1 is to be 
    authenticated. In practical implementation,such procedure is the 
    same to the situation vice versa.
          	
    The primary motivation for this Authentication Option is to allow 
    BGP Speaker to protect itself against the introduction of spoofed 
    BGP messages from the peers into the connection stream.To spoof any 
    message between BGP speakers using the scheme described in this 
    paper, an attacker would not only have to guess 16 octets random 

Hu & Deng & Ni	BGP Sessions Protection via MD5 Authentication	[Page 4]

Internet Draft	draft-huawei-idr-protection-open-00.txt      August 2002
    
    numbers in Optional Parameter, but would also have had to obtain the 
    password included in the MD5 digest.This password never appears in 
    the connection stream, and the actual form of the password is up to 
    the configuration where password can be shown with encrypt form,that 
    is out of the scope of this paper.With the Marker Field replaced 
    with 16-octets digest1,it is difficult for the attacker to find out
    what is the beginning of BGP message.
   
2.0  Some Implications

2.1  Message Authentication period

     The procedure specified by section 1.0 is valid only during BGP FSM 
     state transition period after OPEN message is sent from a BGP 
     speaker,and if the BGP session is reset, the Authentication 
     procedure is invalid until another session.                 

2.2  Performance

     The cost in calculating digests of authentication 
     information and 16-byte compare isn't that much,so the impact 
     of BGP message process efficiency is slim.So the performance of 
     such BGP session protection based on OPEN message is presentable.

2.3  OPEN message Header Size
 
     The least OPEN message Header Size is 29 octets when there is no 
     Optional Parameter,in the situation this paper concerned, The 
     total Optional Parameter length is 19 octets (1 octet(Parm. Type)+
     1 octet(Parm. Length)+1 octet(Auth. Code)+16 octets Authentication 
     Data),so the least OPEN message Header Size is 48 octets. 

2.4 Password configuration

     It should be noted that the Password configuration mechanism of 
     routers may restrict the possible passwords that may be used 
     between peers.  It is strongly recommended that an implementation 
     be able to support at minimum a password composed of a string of 
     printable ASCII of 80 bytes or less, as this is current practice.

3.0 Security Considerations

    This BGP extension mechanism provides an simple but efficient 
    method to protect the security of BGP route information,compared 
    with other methods which encrypt the whole BGP message,the impact 
    to the performance of route protocol will be sustainable,and in 
    contrast to the existing BGP security mechanism such as RFC2385,
    which is from the perspective of the transport layer ,this 
    mechanism takes measure on the application layer and do nothing to 
    the transport layer.

4.0  References

     [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, 
     April 1992.


Hu & Deng & Ni BGP Sessions Protection via MD5 Authentication   [Page 5]

Internet Draft	draft-huawei-idr-protection-md5-00.txt       August 2002

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

     [RFC2842] Ravi Chandra, "Capabilities Advertisement with BGP-4", 
     RFC 2842, May 2000.
             
5.0 Author's Address

    Hu Chunzhe  
    C401 ,HuaWei Bld. No3 Xinxi Rd.
    Shang-Di Information Industry Base,
    Hai-Dian District BeiJing P.R.China
    Zip : 100085
    Email : [e-mail]
    
    Deng Qiulin  
    C401 ,HuaWei Bld. No.3 Xinxi Rd.
    Shang-Di Information Industry Base,
    Hai-Dian District BeiJing P.R.China
    Zip : 100085
    Email : [e-mail]
  
    Ni Hui
    C401 ,HuaWei Bld. No.3 Xinxi Rd.
    Shang-Di Information Industry Base,
    Hai-Dian District BeiJing P.R.China
    Zip : 100085
    Email : [e-mail]

    Li Defeng
    D201 ,HuaWei Bld. No.3 Xinxi Rd.
    Shang-Di Information Industry Base,
    Hai-Dian District BeiJing P.R.China
    Zip : 100085
    Email : [e-mail]

 Full Copyright Statement 
         
        Copyright (C) The Internet Society (2000). All Rights Reserved. 
        This document and translations of it may be copied and 
        furnished to others, and derivative works that comment on or 
        otherwise explain it or assist in its implementation may be 
        prepared, copied, published and distributed, in whole or in 
        part, without restriction of any kind, provided that the above 
        copyright notice and this paragraph are included on all such 
        copies and derivative works. However, this document itself may 
        not be modified in any way, such as by removing the copyright 
        notice or references to the Internet Society or other Internet 
        organizations, except as needed for the purpose of developing 
        Internet standards in which case the procedures for copyrights 
        defined in the Internet Standards process must be followed, or 
        as required to translate it into languages other than English. 
         
        The limited permissions granted above are perpetual and will 
        not be revoked by the Internet Society or its successors or 
        assigns. 
Hu & Deng & Ni BGP Sessions Protection via MD5 Authentication   [Page 6]

--Boundary_(ID_PelCQcuoIume4raEodr2eg)--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA08897 for <[e-mail]>; Sun, 25 Aug 2002 10:14:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6C1349120E; Sun, 25 Aug 2002 10:14:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39F8291211; Sun, 25 Aug 2002 10:14:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 114979120E for <[e-mail]>; Sun, 25 Aug 2002 10:14:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E85A35DE55; Sun, 25 Aug 2002 10:14:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from utopia.opentransit.net (utopia.opentransit.net [193.251.151.78]) by segue.merit.edu (Postfix) with ESMTP id 4B4795DD90 for <[e-mail]>; Sun, 25 Aug 2002 10:14:09 -0400 (EDT)
Received: from utopia.opentransit.net (localhost [127.0.0.1]) by utopia.opentransit.net (8.12.4/8.12.4/Debian-4) with ESMTP id g7PEE5Bn003651; Sun, 25 Aug 2002 16:14:05 +0200
Received: (from vgi@localhost) by utopia.opentransit.net (8.12.4/8.12.4/Debian-4) id g7PEE4tA003650; Sun, 25 Aug 2002 16:14:04 +0200
Date: Sun, 25 Aug 2002 16:14:04 +0200
From: Vincent Gillet <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP INFORM message
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4i
Sender: [e-mail]
Precedence: bulk

[e-mail] disait :

> To help determine whether there is a rough consensus for
> accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
> document, please send an e-mail with either "yes" or "no".
> The deadline is August 29.

NO
Much a paint to implement i guess.
>From my operating point of view, the most interesting events in
this draft should lead to session reset and can be notified with the
CEASE sub-code if necessary (much easyer to implement).

Vincent.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA11975 for <[e-mail]>; Fri, 23 Aug 2002 13:05:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1C76D913A1; Fri, 23 Aug 2002 13:01:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FFFD913A3; Fri, 23 Aug 2002 13:01:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D9B2C913A1 for <[e-mail]>; Fri, 23 Aug 2002 13:01:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BA4005DE6C; Fri, 23 Aug 2002 13:01:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 746FE5DE36 for <[e-mail]>; Fri, 23 Aug 2002 13:01:07 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1AABT>; Fri, 23 Aug 2002 13:01:07 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Bill Fenner'" <[e-mail]>
Cc: [e-mail]
Subject: RE: BGP spec and IDR WG charter
Date: Fri, 23 Aug 2002 13:01:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Bill,

OK,  thank you for replying.

-Jonathan

-----Original Message-----
From: Bill Fenner [mailto:[e-mail]] 
Sent: Friday, August 23, 2002 12:12 PM
To: [e-mail]
Cc: [e-mail]
Subject: RE: BGP spec and IDR WG charter


>    "DONE    Submit BGP Capability Advertisement to the IESG"

Although this was approved by the IESG in May, it is still in the
RFC-Editor's queue so if the WG and the ADs agree that there are problems
with it they could conceivably be fixed during the author's 48 hours.

  Bill


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA10211 for <[e-mail]>; Fri, 23 Aug 2002 12:12:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 03FBD9120C; Fri, 23 Aug 2002 12:12:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C3A5591212; Fri, 23 Aug 2002 12:12:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8ED9E9120C for <[e-mail]>; Fri, 23 Aug 2002 12:12:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 647735DEC7; Fri, 23 Aug 2002 12:12:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by segue.merit.edu (Postfix) with ESMTP id 40CD15DDC5 for <[e-mail]>; Fri, 23 Aug 2002 12:12:07 -0400 (EDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id B58261E06A; Fri, 23 Aug 2002 12:12:02 -0400 (EDT)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA03226; Fri, 23 Aug 2002 12:12:01 -0400 (EDT)
From: Bill Fenner <[e-mail]>
Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id JAA27208; Fri, 23 Aug 2002 09:12:02 -0700 (PDT)
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: [e-mail]
Subject: RE: BGP spec and IDR WG charter
Cc: [e-mail]
Date: Fri, 23 Aug 2002 09:12:01 -0700
Versions: dmail (solaris) 2.5a/makemail 2.9d
Sender: [e-mail]
Precedence: bulk

>    "DONE    Submit BGP Capability Advertisement to the IESG"

Although this was approved by the IESG in May, it is still in the
RFC-Editor's queue so if the WG and the ADs agree that there are problems
with it they could conceivably be fixed during the author's 48 hours.

  Bill


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA09081 for <[e-mail]>; Fri, 23 Aug 2002 11:35:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0157B91201; Fri, 23 Aug 2002 11:34:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3632913A1; Fri, 23 Aug 2002 11:34:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 81F1D91201 for <[e-mail]>; Fri, 23 Aug 2002 11:34:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6A7A45DEAE; Fri, 23 Aug 2002 11:34:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 223EF5DE4E for <[e-mail]>; Fri, 23 Aug 2002 11:34:19 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBCD00V2>; Fri, 23 Aug 2002 11:34:18 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'Bill Fenner'" <[e-mail]>, [e-mail]
Subject: RE: BGP spec and IDR WG charter 
Date: Fri, 23 Aug 2002 11:34:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Yakov,

Ok, thank you for replying.

-Jonathan

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Friday, August 23, 2002 10:18 AM
To: Natale, Jonathan
Cc: 'Bill Fenner'; [e-mail]
Subject: Re: BGP spec and IDR WG charter 

Jonathan,

> I am sorry, but I disagree with:
>     "DONE    Submit BGP Capability Advertisement to the IESG"

The "DONE submit BGP Capability Advertisement to the IESG" just
documents the *fact*, that BGP Capability Advertisement was submitted 
to the IESG back in Spring of 2002, and was approved by the IESG
in May 2002 for publication as a Draft Standard.

>  and AGAIN ( for the last time) I propose:
> 
> 
> >    "If a BGP speaker that supports a certain capability determines that
> >    its peer doesn't support this capability, the speaker MAY send a
> >    NOTIFICATION message to the peer, and terminate peering (see Section
> >    "Extensions to Error Handling" for more details). The Error Subcode
> >    in the message is set to Unsupported Capability. The message SHOULD
> >    contain the capability (capabilities) that causes the speaker to send
> >    the message.  The decision to send the message and terminate peering
> >    is local to the speaker. If terminated, such peering SHOULD NOT be
> >    re-established automatically."
> >
> >be changed to:
> >
> >    "If a BGP speaker that **does not want its peer to support** a
certain
> >    capability determines that
> >    its peer **does** support this capability, the speaker MAY send a
> >    NOTIFICATION message to the peer, and terminate peering (see Section
> >    "Extensions to Error Handling" for more details). The Error Subcode
> >    in the message is set to Unsupported Capability. The message SHOULD
> >    contain the capability (capabilities) that causes the speaker to send
> >    the message.  The decision to send the message and terminate peering
> >    is local to the speaker. **If terminated, the peer MAY re-open the
> >    connection without the offending capability-this is known as
capability
> >    negotiation.**"
> 
> Thank you.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA08333 for <[e-mail]>; Fri, 23 Aug 2002 11:12:15 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3112C9139D; Fri, 23 Aug 2002 11:11:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1DDF9139F; Fri, 23 Aug 2002 11:11:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EEB549139D for <[e-mail]>; Fri, 23 Aug 2002 11:11:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D25B85DEAE; Fri, 23 Aug 2002 11:11:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 401C65DEC7 for <[e-mail]>; Fri, 23 Aug 2002 11:11:35 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7NFB3b30281; Fri, 23 Aug 2002 11:11:03 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7NFB1130274; Fri, 23 Aug 2002 11:11:01 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7NFB0x00377; Fri, 23 Aug 2002 11:11:00 -0400 (EDT)
Date: Fri, 23 Aug 2002 11:11:00 -0400
From: Jeffrey Haas <[e-mail]>
To: Avi Freedman <[e-mail]>
Cc: [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Aug 23, 2002 at 10:51:53AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Aug 23, 2002 at 10:51:53AM -0400, Avi Freedman wrote:
> I haven't seen or heard of any packets that were corrupted in
> the NLRI.  AS_PATH mostly, and usually by the origin AS or
> the immediate upstream AS.

This may be why we aren't seeing quite eye-to-eye.
You've seen some particular bugs related to AS_PATHS.
Many of the people on this list implement the protocols.  Buffer
creation (painting) errors are pretty common.  Thankfully software
engineer, debugging and QA work and you generally don't see these
in the real world except under edge circumstances that weren't
caught by some test.

My concerns are about the general issue, not a specific instance of
it.  Well known bugs (started that ID yet? :-) are worth working around.

> > We currently don't have a way, in the presence of error 
> > conditions, to assert that we have good or bad state.
> 
> That's true.  But of course that hints at another problem,
> somewhat operational, which is that we have no idea whether
> any origin AS should be announcing a particular prefix.

Different issue, but the origin AS issue is definitely worth
addressing.  BGP is likely not the place to do it.  Policy
implementations and a distributed policy distribution system
(RPSL et al) are a good candidate for it.

> Right now there's a huge amount more churn in the BGP system than
> there 'should' be from the topology changes happening at the edge.
> Noone knows 'why' this is, though people are starting to try to
> figure it out.

And its very interesting stuff to watch.  For my part, I expect
a pretty big amount of churn any time a topology change happens.
Its a expected side-effect of path vector.

> As someone who wants the Internet to work, I don't want the NOTIFY
> mechanism to be an attack vector on the Internet infrastructure.
> (Someone getting 10-20 t1s, speaking BGP using their own implementation,
> and injecting UPDATEs for a few minutes at a time that cause Ciscos
> and Junipers to break sessions to each other).

The right answer to this is conformance and exception testing.
Problems need to be caught where they occur - not later down the chain.

> Avi

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA07329 for <[e-mail]>; Fri, 23 Aug 2002 10:41:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 832809139C; Fri, 23 Aug 2002 10:37:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49B0B913A3; Fri, 23 Aug 2002 10:37:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ABE439139C for <[e-mail]>; Fri, 23 Aug 2002 10:36:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 83A345DEAE; Fri, 23 Aug 2002 10:36:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 0FA275DDBB for <[e-mail]>; Fri, 23 Aug 2002 10:36:49 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7NEaHR28949; Fri, 23 Aug 2002 10:36:17 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7NEaC128935; Fri, 23 Aug 2002 10:36:12 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7NEaCt16258; Fri, 23 Aug 2002 10:36:12 -0400 (EDT)
Date: Fri, 23 Aug 2002 10:36:12 -0400
From: Jeffrey Haas <[e-mail]>
To: Avi Freedman <[e-mail]>
Cc: [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Aug 20, 2002 at 01:02:17PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Aug 20, 2002 at 01:02:17PM -0400, Avi Freedman wrote:
> That would be a good idea.  Even just a museum web page.

I look forward to seeing such a thing.  

> I don't care; my suggested heuristic is ignore if any part of it
> is syntactically or semantically incorrect.  Thus, also don't
> pass it on.  But I don't want to kill my sessions because of
> one or 1000 malformed UPDATEs.

BGP is stateful.  If, for example, you get state for Yahoo,
and you get a corrupt packet for Yahoo's NLRI, do you really want
to keep using it?  What if Yahoo's NLRI isn't in that packet
but it should have been?

We currently don't have a way, in the presence of error 
conditions, to assert that we have good or bad state.

That prefix you propagate for Yahoo may cause you more calls to your
NOC than dropping the peering session.  This could be because
the path information is wrong and you've introduced routing blackholes
or loops.

What is your actual concern with dropping the peering session
operationally?  The fact that you've lost *their* routes or
that *your* routes (which are perfectly fine) get flapped?
Or is it that this may happen repeatedly?

> Avi

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA06682 for <[e-mail]>; Fri, 23 Aug 2002 10:21:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8CCA691395; Fri, 23 Aug 2002 10:19:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E60E91396; Fri, 23 Aug 2002 10:19:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A181B91398 for <[e-mail]>; Fri, 23 Aug 2002 10:18:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 842825DDBB; Fri, 23 Aug 2002 10:18:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 077EF5DDB9 for <[e-mail]>; Fri, 23 Aug 2002 10:18:20 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7NEIHm59016; Fri, 23 Aug 2002 07:18:17 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Bill Fenner'" <[e-mail]>, [e-mail]
Subject: Re: BGP spec and IDR WG charter 
In-Reply-To: Your message of "Fri, 23 Aug 2002 09:26:22 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 23 Aug 2002 07:18:17 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> I am sorry, but I disagree with:
>     "DONE    Submit BGP Capability Advertisement to the IESG"

The "DONE submit BGP Capability Advertisement to the IESG" just
documents the *fact*, that BGP Capability Advertisement was submitted 
to the IESG back in Spring of 2002, and was approved by the IESG
in May 2002 for publication as a Draft Standard.

>  and AGAIN ( for the last time) I propose:
> 
> 
> >    "If a BGP speaker that supports a certain capability determines that
> >    its peer doesn't support this capability, the speaker MAY send a
> >    NOTIFICATION message to the peer, and terminate peering (see Section
> >    "Extensions to Error Handling" for more details). The Error Subcode
> >    in the message is set to Unsupported Capability. The message SHOULD
> >    contain the capability (capabilities) that causes the speaker to send
> >    the message.  The decision to send the message and terminate peering
> >    is local to the speaker. If terminated, such peering SHOULD NOT be
> >    re-established automatically."
> >
> >be changed to:
> >
> >    "If a BGP speaker that **does not want its peer to support** a certain
> >    capability determines that
> >    its peer **does** support this capability, the speaker MAY send a
> >    NOTIFICATION message to the peer, and terminate peering (see Section
> >    "Extensions to Error Handling" for more details). The Error Subcode
> >    in the message is set to Unsupported Capability. The message SHOULD
> >    contain the capability (capabilities) that causes the speaker to send
> >    the message.  The decision to send the message and terminate peering
> >    is local to the speaker. **If terminated, the peer MAY re-open the
> >    connection without the offending capability-this is known as capability
> >    negotiation.**"
> 
> Thank you.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA05523 for <[e-mail]>; Fri, 23 Aug 2002 09:50:54 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1AEFE91393; Fri, 23 Aug 2002 09:46:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8A0E91394; Fri, 23 Aug 2002 09:46:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6409A91393 for <[e-mail]>; Fri, 23 Aug 2002 09:46:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 22B2C5DE42; Fri, 23 Aug 2002 09:46:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 723A55DDB9 for <[e-mail]>; Fri, 23 Aug 2002 09:46:35 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7NDkWH27500; Fri, 23 Aug 2002 09:46:32 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7NDkT127493; Fri, 23 Aug 2002 09:46:29 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7NDkTp16141; Fri, 23 Aug 2002 09:46:29 -0400 (EDT)
Date: Fri, 23 Aug 2002 09:46:29 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Aug 21, 2002 at 12:05:27PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Aug 21, 2002 at 12:05:27PM -0400, Abarbanel, Benjamin wrote:
> > If we have determined that some portion of the packet is bad - say
> > the route origin (e.g. type=4), can we trust the rest of the packet?
> 
> NO

[...]

> I suggest, we ignore the packet with bad/malformed data in its PDU/NLRI
> section
> and send it back as an INFORM message to let the originating peer either
> repair the packet and retransmit or drop the session. 

Sending the packet back wont do a lot of good.
I don't think current implementations bother to hold onto the
completed BGP buffer/PDU once it has been transmitted.

If you added a postive acknowledgement mechanism (possibly by overloading/
actually using the marker field), then this might work.

I don't see this happening in the reasonable future.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA04709 for <[e-mail]>; Fri, 23 Aug 2002 09:28:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8DD6891399; Fri, 23 Aug 2002 09:26:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58AC8913AC; Fri, 23 Aug 2002 09:26:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 902CB91399 for <[e-mail]>; Fri, 23 Aug 2002 09:26:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5B7B25DEDD; Fri, 23 Aug 2002 09:26:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 0D93F5DEC7 for <[e-mail]>; Fri, 23 Aug 2002 09:26:24 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBCD00FY>; Fri, 23 Aug 2002 09:26:23 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Bill Fenner'" <[e-mail]>, [e-mail]
Subject: RE: BGP spec and IDR WG charter
Date: Fri, 23 Aug 2002 09:26:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I am sorry, but I disagree with:
    "DONE    Submit BGP Capability Advertisement to the IESG"
 and AGAIN ( for the last time) I propose:


>    "If a BGP speaker that supports a certain capability determines that
>    its peer doesn't support this capability, the speaker MAY send a
>    NOTIFICATION message to the peer, and terminate peering (see Section
>    "Extensions to Error Handling" for more details). The Error Subcode
>    in the message is set to Unsupported Capability. The message SHOULD
>    contain the capability (capabilities) that causes the speaker to send
>    the message.  The decision to send the message and terminate peering
>    is local to the speaker. If terminated, such peering SHOULD NOT be
>    re-established automatically."
>
>be changed to:
>
>    "If a BGP speaker that **does not want its peer to support** a certain
>    capability determines that
>    its peer **does** support this capability, the speaker MAY send a
>    NOTIFICATION message to the peer, and terminate peering (see Section
>    "Extensions to Error Handling" for more details). The Error Subcode
>    in the message is set to Unsupported Capability. The message SHOULD
>    contain the capability (capabilities) that causes the speaker to send
>    the message.  The decision to send the message and terminate peering
>    is local to the speaker. **If terminated, the peer MAY re-open the
>    connection without the offending capability-this is known as capability
>    negotiation.**"

Thank you.



-----Original Message-----
From: Bill Fenner [mailto:[e-mail]] 
Sent: Thursday, August 22, 2002 7:11 PM
To: [e-mail]
Subject: BGP spec and IDR WG charter

Dear IDR WG,

  After some consideration, the Routing Area Directors have decided
not to forward any IDR documents for IESG consideration until the
base BGP spec update is finished.[*]  Despite the best efforts of all
involved, the spec update has been taking an incredible amount of
time.  We take this step in order to focus all possible resources
of the WG community on the BGP spec update.

  This may seem like a negative action.  On the contrary, it is
meant to support the accomplishment of the working group's goals.[**]
The milestone for the submission of the BGP4 draft to the IESG
was scheduled for January 2002.

  Attached is a proposed update for the IDR working group charter.
Note that we just made up the dates in the goals and milestones,
and the WG should come up with realistic ones.

  Bill and Alex

[*] "finished" means, in this case, WG consensus, WG Last Call,
AD Review, IETF Last Call, and IESG approval for publication.

[**] In further support of the goal of having a quality specification
that reflects current reality, the ADs have been working on assembling
a team of reviewers that consists primarily of protocol implementors,
who have committed their time to examine the spec.  We will be
sending another message to this list explaining the details of how
this team will do its work.

- - -

The Inter-Domain Routing Working Group is chartered to standardize
and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
1771] capable of supporting policy based routing for TCP/IP internets.
The objective is to promote the use of BGP-4 to support IP version
4 and IP version 6. The working group will continue to work on
improving the scalability of BGP.

The current tasks of the WG are limited to:

- Revise and clarify the base BGP4 document (RFC 1771). Note that
RFC 1771 no longer documents existing practice and one goal of the
update is document existing practice. Determine whether the document
can be advanced as full Standard or needs to recycle at Proposed
or Draft Standard.

- Submit updated MIBs to accompany the revised base BGP4 document.

Once these tasks are completed, work will progress on the following:

- Review and Evaluate Existing RFCs on AS Confederations and Route
Reflection. If changes are needed, create and advance revisions.

- Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see
if any changes need to be made based on current Internet practice
or based on the changes to the current bgp draft. If changes are
needed, create an revision. Issue the WG Last Call on advancing
the document to Draft Standard.

- Produce an updated MIB for AS Confederations, Route Reflection,
Communities, Multi-Protocol BGP, etc..

- Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
as Draft Standard.

- Complete work on an Extended Community Attribute. Develop MIB
for BGP Extended Communities.

- Extend BGP to support a 4-byte AS number, develop plan for
transitioning to usage of 4-byte AS numbers

- Progress along the IETF standards track a BGP-based mechanism
that allows a BGP speaker to send to its BGP peer a set of route
filters that the peer would use to constrain/filter its outbound
routing updates to the speaker. Currently defined in
draft-ietf-idr-route-filter-03.txt.

- Progress along standards track an Outbound Router Filter (ORF)
type for BGP, that can be used to perform aspath based route
filtering. The ORF-type will support aspath based route filtering
as well as regular expression based matching for address groups.
Currently defined in draft-ietf-idr-aspath-orf-00.txt.

Tasks for this working group are limited to those listed above;
new items to be added to the charter must be approved by the IESG.

Goals and Milestones

DONE    Submit BGP Capability Advertisement to the IESG
NOV 02  Submit BGP4 document to IESG.
DEC 02  Submit updated base BGP4 MIB to IESG.
MAR 03  Submit extensible BGP MIB to IESG.
MAR 03  Submit Extended Communities draft to IESG.
MAR 03  Submit 4-byte AS ID to IESG.
MAR 03  Initial Draft for RFC2858 (if needed)
MAR 03  BGP TCP MD5 signatures document to IESG.
MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA02906 for <[e-mail]>; Fri, 23 Aug 2002 08:43:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 75B839138B; Fri, 23 Aug 2002 08:42:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27B709138E; Fri, 23 Aug 2002 08:42:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BB0F19138B for <[e-mail]>; Fri, 23 Aug 2002 08:42:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A75235DEC7; Fri, 23 Aug 2002 08:42:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cmail.packetcom.com (unknown [63.108.173.139]) by segue.merit.edu (Postfix) with ESMTP id 4F7C95DDB1 for <[e-mail]>; Fri, 23 Aug 2002 08:42:46 -0400 (EDT)
Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ACD63031 (AUTH [e-mail]); Fri, 23 Aug 2002 05:42:38 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 23 Aug 2002 07:42:34 -0700
From: Jeff Pickering <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Martin, Christian" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: Re: BGP INFORM message
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

yes

"Martin, Christian" wrote:

> yes
>
> >-----Original Message-----
> >From: Yakov Rekhter [mailto:[e-mail]]
> >Sent: Wednesday, August 21, 2002 10:37 AM
> >To: [e-mail]
> >Subject: BGP INFORM message
> >
> >
> >Folks,
> >
> >To help determine whether there is a rough consensus for
> >accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
> >document, please send an e-mail with either "yes" or "no". The
> >deadline is August 29.
> >
> >Yakov.
> >------- Forwarded Message
> >
> >Date:    Thu, 15 Aug 2002 07:00:49 -0700
> >From:    Yakov Rekhter <[e-mail]>
> >To:      [e-mail]
> >Subject: BGP INFORM message
> >
> >Folks,
> >
> >The authors of draft-nalawade-bgp-inform-02.txt would like
> >to make it the IDR WG document. The deadline for comments
> >(either positive or negative) on this request is August 29.
> >
> >Yakov.
> >- ------- Forwarded Message
> >
> >Date:    Thu, 15 Aug 2002 08:15:30 -0400
> >From:    [e-mail]
> >To:      IETF-Announce: ;
> >Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt
> >
> >- - --NextPart
> >
> >A New Internet-Draft is available from the on-line
> >Internet-Drafts directories.
> >
> >
> >       Title           : BGPv4 INFORM message
> >       Author(s)       : G. Nalawade, J. Scudder, D. Ward
> >       Filename        : draft-nalawade-bgp-inform-02.txt
> >       Pages           : 11
> >       Date            : 14-Aug-02
> >
> >This document defines a new message type, the BGP INFORM
> >message that communicates Informational data and operational
> >warnings without resetting the peering session.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt
> >
> >To remove yourself from the IETF Announcement list, send a message to
> >ietf-announce-request with the word unsubscribe in the body of
> >the message.
> >
> >Internet-Drafts are also available by anonymous FTP. Login
> >with the username "anonymous" and a password of your e-mail
> >address. After logging in, type "cd internet-drafts" and then
> >       "get draft-nalawade-bgp-inform-02.txt".
> >
> >A list of Internet-Drafts directories can be found in
> >http://www.ietf.org/shadow.html
> >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> >Internet-Drafts can also be obtained by e-mail.
> >
> >Send a message to:
> >       [e-mail].
> >In the body type:
> >       "FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
> >
> >NOTE:  The mail server at ietf.org can return the document in
> >       MIME-encoded form by using the "mpack" utility.  To use this
> >       feature, insert the command "ENCODING mime" before the "FILE"
> >       command.  To decode the response(s), you will need "munpack" or
> >       a MIME-compliant mail reader.  Different MIME-compliant
> >mail readers
> >       exhibit different behavior, especially when dealing with
> >       "multipart" MIME messages (i.e. documents which have been split
> >       up into multiple messages), so check your local documentation on
> >       how to manipulate these messages.
> >
> >
> >Below is the data which will enable a MIME compliant mail
> >reader implementation to automatically retrieve the ASCII
> >version of the Internet-Draft.
> >
> >- - --NextPart
> >Content-Type: Multipart/Alternative; Boundary="OtherAccess"
> >
> >- - --OtherAccess
> >Content-Type: Message/External-body;
> >       access-type="mail-server";
> >       server="[e-mail]"
> >
> >Content-Type: text/plain
> >Content-ID:    <[e-mail]>
> >
> >ENCODING mime
> >FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt
> >
> >- - --OtherAccess
> >Content-Type: Message/External-body;
> >       name="draft-nalawade-bgp-inform-02.txt";
> >       site="ftp.ietf.org";
> >       access-type="anon-ftp";
> >       directory="internet-drafts"
> >
> >Content-Type: text/plain
> >Content-ID:    <[e-mail]>
> >
> >- - --OtherAccess--
> >
> >- - --NextPart--
> >
> >
> >
> >- ------- End of Forwarded Message
> >
> >
> >------- End of Forwarded Message
> >



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA14563 for <[e-mail]>; Thu, 22 Aug 2002 23:53:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 85A349122B; Thu, 22 Aug 2002 23:52:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 55B5B9122D; Thu, 22 Aug 2002 23:52:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 107779122B for <[e-mail]>; Thu, 22 Aug 2002 23:52:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EA85A5DDE4; Thu, 22 Aug 2002 23:52:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from realname (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 9B8DB5DDE1 for <[e-mail]>; Thu, 22 Aug 2002 23:52:40 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) id <[e-mail]> for [e-mail]; Fri, 23 Aug 2002 12:56:10 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 23 Aug 2002 12:56:10 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) with ESMTPA id <[e-mail]> for [e-mail]; Fri, 23 Aug 2002 12:56:29 +0900 (KST)
Date: Fri, 23 Aug 2002 09:23:09 +0530
From: Manav Bhatia <[e-mail]>
Subject: Re: BGP INFORM message
To: Chandrashekhar Appanna <[e-mail]>
Cc: [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <094001c24a58$9b9d25e0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <07f501c24998$77f0ed90$[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Chandra,

|   Not sure I understand your example - what is the problem and how do
|   you think we can fix it? (I do not see the problem).
|
|   The FSM is internal to an implementation and is a guide for
implementations.
|   How do you think you can detect non compliance for sure?
|

some time back on the list it was suggested that we update the draft to
include other BGP messages (Route Refresh, Dynamic Capability, INFORM)
which when received by the local system act as surrogate for the KEEPALIVE
messages it would expect from the remote end. The local system upon
receiving such messages must then restart its Hold Timer. This is one case
which directly affects the FSM.

Consider what might happen if this isn't documented. Vendor A might follow
this and may not send KEEPALIVE messages when it receives other BGP
messages, while the other vendor, which isn't following this will time out
and break the session.

This is just an example of how interoperability can be put at stake if FSM
and other things are not properly documented in the draft.

-- Manav




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA05615 for <[e-mail]>; Thu, 22 Aug 2002 19:11:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 416FB91254; Thu, 22 Aug 2002 19:11:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D49A99138F; Thu, 22 Aug 2002 19:11:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE0B691254 for <[e-mail]>; Thu, 22 Aug 2002 19:11:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C59FD5DE9F; Thu, 22 Aug 2002 19:11:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mango.attlabs.att.com (mpfg.attlabs.net [12.106.35.2]) by segue.merit.edu (Postfix) with ESMTP id 39A365DDDA for <[e-mail]>; Thu, 22 Aug 2002 19:11:19 -0400 (EDT)
Received: (from fenner@localhost) by mango.attlabs.att.com (8.11.3/8.11.3) id g7MNBAm09751 for [e-mail]; Thu, 22 Aug 2002 16:11:10 -0700 (PDT) (envelope-from fenner)
Date: Thu, 22 Aug 2002 16:11:10 -0700 (PDT)
From: Bill Fenner <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: BGP spec and IDR WG charter
Sender: [e-mail]
Precedence: bulk

Dear IDR WG,

  After some consideration, the Routing Area Directors have decided
not to forward any IDR documents for IESG consideration until the
base BGP spec update is finished.[*]  Despite the best efforts of all
involved, the spec update has been taking an incredible amount of
time.  We take this step in order to focus all possible resources
of the WG community on the BGP spec update.

  This may seem like a negative action.  On the contrary, it is
meant to support the accomplishment of the working group's goals.[**]
The milestone for the submission of the BGP4 draft to the IESG
was scheduled for January 2002.

  Attached is a proposed update for the IDR working group charter.
Note that we just made up the dates in the goals and milestones,
and the WG should come up with realistic ones.

  Bill and Alex

[*] "finished" means, in this case, WG consensus, WG Last Call,
AD Review, IETF Last Call, and IESG approval for publication.

[**] In further support of the goal of having a quality specification
that reflects current reality, the ADs have been working on assembling
a team of reviewers that consists primarily of protocol implementors,
who have committed their time to examine the spec.  We will be
sending another message to this list explaining the details of how
this team will do its work.

- - -

The Inter-Domain Routing Working Group is chartered to standardize
and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
1771] capable of supporting policy based routing for TCP/IP internets.
The objective is to promote the use of BGP-4 to support IP version
4 and IP version 6. The working group will continue to work on
improving the scalability of BGP.

The current tasks of the WG are limited to:

- Revise and clarify the base BGP4 document (RFC 1771). Note that
RFC 1771 no longer documents existing practice and one goal of the
update is document existing practice. Determine whether the document
can be advanced as full Standard or needs to recycle at Proposed
or Draft Standard.

- Submit updated MIBs to accompany the revised base BGP4 document.

Once these tasks are completed, work will progress on the following:

- Review and Evaluate Existing RFCs on AS Confederations and Route
Reflection. If changes are needed, create and advance revisions.

- Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see
if any changes need to be made based on current Internet practice
or based on the changes to the current bgp draft. If changes are
needed, create an revision. Issue the WG Last Call on advancing
the document to Draft Standard.

- Produce an updated MIB for AS Confederations, Route Reflection,
Communities, Multi-Protocol BGP, etc..

- Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
as Draft Standard.

- Complete work on an Extended Community Attribute. Develop MIB
for BGP Extended Communities.

- Extend BGP to support a 4-byte AS number, develop plan for
transitioning to usage of 4-byte AS numbers

- Progress along the IETF standards track a BGP-based mechanism
that allows a BGP speaker to send to its BGP peer a set of route
filters that the peer would use to constrain/filter its outbound
routing updates to the speaker. Currently defined in
draft-ietf-idr-route-filter-03.txt.

- Progress along standards track an Outbound Router Filter (ORF)
type for BGP, that can be used to perform aspath based route
filtering. The ORF-type will support aspath based route filtering
as well as regular expression based matching for address groups.
Currently defined in draft-ietf-idr-aspath-orf-00.txt.

Tasks for this working group are limited to those listed above;
new items to be added to the charter must be approved by the IESG.

Goals and Milestones

DONE    Submit BGP Capability Advertisement to the IESG
NOV 02  Submit BGP4 document to IESG.
DEC 02  Submit updated base BGP4 MIB to IESG.
MAR 03  Submit extensible BGP MIB to IESG.
MAR 03  Submit Extended Communities draft to IESG.
MAR 03  Submit 4-byte AS ID to IESG.
MAR 03  Initial Draft for RFC2858 (if needed)
MAR 03  BGP TCP MD5 signatures document to IESG.
MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.


Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA05548 for <[e-mail]>; Thu, 22 Aug 2002 19:09:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8B2E591256; Thu, 22 Aug 2002 19:07:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EEA839137A; Thu, 22 Aug 2002 19:07:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7CCDF91256 for <[e-mail]>; Thu, 22 Aug 2002 19:07:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 632A85DE72; Thu, 22 Aug 2002 19:07:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by segue.merit.edu (Postfix) with ESMTP id D8D365DDDA for <[e-mail]>; Thu, 22 Aug 2002 19:07:27 -0400 (EDT)
Received: (from achandra@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA00448; Thu, 22 Aug 2002 16:07:25 -0700 (PDT)
Date: Thu, 22 Aug 2002 16:07:24 -0700
From: Chandrashekhar Appanna <[e-mail]>
To: Manav Bhatia <[e-mail]>
Cc: Pedro Roque Marques <[e-mail]>, [e-mail]
Subject: Re: BGP INFORM message
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <07f501c24998$77f0ed90$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <07f501c24998$77f0ed90$[e-mail]>
User-Agent: Mutt/1.4i
Sender: [e-mail]
Precedence: bulk

On Thu, Aug 22, 2002 at 10:27:49AM +0530, Manav Bhatia wrote:
> Pedro,
> 
> |
> | If i understand things correctly, the WG has been trying to adjust
> | what is documented according to deployment... while that apears to be
> | a worthwhile goal, the question of what is deployed might be answered
> | differently by different people. The question of what *should be*
> | deployed probably has an even higher number of answers...
> 
> There is a slight difference .. WG has been trying to adjust to the "best"
> practises out there in the field after taking a popular censensus on what
> everyone feels is the best and is required and not just documenting the
> deployment.
> |
> | If you aproach this document from the point of view of what is
> | 'deployed' what should be done when different implementations do
> | different things... what implementations should be considered in a
> | sample, etc.
> 
> No particular implementation .. only what everyone feels is the best and
> most optimal!
> 
> | I would also caution against attempting to over-specify particular
> | areas. With apologies in advance to Sue, which i'm sure put a lot of
> | work on it, imho having a detailed state machine doesn't really add
> | value. It is imho too close to implementation details and probably
> | impossible to verify. As an implementor, i prefer when a spec
> | documents what is intended (and why as a bonus) and the minimum
> | details necessary to interoperate.
> |
> 
> I believe that we need the state machine to be properly documented because
> if some vendor changes its implementation (or puts a bug!) in the state
> machine and if its not documented then there is no "standard" to hold them
> too OR if tomorrow one vendor decides to defer sending KEEPALIVE packets

  Not sure I understand your example - what is the problem and how do
  you think we can fix it? (I do not see the problem).

  The FSM is internal to an implementation and is a guide for implementations.
  How do you think you can detect non compliance for sure?

  -
  Chandra A.

> upon recieving other BGP protocol mesages then we have an issue with the
> interoperatability since the other side has no clue as to why its not
> receiving those messages. It is thus proper to have everything properly
> documented in the draft which forms the basis over which implementations
> are written.
> 
> | I'm not aware that among the large number of interoperable BGP
> | implementations this was ever a significant issue.
> 
> An example of disparate FSM implementations causing interoperatability
> problems has just been citied above.
> 
> Regards,
> Manav
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA15654 for <[e-mail]>; Thu, 22 Aug 2002 09:13:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A027A91252; Thu, 22 Aug 2002 09:13:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65B0391348; Thu, 22 Aug 2002 09:13:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 29C8991252 for <[e-mail]>; Thu, 22 Aug 2002 09:13:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B473F5DE51; Thu, 22 Aug 2002 09:13:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 577555DE3B for <[e-mail]>; Thu, 22 Aug 2002 09:13:12 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7MDDBj86479; Thu, 22 Aug 2002 09:13:11 -0400 (EDT) (envelope-from [e-mail])
Received: from SKH.nexthop.com ([64.211.218.13]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7MDD7186472; Thu, 22 Aug 2002 09:13:08 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 22 Aug 2002 13:13:07 -0400
To: "Tom Petch" <[e-mail]>
From: Susan Hares <[e-mail]>
Subject: Re: TCP state machine doubts
Cc: "Abarbanel, Benjamin" <[e-mail]>, "'Susan Hares'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, "Kunihiro Ishiguro" <[e-mail]>, "BGP mailing list" <[e-mail]>
In-Reply-To: <001201c24962$ca39bf40$0301a8c0@tom3>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Tom:

The FSM allows both single FSM and two FSM approaches.
The document does encompass both implementation types.

Even if an implementation uses two FSMs, the whole entity
is still one box.  Does this clear up the misconceptions?

If not, could you send me a list of questions?

Sue

At 11:33 PM 8/21/2002 +0100, Tom Petch wrote:
>I wonder if there is an underlying question of what the FSM is the
>state of; I do get confused reading it since I believe much but not
>all of it relates to the state of the relationship with a single peer,
>a single speaker with whom the local system may have zero or one or
>more transport connections.  But in other places, perhaps 2.1 partA
>Administrative Events it seems to refer to the whole local system with
>potentially multiple peer relationships which will at later times be
>in different states as defined in the FSM, established, open sent,
>idle etc..
>
>Tom Petch, Network Consultant
>[e-mail]
>+(44) 192 575 3018
>-----Original Message-----
>From: Abarbanel, Benjamin <[e-mail]>
>To: 'Susan Hares' <[e-mail]>
>Cc: 'Jeffrey Haas' <[e-mail]>; Abarbanel, Benjamin
><[e-mail]>; Kunihiro Ishiguro
><[e-mail]>; BGP mailing list <[e-mail]>
>Date: 21 August 2002 16:39
>Subject: RE: TCP state machine doubts
>
>
> >
> >Sue:
> >  Just a follow up suggestion. Can we improve the wording within the
>FSM
> >document to mention any sensitivy to RIB synchronization points if
>such
> >features as Route Refresh or Gracefull Restart, etc. are introduced
>in the
> >spec?
> >
> >Thanks,
> >Ben
> >




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA29222 for <[e-mail]>; Thu, 22 Aug 2002 00:58:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 68E5F91332; Thu, 22 Aug 2002 00:58:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3213591333; Thu, 22 Aug 2002 00:58:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB6D891332 for <[e-mail]>; Thu, 22 Aug 2002 00:58:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BC5CE5DD97; Thu, 22 Aug 2002 00:58:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from realname (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 6C7385DD8E for <[e-mail]>; Thu, 22 Aug 2002 00:58:29 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) id <[e-mail]> for [e-mail]; Thu, 22 Aug 2002 14:01:59 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 22 Aug 2002 14:01:59 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) with ESMTPA id <[e-mail]> for [e-mail]; Thu, 22 Aug 2002 14:02:15 +0900 (KST)
Date: Thu, 22 Aug 2002 10:29:05 +0530
From: Manav Bhatia <[e-mail]>
Subject: Re: BGP INFORM message
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <080701c24998$a4b27290$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

yes

----- Original Message -----
From: "Yakov Rekhter" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, August 21, 2002 8:07 PM
Subject: BGP INFORM message


| Folks,
|
| To help determine whether there is a rough consensus for
| accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
| document, please send an e-mail with either "yes" or "no".
| The deadline is August 29.
|
| Yakov.
| ------- Forwarded Message
|
| Date:    Thu, 15 Aug 2002 07:00:49 -0700
| From:    Yakov Rekhter <[e-mail]>
| To:      [e-mail]
| Subject: BGP INFORM message
|
| Folks,
|
| The authors of draft-nalawade-bgp-inform-02.txt would like
| to make it the IDR WG document. The deadline for comments
| (either positive or negative) on this request is August 29.
|
| Yakov.
| - ------- Forwarded Message
|
| Date:    Thu, 15 Aug 2002 08:15:30 -0400
| From:    [e-mail]
| To:      IETF-Announce: ;
| Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt
|
| - - --NextPart
|
| A New Internet-Draft is available from the on-line Internet-Drafts
directories.
|
|
| Title : BGPv4 INFORM message
| Author(s) : G. Nalawade, J. Scudder, D. Ward
| Filename : draft-nalawade-bgp-inform-02.txt
| Pages : 11
| Date : 14-Aug-02
|
| This document defines a new message type, the BGP INFORM
| message that communicates Informational data and operational
| warnings without resetting the peering session.
|
| A URL for this Internet-Draft is:
| http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt
|
| To remove yourself from the IETF Announcement list, send a message to
| ietf-announce-request with the word unsubscribe in the body of the
message.
|
| Internet-Drafts are also available by anonymous FTP. Login with the
username
| "anonymous" and a password of your e-mail address. After logging in,
| type "cd internet-drafts" and then
| "get draft-nalawade-bgp-inform-02.txt".
|
| A list of Internet-Drafts directories can be found in
| http://www.ietf.org/shadow.html
| or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
|
|
| Internet-Drafts can also be obtained by e-mail.
|
| Send a message to:
| [e-mail].
| In the body type:
| "FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
|
| NOTE: The mail server at ietf.org can return the document in
| MIME-encoded form by using the "mpack" utility.  To use this
| feature, insert the command "ENCODING mime" before the "FILE"
| command.  To decode the response(s), you will need "munpack" or
| a MIME-compliant mail reader.  Different MIME-compliant mail readers
| exhibit different behavior, especially when dealing with
| "multipart" MIME messages (i.e. documents which have been split
| up into multiple messages), so check your local documentation on
| how to manipulate these messages.
|
|
| Below is the data which will enable a MIME compliant mail reader
| implementation to automatically retrieve the ASCII version of the
| Internet-Draft.
|
| - - --NextPart
| Content-Type: Multipart/Alternative; Boundary="OtherAccess"
|
| - - --OtherAccess
| Content-Type: Message/External-body;
| access-type="mail-server";
| server="[e-mail]"
|
| Content-Type: text/plain
| Content-ID: <[e-mail]>
|
| ENCODING mime
| FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt
|
| - - --OtherAccess
| Content-Type: Message/External-body;
| name="draft-nalawade-bgp-inform-02.txt";
| site="ftp.ietf.org";
| access-type="anon-ftp";
| directory="internet-drafts"
|
| Content-Type: text/plain
| Content-ID: <[e-mail]>
|
| - - --OtherAccess--
|
| - - --NextPart--
|
|
|
| - ------- End of Forwarded Message
|
|
| ------- End of Forwarded Message
|



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA29183 for <[e-mail]>; Thu, 22 Aug 2002 00:57:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A799291228; Thu, 22 Aug 2002 00:57:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7576A91332; Thu, 22 Aug 2002 00:57:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 387FA91228 for <[e-mail]>; Thu, 22 Aug 2002 00:57:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1A61F5DD97; Thu, 22 Aug 2002 00:57:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from realname (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id BFBF55DD8E for <[e-mail]>; Thu, 22 Aug 2002 00:57:14 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) id <[e-mail]> for [e-mail]; Thu, 22 Aug 2002 14:00:44 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 22 Aug 2002 14:00:44 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) with ESMTPA id <[e-mail]> for [e-mail]; Thu, 22 Aug 2002 14:01:00 +0900 (KST)
Date: Thu, 22 Aug 2002 10:27:49 +0530
From: Manav Bhatia <[e-mail]>
Subject: Re: BGP INFORM message
To: Pedro Roque Marques <[e-mail]>
Cc: [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <07f501c24998$77f0ed90$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Pedro,

|
| If i understand things correctly, the WG has been trying to adjust
| what is documented according to deployment... while that apears to be
| a worthwhile goal, the question of what is deployed might be answered
| differently by different people. The question of what *should be*
| deployed probably has an even higher number of answers...

There is a slight difference .. WG has been trying to adjust to the "best"
practises out there in the field after taking a popular censensus on what
everyone feels is the best and is required and not just documenting the
deployment.
|
| If you aproach this document from the point of view of what is
| 'deployed' what should be done when different implementations do
| different things... what implementations should be considered in a
| sample, etc.

No particular implementation .. only what everyone feels is the best and
most optimal!

| I would also caution against attempting to over-specify particular
| areas. With apologies in advance to Sue, which i'm sure put a lot of
| work on it, imho having a detailed state machine doesn't really add
| value. It is imho too close to implementation details and probably
| impossible to verify. As an implementor, i prefer when a spec
| documents what is intended (and why as a bonus) and the minimum
| details necessary to interoperate.
|

I believe that we need the state machine to be properly documented because
if some vendor changes its implementation (or puts a bug!) in the state
machine and if its not documented then there is no "standard" to hold them
too OR if tomorrow one vendor decides to defer sending KEEPALIVE packets
upon recieving other BGP protocol mesages then we have an issue with the
interoperatability since the other side has no clue as to why its not
receiving those messages. It is thus proper to have everything properly
documented in the draft which forms the basis over which implementations
are written.

| I'm not aware that among the large number of interoperable BGP
| implementations this was ever a significant issue.

An example of disparate FSM implementations causing interoperatability
problems has just been citied above.

Regards,
Manav




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA22089 for <[e-mail]>; Wed, 21 Aug 2002 21:30:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 047CE91318; Wed, 21 Aug 2002 21:29:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C3C609131D; Wed, 21 Aug 2002 21:29:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 753D791318 for <[e-mail]>; Wed, 21 Aug 2002 21:29:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 53E7A5DEDA; Wed, 21 Aug 2002 21:29:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id CCFCC5DE84 for <[e-mail]>; Wed, 21 Aug 2002 21:29:32 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17hgmw-000Fcf-00; Wed, 21 Aug 2002 18:29:30 -0700
Date: Wed, 21 Aug 2002 18:28:00 -0700
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Cc: Randy Bush <[e-mail]>, [e-mail]
Subject: Re: BGP INFORM message
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Pedro,

> I'm not a fan of the draft in question for reasons that i've explained
> several times in the past but i believe this issue should be resolved
> from a technical rather than procedural point of view.

Discussion about technical merits of the draft is definitely a must
and by no means the procedural issues should substitute it. Those
are essentially two separate issues: 1) whether the proposal makes
sense technically, and 2) whether the priority of the work is high
enough for the WG to spend its cycles on it at the moment.

> Assuming that a draft technically adds value to BGP or interdomain
> operations i believe it is on charter for the IDR working group, since
> the workgroup is concerned w/ essentially that task, regardless of the
> text present in the web page (which i'm sure most of the regular
> participants have never read).

There are formal rules about the WG charter. (I thought about putting
my own words here, but I figured it would turn out to be rephrased
parts of section 2 from RFC2418.) Of course, it is up to the WG chairs
and the ADs to decide how strict they want to be about this depending
on how well the work in the WG is going.

> As for the question of 'progress of the base spec'... if the IESG
> wants to put that question to the WG then it should do so, imho.

We (ADs, it is not at the IESG level) will.

> I don't see how it is related with any other work.

> The resources, to my knowledge, are not overlapping. It is not as if
> people that are considering this issue would otherwise go work on the
> base spec.

It is not black and white here. It is a question of focusing the
effort of the WG.

We've been sweating over the spec for how many years? We all know
that finishing the last bits is the least interesting work and all other
new things are much more attractive, but we just have to focus on this
and do it. I've been running around trying to help Sue and talking to
many of you folks personally and standing up at the meeting asking exactly
the same thing--let's finish the ... spec. And we're working on pulling
the resources together to make this happen.

> The IESG and ADs may or may not want to give its stamp of aproval to
> the work of any working group but i believe that such evaluation
> should be based on technical rather than procedural grounds.

See my 1st comment, pls.

> As to the question of the base spec... without wanting to diminish the
> value of the current set of drafts (i'm sure a lot of people put a
> whole lot of effort on it), i often wonder if the WG is actually going
> in the right direction.

I think we disagree here and below. If reading the spec is not enough
to implement the protocol (which I believe is the case), then the spec
is incomplete. And I fundamentally believe that it is a high priority
task to have an accurate spec. The longer we don't have it (or even
worse--the longer we have a spec that people know is incomplete)--
the more divergence in implementations we will see that will finally
lead to incompatibilities. It is not about implementations only--
documenting protocol extensions in the absence of accurate base spec
is also troublesome; and we already are having these problems.
But I guess what I'm doing here is trying to explain the generic
question of 'why it is good to have accurate specs', which should
be obvious...

Regarding your note on FSM, I strongly believe that FSM should
be part of the spec.

Regards.

Alex


> There is a specification, which although imperfect, as been the basis
> of dozen of interoperable implementations. Implementations that do
> differ from the spec, however each one of them in its own way.

> If i understand things correctly, the WG has been trying to adjust
> what is documented according to deployment... while that apears to be
> a worthwhile goal, the question of what is deployed might be answered
> differently by different people. The question of what *should be*
> deployed probably has an even higher number of answers...

> If you aproach this document from the point of view of what is
> 'deployed' what should be done when different implementations do
> different things... what implementations should be considered in a
> sample, etc.

> If you take the minimum common denominator between all implementations
> you might not be left w/ a document that is superior to the existing
> one.

> It is also not clear to me that the existing -1[6-7] draft is closer
> to 'reality' than RFC 1771, even because 'reality' is hard to pinpoint
> here (depends on implementations, version of such implementations,
> deployment configs, etc). We might just end up trading a set of
> divergences between document and deployment for another.

> I would also caution against attempting to over-specify particular
> areas. With apologies in advance to Sue, which i'm sure put a lot of
> work on it, imho having a detailed state machine doesn't really add
> value. It is imho too close to implementation details and probably
> impossible to verify. As an implementor, i prefer when a spec
> documents what is intended (and why as a bonus) and the minimum
> details necessary to interoperate.

> I'm not aware that among the large number of interoperable BGP
> implementations this was ever a significant issue.

> Just trying to go over some of the potential factors behind the
> lukewarm enthusiasm that the WG has shown over this particular
> endeavor...

>   Pedro.




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA16629 for <[e-mail]>; Wed, 21 Aug 2002 18:47:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CCDF2912E5; Wed, 21 Aug 2002 18:43:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DF52912E6; Wed, 21 Aug 2002 18:43:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DFF2C912E5 for <[e-mail]>; Wed, 21 Aug 2002 18:41:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C13395DE66; Wed, 21 Aug 2002 18:41:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from nemesis.systems.pipex.net (nemesis.systems.pipex.net [62.241.160.8]) by segue.merit.edu (Postfix) with ESMTP id 779B55DDC2 for <[e-mail]>; Wed, 21 Aug 2002 18:41:42 -0400 (EDT)
Received: from tom3 (usermi65.uk.uudial.com [62.188.122.249]) by nemesis.systems.pipex.net (Postfix) with SMTP id 61E2232EA7; Wed, 21 Aug 2002 23:05:58 +0100 (BST)
Message-ID: <00ab01c24963$841d5520$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>, "Yakov Rekhter" <[e-mail]>
Subject: Re: BGP INFORM message
Date: Wed, 21 Aug 2002 23:38:09 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

No

Tom Petch, Network Consultant
[e-mail]

-----Original Message-----
From: Yakov Rekhter <[e-mail]>
To: [e-mail] <[e-mail]>
Date: 21 August 2002 15:36
Subject: BGP INFORM message


>Folks,
>
>To help determine whether there is a rough consensus for
>accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
>document, please send an e-mail with either "yes" or "no".
>The deadline is August 29.
>
>Yakov.
>------- Forwarded Message
>
>Date:    Thu, 15 Aug 2002 07:00:49 -0700
>From:    Yakov Rekhter <[e-mail]>
>To:      [e-mail]
>Subject: BGP INFORM message
>
>Folks,
>
>The authors of draft-nalawade-bgp-inform-02.txt would like
>to make it the IDR WG document. The deadline for comments
>(either positive or negative) on this request is August 29.
>
>Yakov.
>- ------- Forwarded Message
>
>Date:    Thu, 15 Aug 2002 08:15:30 -0400
>From:    [e-mail]
>To:      IETF-Announce: ;
>Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt
>
>- - --NextPart
>
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : BGPv4 INFORM message
> Author(s) : G. Nalawade, J. Scudder, D. Ward
> Filename : draft-nalawade-bgp-inform-02.txt
> Pages : 11
> Date : 14-Aug-02
>
>This document defines a new message type, the BGP INFORM
>message that communicates Informational data and operational
>warnings without resetting the peering session.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the
message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the
username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
> "get draft-nalawade-bgp-inform-02.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
> [e-mail].
>In the body type:
> "FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
>
>NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>- - --NextPart
>Content-Type: Multipart/Alternative; Boundary="OtherAccess"
>
>- - --OtherAccess
>Content-Type: Message/External-body;
> access-type="mail-server";
> server="[e-mail]"
>
>Content-Type: text/plain
>Content-ID: <[e-mail]>
>
>ENCODING mime
>FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt
>
>- - --OtherAccess
>Content-Type: Message/External-body;
> name="draft-nalawade-bgp-inform-02.txt";
> site="ftp.ietf.org";
> access-type="anon-ftp";
> directory="internet-drafts"
>
>Content-Type: text/plain
>Content-ID: <[e-mail]>
>
>- - --OtherAccess--
>
>- - --NextPart--
>
>
>
>- ------- End of Forwarded Message
>
>
>------- End of Forwarded Message
>




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA16329 for <[e-mail]>; Wed, 21 Aug 2002 18:37:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 265FC912D7; Wed, 21 Aug 2002 18:36:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5BC4912D8; Wed, 21 Aug 2002 18:36:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E3170912D7 for <[e-mail]>; Wed, 21 Aug 2002 18:36:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D09495DE2D; Wed, 21 Aug 2002 18:36:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from nemesis.systems.pipex.net (nemesis.systems.pipex.net [62.241.160.8]) by segue.merit.edu (Postfix) with ESMTP id 9E9975DDC2 for <[e-mail]>; Wed, 21 Aug 2002 18:36:30 -0400 (EDT)
Received: from tom3 (usermc17.uk.uudial.com [62.188.120.115]) by nemesis.systems.pipex.net (Postfix) with SMTP id BA53B32EE0; Wed, 21 Aug 2002 23:00:44 +0100 (BST)
Message-ID: <001201c24962$ca39bf40$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>, "'Susan Hares'" <[e-mail]>
Cc: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, "Kunihiro Ishiguro" <[e-mail]>, "BGP mailing list" <[e-mail]>
Subject: Re: TCP state machine doubts
Date: Wed, 21 Aug 2002 23:33:28 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

I wonder if there is an underlying question of what the FSM is the
state of; I do get confused reading it since I believe much but not
all of it relates to the state of the relationship with a single peer,
a single speaker with whom the local system may have zero or one or
more transport connections.  But in other places, perhaps 2.1 partA
Administrative Events it seems to refer to the whole local system with
potentially multiple peer relationships which will at later times be
in different states as defined in the FSM, established, open sent,
idle etc..

Tom Petch, Network Consultant
[e-mail]
+(44) 192 575 3018
-----Original Message-----
From: Abarbanel, Benjamin <[e-mail]>
To: 'Susan Hares' <[e-mail]>
Cc: 'Jeffrey Haas' <[e-mail]>; Abarbanel, Benjamin
<[e-mail]>; Kunihiro Ishiguro
<[e-mail]>; BGP mailing list <[e-mail]>
Date: 21 August 2002 16:39
Subject: RE: TCP state machine doubts


>
>Sue:
>  Just a follow up suggestion. Can we improve the wording within the
FSM
>document to mention any sensitivy to RIB synchronization points if
such
>features as Route Refresh or Gracefull Restart, etc. are introduced
in the
>spec?
>
>Thanks,
>Ben
>



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA16297 for <[e-mail]>; Wed, 21 Aug 2002 18:36:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5A0F3912CC; Wed, 21 Aug 2002 18:36:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D6789912D7; Wed, 21 Aug 2002 18:36:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 21604912CC for <[e-mail]>; Wed, 21 Aug 2002 18:36:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0E16E5DD9C; Wed, 21 Aug 2002 18:36:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10]) by segue.merit.edu (Postfix) with ESMTP id CFA3C5DDC2 for <[e-mail]>; Wed, 21 Aug 2002 18:36:12 -0400 (EDT)
Received: by entmail.gnilink.com with Internet Mail Service (5.5.2656.59) id <QSYH3A7V>; Wed, 21 Aug 2002 18:36:12 -0400
Message-ID: <[e-mail]>
From: "Martin, Christian" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: BGP INFORM message
Date: Wed, 21 Aug 2002 18:36:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

yes

>-----Original Message-----
>From: Yakov Rekhter [mailto:[e-mail]] 
>Sent: Wednesday, August 21, 2002 10:37 AM
>To: [e-mail]
>Subject: BGP INFORM message
>
>
>Folks,
>
>To help determine whether there is a rough consensus for 
>accepting draft-nalawade-bgp-inform-02.txt as an IDR WG 
>document, please send an e-mail with either "yes" or "no". The 
>deadline is August 29.
>
>Yakov.
>------- Forwarded Message
>
>Date:    Thu, 15 Aug 2002 07:00:49 -0700
>From:    Yakov Rekhter <[e-mail]>
>To:      [e-mail]
>Subject: BGP INFORM message
>
>Folks,
>
>The authors of draft-nalawade-bgp-inform-02.txt would like
>to make it the IDR WG document. The deadline for comments 
>(either positive or negative) on this request is August 29. 
>
>Yakov.
>- ------- Forwarded Message
>
>Date:    Thu, 15 Aug 2002 08:15:30 -0400
>From:    [e-mail]
>To:      IETF-Announce: ;
>Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt
>
>- - --NextPart
>
>A New Internet-Draft is available from the on-line 
>Internet-Drafts directories.
>
>
>	Title		: BGPv4 INFORM message
>	Author(s)	: G. Nalawade, J. Scudder, D. Ward
>	Filename	: draft-nalawade-bgp-inform-02.txt
>	Pages		: 11
>	Date		: 14-Aug-02
>	
>This document defines a new message type, the BGP INFORM 
>message that communicates Informational data and operational 
>warnings without resetting the peering session.
>
>A URL for this Internet-Draft is: 
>http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt
>
>To remove yourself from the IETF Announcement list, send a message to 
>ietf-announce-request with the word unsubscribe in the body of 
>the message.
>
>Internet-Drafts are also available by anonymous FTP. Login 
>with the username "anonymous" and a password of your e-mail 
>address. After logging in, type "cd internet-drafts" and then
>	"get draft-nalawade-bgp-inform-02.txt".
>
>A list of Internet-Drafts directories can be found in 
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[e-mail].
>In the body type:
>	"FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant 
>mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>		
>		
>Below is the data which will enable a MIME compliant mail 
>reader implementation to automatically retrieve the ASCII 
>version of the Internet-Draft.
>
>- - --NextPart
>Content-Type: Multipart/Alternative; Boundary="OtherAccess"
>
>- - --OtherAccess
>Content-Type: Message/External-body;
>	access-type="mail-server";
>	server="[e-mail]"
>
>Content-Type: text/plain
>Content-ID:	<[e-mail]>
>
>ENCODING mime
>FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt
>
>- - --OtherAccess
>Content-Type: Message/External-body;
>	name="draft-nalawade-bgp-inform-02.txt";
>	site="ftp.ietf.org";
>	access-type="anon-ftp";
>	directory="internet-drafts"
>
>Content-Type: text/plain
>Content-ID:	<[e-mail]>
>
>- - --OtherAccess--
>
>- - --NextPart--
>
>
>
>- ------- End of Forwarded Message
>
>
>------- End of Forwarded Message
>


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA16287 for <[e-mail]>; Wed, 21 Aug 2002 18:36:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7FE79912C9; Wed, 21 Aug 2002 18:35:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E76D3912E5; Wed, 21 Aug 2002 18:35:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 66F11912CC for <[e-mail]>; Wed, 21 Aug 2002 18:35:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 504775DDC2; Wed, 21 Aug 2002 18:35:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10]) by segue.merit.edu (Postfix) with ESMTP id 21CEF5DD9C for <[e-mail]>; Wed, 21 Aug 2002 18:35:46 -0400 (EDT)
Received: by entmail.gnilink.com with Internet Mail Service (5.5.2656.59) id <QSYH3A7S>; Wed, 21 Aug 2002 18:35:45 -0400
Message-ID: <[e-mail]>
From: "Martin, Christian" <[e-mail]>
To: "'Pedro Roque Marques'" <[e-mail]>, Alex Zinin <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: BGP INFORM message
Date: Wed, 21 Aug 2002 18:35:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Pedro,

I agree with most of your points, with one exception :)  (see below)

: Pedro Roque Marques wrote:
>
>
>I would also caution against attempting to over-specify 
>particular areas. With apologies in advance to Sue, which i'm 
>sure put a lot of work on it, imho having a detailed state 
>machine doesn't really add value. It is imho too close to 
>implementation details and probably impossible to verify. As 
>an implementor, i prefer when a spec documents what is 
>intended (and why as a bonus) and the minimum details 
>necessary to interoperate.

I would think the state machine has a significant role in ensuring
interoperability, at least wrt to the type of actions that should or must be
taken given a particular event or set of events.  This ensures consistency
across vendor implementations, imho.  From an operators point of view, it
also ensures that vendors that claim compliance to a standard can be held
accountable if their implementations fall short.  The IETF tends to be
laissez-faire when it comes to specification rigor, which generally leads to
finger pointing between vendors when they don't interoperate.

>I'm not aware that among the large number of interoperable BGP 
>implementations this was ever a significant issue.

Recall a short while ago when the CEASE sub-codes weren't there?  This was a
major issue for my team operationally, because when received a CEASE message
we didn't know what was wrong with the FSM.  Did we send a bad message?
What kind of message?  How do we fix it?

Having a detailed FSM helps answer these questions more quickly, IMO.
Especially when two vendors are involved.

Regards,

-chris

>
>Just trying to go over some of the potential factors behind 
>the lukewarm enthusiasm that the WG has shown over this 
>particular endeavor...
>
>  Pedro.
>


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA16269 for <[e-mail]>; Wed, 21 Aug 2002 18:35:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4611E91309; Wed, 21 Aug 2002 18:35:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7BA12912C9; Wed, 21 Aug 2002 18:35:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 22C4D912C6 for <[e-mail]>; Wed, 21 Aug 2002 18:35:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 031985DDC2; Wed, 21 Aug 2002 18:35:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 845BE5DD9C for <[e-mail]>; Wed, 21 Aug 2002 18:35:00 -0400 (EDT)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA17939 for <[e-mail]>; Wed, 21 Aug 2002 18:34:59 -0400 (EDT)
Date: Wed, 21 Aug 2002 18:34:59 -0400 (EDT)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: [e-mail]
Subject: Re: BGP INFORM message
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Yes.

Russ

On Wed, 21 Aug 2002, Yakov Rekhter wrote:

> Folks,
> 
> To help determine whether there is a rough consensus for
> accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
> document, please send an e-mail with either "yes" or "no".
> The deadline is August 29.
> 
> Yakov.
> ------- Forwarded Message
> 
> Date:    Thu, 15 Aug 2002 07:00:49 -0700
> From:    Yakov Rekhter <[e-mail]>
> To:      [e-mail]
> Subject: BGP INFORM message
> 
> Folks,
> 
> The authors of draft-nalawade-bgp-inform-02.txt would like
> to make it the IDR WG document. The deadline for comments
> (either positive or negative) on this request is August 29. 
> 
> Yakov.
> - ------- Forwarded Message
> 
> Date:    Thu, 15 Aug 2002 08:15:30 -0400
> From:    [e-mail]
> To:      IETF-Announce: ;
> Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt
> 
> - - --NextPart
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: BGPv4 INFORM message
> 	Author(s)	: G. Nalawade, J. Scudder, D. Ward
> 	Filename	: draft-nalawade-bgp-inform-02.txt
> 	Pages		: 11
> 	Date		: 14-Aug-02
> 	
> This document defines a new message type, the BGP INFORM
> message that communicates Informational data and operational
> warnings without resetting the peering session.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-nalawade-bgp-inform-02.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[e-mail].
> In the body type:
> 	"FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> - - --NextPart
> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
> 
> - - --OtherAccess
> Content-Type: Message/External-body;
> 	access-type="mail-server";
> 	server="[e-mail]"
> 
> Content-Type: text/plain
> Content-ID:	<[e-mail]>
> 
> ENCODING mime
> FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt
> 
> - - --OtherAccess
> Content-Type: Message/External-body;
> 	name="draft-nalawade-bgp-inform-02.txt";
> 	site="ftp.ietf.org";
> 	access-type="anon-ftp";
> 	directory="internet-drafts"
> 
> Content-Type: text/plain
> Content-ID:	<[e-mail]>
> 
> - - --OtherAccess--
> 
> - - --NextPart--
> 
> 
> 
> - ------- End of Forwarded Message
> 
> 
> ------- End of Forwarded Message
> 

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





Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA15783 for <[e-mail]>; Wed, 21 Aug 2002 18:19:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 95096913A0; Wed, 21 Aug 2002 18:16:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A72569151F; Wed, 21 Aug 2002 18:15:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C0104913A0 for <[e-mail]>; Wed, 21 Aug 2002 18:15:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A5DAB5DE2D; Wed, 21 Aug 2002 18:15:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 2DBCD5DD9C for <[e-mail]>; Wed, 21 Aug 2002 18:15:48 -0400 (EDT)
Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7LMFlm98681; Wed, 21 Aug 2002 15:15:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id g7LMFlC66307; Wed, 21 Aug 2002 15:15:47 -0700 (PDT) (envelope-from roque)
Date: Wed, 21 Aug 2002 15:15:47 -0700 (PDT)
Message-Id: <[e-mail]>
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Alex Zinin <[e-mail]>
Cc: Randy Bush <[e-mail]>, [e-mail]
Subject: Re: BGP INFORM message
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Sender: [e-mail]
Precedence: bulk

Alex Zinin writes:

> Randy, You're quite correct--as my message to the list last night
> suggests, it is premature to talk about accepting this draft as a WG
> document given that there is no work item in the WG charter covering
> this topic. Hence, at this stage, the question could indeed only be
> about whether the WG would like its charter to include this topic or
> not, and since charter updates have to be negotiated with the ADs
> and IESG, it indeed means working with the ADs. And as I hoped my
> message last night would hint, I'd rather see the WG finish the base
> spec before taking on any new work items.
  
I'm not a fan of the draft in question for reasons that i've explained
several times in the past but i believe this issue should be resolved
from a technical rather than procedural point of view.

Assuming that a draft technically adds value to BGP or interdomain
operations i believe it is on charter for the IDR working group, since
the workgroup is concerned w/ essentially that task, regardless of the
text present in the web page (which i'm sure most of the regular
participants have never read).

As for the question of 'progress of the base spec'... if the IESG
wants to put that question to the WG then it should do so, imho.  I
don't see how it is related with any other work.

The resources, to my knowledge, are not overlapping. It is not as if
people that are considering this issue would otherwise go work on the
base spec.

The IESG and ADs may or may not want to give its stamp of aproval to
the work of any working group but i believe that such evaluation
should be based on technical rather than procedural grounds.

As to the question of the base spec... without wanting to diminish the
value of the current set of drafts (i'm sure a lot of people put a
whole lot of effort on it), i often wonder if the WG is actually going
in the right direction.

There is a specification, which although imperfect, as been the basis
of dozen of interoperable implementations. Implementations that do
differ from the spec, however each one of them in its own way.

If i understand things correctly, the WG has been trying to adjust
what is documented according to deployment... while that apears to be
a worthwhile goal, the question of what is deployed might be answered
differently by different people. The question of what *should be*
deployed probably has an even higher number of answers...

If you aproach this document from the point of view of what is
'deployed' what should be done when different implementations do
different things... what implementations should be considered in a
sample, etc.

If you take the minimum common denominator between all implementations
you might not be left w/ a document that is superior to the existing
one.

It is also not clear to me that the existing -1[6-7] draft is closer
to 'reality' than RFC 1771, even because 'reality' is hard to pinpoint
here (depends on implementations, version of such implementations,
deployment configs, etc). We might just end up trading a set of
divergences between document and deployment for another.

I would also caution against attempting to over-specify particular
areas. With apologies in advance to Sue, which i'm sure put a lot of
work on it, imho having a detailed state machine doesn't really add
value. It is imho too close to implementation details and probably
impossible to verify. As an implementor, i prefer when a spec
documents what is intended (and why as a bonus) and the minimum
details necessary to interoperate.

I'm not aware that among the large number of interoperable BGP
implementations this was ever a significant issue.

Just trying to go over some of the potential factors behind the
lukewarm enthusiasm that the WG has shown over this particular
endeavor...

  Pedro.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA13490 for <[e-mail]>; Wed, 21 Aug 2002 17:10:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B9F3F913E4; Wed, 21 Aug 2002 17:05:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F37791358; Wed, 21 Aug 2002 16:56:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B4379130C for <[e-mail]>; Wed, 21 Aug 2002 16:42:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 801655DDDD; Wed, 21 Aug 2002 16:42:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id EC5125DD9F for <[e-mail]>; Wed, 21 Aug 2002 16:42:58 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7LKga061247; Wed, 21 Aug 2002 16:42:36 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7LKgP161214; Wed, 21 Aug 2002 16:42:25 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7LKgPX28793; Wed, 21 Aug 2002 16:42:25 -0400 (EDT)
Date: Wed, 21 Aug 2002 16:42:25 -0400
From: Jeffrey Haas <[e-mail]>
To: john heasley <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP INFORM message
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <p05111a00b989954992c2@[192.168.42.10]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Aug 21, 2002 at 12:57:39PM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Aug 21, 2002 at 12:57:39PM -0700, john heasley wrote:
> why is there no consideration of how this might be reflected in the
> bgp mib?  what about the dynamic capabilities?

I think I mentioned something about making INFORM more MIB friendly.
I welcome suggestions.

Right now, the base v2 mib doesn't encompass all of the protocol
extensions, just some of them.  After some implementation
experience comes about, adding the extensions makes a lot of sense.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA11489 for <[e-mail]>; Wed, 21 Aug 2002 16:11:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 22F89912D4; Wed, 21 Aug 2002 16:03:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4899C91301; Wed, 21 Aug 2002 16:03:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A8032912FF for <[e-mail]>; Wed, 21 Aug 2002 15:57:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8C9C75DDD5; Wed, 21 Aug 2002 15:57:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by segue.merit.edu (Postfix) with ESMTP id 0B2915DD9F for <[e-mail]>; Wed, 21 Aug 2002 15:57:43 -0400 (EDT)
Received: (from heas@localhost) by guelah.shrubbery.net (8.11.6/8.11.1) id g7LJvdD04073; Wed, 21 Aug 2002 19:57:39 GMT
Date: Wed, 21 Aug 2002 12:57:39 -0700
From: john heasley <[e-mail]>
To: "John G. Scudder" <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP INFORM message
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <p05111a00b989954992c2@[192.168.42.10]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <p05111a00b989954992c2@[192.168.42.10]>; from [e-mail] on Wed, Aug 21, 2002 at 03:08:19PM -0400
X-note: live free, or die!
X-homer: mmmm, forbidden doughnut.
Sender: [e-mail]
Precedence: bulk

Wed, Aug 21, 2002 at 03:08:19PM -0400, John G. Scudder:
> At 12:04 PM -0700 8/21/02, john heasley wrote:
> >as an operator, i am interested in more state and debug information,
> >esp. when it means not needing to rely upon the remote's operator, who
> >may be clue--.
> 
> BTW, it would be of particular interest to hear from more network operators.
> 
> >agreed that this draft is wanting.
> 
> No doubt, but would you care to elaborate?

off the cuff, i could envision an INFORM preceeding a reset/close
(NOTIFICATION) to provide more information on the cause.

6.1.4: are there any implementations that do not close the session when
       either a max-prefix is reached or some other error is encountered
       (malloc failure)?
       more useful to have an 'approaching max-prefix' INFORM?

6.1.5: is it really valid for the protocol to alter attributes like this?

perhaps defining event codes for further explaination of following
notifications would be useful?  eg: "cease due to shutdown"

defining every possible error condition will likely never happen (which
i'd guess is why folks are not welcoming INFORMs [a holy grail quest])
and there'd be those that are implementation specific.  but, more that
are defined rather than left as unspecified with a string TLV, whose
format is at an implementor's whim, the more useful INFORMs would be.

why is there no consideration of how this might be reflected in the
bgp mib?  what about the dynamic capabilities?



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA09478 for <[e-mail]>; Wed, 21 Aug 2002 15:08:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0EBB9912D0; Wed, 21 Aug 2002 15:08:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC247912D1; Wed, 21 Aug 2002 15:08:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CEA46912D0 for <[e-mail]>; Wed, 21 Aug 2002 15:08:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B23DC5DDAF; Wed, 21 Aug 2002 15:08:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id E95015DD9F for <[e-mail]>; Wed, 21 Aug 2002 15:08:28 -0400 (EDT)
Received: from [171.69.182.142] (dhcp-171-69-182-142.cisco.com [171.69.182.142]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA13854; Wed, 21 Aug 2002 15:08:20 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a00b989954992c2@[192.168.42.10]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 21 Aug 2002 15:08:19 -0400
To: john heasley <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: BGP INFORM message
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 12:04 PM -0700 8/21/02, john heasley wrote:
>as an operator, i am interested in more state and debug information,
>esp. when it means not needing to rely upon the remote's operator, who
>may be clue--.

BTW, it would be of particular interest to hear from more network operators.

>agreed that this draft is wanting.

No doubt, but would you care to elaborate?

Thanks,

--John


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA09357 for <[e-mail]>; Wed, 21 Aug 2002 15:04:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DDA61912CF; Wed, 21 Aug 2002 15:04:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95C89912C6; Wed, 21 Aug 2002 15:04:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B9CB1912E5 for <[e-mail]>; Wed, 21 Aug 2002 15:04:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9B8625DDAF; Wed, 21 Aug 2002 15:04:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by segue.merit.edu (Postfix) with ESMTP id 140AF5DD9F for <[e-mail]>; Wed, 21 Aug 2002 15:04:21 -0400 (EDT)
Received: (from heas@localhost) by guelah.shrubbery.net (8.11.6/8.11.1) id g7LJ4Ja03839; Wed, 21 Aug 2002 19:04:19 GMT
Date: Wed, 21 Aug 2002 12:04:18 -0700
From: john heasley <[e-mail]>
To: "Srihari R. Sangli" <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: BGP INFORM message
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Aug 21, 2002 at 11:54:42AM -0700
X-note: live free, or die!
X-homer: mmmm, forbidden doughnut.
Sender: [e-mail]
Precedence: bulk

example, please.

as an operator, i am interested in more state and debug information,
esp. when it means not needing to rely upon the remote's operator, who
may be clue--.

agreed that this draft is wanting.

Wed, Aug 21, 2002 at 11:54:42AM -0700, Srihari R. Sangli:
> 
> NO (overloads protocol, can be solved outside protocol scope).
> 
> srihari...
> 
> > To help determine whether there is a rough consensus for
> > accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
> > document, please send an e-mail with either "yes" or "no".
> > The deadline is August 29.
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA08967 for <[e-mail]>; Wed, 21 Aug 2002 14:55:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DF90B912C5; Wed, 21 Aug 2002 14:54:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A6CEE912C6; Wed, 21 Aug 2002 14:54:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE7BE912C5 for <[e-mail]>; Wed, 21 Aug 2002 14:54:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D8D865DF06; Wed, 21 Aug 2002 14:54:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from dmz1.procket.com (dmz1.procket.com [65.174.124.36]) by segue.merit.edu (Postfix) with ESMTP id A9BF25DE15 for <[e-mail]>; Wed, 21 Aug 2002 14:54:43 -0400 (EDT)
Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 2771723C3E; Wed, 21 Aug 2002 12:39:22 -0700 (PDT)
Received: from localhost (srihari@localhost) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g7LIsgi1004465; Wed, 21 Aug 2002 11:54:42 -0700 (PDT)
Date: Wed, 21 Aug 2002 11:54:42 -0700 (PDT)
From: "Srihari R. Sangli" <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP INFORM message
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

NO (overloads protocol, can be solved outside protocol scope).

srihari...

> To help determine whether there is a rough consensus for
> accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
> document, please send an e-mail with either "yes" or "no".
> The deadline is August 29.




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA08347 for <[e-mail]>; Wed, 21 Aug 2002 14:34:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1D66791203; Wed, 21 Aug 2002 14:32:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3408912C5; Wed, 21 Aug 2002 14:32:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BEDE191203 for <[e-mail]>; Wed, 21 Aug 2002 14:32:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A7EAC5DE15; Wed, 21 Aug 2002 14:32:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 55F705DDDD for <[e-mail]>; Wed, 21 Aug 2002 14:32:40 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id LAA17891; Wed, 21 Aug 2002 11:29:48 -0700 (PDT)
Date: Wed, 21 Aug 2002 11:29:48 -0700
From: [e-mail]
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP INFORM message
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Aug 21, 2002 at 07:37:21AM -0700
Sender: [e-mail]
Precedence: bulk

Yes.

Andrew

On Wed, Aug 21, 2002 at 07:37:21AM -0700, Yakov Rekhter wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> To: [e-mail]
> Subject: BGP INFORM message
> Date: Wed, 21 Aug 2002 07:37:21 -0700
> From: Yakov Rekhter <[e-mail]>
> Precedence: bulk
> X-OriginalArrivalTime: 21 Aug 2002 14:40:26.0949 (UTC) FILETIME=[B08B3750:01C24920]
> 
> Folks,
> 
> To help determine whether there is a rough consensus for
> accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
> document, please send an e-mail with either "yes" or "no".
> The deadline is August 29.
> 
> Yakov.
> ------- Forwarded Message
> 
> Date:    Thu, 15 Aug 2002 07:00:49 -0700
> From:    Yakov Rekhter <[e-mail]>
> To:      [e-mail]
> Subject: BGP INFORM message
> 
> Folks,
> 
> The authors of draft-nalawade-bgp-inform-02.txt would like
> to make it the IDR WG document. The deadline for comments
> (either positive or negative) on this request is August 29. 
> 
> Yakov.
> - ------- Forwarded Message
> 
> Date:    Thu, 15 Aug 2002 08:15:30 -0400
> From:    [e-mail]
> To:      IETF-Announce: ;
> Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt
> 
> - - --NextPart
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: BGPv4 INFORM message
> 	Author(s)	: G. Nalawade, J. Scudder, D. Ward
> 	Filename	: draft-nalawade-bgp-inform-02.txt
> 	Pages		: 11
> 	Date		: 14-Aug-02
> 	
> This document defines a new message type, the BGP INFORM
> message that communicates Informational data and operational
> warnings without resetting the peering session.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-nalawade-bgp-inform-02.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[e-mail].
> In the body type:
> 	"FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> - - --NextPart
> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
> 
> - - --OtherAccess
> Content-Type: Message/External-body;
> 	access-type="mail-server";
> 	server="[e-mail]"
> 
> Content-Type: text/plain
> Content-ID:	<[e-mail]>
> 
> ENCODING mime
> FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt
> 
> - - --OtherAccess
> Content-Type: Message/External-body;
> 	name="draft-nalawade-bgp-inform-02.txt";
> 	site="ftp.ietf.org";
> 	access-type="anon-ftp";
> 	directory="internet-drafts"
> 
> Content-Type: text/plain
> Content-ID:	<[e-mail]>
> 
> - - --OtherAccess--
> 
> - - --NextPart--
> 
> 
> 
> - ------- End of Forwarded Message
> 
> 
> ------- End of Forwarded Message


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA07776 for <[e-mail]>; Wed, 21 Aug 2002 14:17:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 05875912C2; Wed, 21 Aug 2002 14:16:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A88BE912C3; Wed, 21 Aug 2002 14:16:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2C4A9912C2 for <[e-mail]>; Wed, 21 Aug 2002 14:16:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EDFD85DF02; Wed, 21 Aug 2002 14:16:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web14107.mail.yahoo.com (web14107.mail.yahoo.com [216.136.172.137]) by segue.merit.edu (Postfix) with SMTP id 5E0D85DE20 for <[e-mail]>; Wed, 21 Aug 2002 14:16:03 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [47.234.0.51] by web14107.mail.yahoo.com via HTTP; Wed, 21 Aug 2002 11:16:02 PDT
Date: Wed, 21 Aug 2002 11:16:02 -0700 (PDT)
From: PamSri <[e-mail]>
Subject: Re: BGP INFORM message 
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

No. Better ways can be devised using exisiting
protocol concepts to handle restarts. 

sri

--- vrishab sikand <[e-mail]> wrote:
> 
> ditto
>  Enke Chen wrote:NO (too much work with very little
> benefit). -- Enke
> 
> > Message-Id:
> <[e-mail]>
> > To: [e-mail]
> > Subject: BGP INFORM message
> > Date: Wed, 21 Aug 2002 07:37:21 -0700
> > From: Yakov Rekhter 
> > Sender: [e-mail]
> > Precedence: bulk
> > 
> > Folks,
> > 
> > To help determine whether there is a rough
> consensus for
> > accepting draft-nalawade-bgp-inform-02.txt as an
> IDR WG
> > document, please send an e-mail with either "yes"
> or "no".
> > The deadline is August 29.
> > 
> > Yakov.
> > ------- Forwarded Message
> > 
> > Date: Thu, 15 Aug 2002 07:00:49 -0700
> > From: Yakov Rekhter 
> > To: [e-mail]
> > Subject: BGP INFORM message
> > 
> > Folks,
> > 
> > The authors of draft-nalawade-bgp-inform-02.txt
> would like
> > to make it the IDR WG document. The deadline for
> comments
> > (either positive or negative) on this request is
> August 29. 
> > 
> > Yakov.
> > - ------- Forwarded Message
> > 
> > Date: Thu, 15 Aug 2002 08:15:30 -0400
> > From: [e-mail]
> > To: IETF-Announce: ;
> > Subject: I-D
> ACTION:draft-nalawade-bgp-inform-02.txt
> > 
> > - - --NextPart
> > 
> > A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> > 
> > 
> > Title : BGPv4 INFORM message
> > Author(s) : G. Nalawade, J. Scudder, D. Ward
> > Filename : draft-nalawade-bgp-inform-02.txt
> > Pages : 11
> > Date : 14-Aug-02
> > 
> > This document defines a new message type, the BGP
> INFORM
> > message that communicates Informational data and
> operational
> > warnings without resetting the peering session.
> > 
> > A URL for this Internet-Draft is:
> >
>
http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt
> > 
> > To remove yourself from the IETF Announcement
> list, send a message to 
> > ietf-announce-request with the word unsubscribe in
> the body of the message.
> > 
> > Internet-Drafts are also available by anonymous
> FTP. Login with the username
> > "anonymous" and a password of your e-mail address.
> After logging in,
> > type "cd internet-drafts" and then
> > "get draft-nalawade-bgp-inform-02.txt".
> > 
> > A list of Internet-Drafts directories can be found
> in
> > http://www.ietf.org/shadow.html 
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > [e-mail].
> > In the body type:
> > "FILE
> /internet-drafts/draft-nalawade-bgp-inform-02.txt".
> > 
> > NOTE: The mail server at ietf.org can return the
> document in
> > MIME-encoded form by using the "mpack" utility. To
> use this
> > feature, insert the command "ENCODING mime" before
> the "FILE"
> > command. To decode the response(s), you will need
> "munpack" or
> > a MIME-compliant mail reader. Different
> MIME-compliant mail readers
> > exhibit different behavior, especially when
> dealing with
> > "multipart" MIME messages (i.e. documents which
> have been split
> > up into multiple messages), so check your local
> documentation on
> > how to manipulate these messages.
> > 
> > 
> > Below is the data which will enable a MIME
> compliant mail reader
> > implementation to automatically retrieve the ASCII
> version of the
> > Internet-Draft.
> > 
> > - - --NextPart
> > Content-Type: Multipart/Alternative;
> Boundary="OtherAccess"
> > 
> > - - --OtherAccess
> > Content-Type: Message/External-body;
> > access-type="mail-server";
> > server="[e-mail]"
> > 
> > Content-Type: text/plain
> > Content-ID: <[e-mail]>
> > 
> > ENCODING mime
> > FILE
> /internet-drafts/draft-nalawade-bgp-inform-02.txt
> > 
> > - - --OtherAccess
> > Content-Type: Message/External-body;
> > name="draft-nalawade-bgp-inform-02.txt";
> > site="ftp.ietf.org";
> > access-type="anon-ftp";
> > directory="internet-drafts"
> > 
> > Content-Type: text/plain
> > Content-ID: <[e-mail]>
> > 
> > - - --OtherAccess--
> > 
> > - - --NextPart--
> > 
> > 
> > 
> > - ------- End of Forwarded Message
> > 
> > 
> > ------- End of Forwarded Message
> > 
> 
> 
> 
> ---------------------------------
> Do You Yahoo!?
> HotJobs, a Yahoo! service - Search Thousands of New
Jobs


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA06605 for <[e-mail]>; Wed, 21 Aug 2002 13:41:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 30160912BF; Wed, 21 Aug 2002 13:40:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05C0B912C0; Wed, 21 Aug 2002 13:40:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C1546912BF for <[e-mail]>; Wed, 21 Aug 2002 13:40:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A106D5DED4; Wed, 21 Aug 2002 13:40:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 75E405DDDD for <[e-mail]>; Wed, 21 Aug 2002 13:40:29 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17hZT2-000DLA-00; Wed, 21 Aug 2002 10:40:28 -0700
Date: Wed, 21 Aug 2002 10:39:00 -0700
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Randy Bush <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: BGP INFORM message
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Randy,

  You're quite correct--as my message to the list last night
  suggests, it is premature to talk about accepting this draft
  as a WG document given that there is no work item in the WG
  charter covering this topic. Hence, at this stage, the question
  could indeed only be about whether the WG would like its
  charter to include this topic or not, and since charter updates
  have to be negotiated with the ADs and IESG, it indeed means
  working with the ADs. And as I hoped my message last night would
  hint, I'd rather see the WG finish the base spec before taking
  on any new work items.
  
-- 
Alex

Wednesday, August 21, 2002, 8:29:13 AM, Randy Bush wrote:
>> To help determine whether there is a rough consensus for
>> accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
>> document, please send an e-mail with either "yes" or "no".
>> The deadline is August 29.

> given a read of the wg's charter caused by alex's comment,
> perhaps this would be more appropriately phrased as

>    should the wg work with the area directors to change
>    the wg's charter to include this item?

> because, as far as i can tell (and i am below my quota of
> wrong for the day.  and alex and bill seem to be late
> sleepers, so i have not been able to get their opinions this
> morning), this is outside the current charter.

> alsoso it seems to me that alex's question about how the
> base and primary work, the bgp draft, is going is germane.
> and, from a broad ietf point of view, it sure seems more
> urgent.

> randy




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA06308 for <[e-mail]>; Wed, 21 Aug 2002 13:30:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DDBC5912B3; Wed, 21 Aug 2002 13:29:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD517912BF; Wed, 21 Aug 2002 13:29:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 74BAF912B3 for <[e-mail]>; Wed, 21 Aug 2002 13:29:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 611CF5DED3; Wed, 21 Aug 2002 13:29:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web12806.mail.yahoo.com (web12806.mail.yahoo.com [216.136.174.41]) by segue.merit.edu (Postfix) with SMTP id C029F5DDDD for <[e-mail]>; Wed, 21 Aug 2002 13:29:56 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [208.246.215.128] by web12806.mail.yahoo.com via HTTP; Wed, 21 Aug 2002 10:29:56 PDT
Date: Wed, 21 Aug 2002 10:29:56 -0700 (PDT)
From: vrishab sikand <[e-mail]>
Subject: Re: BGP INFORM message 
To: Enke Chen <[e-mail]>, Yakov Rekhter <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1500493569-1029950996=:44478"
Sender: [e-mail]
Precedence: bulk

--0-1500493569-1029950996=:44478
Content-Type: text/plain; charset=us-ascii


ditto
 Enke Chen wrote:NO (too much work with very little benefit). -- Enke

> Message-Id: <[e-mail]>
> To: [e-mail]
> Subject: BGP INFORM message
> Date: Wed, 21 Aug 2002 07:37:21 -0700
> From: Yakov Rekhter 
> Sender: [e-mail]
> Precedence: bulk
> 
> Folks,
> 
> To help determine whether there is a rough consensus for
> accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
> document, please send an e-mail with either "yes" or "no".
> The deadline is August 29.
> 
> Yakov.
> ------- Forwarded Message
> 
> Date: Thu, 15 Aug 2002 07:00:49 -0700
> From: Yakov Rekhter 
> To: [e-mail]
> Subject: BGP INFORM message
> 
> Folks,
> 
> The authors of draft-nalawade-bgp-inform-02.txt would like
> to make it the IDR WG document. The deadline for comments
> (either positive or negative) on this request is August 29. 
> 
> Yakov.
> - ------- Forwarded Message
> 
> Date: Thu, 15 Aug 2002 08:15:30 -0400
> From: [e-mail]
> To: IETF-Announce: ;
> Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt
> 
> - - --NextPart
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> Title : BGPv4 INFORM message
> Author(s) : G. Nalawade, J. Scudder, D. Ward
> Filename : draft-nalawade-bgp-inform-02.txt
> Pages : 11
> Date : 14-Aug-02
> 
> This document defines a new message type, the BGP INFORM
> message that communicates Informational data and operational
> warnings without resetting the peering session.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-nalawade-bgp-inform-02.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
> 
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility. To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command. To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader. Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> - - --NextPart
> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
> 
> - - --OtherAccess
> Content-Type: Message/External-body;
> access-type="mail-server";
> server="[e-mail]"
> 
> Content-Type: text/plain
> Content-ID: <[e-mail]>
> 
> ENCODING mime
> FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt
> 
> - - --OtherAccess
> Content-Type: Message/External-body;
> name="draft-nalawade-bgp-inform-02.txt";
> site="ftp.ietf.org";
> access-type="anon-ftp";
> directory="internet-drafts"
> 
> Content-Type: text/plain
> Content-ID: <[e-mail]>
> 
> - - --OtherAccess--
> 
> - - --NextPart--
> 
> 
> 
> - ------- End of Forwarded Message
> 
> 
> ------- End of Forwarded Message
> 



---------------------------------
Do You Yahoo!?
HotJobs, a Yahoo! service - Search Thousands of New Jobs
--0-1500493569-1029950996=:44478
Content-Type: text/html; charset=us-ascii

<P>ditto
<P>&nbsp;<B><I>Enke Chen <[e-mail]></I></B>wrote:
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">NO (too much work with very little benefit). -- Enke<BR><BR>&gt; Message-Id: &lt;[e-mail]&gt;<BR>&gt; To: [e-mail]<BR>&gt; Subject: BGP INFORM message<BR>&gt; Date: Wed, 21 Aug 2002 07:37:21 -0700<BR>&gt; From: Yakov Rekhter <[e-mail]><BR>&gt; Sender: [e-mail]<BR>&gt; Precedence: bulk<BR>&gt; <BR>&gt; Folks,<BR>&gt; <BR>&gt; To help determine whether there is a rough consensus for<BR>&gt; accepting draft-nalawade-bgp-inform-02.txt as an IDR WG<BR>&gt; document, please send an e-mail with either "yes" or "no".<BR>&gt; The deadline is August 29.<BR>&gt; <BR>&gt; Yakov.<BR>&gt; ------- Forwarded Message<BR>&gt; <BR>&gt; Date: Thu, 15 Aug 2002 07:00:49 -0700<BR>&gt; From: Yakov Rekhter <[e-mail]><BR>&gt; To: [e-mail]<BR>&gt; Subject: BGP INFORM message<BR>&gt; <BR>&gt; Folks,<BR>&gt; <BR>&gt; The authors of draft-nalawade-bgp-inform-02.txt would like<BR>&gt; to make it the IDR WG document. The deadline for comments<BR>&gt; (either positive or negative) on this request is August 29. <BR>&gt; <BR>&gt; Yakov.<BR>&gt; - ------- Forwarded Message<BR>&gt; <BR>&gt; Date: Thu, 15 Aug 2002 08:15:30 -0400<BR>&gt; From: [e-mail]<BR>&gt; To: IETF-Announce: ;<BR>&gt; Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt<BR>&gt; <BR>&gt; - - --NextPart<BR>&gt; <BR>&gt; A New Internet-Draft is available from the on-line Internet-Drafts directories.<BR>&gt; <BR>&gt; <BR>&gt; Title : BGPv4 INFORM message<BR>&gt; Author(s) : G. Nalawade, J. Scudder, D. Ward<BR>&gt; Filename : draft-nalawade-bgp-inform-02.txt<BR>&gt; Pages : 11<BR>&gt; Date : 14-Aug-02<BR>&gt; <BR>&gt; This document defines a new message type, the BGP INFORM<BR>&gt; message that communicates Informational data and operational<BR>&gt; warnings without resetting the peering session.<BR>&gt; <BR>&gt; A URL for this Internet-Draft is:<BR>&gt; http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt<BR>&gt; <BR>&gt; To remove yourself from the IETF Announcement list, send a message to <BR>&gt; ietf-announce-request with the word unsubscribe in the body of the message.<BR>&gt; <BR>&gt; Internet-Drafts are also available by anonymous FTP. Login with the username<BR>&gt; "anonymous" and a password of your e-mail address. After logging in,<BR>&gt; type "cd internet-drafts" and then<BR>&gt; "get draft-nalawade-bgp-inform-02.txt".<BR>&gt; <BR>&gt; A list of Internet-Drafts directories can be found in<BR>&gt; http://www.ietf.org/shadow.html <BR>&gt; or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<BR>&gt; <BR>&gt; <BR>&gt; Internet-Drafts can also be obtained by e-mail.<BR>&gt; <BR>&gt; Send a message to:<BR>&gt; [e-mail].<BR>&gt; In the body type:<BR>&gt; "FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".<BR>&gt; <BR>&gt; NOTE: The mail server at ietf.org can return the document in<BR>&gt; MIME-encoded form by using the "mpack" utility. To use this<BR>&gt; feature, insert the command "ENCODING mime" before the "FILE"<BR>&gt; command. To decode the response(s), you will need "munpack" or<BR>&gt; a MIME-compliant mail reader. Different MIME-compliant mail readers<BR>&gt; exhibit different behavior, especially when dealing with<BR>&gt; "multipart" MIME messages (i.e. documents which have been split<BR>&gt; up into multiple messages), so check your local documentation on<BR>&gt; how to manipulate these messages.<BR>&gt; <BR>&gt; <BR>&gt; Below is the data which will enable a MIME compliant mail reader<BR>&gt; implementation to automatically retrieve the ASCII version of the<BR>&gt; Internet-Draft.<BR>&gt; <BR>&gt; - - --NextPart<BR>&gt; Content-Type: Multipart/Alternative; Boundary="OtherAccess"<BR>&gt; <BR>&gt; - - --OtherAccess<BR>&gt; Content-Type: Message/External-body;<BR>&gt; access-type="mail-server";<BR>&gt; server="[e-mail]"<BR>&gt; <BR>&gt; Content-Type: text/plain<BR>&gt; Content-ID: &lt;[e-mail]&gt;<BR>&gt; <BR>&gt; ENCODING mime<BR>&gt; FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt<BR>&gt; <BR>&gt; - - --OtherAccess<BR>&gt; Content-Type: Message/External-body;<BR>&gt; name="draft-nalawade-bgp-inform-02.txt";<BR>&gt; site="ftp.ietf.org";<BR>&gt; access-type="anon-ftp";<BR>&gt; directory="internet-drafts"<BR>&gt; <BR>&gt; Content-Type: text/plain<BR>&gt; Content-ID: &lt;[e-mail]&gt;<BR>&gt; <BR>&gt; - - --OtherAccess--<BR>&gt; <BR>&gt; - - --NextPart--<BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; - ------- End of Forwarded Message<BR>&gt; <BR>&gt; <BR>&gt; ------- End of Forwarded Message<BR>&gt; <BR></BLOCKQUOTE><p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="http://rd.yahoo.com/careers/mailsig/new/*http://www.hotjobs.com">HotJobs, a Yahoo! service</a> - Search Thousands of New Jobs
--0-1500493569-1029950996=:44478--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA03489 for <[e-mail]>; Wed, 21 Aug 2002 12:05:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 39292912BC; Wed, 21 Aug 2002 12:05:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 00968912BD; Wed, 21 Aug 2002 12:05:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2158A912BC for <[e-mail]>; Wed, 21 Aug 2002 12:05:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 096ED5DEC3; Wed, 21 Aug 2002 12:05:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 888E95DEC0 for <[e-mail]>; Wed, 21 Aug 2002 12:05:30 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA12448; Wed, 21 Aug 2002 12:05:28 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA12025; Wed, 21 Aug 2002 12:05:29 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <RHFQ52YT>; Wed, 21 Aug 2002 12:05:28 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: questions on INFORM draft
Date: Wed, 21 Aug 2002 12:05:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> > If the receiving BGP peer determines that
> > the NLRI is invalid, it should have a way to say something 
> is wrong with the
> > given packet and maybe send it back as an attached data 
> portion to an INFORM
> > message.
> 
> If we have determined that some portion of the packet is bad - say
> the route origin (e.g. type=4), can we trust the rest of the packet?

NO
> 
> If we trust the NLRI is correct and well formed, we could then 
> delete those NLRI as being "bad" from our adj-ribs-in for that peer.
> 
> If we can't trust them, all we can know is we're out of sync with that
> peer.  We may have to mistrust up to a full-packet's worth of
> routes - but which ones?

I suggest, we ignore the packet with bad/malformed data in its PDU/NLRI
section
and send it back as an INFORM message to let the originating peer either
repair the packet and retransmit or drop the session. 
One possible advantage is that it gives the offending peer a second chance 
to repair the problem before a session disconnect is done by either side of
the connection.

In a previous mail someone said if a peer sends a bad/malformed packet it is
suffering from a software error that is not recoverable. I contend that some
software errors are recoverable, especially if in the future we have
multiple
instances of BGP engines within a given router, with backup capabilities. 

Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA03002 for <[e-mail]>; Wed, 21 Aug 2002 11:53:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F0951912BA; Wed, 21 Aug 2002 11:51:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AFE1E912BB; Wed, 21 Aug 2002 11:51:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F5AE912BA for <[e-mail]>; Wed, 21 Aug 2002 11:51:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5E9FE5DE9F; Wed, 21 Aug 2002 11:51:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 054DD5DE54 for <[e-mail]>; Wed, 21 Aug 2002 11:51:01 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7LFoxM48579; Wed, 21 Aug 2002 11:50:59 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7LFot148564; Wed, 21 Aug 2002 11:50:55 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7LFotA29214; Wed, 21 Aug 2002 11:50:55 -0400 (EDT)
Date: Wed, 21 Aug 2002 11:50:54 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Aug 20, 2002 at 10:44:01AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Aug 20, 2002 at 10:44:01AM -0400, Abarbanel, Benjamin wrote:
> TCP will check the header and data fields of a packet for correctness as
> its associated checksum when calculated will identify any data corruption. 

Its the BGP PDU I'm concerned with.
The most common BGP errors have to do with forming a bad packet.

> If the receiving BGP peer determines that
> the NLRI is invalid, it should have a way to say something is wrong with the
> given packet and maybe send it back as an attached data portion to an INFORM
> message.

If we have determined that some portion of the packet is bad - say
the route origin (e.g. type=4), can we trust the rest of the packet?

If we trust the NLRI is correct and well formed, we could then 
delete those NLRI as being "bad" from our adj-ribs-in for that peer.

If we can't trust them, all we can know is we're out of sync with that
peer.  We may have to mistrust up to a full-packet's worth of
routes - but which ones?

> Ben

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA02819 for <[e-mail]>; Wed, 21 Aug 2002 11:46:58 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 73AF8912B8; Wed, 21 Aug 2002 11:45:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4918F912B9; Wed, 21 Aug 2002 11:45:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C6B0912B8 for <[e-mail]>; Wed, 21 Aug 2002 11:45:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EA2DC5DEDF; Wed, 21 Aug 2002 11:45:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 70BE25DEFB for <[e-mail]>; Wed, 21 Aug 2002 11:45:16 -0400 (EDT)
Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 8CF5F1DCC6C; Wed, 21 Aug 2002 08:45:15 -0700 (PDT)
Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id 1220815D3C1; Wed, 21 Aug 2002 08:45:14 -0700 (PDT)
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: BGP INFORM message 
In-Reply-To: Message from Yakov Rekhter <[e-mail]>  of "Wed, 21 Aug 2002 07:37:21 PDT." <[e-mail]> 
Date: Wed, 21 Aug 2002 08:45:14 -0700
From: Enke Chen <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

NO (too much work with very little benefit). -- Enke

> Message-Id: <[e-mail]>
> To: [e-mail]
> Subject: BGP INFORM message
> Date: Wed, 21 Aug 2002 07:37:21 -0700
> From: Yakov Rekhter <[e-mail]>
> Sender: [e-mail]
> Precedence: bulk
> 
> Folks,
> 
> To help determine whether there is a rough consensus for
> accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
> document, please send an e-mail with either "yes" or "no".
> The deadline is August 29.
> 
> Yakov.
> ------- Forwarded Message
> 
> Date:    Thu, 15 Aug 2002 07:00:49 -0700
> From:    Yakov Rekhter <[e-mail]>
> To:      [e-mail]
> Subject: BGP INFORM message
> 
> Folks,
> 
> The authors of draft-nalawade-bgp-inform-02.txt would like
> to make it the IDR WG document. The deadline for comments
> (either positive or negative) on this request is August 29. 
> 
> Yakov.
> - ------- Forwarded Message
> 
> Date:    Thu, 15 Aug 2002 08:15:30 -0400
> From:    [e-mail]
> To:      IETF-Announce: ;
> Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt
> 
> - - --NextPart
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: BGPv4 INFORM message
> 	Author(s)	: G. Nalawade, J. Scudder, D. Ward
> 	Filename	: draft-nalawade-bgp-inform-02.txt
> 	Pages		: 11
> 	Date		: 14-Aug-02
> 	
> This document defines a new message type, the BGP INFORM
> message that communicates Informational data and operational
> warnings without resetting the peering session.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-nalawade-bgp-inform-02.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[e-mail].
> In the body type:
> 	"FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> - - --NextPart
> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
> 
> - - --OtherAccess
> Content-Type: Message/External-body;
> 	access-type="mail-server";
> 	server="[e-mail]"
> 
> Content-Type: text/plain
> Content-ID:	<[e-mail]>
> 
> ENCODING mime
> FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt
> 
> - - --OtherAccess
> Content-Type: Message/External-body;
> 	name="draft-nalawade-bgp-inform-02.txt";
> 	site="ftp.ietf.org";
> 	access-type="anon-ftp";
> 	directory="internet-drafts"
> 
> Content-Type: text/plain
> Content-ID:	<[e-mail]>
> 
> - - --OtherAccess--
> 
> - - --NextPart--
> 
> 
> 
> - ------- End of Forwarded Message
> 
> 
> ------- End of Forwarded Message
> 



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA02623 for <[e-mail]>; Wed, 21 Aug 2002 11:41:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5AA18912B7; Wed, 21 Aug 2002 11:41:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2626D912B8; Wed, 21 Aug 2002 11:41:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 410F9912B7 for <[e-mail]>; Wed, 21 Aug 2002 11:41:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2C86E5DE9F; Wed, 21 Aug 2002 11:41:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id A8E395DE54 for <[e-mail]>; Wed, 21 Aug 2002 11:41:15 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA10530; Wed, 21 Aug 2002 11:41:12 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA06488; Wed, 21 Aug 2002 11:41:14 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <RHFQ5HN0>; Wed, 21 Aug 2002 11:41:13 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Susan Hares'" <[e-mail]>
Cc: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, Kunihiro Ishiguro <[e-mail]>, BGP mailing list <[e-mail]>
Subject: RE: TCP state machine doubts
Date: Wed, 21 Aug 2002 11:41:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Sue:
  Just a follow up suggestion. Can we improve the wording within the FSM
document to mention any sensitivy to RIB synchronization points if such 
features as Route Refresh or Gracefull Restart, etc. are introduced in the
spec?

Thanks,
Ben



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA02409 for <[e-mail]>; Wed, 21 Aug 2002 11:34:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 95571912B5; Wed, 21 Aug 2002 11:32:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60492912B6; Wed, 21 Aug 2002 11:32:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 97874912B5 for <[e-mail]>; Wed, 21 Aug 2002 11:32:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 740045DE9F; Wed, 21 Aug 2002 11:32:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 056E85DE54 for <[e-mail]>; Wed, 21 Aug 2002 11:32:11 -0400 (EDT)
Received: from mira-sjcm-3.cisco.com (IDENT:[e-mail] [171.69.24.15]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g7LFW80Y028479; Wed, 21 Aug 2002 08:32:08 -0700 (PDT)
Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AFY06971; Wed, 21 Aug 2002 08:31:40 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 21 Aug 2002 17:32:03 +0200
From: Robert Raszuk <[e-mail]>
Reply-To: [e-mail]
Organization: Signature: http://www.employees.org/~raszuk/sig/
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: BGP INFORM message
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

yes

R.

> Yakov Rekhter wrote:
> 
> Folks,
> 
> To help determine whether there is a rough consensus for
> accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
> document, please send an e-mail with either "yes" or "no".
> The deadline is August 29.
> 
> Yakov.
> ------- Forwarded Message
> 
> Date:    Thu, 15 Aug 2002 07:00:49 -0700
> From:    Yakov Rekhter <[e-mail]>
> To:      [e-mail]
> Subject: BGP INFORM message
> 
> Folks,
> 
> The authors of draft-nalawade-bgp-inform-02.txt would like
> to make it the IDR WG document. The deadline for comments
> (either positive or negative) on this request is August 29.
> 
> Yakov.
> - ------- Forwarded Message
> 
> Date:    Thu, 15 Aug 2002 08:15:30 -0400
> From:    [e-mail]
> To:      IETF-Announce: ;
> Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt
> 
> - - --NextPart
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
>         Title           : BGPv4 INFORM message
>         Author(s)       : G. Nalawade, J. Scudder, D. Ward
>         Filename        : draft-nalawade-bgp-inform-02.txt
>         Pages           : 11
>         Date            : 14-Aug-02
> 
> This document defines a new message type, the BGP INFORM
> message that communicates Informational data and operational
> warnings without resetting the peering session.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-nalawade-bgp-inform-02.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [e-mail].
> In the body type:
>         "FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> - - --NextPart
> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
> 
> - - --OtherAccess
> Content-Type: Message/External-body;
>         access-type="mail-server";
>         server="[e-mail]"
> 
> Content-Type: text/plain
> Content-ID:     <[e-mail]>
> 
> ENCODING mime
> FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt
> 
> - - --OtherAccess
> Content-Type: Message/External-body;
>         name="draft-nalawade-bgp-inform-02.txt";
>         site="ftp.ietf.org";
>         access-type="anon-ftp";
>         directory="internet-drafts"
> 
> Content-Type: text/plain
> Content-ID:     <[e-mail]>
> 
> - - --OtherAccess--
> 
> - - --NextPart--
> 
> - ------- End of Forwarded Message
> 
> ------- End of Forwarded Message


Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA02277 for <[e-mail]>; Wed, 21 Aug 2002 11:29:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 97691912B2; Wed, 21 Aug 2002 11:29:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 68B4D912B4; Wed, 21 Aug 2002 11:29:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8B7EF912B2 for <[e-mail]>; Wed, 21 Aug 2002 11:29:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 71B235DEC0; Wed, 21 Aug 2002 11:29:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 4AE215DDDD for <[e-mail]>; Wed, 21 Aug 2002 11:29:14 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17hXQ1-000LwF-00; Wed, 21 Aug 2002 08:29:13 -0700
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP INFORM message
References: <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 21 Aug 2002 08:29:13 -0700
Sender: [e-mail]
Precedence: bulk

> To help determine whether there is a rough consensus for
> accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
> document, please send an e-mail with either "yes" or "no".
> The deadline is August 29.

given a read of the wg's charter caused by alex's comment,
perhaps this would be more appropriately phrased as

   should the wg work with the area directors to change
   the wg's charter to include this item?

because, as far as i can tell (and i am below my quota of
wrong for the day.  and alex and bill seem to be late
sleepers, so i have not been able to get their opinions this
morning), this is outside the current charter.

alsoso it seems to me that alex's question about how the
base and primary work, the bgp draft, is going is germane.
and, from a broad ietf point of view, it sure seems more
urgent.

randy



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA02268 for <[e-mail]>; Wed, 21 Aug 2002 11:29:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 635FA912B4; Wed, 21 Aug 2002 11:29:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38FB5912B5; Wed, 21 Aug 2002 11:29:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15112912B4 for <[e-mail]>; Wed, 21 Aug 2002 11:29:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 030DD5DDDD; Wed, 21 Aug 2002 11:29:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from smtp.adc.com (smtp.adc.com [155.226.10.207]) by segue.merit.edu (Postfix) with ESMTP id 447195DEC0 for <[e-mail]>; Wed, 21 Aug 2002 11:29:37 -0400 (EDT)
Received: from smtp.adc.com (localhost [127.0.0.1]) by smtp.adc.com (8.11.1/8.11.1) with ESMTP id g7LFTaX14703 for <[e-mail]>; Wed, 21 Aug 2002 10:29:36 -0500 (CDT)
Received: from mplsgtwy02.adc.com (MPLSGTWY02.adc.com [155.226.11.1]) by smtp.adc.com (8.11.1/8.11.1) with ESMTP id g7LFTZd14699; Wed, 21 Aug 2002 10:29:35 -0500 (CDT)
Received: from B10.basystems.com.adc.com (146.71.193.223 [146.71.193.223]) by mplsgtwy02.adc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QWTW2MMS; Wed, 21 Aug 2002 10:29:35 -0500
From: Igor Lasic <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 21 Aug 2002 11:27:51 -0400
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: BGP INFORM message
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 7.03 under Emacs 21.2.1
Sender: [e-mail]
Precedence: bulk

No.

Abarbanel, Benjamin writes:
 > Yes
 > 
 > Ben
 > 
 > > -----Original Message-----
 > > From: Yakov Rekhter [mailto:[e-mail]]
 > > Sent: Wednesday, August 21, 2002 10:37 AM
 > > To: [e-mail]
 > > Subject: BGP INFORM message
 > > 
 > > 
 > > Folks,
 > > 
 > > To help determine whether there is a rough consensus for
 > > accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
 > > document, please send an e-mail with either "yes" or "no".
 > > The deadline is August 29.
 > > 
 > > Yakov.
 > > ------- Forwarded Message
 > > 
 > > Date:    Thu, 15 Aug 2002 07:00:49 -0700
 > > From:    Yakov Rekhter <[e-mail]>
 > > To:      [e-mail]
 > > Subject: BGP INFORM message
 > > 
 > > Folks,
 > > 
 > > The authors of draft-nalawade-bgp-inform-02.txt would like
 > > to make it the IDR WG document. The deadline for comments
 > > (either positive or negative) on this request is August 29. 
 > > 
 > > Yakov.
 > > - ------- Forwarded Message
 > > 
 > > Date:    Thu, 15 Aug 2002 08:15:30 -0400
 > > From:    [e-mail]
 > > To:      IETF-Announce: ;
 > > Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt
 > > 
 > > - - --NextPart
 > > 
 > > A New Internet-Draft is available from the on-line 
 > > Internet-Drafts directories.
 > > 
 > > 
 > > 	Title		: BGPv4 INFORM message
 > > 	Author(s)	: G. Nalawade, J. Scudder, D. Ward
 > > 	Filename	: draft-nalawade-bgp-inform-02.txt
 > > 	Pages		: 11
 > > 	Date		: 14-Aug-02
 > > 	
 > > This document defines a new message type, the BGP INFORM
 > > message that communicates Informational data and operational
 > > warnings without resetting the peering session.
 > > 
 > > A URL for this Internet-Draft is:
 > > http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt
 > > 
 > > To remove yourself from the IETF Announcement list, send a message to 
 > > ietf-announce-request with the word unsubscribe in the body 
 > > of the message.
 > > 
 > > Internet-Drafts are also available by anonymous FTP. Login 
 > > with the username
 > > "anonymous" and a password of your e-mail address. After logging in,
 > > type "cd internet-drafts" and then
 > > 	"get draft-nalawade-bgp-inform-02.txt".
 > > 
 > > A list of Internet-Drafts directories can be found in
 > > http://www.ietf.org/shadow.html 
 > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 > > 
 > > 
 > > Internet-Drafts can also be obtained by e-mail.
 > > 
 > > Send a message to:
 > > 	[e-mail].
 > > In the body type:
 > > 	"FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
 > > 	
 > > NOTE:	The mail server at ietf.org can return the document in
 > > 	MIME-encoded form by using the "mpack" utility.  To use this
 > > 	feature, insert the command "ENCODING mime" before the "FILE"
 > > 	command.  To decode the response(s), you will need "munpack" or
 > > 	a MIME-compliant mail reader.  Different MIME-compliant 
 > > mail readers
 > > 	exhibit different behavior, especially when dealing with
 > > 	"multipart" MIME messages (i.e. documents which have been split
 > > 	up into multiple messages), so check your local documentation on
 > > 	how to manipulate these messages.
 > > 		
 > > 		
 > > Below is the data which will enable a MIME compliant mail reader
 > > implementation to automatically retrieve the ASCII version of the
 > > Internet-Draft.
 > > 
 > > - - --NextPart
 > > Content-Type: Multipart/Alternative; Boundary="OtherAccess"
 > > 
 > > - - --OtherAccess
 > > Content-Type: Message/External-body;
 > > 	access-type="mail-server";
 > > 	server="[e-mail]"
 > > 
 > > Content-Type: text/plain
 > > Content-ID:	<[e-mail]>
 > > 
 > > ENCODING mime
 > > FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt
 > > 
 > > - - --OtherAccess
 > > Content-Type: Message/External-body;
 > > 	name="draft-nalawade-bgp-inform-02.txt";
 > > 	site="ftp.ietf.org";
 > > 	access-type="anon-ftp";
 > > 	directory="internet-drafts"
 > > 
 > > Content-Type: text/plain
 > > Content-ID:	<[e-mail]>
 > > 
 > > - - --OtherAccess--
 > > 
 > > - - --NextPart--
 > > 
 > > 
 > > 
 > > - ------- End of Forwarded Message
 > > 
 > > 
 > > ------- End of Forwarded Message
 > > 



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA02224 for <[e-mail]>; Wed, 21 Aug 2002 11:28:21 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4DD32912B1; Wed, 21 Aug 2002 11:28:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 170E1912B2; Wed, 21 Aug 2002 11:28:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C25EB912B1 for <[e-mail]>; Wed, 21 Aug 2002 11:28:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B14CA5DEBE; Wed, 21 Aug 2002 11:28:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 53F015DE93 for <[e-mail]>; Wed, 21 Aug 2002 11:28:00 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7LFRxj47669; Wed, 21 Aug 2002 11:27:59 -0400 (EDT) (envelope-from [e-mail])
Received: from SKH.nexthop.com ([64.211.218.13]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7LFRu147660; Wed, 21 Aug 2002 11:27:56 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 21 Aug 2002 15:27:57 -0400
To: "Abarbanel, Benjamin" <[e-mail]>
From: Susan Hares <[e-mail]>
Subject: RE: TCP state machine doubts
Cc: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, "'Susan Hares'" <[e-mail]>, Kunihiro Ishiguro <[e-mail]>, BGP mailing list <[e-mail]>
In-Reply-To: <[e-mail] re.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Ben:

I do not think the RIB synchronization points interact with
the connection machine (bringing the machine into Established state,
and dropping it out of connection state.  The only RIB interaction is
the keeping the routes or throwing all routes away.

Most of the route changes and RIB synchronization within the update
state has to do with later drafts (route refresh, graceful restart,etc.)

Can you make a specific suggestion to improving either the
FSM words or the FSM document regarding the RIB synchronization
points?


Sue
At 05:50 PM 7/30/2002 -0400, Abarbanel, Benjamin wrote:
>Jeff:
>   The FSM state machine actions taken are internal sequenced procedures.
>These
>actions could get messy and possibly execute out of sequence when there is a
>multi-threads implemenatation. Although the FSM is preoccupied mostly with
>the setting up and tearing down the peering sessions, in the processing of
>these states certain multi-threaded sensitive processing rules should be
>defined.
>
>For Example:
>============
>Define locks around the various RIB synchronization points and mentioned
>when to take them and when to release them if a state transition has occured
>via the various action statements. This will gaurantee that the RIB data is
>protected from parallel thread execution. It really does not matter which
>thread takes the lock or which thread releases it.  If RIB resource is
>locked, what happens to the state machine when state changing events are
>seen. (E.G. Session disconnected by TCP or Peer. What happens when an
>operator configuration command shuts down a peer session or the whole BGP
>engine?
>
>I know this is getting very detailed, but the FSM is a gray area between the
>internal and external world.
>
>
>Ben
>
>
>
> > -----Original Message-----
> > From: Jeffrey Haas [mailto:[e-mail]]
> > Sent: Tuesday, July 30, 2002 4:52 PM
> > To: Abarbanel, Benjamin
> > Cc: 'Susan Hares'; Kunihiro Ishiguro; BGP mailing list
> > Subject: Re: TCP state machine doubts
> >
> >
> > On Thu, Jul 25, 2002 at 11:19:11AM -0400, Abarbanel, Benjamin wrote:
> > > There are various phases that BGP goes through that one
> > > might want to use multiple threads. The inter-locking or
> > inter-working
> > > between the threads could affect the state transitions. For
> > example, Say you
> > > are in Establish state and something happens to the session
> > and it is
> > > disconnected. In a single threaded environment it is easy,
> > first come, first
> > > served. In a multi-threaded case with thread priorities and
> > interruptions,
> > > it might get tricky at times. Some assumptions or
> > expectations by the state
> > > machine on actions it should take with regards to semaphore
> > locks (RIB
> > > Table, etc.), thread prioritization, processing,
> > pre-emption and so forth
> > > might be helpfull. Maybe these actions should only be
> > suggestions not
> > > required ways for implementations.
> >
> > There are certain situations where the FSM suggests that things be
> > done in certain events where an implementation *could* do things
> > in a slightly different order.
> >
> > For example, after the TCP connection has completed, you are supposed
> > to send your messages *before* reading the socket.  In a
> > multi-threaded
> > environment, you may obviously not do this.  Indeed, for passive or
> > unconfigured peers, you may not even send your message immediately.
> >
> > The FSM would suggest where your synchronization points need to go.
> > Happily, most of this work seems to need to be done during
> > peering setup.
> >
> > For the most part, like the 3-rib abstraction, you should be able
> > to do whatever you want inside your black box so long as it looks
> > right on the wire.  The FSM gives guidance on what probably is
> > happening in the box to get things out as you expect them to.
> >
> > More specific examples might be helpful.
> >
> > > Ben
> >
> > --
> > Jeff Haas
> > NextHop Technologies
> >




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA01929 for <[e-mail]>; Wed, 21 Aug 2002 11:19:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1D3CA912AF; Wed, 21 Aug 2002 11:19:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA54A912B0; Wed, 21 Aug 2002 11:19:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 404BD912AF for <[e-mail]>; Wed, 21 Aug 2002 11:18:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1A78F5DE93; Wed, 21 Aug 2002 11:18:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from hotmail.com (f133.law12.hotmail.com [64.4.19.133]) by segue.merit.edu (Postfix) with ESMTP id CF0C25DDDD for <[e-mail]>; Wed, 21 Aug 2002 11:18:58 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Aug 2002 08:18:58 -0700
Received: from 63.197.79.145 by lw12fd.law12.hotmail.msn.com with HTTP; Wed, 21 Aug 2002 15:18:57 GMT
X-Originating-IP: [63.197.79.145]
From: "George Sheng" <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: BGP INFORM message
Date: Wed, 21 Aug 2002 15:18:57 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 21 Aug 2002 15:18:58.0319 (UTC) FILETIME=[123A49F0:01C24926]
Sender: [e-mail]
Precedence: bulk

NO.

>From: Yakov Rekhter <[e-mail]>
>To: [e-mail]
>Subject: BGP INFORM message
>Date: Wed, 21 Aug 2002 07:37:21 -0700
>
>Folks,
>
>To help determine whether there is a rough consensus for
>accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
>document, please send an e-mail with either "yes" or "no".
>The deadline is August 29.
>
>Yakov.

george


_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA01851 for <[e-mail]>; Wed, 21 Aug 2002 11:17:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 23CAC912AE; Wed, 21 Aug 2002 11:16:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B52ED912AF; Wed, 21 Aug 2002 11:16:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E1281912AE for <[e-mail]>; Wed, 21 Aug 2002 11:16:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C8A225DEBE; Wed, 21 Aug 2002 11:16:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 3A39C5DE93 for <[e-mail]>; Wed, 21 Aug 2002 11:16:01 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7LFFxa47198; Wed, 21 Aug 2002 11:15:59 -0400 (EDT) (envelope-from [e-mail])
Received: from SKH.nexthop.com ([64.211.218.13]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7LFFs147191; Wed, 21 Aug 2002 11:15:55 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 21 Aug 2002 15:15:56 -0400
To: "Tom Petch" <[e-mail]>
From: Susan Hares <[e-mail]>
Subject: Re: BGP FSM transport primitives
Cc: "idr" <[e-mail]>
In-Reply-To: <009b01c247b4$c7f36e20$0301a8c0@tom3>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Tom:

Thank you for the input on the FSM.

Sue

At 05:55 PM 8/19/2002 +0100, Tom Petch wrote:
>ietf-hares-bgp-statemt-01.txt section 2.3.2 states that BGP can run
>over any Transport protocol and defines transport primitives for
>events 13 to 17.  But when it comes to actions in 3.0, the references
>are explicitly to TCP eg Drop TCP connection.
>
>I suggest that section 3 should also use protocol independent
>primitives with a separate paragraph defining their mapping onto TCP
>(this would also make section 3 more concise, no bad idea).
>
>Tom Petch
>[e-mail]




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA01836 for <[e-mail]>; Wed, 21 Aug 2002 11:16:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 59EC6912AC; Wed, 21 Aug 2002 11:15:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2368D912AE; Wed, 21 Aug 2002 11:15:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A9D00912AC for <[e-mail]>; Wed, 21 Aug 2002 11:15:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C27FF5DF03; Wed, 21 Aug 2002 11:15:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 40BA15DF02 for <[e-mail]>; Wed, 21 Aug 2002 11:15:22 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBCD0V99>; Wed, 21 Aug 2002 11:15:21 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: BGP INFORM message
Date: Wed, 21 Aug 2002 11:15:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

yes

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, August 21, 2002 10:37 AM
To: [e-mail]
Subject: BGP INFORM message

Folks,

To help determine whether there is a rough consensus for
accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
document, please send an e-mail with either "yes" or "no".
The deadline is August 29.

Yakov.
------- Forwarded Message

Date:    Thu, 15 Aug 2002 07:00:49 -0700
From:    Yakov Rekhter <[e-mail]>
To:      [e-mail]
Subject: BGP INFORM message

Folks,

The authors of draft-nalawade-bgp-inform-02.txt would like
to make it the IDR WG document. The deadline for comments
(either positive or negative) on this request is August 29. 

Yakov.
- ------- Forwarded Message

Date:    Thu, 15 Aug 2002 08:15:30 -0400
From:    [e-mail]
To:      IETF-Announce: ;
Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt

- - --NextPart

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


	Title		: BGPv4 INFORM message
	Author(s)	: G. Nalawade, J. Scudder, D. Ward
	Filename	: draft-nalawade-bgp-inform-02.txt
	Pages		: 11
	Date		: 14-Aug-02
	
This document defines a new message type, the BGP INFORM
message that communicates Informational data and operational
warnings without resetting the peering session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-nalawade-bgp-inform-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- - --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- - --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt

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

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

- - --OtherAccess--

- - --NextPart--



- ------- End of Forwarded Message


------- End of Forwarded Message


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA01403 for <[e-mail]>; Wed, 21 Aug 2002 11:04:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9DF87912A9; Wed, 21 Aug 2002 11:04:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB354912AC; Wed, 21 Aug 2002 11:03:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 327ED912A9 for <[e-mail]>; Wed, 21 Aug 2002 11:02:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 11A325DEB2; Wed, 21 Aug 2002 11:02:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 91CA05DDDD for <[e-mail]>; Wed, 21 Aug 2002 11:02:10 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA07679; Wed, 21 Aug 2002 11:02:07 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27704; Wed, 21 Aug 2002 11:02:08 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <RHFQ5FFY>; Wed, 21 Aug 2002 11:02:08 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: BGP INFORM message
Date: Wed, 21 Aug 2002 11:02:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yes

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, August 21, 2002 10:37 AM
> To: [e-mail]
> Subject: BGP INFORM message
> 
> 
> Folks,
> 
> To help determine whether there is a rough consensus for
> accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
> document, please send an e-mail with either "yes" or "no".
> The deadline is August 29.
> 
> Yakov.
> ------- Forwarded Message
> 
> Date:    Thu, 15 Aug 2002 07:00:49 -0700
> From:    Yakov Rekhter <[e-mail]>
> To:      [e-mail]
> Subject: BGP INFORM message
> 
> Folks,
> 
> The authors of draft-nalawade-bgp-inform-02.txt would like
> to make it the IDR WG document. The deadline for comments
> (either positive or negative) on this request is August 29. 
> 
> Yakov.
> - ------- Forwarded Message
> 
> Date:    Thu, 15 Aug 2002 08:15:30 -0400
> From:    [e-mail]
> To:      IETF-Announce: ;
> Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt
> 
> - - --NextPart
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: BGPv4 INFORM message
> 	Author(s)	: G. Nalawade, J. Scudder, D. Ward
> 	Filename	: draft-nalawade-bgp-inform-02.txt
> 	Pages		: 11
> 	Date		: 14-Aug-02
> 	
> This document defines a new message type, the BGP INFORM
> message that communicates Informational data and operational
> warnings without resetting the peering session.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-nalawade-bgp-inform-02.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[e-mail].
> In the body type:
> 	"FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> - - --NextPart
> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
> 
> - - --OtherAccess
> Content-Type: Message/External-body;
> 	access-type="mail-server";
> 	server="[e-mail]"
> 
> Content-Type: text/plain
> Content-ID:	<[e-mail]>
> 
> ENCODING mime
> FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt
> 
> - - --OtherAccess
> Content-Type: Message/External-body;
> 	name="draft-nalawade-bgp-inform-02.txt";
> 	site="ftp.ietf.org";
> 	access-type="anon-ftp";
> 	directory="internet-drafts"
> 
> Content-Type: text/plain
> Content-ID:	<[e-mail]>
> 
> - - --OtherAccess--
> 
> - - --NextPart--
> 
> 
> 
> - ------- End of Forwarded Message
> 
> 
> ------- End of Forwarded Message
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA00519 for <[e-mail]>; Wed, 21 Aug 2002 10:39:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EEA6F9121F; Wed, 21 Aug 2002 10:38:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2733912A8; Wed, 21 Aug 2002 10:38:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9544E9121F for <[e-mail]>; Wed, 21 Aug 2002 10:37:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 784535DE9F; Wed, 21 Aug 2002 10:37:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id BF3855DDDD for <[e-mail]>; Wed, 21 Aug 2002 10:37:21 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7LEbLm55244 for <[e-mail]>; Wed, 21 Aug 2002 07:37:21 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: BGP INFORM message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 21 Aug 2002 07:37:21 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

To help determine whether there is a rough consensus for
accepting draft-nalawade-bgp-inform-02.txt as an IDR WG
document, please send an e-mail with either "yes" or "no".
The deadline is August 29.

Yakov.
------- Forwarded Message

Date:    Thu, 15 Aug 2002 07:00:49 -0700
From:    Yakov Rekhter <[e-mail]>
To:      [e-mail]
Subject: BGP INFORM message

Folks,

The authors of draft-nalawade-bgp-inform-02.txt would like
to make it the IDR WG document. The deadline for comments
(either positive or negative) on this request is August 29. 

Yakov.
- ------- Forwarded Message

Date:    Thu, 15 Aug 2002 08:15:30 -0400
From:    [e-mail]
To:      IETF-Announce: ;
Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt

- - --NextPart

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


	Title		: BGPv4 INFORM message
	Author(s)	: G. Nalawade, J. Scudder, D. Ward
	Filename	: draft-nalawade-bgp-inform-02.txt
	Pages		: 11
	Date		: 14-Aug-02
	
This document defines a new message type, the BGP INFORM
message that communicates Informational data and operational
warnings without resetting the peering session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-nalawade-bgp-inform-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- - --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- - --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt

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

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

- - --OtherAccess--

- - --NextPart--



- ------- End of Forwarded Message


------- End of Forwarded Message



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA03642 for <[e-mail]>; Tue, 20 Aug 2002 21:37:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1B7B69124C; Tue, 20 Aug 2002 21:36:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF56491282; Tue, 20 Aug 2002 21:36:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B0C799124C for <[e-mail]>; Tue, 20 Aug 2002 21:36:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9A3915DE53; Tue, 20 Aug 2002 21:36:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 72FE35DDD2 for <[e-mail]>; Tue, 20 Aug 2002 21:36:33 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17hKQC-0009HJ-00 for [e-mail]; Tue, 20 Aug 2002 18:36:33 -0700
Date: Tue, 20 Aug 2002 18:35:01 -0700
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: Re: questions on INFORM draft
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Folks-

<ad>

 A procedural bit: accepting this draft as a WG doc requires
 addition of the corresponding work item to the WG charter.
 A charter update presumes evaluation of the WG progress, which
 will inevitably trigger the question of how the WG is doing on
 the base BGP spec.

</ad>

Alex




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA20253 for <[e-mail]>; Tue, 20 Aug 2002 14:50:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6EDAA9123F; Tue, 20 Aug 2002 14:50:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A7CB91242; Tue, 20 Aug 2002 14:50:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EBC709123F for <[e-mail]>; Tue, 20 Aug 2002 14:50:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C89CE5DDB7; Tue, 20 Aug 2002 14:50:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from backin5.merit.edu (backin5.merit.edu [198.108.60.28]) by segue.merit.edu (Postfix) with ESMTP id 78C6A5DDB2 for <[e-mail]>; Tue, 20 Aug 2002 14:50:10 -0400 (EDT)
Date: Tue, 20 Aug 2002 14:50:10 -0400 (EDT)
From: Susan Harris <[e-mail]>
To: [e-mail]
Subject: Research/ops forum at October NANOG
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

                     * * * * * * * * * * * * * * * * *
   
			   CALL FOR PRESENTATIONS    
                                  NANOG 26              

                              GENERAL SESSION        
                                 TUTORIALS           
                     SPECIAL RESEARCH/OPERATIONS FORUM             

                            October 27-29, 2002

                     * * * * * * * * * * * * * * * * *


The North American Network Operators' Group (NANOG) will hold its 26th
meeting October 27-29, 2002, in Eugene, Oregon. The meeting will be hosted
by the University of Oregon and Sprint.  Registration opens September 4.
 
NANOG 26 is a special occasion - the first joint meeting with ARIN, the
American Registry for Internet Numbers. ARIN manages IP numbers for North
and South America, the Caribbean, and sub-Saharan Africa. NANOG will meet
as usual from Sunday to Tuesday, and ARIN from Wednesday to Friday.

NANOG conferences provide a forum for the coordination and dissemination
of technical information related to large-scale (i.e.,
national/international) Internet backbone networking technologies and
operational practices.  Meetings are held three times each year, and
include two days of short presentations, plus afternoon/evening tutorial
sessions and special forums. The meetings are informal, with an emphasis
on relevance to current backbone engineering practices. NANOG conferences
draw over 500 participants, mainly consisting of engineering staff from
national service providers, and members of the research and education
community.  

The meeting will be held at the Hilton Eugene and Conference Center. For
more information about NANOG meetings, schedules, and logistics, see:

     http://www.nanog.org
------------------------------------------------------------------------------

CALL FOR PRESENTATIONS

NANOG invites presentations on backbone engineering, coordination, and
research topics. Presentations should highlight issues relating to
technology already deployed or soon to be deployed in core Internet
backbones and exchange points.

Previous meetings have included presentations on:

    - Backbone traffic engineering 
    - Inter-provider security and routing protocol authentication 
    - Routing scalability in backbone infrastructures 
    - Security issues for the Internet core 
    - Routing policy specification and backbone router configuration 
    - Building large-scale measurement infrastructure 
    - Cooperative inter-provider caching 
    - Alternatives to hot-potato routing 
    - Recommendations on queue management and congestion avoidance 
    - Experience with differentiated services 
    - Inter-domain multicast deployment 
    - Backbone network failure analysis 

Tutorials have covered topics such as:

    - IP traffic management
    - BGP multihoming guide
    - ISP security: real world techniques 
    - IP multicast technologies

The special research/operations forum offers researchers a short time slot
to present ongoing work for evaluation and feedback from the operations
community. Topics include routing, network performance, statistical
measurement and analysis, and protocol development and implementation.
Researchers from academia, government, and industry are invited to
participate.
  
------------------------------------------------------------------------------
HOW TO PRESENT

Submit a detailed abstract or outline describing the presentation in email
to [e-mail].  The deadline for proposals is September 16,
2002.  While the majority of speaking slots will be filled by September
16, a limited number of slots will be available after that date for topics
that are exceptionally timely and important. Submissions will be reviewed
by the NANOG Program Committee, and presenters will be notified of
acceptance by September 30, 2002.

NANOG also welcomes suggestions/recommendations for tutorials, panels and
other presentation topics.
---------------------------------------------------------------------------






Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA12255 for <[e-mail]>; Tue, 20 Aug 2002 10:44:30 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A6AF591220; Tue, 20 Aug 2002 10:44:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E5EE9123A; Tue, 20 Aug 2002 10:44:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A90C91220 for <[e-mail]>; Tue, 20 Aug 2002 10:44:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 62CFE5DDA3; Tue, 20 Aug 2002 10:44:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id DFE115DD8C for <[e-mail]>; Tue, 20 Aug 2002 10:44:03 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03373; Tue, 20 Aug 2002 10:44:01 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19333; Tue, 20 Aug 2002 10:44:02 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <RHFQYZPD>; Tue, 20 Aug 2002 10:44:02 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, Avi Freedman <[e-mail]>
Cc: George Sheng <[e-mail]>, [e-mail]
Subject: RE: questions on INFORM draft
Date: Tue, 20 Aug 2002 10:44:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

 
> 
> On Sat, Aug 17, 2002 at 02:58:52PM -0400, Avi Freedman wrote:
> > That said, I will go back and recheck the behavior of various
> > routers for reserved ASs appearing outside confederation segments.
> > Perhaps that's not an issue any more.
> 
> That would be appreciated.
> It may even be worthy of an ID - or at least something for the
> museum of broken packets.
> 
> > I think we might be agreeing - I'm not suggesting that fixing broken
> > packets is the desired thing, but rather that not requiring that
> > one broken packet being propagated take down a peering session is
> > the desired thing.
> 
> Here is the trick:
> When I receive a packet that is either well- or mal-formed
> that wasn't originated by the adjacent router, how can I tell that
> the information is the individual fields is mostly correct?
>

TCP will check the header and data fields of a packet for correctness as
its associated checksum when calculated will identify any data corruption. 
If the sending BGP peer puts malformed/bad NLRI information in the packet
the TCP layer will not catch it. If the receiving BGP peer determines that
the NLRI is invalid, it should have a way to say something is wrong with the
given packet and maybe send it back as an attached data portion to an INFORM
message. If the offending peer continues to send malformed/bad NLRI packets,
the receiving peer should drop the session. I would think that is a
reasonable
way to handle malformed/bad NLRI packets.

Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA11705 for <[e-mail]>; Tue, 20 Aug 2002 10:27:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2765F912E3; Tue, 20 Aug 2002 10:26:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECE59912E5; Tue, 20 Aug 2002 10:26:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DB227912E3 for <[e-mail]>; Tue, 20 Aug 2002 10:26:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BBA375DD91; Tue, 20 Aug 2002 10:26:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 650D55DD8F for <[e-mail]>; Tue, 20 Aug 2002 10:26:43 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7KEQce06435; Tue, 20 Aug 2002 10:26:38 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7KEQZ106427; Tue, 20 Aug 2002 10:26:35 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7KEQZC22981; Tue, 20 Aug 2002 10:26:35 -0400 (EDT)
Date: Tue, 20 Aug 2002 10:26:35 -0400
From: Jeffrey Haas <[e-mail]>
To: George Sheng <[e-mail]>
Cc: [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Aug 20, 2002 at 04:56:56AM +0000
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Aug 20, 2002 at 04:56:56AM +0000, George Sheng wrote:
> >Out of scope for IDR.
> 
> sounds to me like: things either happen inside IDR, or it just
> does not happen at all.

The way I usually see it, which may not match reality, is:
o Customer has issue foo.  
o Customer puts it to their vendor that the issue bgp related,
  even if it really isn't.
o Vendor comes up with extension that mostly solves problem,
  but *might* be better solved a different way.

INFORM is nice if you want your O&M to come from your router.
If so, its bgp.

If you want the same info to come from an NMS in your AS and
you want NMS's to talk to each other to solve the problem,
then get the right stuff in the bgp mib and work with the OPS
group to get inter-noc stuff done. :-)

Give an engineer a "problem" without describing the whole thing
and you'll get a solution.  It just may not be the one you're
looking for.

> I think we can handle one more mailing
> list, maybe [e-mail] (wg list for distributed
> mangement) :-)

Well, you might be able to. :-)

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA11435 for <[e-mail]>; Tue, 20 Aug 2002 10:19:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F38DA912A7; Tue, 20 Aug 2002 10:18:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6E3D912E3; Tue, 20 Aug 2002 10:18:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A52FE912A7 for <[e-mail]>; Tue, 20 Aug 2002 10:18:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 927FC5DD9A; Tue, 20 Aug 2002 10:18:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 3A4D35DD91 for <[e-mail]>; Tue, 20 Aug 2002 10:18:31 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7KEHkp06291; Tue, 20 Aug 2002 10:17:46 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7KEHh106283; Tue, 20 Aug 2002 10:17:43 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7KEHh422944; Tue, 20 Aug 2002 10:17:43 -0400 (EDT)
Date: Tue, 20 Aug 2002 10:17:43 -0400
From: Jeffrey Haas <[e-mail]>
To: Avi Freedman <[e-mail]>
Cc: George Sheng <[e-mail]>, [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Sat, Aug 17, 2002 at 02:58:52PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Sat, Aug 17, 2002 at 02:58:52PM -0400, Avi Freedman wrote:
> That said, I will go back and recheck the behavior of various
> routers for reserved ASs appearing outside confederation segments.
> Perhaps that's not an issue any more.

That would be appreciated.
It may even be worthy of an ID - or at least something for the
museum of broken packets.

> I think we might be agreeing - I'm not suggesting that fixing broken
> packets is the desired thing, but rather that not requiring that
> one broken packet being propagated take down a peering session is
> the desired thing.

Here is the trick:
When I receive a packet that is either well- or mal-formed
that wasn't originated by the adjacent router, how can I tell that
the information is the individual fields is mostly correct?

Pedro from Juniper has made this point a few times before.  If
we think the data in the packet is invalid, we may not be able
to trust the NLRI fields.  Given that BGP is a stateful protocol,
you MUST be able to trust at least that much for purposes of deciding
"foo" path attribute is broken and potentially:
o Ignorable/Discardable
o Fixable

and then doing the right thing with the prefixes that go along with
the brokenness.

The best heuristic we can do is know about certain well-known types
of brokenness and provide knobs to work around them.  Anything else,
you'd be playing Russian Roulette with your routes.

If you can provide a solid heuristic of the type of potential
brokenness you're willing to put up with in your network, let us know. :-)

> Avi

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA22770 for <[e-mail]>; Tue, 20 Aug 2002 00:57:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C587F91293; Tue, 20 Aug 2002 00:56:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8CF7191294; Tue, 20 Aug 2002 00:56:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4633F91293 for <[e-mail]>; Tue, 20 Aug 2002 00:56:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2CBB65DEA9; Tue, 20 Aug 2002 00:56:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from hotmail.com (f34.law12.hotmail.com [64.4.19.34]) by segue.merit.edu (Postfix) with ESMTP id E33925DE37 for <[e-mail]>; Tue, 20 Aug 2002 00:56:56 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 19 Aug 2002 21:56:56 -0700
Received: from 63.197.79.145 by lw12fd.law12.hotmail.msn.com with HTTP; Tue, 20 Aug 2002 04:56:56 GMT
X-Originating-IP: [63.197.79.145]
From: "George Sheng" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: questions on INFORM draft
Date: Tue, 20 Aug 2002 04:56:56 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 20 Aug 2002 04:56:56.0508 (UTC) FILETIME=[02481FC0:01C24806]
Sender: [e-mail]
Precedence: bulk

>
> > * If vendors do want to help ISPs to improve inter-noc
> >    communication, then a generic agent would be a nice thing
> >    to do.
>
>Out of scope for IDR.

sounds to me like: things either happen inside IDR, or it just
does not happen at all. I think we can handle one more mailing
list, maybe [e-mail] (wg list for distributed
mangement) :-)

>Border "Glue" Protocol we may be but I don't want to see ASN.1
>in my routing streams.

george


_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA03180 for <[e-mail]>; Mon, 19 Aug 2002 15:20:06 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F18E691276; Mon, 19 Aug 2002 15:19:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD36091278; Mon, 19 Aug 2002 15:19:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9AD0691276 for <[e-mail]>; Mon, 19 Aug 2002 15:19:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 86FC85DE1D; Mon, 19 Aug 2002 15:19:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by segue.merit.edu (Postfix) with ESMTP id 56BBC5DDEE for <[e-mail]>; Mon, 19 Aug 2002 15:19:29 -0400 (EDT)
Received: from tom3 (userbm58.uk.uudial.com [62.188.145.10]) by colossus.systems.pipex.net (Postfix) with SMTP id 4D7A416000693 for <[e-mail]>; Mon, 19 Aug 2002 20:18:21 +0100 (BST)
Message-ID: <009b01c247b4$c7f36e20$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>
Subject: BGP FSM transport primitives
Date: Mon, 19 Aug 2002 17:55:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

ietf-hares-bgp-statemt-01.txt section 2.3.2 states that BGP can run
over any Transport protocol and defines transport primitives for
events 13 to 17.  But when it comes to actions in 3.0, the references
are explicitly to TCP eg Drop TCP connection.

I suggest that section 3 should also use protocol independent
primitives with a separate paragraph defining their mapping onto TCP
(this would also make section 3 more concise, no bad idea).

Tom Petch
[e-mail]




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA28580 for <[e-mail]>; Mon, 19 Aug 2002 13:00:01 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EC82591268; Mon, 19 Aug 2002 12:59:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B203C91269; Mon, 19 Aug 2002 12:59:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C474991268 for <[e-mail]>; Mon, 19 Aug 2002 12:59:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B44FF5DE4B; Mon, 19 Aug 2002 12:59:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 417295DE18 for <[e-mail]>; Mon, 19 Aug 2002 12:59:29 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA02656; Mon, 19 Aug 2002 12:59:26 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA17834; Mon, 19 Aug 2002 12:59:23 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <RHFQXY3S>; Mon, 19 Aug 2002 12:59:14 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'John G. Scudder'" <[e-mail]>, [e-mail]
Subject: RE: questions on INFORM draft
Date: Mon, 19 Aug 2002 12:59:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

 
> On Mon, Aug 19, 2002 at 12:44:05PM -0400, Abarbanel, Benjamin wrote:
> > Can you site some examples where subsecond information is 
> needed to be sent
> > to a peer?
> 
> Who needs subsecond?  More than 60 in a minute is good enough.
> 
So why not aggregate the information before you sent the INFORM and
then dont send more than 1 per second. 


> As an example, say we are getting INFORMs of a bad aspath that
> has been repaired.  It is quite possible that we may need to
> do this for the majority of the routes we are sent from a given
> peer.  This would mean potentially one INFORM per route we get
> sent.
> 
Whats the point in sending 60 messages almost all within the same 
few seconds. Its just going to sit in the receive queue of the 
destination peer. 

Aggregation of all the routes' status into one message with time delay, 
1 message per second is a more efficient way to handle it.

I contend that the implementation of a given INFORM message must decide
what is a reasonable way to burst or not burst data to a given destination
peer.

Ben
  


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA28270 for <[e-mail]>; Mon, 19 Aug 2002 12:51:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3B3BC91267; Mon, 19 Aug 2002 12:51:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D215991268; Mon, 19 Aug 2002 12:51:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ABAFE91267 for <[e-mail]>; Mon, 19 Aug 2002 12:51:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 920DE5DE4B; Mon, 19 Aug 2002 12:51:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 203F45DE18 for <[e-mail]>; Mon, 19 Aug 2002 12:51:27 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA02119; Mon, 19 Aug 2002 12:51:25 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA16372; Mon, 19 Aug 2002 12:51:26 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <RHFQXY1H>; Mon, 19 Aug 2002 12:51:25 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'John G. Scudder'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Subject: RE: questions on INFORM draft
Date: Mon, 19 Aug 2002 12:51:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

The point was, how can we loss information if we sent the INFORM 
status message once a second? 

My point is that at worst the information will be 1 second old + time
to transmit across the wire. How can that be an issue?

Ben

> -----Original Message-----
> From: John G. Scudder [mailto:[e-mail]]
> Sent: Monday, August 19, 2002 12:47 PM
> To: Abarbanel, Benjamin
> Cc: Abarbanel, Benjamin; 'Jeffrey Haas'; [e-mail]
> Subject: RE: questions on INFORM draft
> 
> 
> At 12:44 PM -0400 8/19/02, Abarbanel, Benjamin wrote:
> >Can you site some examples where subsecond information is 
> needed to be sent
> >to a peer?
> 
> Nope.  I seem to have lost the point of this discussion.
> 
> Regards,
> 
> --John
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA28212 for <[e-mail]>; Mon, 19 Aug 2002 12:49:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5A2B691265; Mon, 19 Aug 2002 12:49:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BE9191266; Mon, 19 Aug 2002 12:49:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 27F7191265 for <[e-mail]>; Mon, 19 Aug 2002 12:49:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0ACD55DE4B; Mon, 19 Aug 2002 12:49:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 6D7AE5DE18 for <[e-mail]>; Mon, 19 Aug 2002 12:49:34 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7JGnJg70283; Mon, 19 Aug 2002 12:49:19 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7JGnG170276; Mon, 19 Aug 2002 12:49:16 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7JGnGx18522; Mon, 19 Aug 2002 12:49:16 -0400 (EDT)
Date: Mon, 19 Aug 2002 12:49:16 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'John G. Scudder'" <[e-mail]>, [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Aug 19, 2002 at 12:44:05PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Aug 19, 2002 at 12:44:05PM -0400, Abarbanel, Benjamin wrote:
> Can you site some examples where subsecond information is needed to be sent
> to a peer?

Who needs subsecond?  More than 60 in a minute is good enough.

As an example, say we are getting INFORMs of a bad aspath that
has been repaired.  It is quite possible that we may need to
do this for the majority of the routes we are sent from a given
peer.  This would mean potentially one INFORM per route we get
sent.

> Ben

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA28194 for <[e-mail]>; Mon, 19 Aug 2002 12:49:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 721DD91262; Mon, 19 Aug 2002 12:48:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 672DE91265; Mon, 19 Aug 2002 12:47:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DDC0F91262 for <[e-mail]>; Mon, 19 Aug 2002 12:47:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C26615DE18; Mon, 19 Aug 2002 12:47:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id E7F5E5DEDA for <[e-mail]>; Mon, 19 Aug 2002 12:47:10 -0400 (EDT)
Received: from [171.69.182.142] (dhcp-171-69-182-142.cisco.com [171.69.182.142]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA22823; Mon, 19 Aug 2002 12:47:07 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a02b986d15d1535@[171.69.182.142]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Mon, 19 Aug 2002 12:47:01 -0400
To: "Abarbanel, Benjamin" <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: RE: questions on INFORM draft
Cc: "Abarbanel, Benjamin" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 12:44 PM -0400 8/19/02, Abarbanel, Benjamin wrote:
>Can you site some examples where subsecond information is needed to be sent
>to a peer?

Nope.  I seem to have lost the point of this discussion.

Regards,

--John


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA28055 for <[e-mail]>; Mon, 19 Aug 2002 12:44:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F00DA91261; Mon, 19 Aug 2002 12:44:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B796591262; Mon, 19 Aug 2002 12:44:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA07591261 for <[e-mail]>; Mon, 19 Aug 2002 12:44:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B37235DEDA; Mon, 19 Aug 2002 12:44:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 6C3AD5DE4B for <[e-mail]>; Mon, 19 Aug 2002 12:44:09 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA01683; Mon, 19 Aug 2002 12:44:07 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA15278; Mon, 19 Aug 2002 12:44:08 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <RHFQXX6X>; Mon, 19 Aug 2002 12:44:07 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'John G. Scudder'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: RE: questions on INFORM draft
Date: Mon, 19 Aug 2002 12:44:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

John and Jeff:
  I cannot imagine any status information that will need subsecond
notification
to a peer. Therefore, the notion of event loss is very unlikely to me.

Can you site some examples where subsecond information is needed to be sent
to a peer?

Ben

> -----Original Message-----
> From: John G. Scudder [mailto:[e-mail]]
> Sent: Monday, August 19, 2002 12:18 PM
> To: Abarbanel, Benjamin
> Cc: 'Jeffrey Haas'; Abarbanel, Benjamin; [e-mail]
> Subject: RE: questions on INFORM draft
> 
> 
> Clearly if you're generating events at a mean rate greater than 
> one/second, then 60/minute rate-limiting will result in the loss of 
> events (or delay approaching infinity if you have an infinite queue 
> available in your router :-).
> 
> Our intent in the proposal is that implementors should generate 
> events sparingly (at a mean rate much lower than one/second) and _if_ 
> micro-events are deemed to be worthy of an INFORM they should be 
> aggregated.
> 
> Furthermore as we discussed on the list about a month ago and as the 
> current version of the draft explicitly states in 7.1.2, we 
> specifically don't want INFORM to be part of BGP's control loop. 
> This relates to rate limiting in that it implies loss or delay of an 
> INFORM won't affect the operation of the protocol.  On the other 
> hand, allowing INFORMs to be spewed arbitrarily fast would have the 
> potential to delay important messages such as UPDATEs; a bad thing.
> 
> Regards,
> 
> --John
> 
> At 11:53 AM -0400 8/19/02, Abarbanel, Benjamin wrote:
> >Jeff:
> >  Section 7.1.1 states,
> >"The rate at which INFORM messages are generated must be 
> rate-limited.
> >  A suggested default limit is 60 messages per minute." This does not
> >  imply that messages are lost, just that status is conveyed 60 times
> >  per second.
> >
> >Ben
> ...
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA27174 for <[e-mail]>; Mon, 19 Aug 2002 12:18:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 174299125E; Mon, 19 Aug 2002 12:17:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D146491262; Mon, 19 Aug 2002 12:17:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A6C159125E for <[e-mail]>; Mon, 19 Aug 2002 12:17:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9834E5DE6D; Mon, 19 Aug 2002 12:17:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id D47E55DEC8 for <[e-mail]>; Mon, 19 Aug 2002 12:17:43 -0400 (EDT)
Received: from [192.168.42.10] (dhcp-171-69-182-142.cisco.com [171.69.182.142]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA21313; Mon, 19 Aug 2002 12:17:38 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a0ab986c6a29143@[192.168.42.10]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Mon, 19 Aug 2002 12:17:38 -0400
To: "Abarbanel, Benjamin" <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: RE: questions on INFORM draft
Cc: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Clearly if you're generating events at a mean rate greater than 
one/second, then 60/minute rate-limiting will result in the loss of 
events (or delay approaching infinity if you have an infinite queue 
available in your router :-).

Our intent in the proposal is that implementors should generate 
events sparingly (at a mean rate much lower than one/second) and _if_ 
micro-events are deemed to be worthy of an INFORM they should be 
aggregated.

Furthermore as we discussed on the list about a month ago and as the 
current version of the draft explicitly states in 7.1.2, we 
specifically don't want INFORM to be part of BGP's control loop. 
This relates to rate limiting in that it implies loss or delay of an 
INFORM won't affect the operation of the protocol.  On the other 
hand, allowing INFORMs to be spewed arbitrarily fast would have the 
potential to delay important messages such as UPDATEs; a bad thing.

Regards,

--John

At 11:53 AM -0400 8/19/02, Abarbanel, Benjamin wrote:
>Jeff:
>  Section 7.1.1 states,
>"The rate at which INFORM messages are generated must be rate-limited.
>  A suggested default limit is 60 messages per minute." This does not
>  imply that messages are lost, just that status is conveyed 60 times
>  per second.
>
>Ben
...


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA26677 for <[e-mail]>; Mon, 19 Aug 2002 12:02:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1E80D9125C; Mon, 19 Aug 2002 12:00:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D23A89125E; Mon, 19 Aug 2002 12:00:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4E7009125C for <[e-mail]>; Mon, 19 Aug 2002 12:00:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DB0F65DED6; Mon, 19 Aug 2002 12:00:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 4BAA05DE6D for <[e-mail]>; Mon, 19 Aug 2002 12:00:31 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7JG0Tl68202; Mon, 19 Aug 2002 12:00:29 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7JG0Q168195; Mon, 19 Aug 2002 12:00:26 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7JG0Qm18364; Mon, 19 Aug 2002 12:00:26 -0400 (EDT)
Date: Mon, 19 Aug 2002 12:00:26 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Aug 19, 2002 at 11:53:43AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Aug 19, 2002 at 11:53:43AM -0400, Abarbanel, Benjamin wrote:
> "The rate at which INFORM messages are generated must be rate-limited.
>  A suggested default limit is 60 messages per minute." This does not
>  imply that messages are lost, just that status is conveyed 60 times
>  per second.

Typically, rate limiting will imply loss of information when
"noisy" events happen.
Queues should not grow without bound.

> Ben

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA26436 for <[e-mail]>; Mon, 19 Aug 2002 11:55:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3907F91216; Mon, 19 Aug 2002 11:55:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 008C291225; Mon, 19 Aug 2002 11:55:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0A9A791216 for <[e-mail]>; Mon, 19 Aug 2002 11:55:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EBDAE5DECD; Mon, 19 Aug 2002 11:55:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 7765B5DE6D for <[e-mail]>; Mon, 19 Aug 2002 11:55:40 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA28271; Mon, 19 Aug 2002 11:55:38 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA06624; Mon, 19 Aug 2002 11:55:39 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <RHFQXV72>; Mon, 19 Aug 2002 11:55:37 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: questions on INFORM draft
Date: Mon, 19 Aug 2002 11:55:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Sorry that is 60 times per minute.

Ben

> -----Original Message-----
> From: Abarbanel, Benjamin 
> Sent: Monday, August 19, 2002 11:54 AM
> To: 'Jeffrey Haas'; Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: RE: questions on INFORM draft
> 
> 
> Jeff:
>  Section 7.1.1 states,
> "The rate at which INFORM messages are generated must be rate-limited.
>  A suggested default limit is 60 messages per minute." This does not
>  imply that messages are lost, just that status is conveyed 60 times
>  per second.
> 
> Ben
> 
> > -----Original Message-----
> > From: Jeffrey Haas [mailto:[e-mail]]
> > Sent: Monday, August 19, 2002 11:18 AM
> > To: Abarbanel, Benjamin
> > Cc: [e-mail]
> > Subject: Re: questions on INFORM draft
> > 
> > 
> > On Mon, Aug 19, 2002 at 11:11:53AM -0400, Abarbanel, Benjamin wrote:
> > >  How, if TCP gaurantee delivary. You mean likely to be 
> old or stale?
> > 
> > INFORM proposal, section 7.1.1
> > 
> > -- 
> > Jeff Haas 
> > NextHop Technologies
> > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA26398 for <[e-mail]>; Mon, 19 Aug 2002 11:54:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8258091264; Mon, 19 Aug 2002 11:53:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D90391262; Mon, 19 Aug 2002 11:53:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ACF6091216 for <[e-mail]>; Mon, 19 Aug 2002 11:53:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9710A5DECD; Mon, 19 Aug 2002 11:53:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 1FD305DE6D for <[e-mail]>; Mon, 19 Aug 2002 11:53:46 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27975; Mon, 19 Aug 2002 11:53:44 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA06123; Mon, 19 Aug 2002 11:53:45 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <RHFQXVYG>; Mon, 19 Aug 2002 11:53:43 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: questions on INFORM draft
Date: Mon, 19 Aug 2002 11:53:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Jeff:
 Section 7.1.1 states,
"The rate at which INFORM messages are generated must be rate-limited.
 A suggested default limit is 60 messages per minute." This does not
 imply that messages are lost, just that status is conveyed 60 times
 per second.

Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Monday, August 19, 2002 11:18 AM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: questions on INFORM draft
> 
> 
> On Mon, Aug 19, 2002 at 11:11:53AM -0400, Abarbanel, Benjamin wrote:
> >  How, if TCP gaurantee delivary. You mean likely to be old or stale?
> 
> INFORM proposal, section 7.1.1
> 
> -- 
> Jeff Haas 
> NextHop Technologies
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA25215 for <[e-mail]>; Mon, 19 Aug 2002 11:20:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C0D6D91259; Mon, 19 Aug 2002 11:19:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 720B49125A; Mon, 19 Aug 2002 11:19:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5DED891259 for <[e-mail]>; Mon, 19 Aug 2002 11:19:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3C49D5DED4; Mon, 19 Aug 2002 11:19:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id AE3D05DE6D for <[e-mail]>; Mon, 19 Aug 2002 11:19:44 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7JFIFo66985; Mon, 19 Aug 2002 11:18:15 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7JFIC166977; Mon, 19 Aug 2002 11:18:12 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7JFICM18180; Mon, 19 Aug 2002 11:18:12 -0400 (EDT)
Date: Mon, 19 Aug 2002 11:18:12 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Aug 19, 2002 at 11:11:53AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Aug 19, 2002 at 11:11:53AM -0400, Abarbanel, Benjamin wrote:
>  How, if TCP gaurantee delivary. You mean likely to be old or stale?

INFORM proposal, section 7.1.1

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA24987 for <[e-mail]>; Mon, 19 Aug 2002 11:12:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2DE7691258; Mon, 19 Aug 2002 11:12:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 01AF191259; Mon, 19 Aug 2002 11:11:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1208D91258 for <[e-mail]>; Mon, 19 Aug 2002 11:11:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EE4835DED3; Mon, 19 Aug 2002 11:11:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id A95275DE6D for <[e-mail]>; Mon, 19 Aug 2002 11:11:58 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23832; Mon, 19 Aug 2002 11:11:56 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24901; Mon, 19 Aug 2002 11:11:57 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <RHFQXS84>; Mon, 19 Aug 2002 11:11:56 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: George Sheng <[e-mail]>, [e-mail]
Subject: RE: questions on INFORM draft
Date: Mon, 19 Aug 2002 11:11:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

 
> 
> On Mon, Aug 19, 2002 at 10:59:36AM -0400, Abarbanel, Benjamin wrote:
> > I believe the INFORM message mechanism is a GOOD idea to 
> provide a vehicle
> > for future implementations to convey BGP status information 
> between peers
> > without implying a session reset.   
> 
> The fact that its rate limited means that some status is 
> likely to be lost.
>
 How, if TCP gaurantee delivary. You mean likely to be old or stale?

> > Ben
> 
> -- 
> Jeff Haas 
> NextHop Technologies
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA24748 for <[e-mail]>; Mon, 19 Aug 2002 11:05:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BDE9191249; Mon, 19 Aug 2002 11:04:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DAAB91257; Mon, 19 Aug 2002 11:04:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 89AE591249 for <[e-mail]>; Mon, 19 Aug 2002 11:04:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 76D755DEC8; Mon, 19 Aug 2002 11:04:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id E648B5DEA3 for <[e-mail]>; Mon, 19 Aug 2002 11:04:48 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7JF4ku66386; Mon, 19 Aug 2002 11:04:46 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7JF4h166379; Mon, 19 Aug 2002 11:04:43 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7JF4h018066; Mon, 19 Aug 2002 11:04:43 -0400 (EDT)
Date: Mon, 19 Aug 2002 11:04:43 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: George Sheng <[e-mail]>, [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Aug 19, 2002 at 10:59:36AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Aug 19, 2002 at 10:59:36AM -0400, Abarbanel, Benjamin wrote:
> I believe the INFORM message mechanism is a GOOD idea to provide a vehicle
> for future implementations to convey BGP status information between peers
> without implying a session reset.   

The fact that its rate limited means that some status is likely to be lost.

> Ben

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA24716 for <[e-mail]>; Mon, 19 Aug 2002 11:04:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4C16D91255; Mon, 19 Aug 2002 11:04:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DA2A91249; Mon, 19 Aug 2002 11:04:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 868B691255 for <[e-mail]>; Mon, 19 Aug 2002 11:03:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 692875DEC8; Mon, 19 Aug 2002 11:03:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id D330A5DEA3 for <[e-mail]>; Mon, 19 Aug 2002 11:03:34 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7JF3X466355; Mon, 19 Aug 2002 11:03:33 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7JF3U166348; Mon, 19 Aug 2002 11:03:30 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7JF3UQ18058; Mon, 19 Aug 2002 11:03:30 -0400 (EDT)
Date: Mon, 19 Aug 2002 11:03:30 -0400
From: Jeffrey Haas <[e-mail]>
To: George Sheng <[e-mail]>
Cc: [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Aug 19, 2002 at 03:43:50AM +0000
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Aug 19, 2002 at 03:43:50AM +0000, George Sheng wrote:
> Just wondering why we have not seen them. This hits me again
> there is something special in BGP, or maybe BGP is overloaded
> by all sorts of mechanism, add some more is not a big deal;-)

Much like having an IGP break, breaking BGP means the Internet is
broken.  Your users notice it pretty quickly.

IGPs, for whatever reason, seem to be more stable than BGP.
I'll withhold further comment on that.

> >In the case of IGP's, SNMP is sufficient.
> 
> even in the case of two areas are monitored by diff NOCs?
> they seem also need the "inform", if area 0 received too many
> inter-area routes for it's peer, No?

No.
Both are part of the same organization, both are likely receiving
the SNMP from the ABR.

> or are you saying INFORM can be used to sneak messages around
> your competitor's firewall or security system?

I have no idea why you're even thinking this way.

> I can only modify our own NMS to include such a functionality
> if people here really want this. I can post some pseudo-code
> of "expect"/"perl" if people are interested:-)

Can you convince your upstreams to take your SNMP?

> Basically here is what my take on this proposal:
> 
> * bgp serious errors usually better to bring session down

Agreed.

> * bgp less serious errors should not bring down session, but
>    some human involvement is needed to make a intelligent
>    decisions(including make a phone call)

Right.  But you need to bring things to the attention of the other
party.

> * If vendors do want to help ISPs to improve inter-noc
>    communication, then a generic agent would be a nice thing
>    to do.

Out of scope for IDR. 
Border "Glue" Protocol we may be but I don't want to see ASN.1
in my routing streams.

> * I'm not routing literate, but I'm wondering if NOTIFY msg can
>    be changed to flag not to "reset peer", maybe combined
>    with bgp capability attributes so backwards compatibility
>    is ensured?

Unlikely.  NOTIFY is the ultimate hammer.

> * in order to use this INFORM meaningfully, I'm afraid
>    complicated filtering/policy things have to be added later,
>    which may not be a good thing for BGP.

This would have to be added in whatever inter-noc "thing"
you want to put together.  This simply argues for keeping
things in INFORM simple.

> * this mechanism does have a simple way to inform the other
>    side. if people can find useful things to do(i'm still trying
>    to think), then it's ok. but I'm not convinced just yet.

I think the idea has some merit but has a ways to go.

> -george

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA24582 for <[e-mail]>; Mon, 19 Aug 2002 11:00:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DD0AA91244; Mon, 19 Aug 2002 10:59:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AEC8391249; Mon, 19 Aug 2002 10:59:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AAD6B91244 for <[e-mail]>; Mon, 19 Aug 2002 10:59:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9A60D5DECD; Mon, 19 Aug 2002 10:59:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 280EC5DEC8 for <[e-mail]>; Mon, 19 Aug 2002 10:59:40 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22645; Mon, 19 Aug 2002 10:59:37 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22180; Mon, 19 Aug 2002 10:59:38 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <RHFQXSJK>; Mon, 19 Aug 2002 10:59:37 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, George Sheng <[e-mail]>
Cc: [e-mail]
Subject: RE: questions on INFORM draft
Date: Mon, 19 Aug 2002 10:59:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I believe the INFORM message mechanism is a GOOD idea to provide a vehicle
for future implementations to convey BGP status information between peers
without implying a session reset.   

Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Saturday, August 17, 2002 2:19 PM
> To: George Sheng
> Cc: [e-mail]
> Subject: Re: questions on INFORM draft
> 
> 
> George,
> 
> On Sat, Aug 17, 2002 at 05:38:06AM +0000, George Sheng wrote:
> > that is cool. but still the question is why bgp?
> 
> Why not?  Has the idea been previously proposed for other protocols?
> 
> > there are a couple of protocols need inter-noc communications,
> 
> For each of these, there may be appropriate information that should
> be conveyed.
> 
> > For some large/huge networks, even the IGPs
> > at different areas are monitored by different departments/NOCs.
> 
> In the case of IGP's, SNMP is sufficient.
> 
> > Those actions may include send an
> > inter-noc trap to another NOC,
> 
> Exactly.  But:
> 1. Do you want SNMP coming from the other provider?
> 2. Why should the information come from a remote NMS rather than
>    the adjacent router?  You do provide some useful justifications:
> 
> > This way, you don't just restrict something to
> > only BGP, but to anything including DDOS attack, weird traffic
> > pattern and other protocol INFORM msgs.
> 
> I'm going to take the cop-out on this.
> A generic inter-noc protocol is out of scope for BGP.
> If you can provide such a thing, we should use that instead. :-)
> 
> > In the example
> > of "too many routes", for every peer, you may need to define
> > a "too many routes" limit since they can have different
> > requirements.
> 
> This is the way many providers already work.
> 
> > Also those limits do change with time.
> 
> And this is the way providers usually deal with things.
> 
> > Can ISPs keep up with those configurations?
> 
> As soon as someone proposes what they want the traps to look like,
> they'll show up in the bgp v2mib.
> 
> > You may also need to define
> > lots of inform-groups(similar to bgp peer-groups) to group
> > all the INFORM parameters for some peers. do we really want
> > to get into this?
> 
> Why would you?  Just like you would NOTIFY a given peer, you INFORM
> them.  Its up to the remote implementation to forward the information
> to the party that cares about it.
> 
> > you are probably thinking this(local NMS sending traps to
> > other NOCs) puts to much development burden on ISPs.
> 
> What I am thinking is that ISPs must already provide monitoring
> services by monitoring their routers already.  This just provides
> another piece of information that must be collected, summarized and
> processed.  As stands, I don't think INFORM is good enough to
> be summarized and easy to process.  But its a young proposal yet.
> 
> 
> -- 
> Jeff Haas 
> NextHop Technologies
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA23324 for <[e-mail]>; Mon, 19 Aug 2002 10:21:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3F25591243; Mon, 19 Aug 2002 10:20:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 12EBE91244; Mon, 19 Aug 2002 10:20:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2140191243 for <[e-mail]>; Mon, 19 Aug 2002 10:20:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 085FC5DE6E; Mon, 19 Aug 2002 10:20:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 725A75DDA9 for <[e-mail]>; Mon, 19 Aug 2002 10:20:50 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18651; Mon, 19 Aug 2002 10:20:48 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA12417; Mon, 19 Aug 2002 10:20:45 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <RHFQXQBK>; Mon, 19 Aug 2002 10:20:44 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'John G. Scudder'" <[e-mail]>, Pedro Roque Marques <[e-mail]>
Cc: Manav Bhatia <[e-mail]>, Mathew Richardson <[e-mail]>, [e-mail]
Subject: RE: Proposal to support dynamic capability negotiation of gracefu l  restart
Date: Mon, 19 Aug 2002 10:20:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

John:

> -----Original Message-----
> From: John G. Scudder [mailto:[e-mail]]
> Sent: Wednesday, August 14, 2002 3:05 PM
> To: Pedro Roque Marques
> Cc: Manav Bhatia; Mathew Richardson; [e-mail]
> Subject: Re: Proposal to support dynamic capability negotiation of
> gracefu l restart
> 
> 
> At 11:18 AM -0700 8/14/02, Pedro Roque Marques wrote:
> >Manav Bhatia writes:
> >
> >
> >>  I don't think any of the current implementations out there in the
> >>  field update their Hold Timer/Keep Alive timer based on messages
> >>  other than UPDATEs/KEEPALIVEs. But I propose that we must start
> >>  doing so.
> >
> >The drawbacks of such change are clear: introduction of
> >interoperability issues, need for "migration", etc...
> >
> >What exactly are the advantages... ? i fail to see any.
> 
> The advantage of resetting your holdtime based on reception of any 
> valid message seems obvious -- marginally less risk of unnecessary 
> session resets.
> 
> The risk of relying on such behavior from your peer seems 
> even more obvious.
> 
> Prudent implementors will act accordingly, regardless of what the 
> spec says or does not say.  This is just another application of the 
> adage about being liberal in what you accept and conservative in what 
> you send.
> 
> Considering that in real life the relative frequency of non-UPDATE, 
> non-KEEPALIVE messages is exceedingly low, the practical benefit to 
> be derived is marginal at best.  On the other hand, the cost of 
> changing deployed infrastructure is more than marginal.  So let's 
> leave the spec alone, please.
> 
If people implement based on good common sense (your comment "Prudent
implementors will act accordingly, regardless of what the spec says or
does not say") in lieu of the standard spec, what consistency or 
predictability will we have? 

I think change and evolution is a necessary must to get from point A to
point 
B. We will have to implement a phasing mechanism or some form of
deterministic
method to get the protocol to become more robust.

Ben

> Regards,
> 
> --John
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA22337 for <[e-mail]>; Mon, 19 Aug 2002 09:56:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2742191235; Mon, 19 Aug 2002 09:55:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8F6091243; Mon, 19 Aug 2002 09:55:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED45791235 for <[e-mail]>; Mon, 19 Aug 2002 09:55:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C231E5DE5D; Mon, 19 Aug 2002 09:55:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 4BBEF5DDA9 for <[e-mail]>; Mon, 19 Aug 2002 09:55:49 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA16368; Mon, 19 Aug 2002 09:55:45 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06991; Mon, 19 Aug 2002 09:55:47 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <RHFQX3X3>; Mon, 19 Aug 2002 09:55:46 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Subject: RE: Proposal to support dynamic capability negotiation of gracefu l restart
Date: Mon, 19 Aug 2002 09:55:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Jeffrey:

I have been on vacation, hence late response below.

Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Monday, August 12, 2002 11:03 AM
> To: [e-mail]
> Subject: Re: Proposal to support dynamic capability negotiation of
> gracefu l restart
> 
> 
> On Tue, Aug 06, 2002 at 03:05:30PM -0400, Abarbanel, Benjamin wrote:
> > Is it fair to assume that if a capability is "dynamic" in 
> nature than it 
> > can be activated or deactived "dynamically" without 
> disturbance to the
> > peering session or FSM state.
> 

The peering session should definitely not be disturbed, the FSM state well
if the new feature requires an FSM state change than it is reasonable to
expect it. Whatever new state might be defined should be exclusive of all
other states.

> My guess would be "no".
> However, this is hard to discuss because most of the recent
> extensions (route refresh, etc.) don't bother to document their
> FSM implications.
> 
> To give just one example, say a speaker is about to hit its timeout
> to send a keepalive.  In place of the keepalive, it sends a route
> refresh message.  Should the FSM treat the route refresh in the
> same sense that a keepalive or an update would be treated for
> purposes of resetting the relevant timers?
>

In this case, since the peer has responded with a BGP ("route refresh")
message, that is sufficient to declare it active and able to communicate. 
The keepalive should only be sent if there are NO other BGP messages to 
send in order to declare the peer's ability to communicate.
 
Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA00948 for <[e-mail]>; Sun, 18 Aug 2002 23:44:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 816EE9121D; Sun, 18 Aug 2002 23:43:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 597A391233; Sun, 18 Aug 2002 23:43:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE2149121D for <[e-mail]>; Sun, 18 Aug 2002 23:43:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C98935DF34; Sun, 18 Aug 2002 23:43:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from hotmail.com (f240.law12.hotmail.com [64.4.19.240]) by segue.merit.edu (Postfix) with ESMTP id 7A95D5DE47 for <[e-mail]>; Sun, 18 Aug 2002 23:43:51 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 18 Aug 2002 20:43:50 -0700
Received: from 63.197.79.145 by lw12fd.law12.hotmail.msn.com with HTTP; Mon, 19 Aug 2002 03:43:50 GMT
X-Originating-IP: [63.197.79.145]
From: "George Sheng" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: questions on INFORM draft
Date: Mon, 19 Aug 2002 03:43:50 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 19 Aug 2002 03:43:50.0953 (UTC) FILETIME=[A1DFC990:01C24732]
Sender: [e-mail]
Precedence: bulk

Jeff,

>
>Why not?  Has the idea been previously proposed for other protocols?
>

Not sure, but do they need to? I assume
the bgp-ignorants in NOCs are still capable of using phones:-)

> > there are a couple of protocols need inter-noc communications,
>
>For each of these, there may be appropriate information that should
>be conveyed.

Just wondering why we have not seen them. This hits me again
there is something special in BGP, or maybe BGP is overloaded
by all sorts of mechanism, add some more is not a big deal;-)

>
> > For some large/huge networks, even the IGPs
> > at different areas are monitored by different departments/NOCs.
>
>In the case of IGP's, SNMP is sufficient.

even in the case of two areas are monitored by diff NOCs?
they seem also need the "inform", if area 0 received too many
inter-area routes for it's peer, No?

>
> > Those actions may include send an
> > inter-noc trap to another NOC,
>
>Exactly.  But:
>1. Do you want SNMP coming from the other provider?

things can be worked out between NOCs. If they don't,
do you think they would love to see your INFORM messages?
or are you saying INFORM can be used to sneak messages around
your competitor's firewall or security system?

>2. Why should the information come from a remote NMS rather than
>    the adjacent router?  You do provide some useful justifications:
>

yes, I did I think.

> > This way, you don't just restrict something to
> > only BGP, but to anything including DDOS attack, weird traffic
> > pattern and other protocol INFORM msgs.
>
>I'm going to take the cop-out on this.
>A generic inter-noc protocol is out of scope for BGP.
>If you can provide such a thing, we should use that instead. :-)

I can only modify our own NMS to include such a functionality
if people here really want this. I can post some pseudo-code
of "expect"/"perl" if people are interested:-)

>
> > In the example
> > of "too many routes", for every peer, you may need to define
> > a "too many routes" limit since they can have different
> > requirements.
>
>This is the way many providers already work.
>
> > Also those limits do change with time.
>
>And this is the way providers usually deal with things.

I think I was talking about more complicated cases when
this INFORM can be really appreciated. For exceeding route
limit, I don't feel reset peer is a bad thing to do. But as
Andrew suggested setting some soft limit, maybe primary soft
and secondary soft, things can get complicated.

>
> > Can ISPs keep up with those configurations?
>
>As soon as someone proposes what they want the traps to look like,
>they'll show up in the bgp v2mib.
>
> > You may also need to define
> > lots of inform-groups(similar to bgp peer-groups) to group
> > all the INFORM parameters for some peers. do we really want
> > to get into this?
>
>Why would you?  Just like you would NOTIFY a given peer, you INFORM
>them.  Its up to the remote implementation to forward the information
>to the party that cares about it.

If you need too much configuration to deal with each INFORM
conditions, to group them into something can be shared
with different peers is a well known mechanism I think.

Basically here is what my take on this proposal:

* bgp serious errors usually better to bring session down
* bgp less serious errors should not bring down session, but
   some human involvement is needed to make a intelligent
   decisions(including make a phone call)
* If vendors do want to help ISPs to improve inter-noc
   communication, then a generic agent would be a nice thing
   to do.
* I'm not routing literate, but I'm wondering if NOTIFY msg can
   be changed to flag not to "reset peer", maybe combined
   with bgp capability attributes so backwards compatibility
   is ensured?
* in order to use this INFORM meaningfully, I'm afraid
   complicated filtering/policy things have to be added later,
   which may not be a good thing for BGP.
* this mechanism does have a simple way to inform the other
   side. if people can find useful things to do(i'm still trying
   to think), then it's ok. but I'm not convinced just yet.

My 2 cents.

>
> > you are probably thinking this(local NMS sending traps to
> > other NOCs) puts to much development burden on ISPs.
>
>What I am thinking is that ISPs must already provide monitoring
>services by monitoring their routers already.  This just provides
>another piece of information that must be collected, summarized and
>processed.  As stands, I don't think INFORM is good enough to
>be summarized and easy to process.  But its a young proposal yet.
>
>
>--
>Jeff Haas
>NextHop Technologies





-george


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA24820 for <[e-mail]>; Sun, 18 Aug 2002 04:49:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 587F691232; Sun, 18 Aug 2002 04:49:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E96E91233; Sun, 18 Aug 2002 04:48:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7174A91232 for <[e-mail]>; Sun, 18 Aug 2002 04:47:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 381BE5DDF5; Sun, 18 Aug 2002 04:47:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from titanium.zebra.org (12-236-237-176.client.attbi.com [12.236.237.176]) by segue.merit.edu (Postfix) with ESMTP id 8B25F5DD96 for <[e-mail]>; Sun, 18 Aug 2002 04:47:16 -0400 (EDT)
Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id EAA07812; Sun, 18 Aug 2002 04:49:23 -0400
Date: Sun, 18 Aug 2002 01:49:22 -0700
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP INFORM message
In-Reply-To: <[e-mail]>
References: <[e-mail]>
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>Are there any implementations?

You will see ;-).
--
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA26470 for <[e-mail]>; Sat, 17 Aug 2002 14:19:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 97A9791209; Sat, 17 Aug 2002 14:19:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F73A9120A; Sat, 17 Aug 2002 14:19:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 433AB91209 for <[e-mail]>; Sat, 17 Aug 2002 14:19:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2F8195DDF1; Sat, 17 Aug 2002 14:19:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 9AB475DD92 for <[e-mail]>; Sat, 17 Aug 2002 14:19:31 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7HIJUi20288; Sat, 17 Aug 2002 14:19:30 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7HIJR120281; Sat, 17 Aug 2002 14:19:27 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7HIJRC13923; Sat, 17 Aug 2002 14:19:27 -0400 (EDT)
Date: Sat, 17 Aug 2002 14:19:27 -0400
From: Jeffrey Haas <[e-mail]>
To: George Sheng <[e-mail]>
Cc: [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Sat, Aug 17, 2002 at 05:38:06AM +0000
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

George,

On Sat, Aug 17, 2002 at 05:38:06AM +0000, George Sheng wrote:
> that is cool. but still the question is why bgp?

Why not?  Has the idea been previously proposed for other protocols?

> there are a couple of protocols need inter-noc communications,

For each of these, there may be appropriate information that should
be conveyed.

> For some large/huge networks, even the IGPs
> at different areas are monitored by different departments/NOCs.

In the case of IGP's, SNMP is sufficient.

> Those actions may include send an
> inter-noc trap to another NOC,

Exactly.  But:
1. Do you want SNMP coming from the other provider?
2. Why should the information come from a remote NMS rather than
   the adjacent router?  You do provide some useful justifications:

> This way, you don't just restrict something to
> only BGP, but to anything including DDOS attack, weird traffic
> pattern and other protocol INFORM msgs.

I'm going to take the cop-out on this.
A generic inter-noc protocol is out of scope for BGP.
If you can provide such a thing, we should use that instead. :-)

> In the example
> of "too many routes", for every peer, you may need to define
> a "too many routes" limit since they can have different
> requirements.

This is the way many providers already work.

> Also those limits do change with time.

And this is the way providers usually deal with things.

> Can ISPs keep up with those configurations?

As soon as someone proposes what they want the traps to look like,
they'll show up in the bgp v2mib.

> You may also need to define
> lots of inform-groups(similar to bgp peer-groups) to group
> all the INFORM parameters for some peers. do we really want
> to get into this?

Why would you?  Just like you would NOTIFY a given peer, you INFORM
them.  Its up to the remote implementation to forward the information
to the party that cares about it.

> you are probably thinking this(local NMS sending traps to
> other NOCs) puts to much development burden on ISPs.

What I am thinking is that ISPs must already provide monitoring
services by monitoring their routers already.  This just provides
another piece of information that must be collected, summarized and
processed.  As stands, I don't think INFORM is good enough to
be summarized and easy to process.  But its a young proposal yet.


-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA26118 for <[e-mail]>; Sat, 17 Aug 2002 14:09:06 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 285F891207; Sat, 17 Aug 2002 14:08:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E652D91209; Sat, 17 Aug 2002 14:08:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A95C891207 for <[e-mail]>; Sat, 17 Aug 2002 14:08:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8AC195DDF1; Sat, 17 Aug 2002 14:08:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 004E55DD92 for <[e-mail]>; Sat, 17 Aug 2002 14:08:34 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7HI82w20009; Sat, 17 Aug 2002 14:08:02 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7HI7x120002; Sat, 17 Aug 2002 14:07:59 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7HI7wq13906; Sat, 17 Aug 2002 14:07:58 -0400 (EDT)
Date: Sat, 17 Aug 2002 14:07:58 -0400
From: Jeffrey Haas <[e-mail]>
To: Avi Freedman <[e-mail]>
Cc: George Sheng <[e-mail]>, [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Sat, Aug 17, 2002 at 03:07:47AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Avi,

On Sat, Aug 17, 2002 at 03:07:47AM -0400, Avi Freedman wrote:
> Isn't this also something to eventually replace the NOTIFY behavior?

Not at all.
Again, I'll let the authors comment.

> Right now the default behavior is pretty evil, and every time 
> someone leaks a reserved AS which is generally transitied all 
> the paranoid vendors' routers reset their Cisco sessions.

Oh ye gods and little fishes.
BGP doesn't care a rats suitcase about "reserved AS" numbers.
You see reserved AS's leaking into the Net all the time.
Please help to stop the spread of this insidious rumor.

The error in question was the fact that a CONFEDERATION segment
(see RFC 3065) leaked outside of a confederation boundary and was
propagated across the Net.  When a router that didn't have this
bug received a confederation segment and the peer was not a 
confederation peer, it was treated as an error and the NOTIFY sent.

If you wont believe me, I'll actually take the time to find a 
freeware BGP packet generator and build the packets for you.
I'll even build it with non-private-as confederation segments.
I'll leave it to you to find instances of the propagator and
also the receiver who sends the NOTIFY.

Normally, you would only see this from an adjacent peer and the
confederation segment would be right at the start of the as path.
If you get this from a peer that you don't have configured as
a confederation peer, someone has a screwed up configuration and
you probably don't want their routes.

The fact that these confederation segments were able to occur in
the middle of a path means that:
1) Someone received the confederation segment and wasn't a
   confederation peer.
2) Propagated them.

1 is bad enough.  2 means you're leaking buggy stuff.

Even if you discard the confederation segment, you now have an AS
that doesn't have itself in the path and can lead to internal
loops for that AS.  You also very likely have routes that are
being leaked to the net unintentionally and a lot of missing policy
that should have been applied.

You treat your confederation peers different policy-wise than your
AS external neighbors?  Thought so.

> I don't love the idea of a BGP extension just for status but
> something that would help people get comfortable moving 
> "broken-packet" notifications into something that some providers
> could watch for and drop sessions and some could not...

I think the idea of "fixing" broken packets is generally abhorrent
as a general case and am queasy at the notion even in specfically
understood well-known cases.  At the very least, these belong in
the "museum of broken packets".

I happen to like the idea of being able to pass along some information
between routers.  INFORM, in this sense, isn't horrible.  The trick
is to make it work generically and not use it where a NOTIFY really
should be used.

> Avi

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA02311 for <[e-mail]>; Sat, 17 Aug 2002 01:38:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id ED53F91227; Sat, 17 Aug 2002 01:38:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAE169123B; Sat, 17 Aug 2002 01:38:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 402EF91227 for <[e-mail]>; Sat, 17 Aug 2002 01:38:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BBDB85DDE1; Sat, 17 Aug 2002 01:38:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from hotmail.com (f73.law12.hotmail.com [64.4.19.73]) by segue.merit.edu (Postfix) with ESMTP id 6F8F85DDB6 for <[e-mail]>; Sat, 17 Aug 2002 01:38:07 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 16 Aug 2002 22:38:07 -0700
Received: from 63.197.79.145 by lw12fd.law12.hotmail.msn.com with HTTP; Sat, 17 Aug 2002 05:38:06 GMT
X-Originating-IP: [63.197.79.145]
From: "George Sheng" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: questions on INFORM draft
Date: Sat, 17 Aug 2002 05:38:06 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 17 Aug 2002 05:38:07.0011 (UTC) FILETIME=[4393B730:01C245B0]
Sender: [e-mail]
Precedence: bulk

Jeff,

>From: Jeffrey Haas <[e-mail]>
>To: George Sheng <[e-mail]>
>CC: [e-mail]
>Subject: Re: questions on INFORM draft
>Date: Thu, 15 Aug 2002 17:48:06 -0400
>
>On Thu, Aug 15, 2002 at 09:20:32PM +0000, George Sheng wrote:
> > If this is only for logging, then
> > why its particular to bgp?
>
>Not speaking for the INFORM authors, the general idea is to
>allow a remote BGP speaker to send O&M type information to you.
>
>Thus, its a "I've done this, you *might* want to know about it."

that is cool. but still the question is why bgp? there are a
couple of protocols need inter-noc communications, such as PIM,
DVMRP, RSVP, LDP. For some large/huge networks, even the IGPs
at different areas are monitored by different departments/NOCs.
wouldn't they all need some version of INFORMs?

if the local SNMP traps get to "local" NMS, then a policy base
rules can be defined to process them, identify them, and take
appropriate actions. Those actions may include send an
inter-noc trap to another NOC, or send an automatic email to
notify them. This way, you don't just restrict something to
only BGP, but to anything including DDOS attack, weird traffic
pattern and other protocol INFORM msgs. Sometimes you don't
want to "INFORM" them every time it hits a condition, you
want to only do one for every 20 times; or combine two events,
if X happens, and then Y also happens, then we send them a
notification. If you want to do all those things inside BGP,
its going to have a very fun configurations. In the example
of "too many routes", for every peer, you may need to define
a "too many routes" limit since they can have different
requirements. Also those limits do change with time. Can ISPs
keep up with those configurations? You may also need to define
lots of inform-groups(similar to bgp peer-groups) to group
all the INFORM parameters for some peers. do we really want
to get into this?

you are probably thinking this(local NMS sending traps to
other NOCs) puts to much development burden
on ISPs. Yes. It can be developed in house if ISPs want to
take this type of control; or it can be new features for
NMS software vendors; or it can be a router software function.
Does "SAA" ring a bell? I think it stands for "service
assurance agent". Can we do something like that? call it
"INENA"(Inter-Noc Event Notification Agent), it should allow
event mapping into rules, and send out snmp traps to diff
NMS stations.

>
>--
>Jeff Haas
>NextHop Technologies

george


_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA16845 for <[e-mail]>; Fri, 16 Aug 2002 17:52:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4E08D912DF; Fri, 16 Aug 2002 17:51:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1956E912E0; Fri, 16 Aug 2002 17:51:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED149912DF for <[e-mail]>; Fri, 16 Aug 2002 17:51:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D776E5DDC2; Fri, 16 Aug 2002 17:51:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 7F18D5DDB9 for <[e-mail]>; Fri, 16 Aug 2002 17:51:11 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7GLp1i95726; Fri, 16 Aug 2002 17:51:01 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7GLou195707; Fri, 16 Aug 2002 17:50:56 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7GLout11710; Fri, 16 Aug 2002 17:50:56 -0400 (EDT)
Date: Fri, 16 Aug 2002 17:50:56 -0400
From: Jeffrey Haas <[e-mail]>
To: Russ White <[e-mail]>
Cc: [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Aug 16, 2002 at 05:13:55PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Aug 16, 2002 at 05:13:55PM -0400, Russ White wrote:
> Couldn't "INFORM TRAPS" be created to provide the right
> information back to NMS'?

MIBs are cleanest to implement when the events are enumerated.
The fact that many of these events are vendor and implementation
version number specific adds the usual awkwardness.

Since the problem is one of enumeration, perhaps a spot can be
set aside in the BGP MIB for the generic INFORM events.  Similarly
a spot can be set aside in the MIB for vendor specific events
with the vendor creating the relevant MIB events.  The base
OID of the trap could be sent as a new type in INFORM and
convention could require that the descriptive text is required
as part of the text.

So, this is a possibility and would address one of the issues.

Note that this would require the vendor to indicate in the INFORM
sufficient information to say what their vendor ID (likely, the
SNMP enterprise number) is for their implementation.  This *might*
be information that a customer may not want to disclose.

Its either that, or create a global registry of all fixup events.

> Russ

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA15650 for <[e-mail]>; Fri, 16 Aug 2002 17:14:38 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3DAAF912CE; Fri, 16 Aug 2002 17:13:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 02DFB912D5; Fri, 16 Aug 2002 17:13:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 63531912CE for <[e-mail]>; Fri, 16 Aug 2002 17:13:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 379975DF3F; Fri, 16 Aug 2002 17:13:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id AFBEB5DD8D for <[e-mail]>; Fri, 16 Aug 2002 17:13:56 -0400 (EDT)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA05169; Fri, 16 Aug 2002 17:13:55 -0400 (EDT)
Date: Fri, 16 Aug 2002 17:13:55 -0400 (EDT)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: questions on INFORM draft
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> I have specific issues with some of the events of the INFORM
> message - specifically the idea of "fixing" broken packets.
> Lets ignore that for the moment.

Well, INFORM isn't actually suggesting that anyone fix bad
packets, just providing a way to tell someone if you do. That
might be considered encouraging someone to do so, but I wouldn't
consider it telling someone to actually do it. :-)

> It is very unlikely that enough information will fit in the
> SNMP Trap to make it back to the NMS, SNMP being what it is.  
> We need to find a way to be concise.

Couldn't "INFORM TRAPS" be created to provide the right
information back to NMS'?

Russ


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




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA10257 for <[e-mail]>; Fri, 16 Aug 2002 14:25:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 040E0912CF; Fri, 16 Aug 2002 14:24:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B917D912D0; Fri, 16 Aug 2002 14:24:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD623912CF for <[e-mail]>; Fri, 16 Aug 2002 14:24:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 917615DDAF; Fri, 16 Aug 2002 14:24:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 109565DD9C for <[e-mail]>; Fri, 16 Aug 2002 14:24:49 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7GIOmM89574 for [e-mail]; Fri, 16 Aug 2002 14:24:48 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7GIOe189553 for <[e-mail]>; Fri, 16 Aug 2002 14:24:40 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7GIOea10201 for [e-mail]; Fri, 16 Aug 2002 14:24:40 -0400 (EDT)
Date: Fri, 16 Aug 2002 14:24:40 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Aug 16, 2002 at 10:46:22AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Aug 16, 2002 at 10:46:22AM -0700, [e-mail] wrote:
> In this example, a bad attribute was getting passed
> around, when an implementation that recognized the bad attribute
> received it, it tore down the session, with a MALFORMED_AS_PATH
> NOTIFY.  However, there was no indication what route caused the
> problem.  If INFORM existed, that information could have been passed
> back to the peer, who could have taken action.  

This is a deficiency in the current spec.  There is no reason why
the the AS PATH couldn't be returned in the data section of the
notification, excepting that this is (probably) not deployed practice.

> Andrew

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA09139 for <[e-mail]>; Fri, 16 Aug 2002 13:50:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 172E5912CC; Fri, 16 Aug 2002 13:49:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DCB5D912CD; Fri, 16 Aug 2002 13:49:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E54D7912CC for <[e-mail]>; Fri, 16 Aug 2002 13:49:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D1EA05DD9C; Fri, 16 Aug 2002 13:49:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 4076B5DD92 for <[e-mail]>; Fri, 16 Aug 2002 13:49:18 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id KAA12401; Fri, 16 Aug 2002 10:46:22 -0700 (PDT)
Date: Fri, 16 Aug 2002 10:46:22 -0700
From: [e-mail]
To: George Sheng <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Aug 15, 2002 at 10:21:16PM +0000
Sender: [e-mail]
Precedence: bulk

George,


> >I think it is important to note, that the INFORM message is NOT
> >in place to cause the remote router to undertake an automated protocol
> >action.  It is in place to faciliate communitcation, and capture
> >significant information.
> 
> basically you are saying it's a inter-noc remote-logging
> facility.

In a lot of ways, yes. The inter-noc boundry is quite opaque at times.
This should help.

> >Could you completely recreate INFORM's functionality with perfect
> >monitoring and inter-noc communication?  Probably.  Does that
> >degree of efficent communication always happen in real backbones?
> >Unfortuntely, not often enough.
> 
> that's true. If there is something really need to communicate
> in this way, I agree that this is useful. but besides this
> route-limit example, i still wait to see like what? usually
> NOCs talk to each other on circuit problems, excessive traffic
> patterns, DOS attacks, which I doubt we should use INFORM to do.

Another example, could be a case where you want to send more info
before you send a NOTIFY and tear down the session.  In the case
a couple of months ago where a MALFORMED_AS_PATH containing 
as_confed types was being erroniously propegated in the internet
comes to mind.  In this example, a bad attribute was getting passed
around, when an implementation that recognized the bad attribute
received it, it tore down the session, with a MALFORMED_AS_PATH
NOTIFY.  However, there was no indication what route caused the
problem.  If INFORM existed, that information could have been passed
back to the peer, who could have taken action.  

I don't think anyone intends for NOTIFY messages to replace inter-noc
communication.  But it will help things along.  As you pointed out
NOTIFY clearly would not work with DOS attacks or irregular traffic
patterns, or other issues outside the scope of the BGP session between
providers.

Andrew


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA07883 for <[e-mail]>; Fri, 16 Aug 2002 13:10:58 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 02156912C5; Fri, 16 Aug 2002 13:10:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C61CE912C8; Fri, 16 Aug 2002 13:10:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D23B5912C5 for <[e-mail]>; Fri, 16 Aug 2002 13:10:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C288E5DF3A; Fri, 16 Aug 2002 13:10:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 9BEE45DD90 for <[e-mail]>; Fri, 16 Aug 2002 13:10:37 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17fkcP-000Dzs-00; Fri, 16 Aug 2002 10:10:37 -0700
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Igor Faynberg <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: consult
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Date: Fri, 16 Aug 2002 10:10:37 -0700
Sender: [e-mail]
Precedence: bulk

> The absolutely accurate RFC index is published by the IETF:
> http://www.ietf.org/iesg/1rfc_index.txt.

<pedantry>

the authoritative site for rfcs is published by the rfc editor

    <http://www.rfc-editor.org/rfc.html>

the ietf site is authoritative for internet-drafts

    <http://www.ietf.org/ID.html>

randy



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA07778 for <[e-mail]>; Fri, 16 Aug 2002 13:07:24 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B1904912CB; Fri, 16 Aug 2002 13:05:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86F16912C8; Fri, 16 Aug 2002 13:05:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D975912C5 for <[e-mail]>; Fri, 16 Aug 2002 13:05:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8C8BA5DF36; Fri, 16 Aug 2002 13:05:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by segue.merit.edu (Postfix) with ESMTP id 506385DD90 for <[e-mail]>; Fri, 16 Aug 2002 13:05:08 -0400 (EDT)
Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with SMTP id g7GH56207866; Fri, 16 Aug 2002 13:05:06 -0400 (EDT)
Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA04282; Fri, 16 Aug 2002 13:05:05 -0400
Message-ID: <[e-mail]>
Date: Fri, 16 Aug 2002 13:05:04 -0400
From: Igor Faynberg <[e-mail]>
Reply-To: [e-mail]
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: "Natale, Jonathan" <[e-mail]>
Cc: "'lidefeng'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: consult
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

The absolutely accurate RFC index is published by the IETF:
http://www.ietf.org/iesg/1rfc_index.txt.

Igor Faynberg

"Natale, Jonathan" wrote:
> 
> I use http://rfc.sunsite.dk/
> Can't say how accurate it is for sure.
> 
> -----Original Message-----
> From: lidefeng [mailto:[e-mail]]
> Sent: Thursday, August 15, 2002 10:33 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: consult
> 
> There are three kinds of statuses of RFC in Standard Track:Proposed
> Standard,Draft Standard,Standard.
> 
> I don't know how to find out what status an RFC is currently on?
> 
> Will anyone tell me ? Thanks
> 
> Best Regards
> 
> Li Defeng


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA07495 for <[e-mail]>; Fri, 16 Aug 2002 12:58:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B2848912C6; Fri, 16 Aug 2002 12:57:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7BCE9912C5; Fri, 16 Aug 2002 12:57:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7491E912C6 for <[e-mail]>; Fri, 16 Aug 2002 12:57:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 60ECC5DF3C; Fri, 16 Aug 2002 12:57:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id C9C025DF3A for <[e-mail]>; Fri, 16 Aug 2002 12:57:53 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7GGvrr86925 for [e-mail]; Fri, 16 Aug 2002 12:57:53 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7GGvn186913 for <[e-mail]>; Fri, 16 Aug 2002 12:57:49 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7GGvnb09995 for [e-mail]; Fri, 16 Aug 2002 12:57:49 -0400 (EDT)
Date: Fri, 16 Aug 2002 12:57:49 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <p05111a10b982d09ca09b@[171.69.182.142]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <p05111a10b982d09ca09b@[171.69.182.142]>; from [e-mail] on Fri, Aug 16, 2002 at 12:06:47PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

I have specific issues with some of the events of the INFORM
message - specifically the idea of "fixing" broken packets.
Lets ignore that for the moment.

On Fri, Aug 16, 2002 at 12:06:47PM -0400, John G. Scudder wrote:
> With INFORM if NOC B wants to receive a trap when network A's router 
> has a problem, the SNMP part remains with in network B.  The path 
> looks like router A --INFORM--> router B --trap--> NOC B.  This 
> avoids both the operational and filtering issues.  While not perfect 
> INFORM is at least operationally scalable and implementable.

Providing a pushback mechanism to allow O&M information relevant
to the remote peering session is a good idea.

The trick is, are we providing the right information using INFORM?

The events that we have currently enumerate involve:
o Bad packets, fixing or discarding attributes.
o Too many routes (useful!)
o Attribute overflow (useful!)
o Dampening 

The data types that we can return in the PDU are:
o Unspecified 
o String
o PDU
o Attribute
o Integer (suggested name change, Integer32)

For bad packets or attributes, the above provides enough information
for a human looking at the message to know that something bad
has happened and give you a pretty good idea what it is.  Taking
this information and passing it back to the NMS is far trickier,
especially if we're talking SNMP.

For example, if we INFORM on a AS Path that we are noting has changed,
(non-prefixed confederation segments, for example), the NMS could
receive a trap from the BGP MIB that has the path attribute ID and
a generic OCTET STRING showing what was the item that was being complained
about.  The "error" string is far more useful here.

It is very unlikely that enough information will fit in the SNMP Trap
to make it back to the NMS, SNMP being what it is.  We need to find a
way to be concise.

Additionally, NMSs must have the ability to apply some amount of
programmatic logic to collect the information and provide useful
summarizations.  Something a human can read wont scale as nicely
as signalling a particular enumerated event.  A very good example
of this is the "too many prefixes" soft and hard limits.  This
would make for very nice events that are concise enough to fit
into a TRAP.

To summarize, INFORM is currently structured as a useful way to
"bring things to the attention of the router's operator".  However,
it is currently structured in such a way that its more useful as a
syslog/dump.  In order to make things fit in better with current O&M
practices, we would need to find a way to make things more concise
so we could use SNMP TRAPs or similar mechanisms.

Any suggestions from the authors?

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA06695 for <[e-mail]>; Fri, 16 Aug 2002 12:33:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D136C912C0; Fri, 16 Aug 2002 12:33:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C5E7912C1; Fri, 16 Aug 2002 12:33:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0CF57912C0 for <[e-mail]>; Fri, 16 Aug 2002 12:32:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D3EF05DF3A; Fri, 16 Aug 2002 12:32:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 53B0C5DF39 for <[e-mail]>; Fri, 16 Aug 2002 12:32:19 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7GGW7T86046; Fri, 16 Aug 2002 12:32:07 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7GGVw186001; Fri, 16 Aug 2002 12:31:58 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7GGVwY09935; Fri, 16 Aug 2002 12:31:58 -0400 (EDT)
Date: Fri, 16 Aug 2002 12:31:58 -0400
From: Jeffrey Haas <[e-mail]>
To: Igor Lasic <[e-mail]>
Cc: George Sheng <[e-mail]>, [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Aug 15, 2002 at 06:03:27PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Aug 15, 2002 at 06:03:27PM -0400, Igor Lasic wrote:
>   Why not define more BGP traps instead of coming up with a completely
>   new mechanism ?

As is mentioned later, this is an issue of causing traps to show
up on the OTHER router.

As to local traps, please feel free to make suggestions.  The v2mib
has room for more.

>   Igor

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA05791 for <[e-mail]>; Fri, 16 Aug 2002 12:07:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3CC7F912BF; Fri, 16 Aug 2002 12:07:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1273D912C0; Fri, 16 Aug 2002 12:07:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F28C3912BF for <[e-mail]>; Fri, 16 Aug 2002 12:06:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CA6745DF35; Fri, 16 Aug 2002 12:06:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id 1B4A25DF30 for <[e-mail]>; Fri, 16 Aug 2002 12:06:59 -0400 (EDT)
Received: from [171.69.182.142] (dhcp-171-69-182-142.cisco.com [171.69.182.142]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA16438; Fri, 16 Aug 2002 12:06:50 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a10b982d09ca09b@[171.69.182.142]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 16 Aug 2002 12:06:47 -0400
To: Igor Lasic <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: questions on INFORM draft
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 6:03 PM -0400 8/15/02, Igor Lasic wrote:
>Typically this type of notifications are better served via SNMP
>   traps. Every NOC relies heavily on trap processing to be able to
>   determine issues in the network. (NOC - Network ops center)
>
>   Why not define more BGP traps instead of coming up with a completely
>   new mechanism ? There will have be a mechanism to notify the NOC
>   about this condidtions anyway (on both peers.)

More traps would be fine, but would not address the same problem. 
Consider that in order to get the same functionality using traps, for 
each session which you might otherwise send an INFORM over, you must 
have (at least) the NMS address at the NOC which is responsible for 
the peer associated with the session.  This is bad enough from an 
operational scalability perspective, but when you consider that it's 
not unusual to impose various types of packet filtering on SNMP 
traffic from beyond your network's border, it's even worse.

With INFORM if NOC B wants to receive a trap when network A's router 
has a problem, the SNMP part remains with in network B.  The path 
looks like router A --INFORM--> router B --trap--> NOC B.  This 
avoids both the operational and filtering issues.  While not perfect 
INFORM is at least operationally scalable and implementable.

Regards,

--John


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA00443 for <[e-mail]>; Fri, 16 Aug 2002 09:20:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id AD89191263; Fri, 16 Aug 2002 09:20:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F4FD912BB; Fri, 16 Aug 2002 09:20:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3859991263 for <[e-mail]>; Fri, 16 Aug 2002 09:20:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 265A35DEDF; Fri, 16 Aug 2002 09:20:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id E0DA85DDD5 for <[e-mail]>; Fri, 16 Aug 2002 09:20:15 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6KGQJG>; Fri, 16 Aug 2002 09:20:15 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'lidefeng'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: consult
Date: Fri, 16 Aug 2002 09:20:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I use http://rfc.sunsite.dk/
Can't say how accurate it is for sure.

-----Original Message-----
From: lidefeng [mailto:[e-mail]] 
Sent: Thursday, August 15, 2002 10:33 PM
To: [e-mail]
Cc: [e-mail]
Subject: consult

There are three kinds of statuses of RFC in Standard Track:Proposed
Standard,Draft Standard,Standard.

I don't know how to find out what status an RFC is currently on?

Will anyone tell me ? Thanks

Best Regards

Li Defeng


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA21683 for <[e-mail]>; Fri, 16 Aug 2002 04:44:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5989F912BA; Fri, 16 Aug 2002 04:44:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2506F912BB; Fri, 16 Aug 2002 04:44:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA4BC912BA for <[e-mail]>; Fri, 16 Aug 2002 04:44:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id AFF395DF18; Fri, 16 Aug 2002 04:44:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mta0 (unknown [61.144.161.2]) by segue.merit.edu (Postfix) with ESMTP id 1E9D95DEB1 for <[e-mail]>; Fri, 16 Aug 2002 04:44:21 -0400 (EDT)
Received: from lidefeng04955 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <[e-mail]> for [e-mail]; Fri, 16 Aug 2002 16:42:30 +0800 (CST)
Date: Fri, 16 Aug 2002 16:40:29 +0800
From: lidefeng <[e-mail]>
Subject: about:draft-jacquenet-qos-nlri-04.txt
To: [e-mail]
Cc: [e-mail]
Message-id: <003001c24500$93ea0820$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Sender: [e-mail]
Precedence: bulk

hi,

In draft-jacquenet-qos-nlri-04.txt, there are several figures was omitted, Please add to it,otherwise I can't understand what you are describing.

Best Regards

Li Defeng


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA09516 for <[e-mail]>; Thu, 15 Aug 2002 22:37:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D94A7912AC; Thu, 15 Aug 2002 22:36:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98610912AE; Thu, 15 Aug 2002 22:36:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 51959912AC for <[e-mail]>; Thu, 15 Aug 2002 22:36:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3AB4D5DF17; Thu, 15 Aug 2002 22:36:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mta0 (unknown [61.144.161.2]) by segue.merit.edu (Postfix) with ESMTP id B3ADE5DF16 for <[e-mail]>; Thu, 15 Aug 2002 22:36:43 -0400 (EDT)
Received: from lidefeng04955 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <[e-mail]> for [e-mail]; Fri, 16 Aug 2002 10:34:53 +0800 (CST)
Date: Fri, 16 Aug 2002 10:32:52 +0800
From: lidefeng <[e-mail]>
Subject: consult
To: [e-mail]
Cc: [e-mail]
Message-id: <008501c244cd$38bba040$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Sender: [e-mail]
Precedence: bulk

There are three kinds of statuses of RFC in Standard Track:Proposed Standard,Draft Standard,Standard.

I don't know how to find out what status an RFC is currently on?

Will anyone tell me ? Thanks

Best Regards

Li Defeng


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA01163 for <[e-mail]>; Thu, 15 Aug 2002 18:21:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CCFA89124C; Thu, 15 Aug 2002 18:21:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9484091297; Thu, 15 Aug 2002 18:21:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 479039124C for <[e-mail]>; Thu, 15 Aug 2002 18:21:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2E67D5DDC3; Thu, 15 Aug 2002 18:21:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from hotmail.com (f193.law12.hotmail.com [64.4.19.193]) by segue.merit.edu (Postfix) with ESMTP id D426F5DDB0 for <[e-mail]>; Thu, 15 Aug 2002 18:21:16 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 15 Aug 2002 15:21:16 -0700
Received: from 155.53.36.107 by lw12fd.law12.hotmail.msn.com with HTTP; Thu, 15 Aug 2002 22:21:16 GMT
X-Originating-IP: [155.53.36.107]
From: "George Sheng" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: questions on INFORM draft
Date: Thu, 15 Aug 2002 22:21:16 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 15 Aug 2002 22:21:16.0426 (UTC) FILETIME=[127016A0:01C244AA]
Sender: [e-mail]
Precedence: bulk

Andrew,

>From: [e-mail]
>To: George Sheng <[e-mail]>
>CC: [e-mail], [e-mail]
>Subject: Re: questions on INFORM draft
>Date: Thu, 15 Aug 2002 14:43:39 -0700
>
>I think it is important to note, that the INFORM message is NOT
>in place to cause the remote router to undertake an automated protocol
>action.  It is in place to faciliate communitcation, and capture
>significant information.

basically you are saying it's a inter-noc remote-logging
facility.

>
>Perhaps I can elaborate a little on the example that the authors present
>in the draft.  In the current Internet, operators often implement a router
>feature where there is a hard cap to the number of routes that they
>will accept from any given peer.  Currently, when that cap is reached,
>the session is dropped with no indication that it has been dropped.
>This inevitably results in a ticket being opened, nocs being contacted,
>all of which take time.  In the meantime the session between the two
>networks is down, which causes BGP to reconverge, and results in
>possibly sub-optimal routing between the two networks.  (There is
>a draft currently to expand the NOTIFY space to allow the remote
>peer to know why the session went down, which is a very good thing,
>but it doesn't have the ability to prevent the situation.).
>
>With the INFORM message, an operator could, for example, set a
>soft cap and a hard cap on the number of sessions that they will
>accept from a peer.  When the soft cap is reached, the router
>sends an INFORM to it's peer.  The remote router now knows
>that it is getting close to the limit, and can log the message.
>The log can then be picked up by the other network's monitoring system
>and action can be taken on the part of the remote NOC.  In most
>cases they will call their peer's NOC and work out a raise in the
>cap, if normal route growth is causing the problem.  Under this
>set of events, the peering session never has to go down.

your example makes some sense. but I am wondering what will be
the gap beteen the soft and hard lines? 100 routes, 1000 routes?
If the gap is too big, you will always hit the soft and never
hit the hard, thus causing two NOCs constantly chatting whethers.
If the gap is too small, then One NOC has not have time to
make the call, the hard limit is already achieved. Reaching
hard limit usually is a serious matter to ISPs, they should
open trouble ticket and call each other to find out why from
my experience.

>
>Could you completely recreate INFORM's functionality with perfect
>monitoring and inter-noc communication?  Probably.  Does that
>degree of efficent communication always happen in real backbones?
>Unfortuntely, not often enough.

that's true. If there is something really need to communicate
in this way, I agree that this is useful. but besides this
route-limit example, i still wait to see like what? usually
NOCs talk to each other on circuit problems, excessive traffic
patterns, DOS attacks, which I doubt we should use INFORM to do.

just my 2 cents.

>
>Andrew
>
>
>On Thu, Aug 15, 2002 at 09:20:32PM +0000, George Sheng wrote:
> > Delivered-To: [e-mail]
> > Delivered-To: [e-mail]
> > Delivered-To: [e-mail]
> > X-Originating-IP: [155.53.36.107]
> > From: "George Sheng" <[e-mail]>
> > To: [e-mail]
> > Subject: questions on INFORM draft
> > Date: Thu, 15 Aug 2002 21:20:32 +0000
> > X-OriginalArrivalTime: 15 Aug 2002 21:20:32.0998 (UTC) 
>FILETIME=[96C91860:01C244A1]
> > Precedence: bulk
> >
> > I'm not familiar with implementation side, not sure how
> > complicated it can be done. By reading this
> > draft-nalawade-bgp-inform-00.txt draft, it seems to me that it
> > only serves some logging capability to bgp remove peers, or do i
> > miss something? from operational point of view, if this bgp
> > side receives a INFORM message, what do I suppose to do besides
> > logging? if this bgp needs to do something, then it seems the
> > implementation will be very complicated. E.g. this bgp sent to
> > it's peer something really wrong, I doubt this INFORM will bring
> > this bgp process back to conscious. Do we have concrete examples
> > from the operations saying people want this? just curious.
> > It seems to me that if this router sends too many routes to
> > the peer(an easy example used by the draft), after receiving the
> > INFORM, should this router just send less routes? but how, which
> > routes should this bgp drop? If this is only for logging, then
> > why its particular to bgp?
> >
> > george
> >
> >
> > _________________________________________________________________
> > MSN Photos is the easiest way to share and print your photos:
> > http://photos.msn.com/support/worldwide.aspx

george


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA00633 for <[e-mail]>; Thu, 15 Aug 2002 18:05:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E47919124B; Thu, 15 Aug 2002 18:04:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABF629124C; Thu, 15 Aug 2002 18:04:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9BF2E9124B for <[e-mail]>; Thu, 15 Aug 2002 18:04:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 898985DDC3; Thu, 15 Aug 2002 18:04:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from smtp.adc.com (smtp.adc.com [155.226.10.207]) by segue.merit.edu (Postfix) with ESMTP id 09BFE5DDB0 for <[e-mail]>; Thu, 15 Aug 2002 18:04:34 -0400 (EDT)
Received: from smtp.adc.com (localhost [127.0.0.1]) by smtp.adc.com (8.11.1/8.11.1) with ESMTP id g7FM4XF26894 for <[e-mail]>; Thu, 15 Aug 2002 17:04:33 -0500 (CDT)
Received: from B10.basystems.com.adc.com (IDENT:[e-mail] [146.71.193.223] (may be forged)) by smtp.adc.com (8.11.1/8.11.1) with ESMTP id g7FM4UR26889; Thu, 15 Aug 2002 17:04:31 -0500 (CDT)
From: Igor Lasic <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 15 Aug 2002 18:03:27 -0400
To: Jeffrey Haas <[e-mail]>
Cc: George Sheng <[e-mail]>, [e-mail]
Subject: Re: questions on INFORM draft
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 7.03 under Emacs 21.2.1
Sender: [e-mail]
Precedence: bulk

Typically this type of notifications are better served via SNMP
  traps. Every NOC relies heavily on trap processing to be able to
  determine issues in the network. (NOC - Network ops center) 

  Why not define more BGP traps instead of coming up with a completely
  new mechanism ? There will have be a mechanism to notify the NOC
  about this condidtions anyway (on both peers.) 

  Igor

Jeffrey Haas writes:
 > On Thu, Aug 15, 2002 at 09:20:32PM +0000, George Sheng wrote:
 > > If this is only for logging, then
 > > why its particular to bgp?
 > 
 > Not speaking for the INFORM authors, the general idea is to
 > allow a remote BGP speaker to send O&M type information to you.
 > 
 > Thus, its a "I've done this, you *might* want to know about it."
 > 
 > -- 
 > Jeff Haas 
 > NextHop Technologies



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA00052 for <[e-mail]>; Thu, 15 Aug 2002 17:48:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 989369124A; Thu, 15 Aug 2002 17:48:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5FBCF91246; Thu, 15 Aug 2002 17:48:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 25C9891295 for <[e-mail]>; Thu, 15 Aug 2002 17:48:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 08B6B5DE89; Thu, 15 Aug 2002 17:48:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 743825DDCF for <[e-mail]>; Thu, 15 Aug 2002 17:48:11 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7FLm9L59836; Thu, 15 Aug 2002 17:48:09 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7FLm6159829; Thu, 15 Aug 2002 17:48:06 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7FLm6A07841; Thu, 15 Aug 2002 17:48:06 -0400 (EDT)
Date: Thu, 15 Aug 2002 17:48:06 -0400
From: Jeffrey Haas <[e-mail]>
To: George Sheng <[e-mail]>
Cc: [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Aug 15, 2002 at 09:20:32PM +0000
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Aug 15, 2002 at 09:20:32PM +0000, George Sheng wrote:
> If this is only for logging, then
> why its particular to bgp?

Not speaking for the INFORM authors, the general idea is to
allow a remote BGP speaker to send O&M type information to you.

Thus, its a "I've done this, you *might* want to know about it."

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA29988 for <[e-mail]>; Thu, 15 Aug 2002 17:47:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D09FF91247; Thu, 15 Aug 2002 17:46:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9831D91295; Thu, 15 Aug 2002 17:46:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7FFCA91247 for <[e-mail]>; Thu, 15 Aug 2002 17:46:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 664E15DDCF; Thu, 15 Aug 2002 17:46:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 4F7CD5DDC3 for <[e-mail]>; Thu, 15 Aug 2002 17:46:42 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id OAA26479; Thu, 15 Aug 2002 14:43:39 -0700 (PDT)
Date: Thu, 15 Aug 2002 14:43:39 -0700
From: [e-mail]
To: George Sheng <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: questions on INFORM draft
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Aug 15, 2002 at 09:20:32PM +0000
Sender: [e-mail]
Precedence: bulk

I think it is important to note, that the INFORM message is NOT 
in place to cause the remote router to undertake an automated protocol
action.  It is in place to faciliate communitcation, and capture 
significant information.

Perhaps I can elaborate a little on the example that the authors present
in the draft.  In the current Internet, operators often implement a router
feature where there is a hard cap to the number of routes that they
will accept from any given peer.  Currently, when that cap is reached,
the session is dropped with no indication that it has been dropped.
This inevitably results in a ticket being opened, nocs being contacted,
all of which take time.  In the meantime the session between the two
networks is down, which causes BGP to reconverge, and results in 
possibly sub-optimal routing between the two networks.  (There is
a draft currently to expand the NOTIFY space to allow the remote
peer to know why the session went down, which is a very good thing,
but it doesn't have the ability to prevent the situation.).

With the INFORM message, an operator could, for example, set a
soft cap and a hard cap on the number of sessions that they will
accept from a peer.  When the soft cap is reached, the router
sends an INFORM to it's peer.  The remote router now knows
that it is getting close to the limit, and can log the message.
The log can then be picked up by the other network's monitoring system
and action can be taken on the part of the remote NOC.  In most
cases they will call their peer's NOC and work out a raise in the
cap, if normal route growth is causing the problem.  Under this
set of events, the peering session never has to go down.

Could you completely recreate INFORM's functionality with perfect
monitoring and inter-noc communication?  Probably.  Does that
degree of efficent communication always happen in real backbones?
Unfortuntely, not often enough.

Andrew


On Thu, Aug 15, 2002 at 09:20:32PM +0000, George Sheng wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> X-Originating-IP: [155.53.36.107]
> From: "George Sheng" <[e-mail]>
> To: [e-mail]
> Subject: questions on INFORM draft
> Date: Thu, 15 Aug 2002 21:20:32 +0000
> X-OriginalArrivalTime: 15 Aug 2002 21:20:32.0998 (UTC) FILETIME=[96C91860:01C244A1]
> Precedence: bulk
> 
> I'm not familiar with implementation side, not sure how
> complicated it can be done. By reading this
> draft-nalawade-bgp-inform-00.txt draft, it seems to me that it
> only serves some logging capability to bgp remove peers, or do i
> miss something? from operational point of view, if this bgp
> side receives a INFORM message, what do I suppose to do besides
> logging? if this bgp needs to do something, then it seems the
> implementation will be very complicated. E.g. this bgp sent to
> it's peer something really wrong, I doubt this INFORM will bring
> this bgp process back to conscious. Do we have concrete examples
> from the operations saying people want this? just curious.
> It seems to me that if this router sends too many routes to
> the peer(an easy example used by the draft), after receiving the
> INFORM, should this router just send less routes? but how, which
> routes should this bgp drop? If this is only for logging, then
> why its particular to bgp?
> 
> george
> 
> 
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos: 
> http://photos.msn.com/support/worldwide.aspx


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA29152 for <[e-mail]>; Thu, 15 Aug 2002 17:21:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2145191241; Thu, 15 Aug 2002 17:20:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E727F91295; Thu, 15 Aug 2002 17:20:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AE6FF91241 for <[e-mail]>; Thu, 15 Aug 2002 17:20:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9CF935DE97; Thu, 15 Aug 2002 17:20:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from hotmail.com (f182.law12.hotmail.com [64.4.19.182]) by segue.merit.edu (Postfix) with ESMTP id 5C8B95DE94 for <[e-mail]>; Thu, 15 Aug 2002 17:20:33 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 15 Aug 2002 14:20:32 -0700
Received: from 155.53.36.107 by lw12fd.law12.hotmail.msn.com with HTTP; Thu, 15 Aug 2002 21:20:32 GMT
X-Originating-IP: [155.53.36.107]
From: "George Sheng" <[e-mail]>
To: [e-mail]
Subject: questions on INFORM draft
Date: Thu, 15 Aug 2002 21:20:32 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 15 Aug 2002 21:20:32.0998 (UTC) FILETIME=[96C91860:01C244A1]
Sender: [e-mail]
Precedence: bulk

I'm not familiar with implementation side, not sure how
complicated it can be done. By reading this
draft-nalawade-bgp-inform-00.txt draft, it seems to me that it
only serves some logging capability to bgp remove peers, or do i
miss something? from operational point of view, if this bgp
side receives a INFORM message, what do I suppose to do besides
logging? if this bgp needs to do something, then it seems the
implementation will be very complicated. E.g. this bgp sent to
it's peer something really wrong, I doubt this INFORM will bring
this bgp process back to conscious. Do we have concrete examples
from the operations saying people want this? just curious.
It seems to me that if this router sends too many routes to
the peer(an easy example used by the draft), after receiving the
INFORM, should this router just send less routes? but how, which
routes should this bgp drop? If this is only for logging, then
why its particular to bgp?

george


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA28632 for <[e-mail]>; Thu, 15 Aug 2002 17:04:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8314C9122F; Thu, 15 Aug 2002 17:03:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5501691241; Thu, 15 Aug 2002 17:03:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 70EA69122F for <[e-mail]>; Thu, 15 Aug 2002 17:02:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 41C045DE15; Thu, 15 Aug 2002 17:02:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id E28AE5DDD3 for <[e-mail]>; Thu, 15 Aug 2002 17:02:54 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7FL2s858153 for [e-mail]; Thu, 15 Aug 2002 17:02:54 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7FL2p158146 for <[e-mail]>; Thu, 15 Aug 2002 17:02:51 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7FL2pF07566 for [e-mail]; Thu, 15 Aug 2002 17:02:51 -0400 (EDT)
Date: Thu, 15 Aug 2002 17:02:51 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l  restart
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <003101c24276$bde1a110$[e-mail]> <[e-mail]> <[e-mail]> <002d01c2433e$9ae16010$[e-mail]> <[e-mail]> <p05111a21b980574fbbef@[192.168.42.10]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Aug 15, 2002 at 11:29:08AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

It was pointed out to me that my choice in wording was poor:

On Thu, Aug 15, 2002 at 11:29:08AM -0400, Jeffrey Haas wrote:
> Why not make the spec do the "Right Thing" (as implied above)
> and let the implementations catch up as various vendors find time
> to rev their code?  As implied, the cost for being non-compliant
> is pretty small at this point.
> 
> This also sets good precedent, which I'm concerned about.

What I had meant to say was that if the spec was changed to account for
FSM implications for non-UPDATE/KEEPALIVE messages, and a vendor
wasn't compliant with them immediately, that there wouldn't be
any grave consequences.

The good precedent would be to make sure that we document all
implications to the FSM.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA21663 for <[e-mail]>; Thu, 15 Aug 2002 13:40:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EDF069123E; Thu, 15 Aug 2002 13:40:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9B719123F; Thu, 15 Aug 2002 13:40:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 626E69123E for <[e-mail]>; Thu, 15 Aug 2002 13:40:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4901C5DDEC; Thu, 15 Aug 2002 13:40:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 0B55B5DD97 for <[e-mail]>; Thu, 15 Aug 2002 13:40:35 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6KGMXH>; Thu, 15 Aug 2002 13:40:34 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: BGP INFORM message
Date: Thu, 15 Aug 2002 13:40:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Are there any implementations?

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Thursday, August 15, 2002 10:01 AM
To: [e-mail]
Subject: BGP INFORM message

Folks,

The authors of draft-nalawade-bgp-inform-02.txt would like
to make it the IDR WG document. The deadline for comments
(either positive or negative) on this request is August 29. 

Yakov.
------- Forwarded Message

Date:    Thu, 15 Aug 2002 08:15:30 -0400
From:    [e-mail]
To:      IETF-Announce: ;
Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt

- --NextPart

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


	Title		: BGPv4 INFORM message
	Author(s)	: G. Nalawade, J. Scudder, D. Ward
	Filename	: draft-nalawade-bgp-inform-02.txt
	Pages		: 11
	Date		: 14-Aug-02
	
This document defines a new message type, the BGP INFORM
message that communicates Informational data and operational
warnings without resetting the peering session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-nalawade-bgp-inform-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt

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

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

- --OtherAccess--

- --NextPart--



------- End of Forwarded Message


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA21352 for <[e-mail]>; Thu, 15 Aug 2002 13:31:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B68599123D; Thu, 15 Aug 2002 13:31:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 701499123E; Thu, 15 Aug 2002 13:31:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A96909123D for <[e-mail]>; Thu, 15 Aug 2002 13:31:23 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 832D95DDA3; Thu, 15 Aug 2002 13:31:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 439CA5DD97 for <[e-mail]>; Thu, 15 Aug 2002 13:31:23 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6KGMVX>; Thu, 15 Aug 2002 13:31:22 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: BGP INFORM message
Date: Thu, 15 Aug 2002 13:31:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

12345678901234567890123456789012345678901234567890123456789012345

1) change:
"6...........................................................3 
Definition of the BGP INFORM Message........................3"
to:
"6. Definition of the BGP INFORM Message....................3"


2) msg type would be 6 (next number), right?


3) if attribute is discarded then you should have the option of
keeping or discarded the associated route(s) and the INFORM
should indicate which.  (current implementation does both)


4) change:
"should be included in
the String field of the data port of the packet."
to:
"should be included in
the String TLV.


5.0)  Attribute Overflow 
    5.1) in current draft, does the TLV have the full or
truncated attribute (need to clarify)?

    5.2) would be good to send both full and truncated
attribute


6) rate limit should be configurable


7) sending INFORMS should be configuable per event type and/or
per peer and/or per peer-AS


8) change:
"should be logged and via locally determined"
to:
"should be logged via locally determined"


9) unrecognized INFORMs should be logged


10) malformed INFORMs should be logged


11) sent INFORMs should be logged

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Thursday, August 15, 2002 10:01 AM
To: [e-mail]
Subject: BGP INFORM message

Folks,

The authors of draft-nalawade-bgp-inform-02.txt would like
to make it the IDR WG document. The deadline for comments
(either positive or negative) on this request is August 29. 

Yakov.
------- Forwarded Message

Date:    Thu, 15 Aug 2002 08:15:30 -0400
From:    [e-mail]
To:      IETF-Announce: ;
Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt

- --NextPart

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


	Title		: BGPv4 INFORM message
	Author(s)	: G. Nalawade, J. Scudder, D. Ward
	Filename	: draft-nalawade-bgp-inform-02.txt
	Pages		: 11
	Date		: 14-Aug-02
	
This document defines a new message type, the BGP INFORM
message that communicates Informational data and operational
warnings without resetting the peering session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-nalawade-bgp-inform-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt

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

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

- --OtherAccess--

- --NextPart--



------- End of Forwarded Message


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA17442 for <[e-mail]>; Thu, 15 Aug 2002 11:30:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D691B91203; Thu, 15 Aug 2002 11:29:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A04B691239; Thu, 15 Aug 2002 11:29:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 71A0191203 for <[e-mail]>; Thu, 15 Aug 2002 11:29:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 514665DDE2; Thu, 15 Aug 2002 11:29:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id F0D235DDD3 for <[e-mail]>; Thu, 15 Aug 2002 11:29:33 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7FFTCU47967; Thu, 15 Aug 2002 11:29:12 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7FFT9147960; Thu, 15 Aug 2002 11:29:09 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7FFT8l06864; Thu, 15 Aug 2002 11:29:08 -0400 (EDT)
Date: Thu, 15 Aug 2002 11:29:08 -0400
From: Jeffrey Haas <[e-mail]>
To: "John G. Scudder" <[e-mail]>
Cc: Pedro Roque Marques <[e-mail]>, Manav Bhatia <[e-mail]>, Mathew Richardson <[e-mail]>, [e-mail]
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l  restart
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <003101c24276$bde1a110$[e-mail]> <[e-mail]> <[e-mail]> <002d01c2433e$9ae16010$[e-mail]> <[e-mail]> <p05111a21b980574fbbef@[192.168.42.10]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <p05111a21b980574fbbef@[192.168.42.10]>; from [e-mail] on Wed, Aug 14, 2002 at 03:05:26PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Aug 14, 2002 at 03:05:26PM -0400, John G. Scudder wrote:
> Prudent implementors will act accordingly, regardless of what the 
> spec says or does not say.  This is just another application of the 
> adage about being liberal in what you accept and conservative in what 
> you send.

I think we are all in agreement about this.  

But this would imply that the "Right Thing" is to reset timers
based on non-UPDATE/KEEPALIVE events.

> Considering that in real life the relative frequency of non-UPDATE, 
> non-KEEPALIVE messages is exceedingly low, the practical benefit to 
> be derived is marginal at best.

Agreed, but this would also imply that the cost of "you're not
compliant to the spec", where "compliant" in this case is
resetting a timer that is relatively unlikely to be expired,
isn't a horrible thing.

> On the other hand, the cost of 
> changing deployed infrastructure is more than marginal.  So let's 
> leave the spec alone, please.

Why not make the spec do the "Right Thing" (as implied above)
and let the implementations catch up as various vendors find time
to rev their code?  As implied, the cost for being non-compliant
is pretty small at this point.

This also sets good precedent, which I'm concerned about.

> --John

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15480 for <[e-mail]>; Thu, 15 Aug 2002 10:33:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3F2239123A; Thu, 15 Aug 2002 10:31:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 634D491298; Thu, 15 Aug 2002 10:31:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F29F59123A for <[e-mail]>; Thu, 15 Aug 2002 10:30:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D5E405DDBF; Thu, 15 Aug 2002 10:30:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web14106.mail.yahoo.com (web14106.mail.yahoo.com [216.136.172.136]) by segue.merit.edu (Postfix) with SMTP id 395DC5DDAD for <[e-mail]>; Thu, 15 Aug 2002 10:30:54 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [47.234.0.51] by web14106.mail.yahoo.com via HTTP; Thu, 15 Aug 2002 07:30:53 PDT
Date: Thu, 15 Aug 2002 07:30:53 -0700 (PDT)
From: PamSri <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

I really dont get it. This draft hinges on a very
vague concept : "An INFORM message may be sent to
inform a peer of an error condition which is not
serious enough to warrant the reset of the BGP peering
session."

This can be interpreted in N number of ways by
different vendor. Secondly if the draft wants to deal
the situations explicitly described with INFORM i
think the existing protocol has enough tools to handle
it in other ways and more efficiently. There is
absolutely no reason why a new message should be
introduced. The vagueness of the concept has a
potential to create enough confusion among different
implementations.

sri

Manav Bhatia writes:



> I don't think any of the current implementations out
there in the
> field update their Hold Timer/Keep Alive timer based
on messages
> other than UPDATEs/KEEPALIVEs. But I propose that we
must start
> doing so.


The drawbacks of such change are clear: introduction
of
interoperability issues, need for "migration", etc...

What exactly are the advantages... ? i fail to see
any.


> There can be issues in interoperatability between
two
> implementations ..  one of which supports the above
extension and
> the other one not. For the migration purposes an
interim solution
> can be for an implementation to provide a knob which
switches this
> feature ON and OFF till all the other
implementations adhere to this
> standard.


Pedro.




__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA14303 for <[e-mail]>; Thu, 15 Aug 2002 10:01:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2EFA6912A7; Thu, 15 Aug 2002 10:01:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2AA69129A; Thu, 15 Aug 2002 10:01:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2A3E7912A8 for <[e-mail]>; Thu, 15 Aug 2002 10:00:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D33135DE46; Thu, 15 Aug 2002 10:00:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 2A01A5DE00 for <[e-mail]>; Thu, 15 Aug 2002 10:00:50 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7FE0nm98365 for <[e-mail]>; Thu, 15 Aug 2002 07:00:49 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: BGP INFORM message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 15 Aug 2002 07:00:49 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

The authors of draft-nalawade-bgp-inform-02.txt would like
to make it the IDR WG document. The deadline for comments
(either positive or negative) on this request is August 29. 

Yakov.
------- Forwarded Message

Date:    Thu, 15 Aug 2002 08:15:30 -0400
From:    [e-mail]
To:      IETF-Announce: ;
Subject: I-D ACTION:draft-nalawade-bgp-inform-02.txt

- --NextPart

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


	Title		: BGPv4 INFORM message
	Author(s)	: G. Nalawade, J. Scudder, D. Ward
	Filename	: draft-nalawade-bgp-inform-02.txt
	Pages		: 11
	Date		: 14-Aug-02
	
This document defines a new message type, the BGP INFORM
message that communicates Informational data and operational
warnings without resetting the peering session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nalawade-bgp-inform-02.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-nalawade-bgp-inform-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-nalawade-bgp-inform-02.txt

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

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

- --OtherAccess--

- --NextPart--



------- End of Forwarded Message



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA07304 for <[e-mail]>; Wed, 14 Aug 2002 15:06:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1C44091285; Wed, 14 Aug 2002 15:05:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D7ABC91286; Wed, 14 Aug 2002 15:05:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D42A91285 for <[e-mail]>; Wed, 14 Aug 2002 15:05:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7EDC35DEE5; Wed, 14 Aug 2002 15:05:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id C26915DEE4 for <[e-mail]>; Wed, 14 Aug 2002 15:05:35 -0400 (EDT)
Received: from [192.168.42.10] (dhcp-171-69-182-142.cisco.com [171.69.182.142]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA13330; Wed, 14 Aug 2002 15:05:29 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a21b980574fbbef@[192.168.42.10]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <[e-mail]> <003101c24276$bde1a110$[e-mail]> <[e-mail]>	<[e-mail]> <002d01c2433e$9ae16010$[e-mail]> <[e-mail]>
Date: Wed, 14 Aug 2002 15:05:26 -0400
To: Pedro Roque Marques <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l  restart
Cc: Manav Bhatia <[e-mail]>, Mathew Richardson <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 11:18 AM -0700 8/14/02, Pedro Roque Marques wrote:
>Manav Bhatia writes:
>
>
>>  I don't think any of the current implementations out there in the
>>  field update their Hold Timer/Keep Alive timer based on messages
>>  other than UPDATEs/KEEPALIVEs. But I propose that we must start
>>  doing so.
>
>The drawbacks of such change are clear: introduction of
>interoperability issues, need for "migration", etc...
>
>What exactly are the advantages... ? i fail to see any.

The advantage of resetting your holdtime based on reception of any 
valid message seems obvious -- marginally less risk of unnecessary 
session resets.

The risk of relying on such behavior from your peer seems even more obvious.

Prudent implementors will act accordingly, regardless of what the 
spec says or does not say.  This is just another application of the 
adage about being liberal in what you accept and conservative in what 
you send.

Considering that in real life the relative frequency of non-UPDATE, 
non-KEEPALIVE messages is exceedingly low, the practical benefit to 
be derived is marginal at best.  On the other hand, the cost of 
changing deployed infrastructure is more than marginal.  So let's 
leave the spec alone, please.

Regards,

--John


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA05674 for <[e-mail]>; Wed, 14 Aug 2002 14:19:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B715A91280; Wed, 14 Aug 2002 14:18:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 82B6A91282; Wed, 14 Aug 2002 14:18:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2037A91280 for <[e-mail]>; Wed, 14 Aug 2002 14:18:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E676D5DED8; Wed, 14 Aug 2002 14:18:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 863F25DE9E for <[e-mail]>; Wed, 14 Aug 2002 14:18:21 -0400 (EDT)
Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7EIIJm39985; Wed, 14 Aug 2002 11:18:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id g7EIIIY44633; Wed, 14 Aug 2002 11:18:18 -0700 (PDT) (envelope-from roque)
Date: Wed, 14 Aug 2002 11:18:18 -0700 (PDT)
Message-Id: <[e-mail]>
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Manav Bhatia <[e-mail]>
Cc: Mathew Richardson <[e-mail]>, [e-mail]
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l restart
In-Reply-To: <002d01c2433e$9ae16010$[e-mail]>
References: <[e-mail]> <[e-mail]> <003101c24276$bde1a110$[e-mail]> <[e-mail]> <[e-mail]> <002d01c2433e$9ae16010$[e-mail]>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Sender: [e-mail]
Precedence: bulk

Manav Bhatia writes:


> I don't think any of the current implementations out there in the
> field update their Hold Timer/Keep Alive timer based on messages
> other than UPDATEs/KEEPALIVEs. But I propose that we must start
> doing so.

The drawbacks of such change are clear: introduction of
interoperability issues, need for "migration", etc...

What exactly are the advantages... ? i fail to see any.

> There can be issues in interoperatability between two
> implementations ..  one of which supports the above extension and
> the other one not. For the migration purposes an interim solution
> can be for an implementation to provide a knob which switches this
> feature ON and OFF till all the other implementations adhere to this
> standard.

  Pedro.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA05984 for <[e-mail]>; Tue, 13 Aug 2002 23:04:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id AE8409127D; Tue, 13 Aug 2002 23:04:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E41E9127E; Tue, 13 Aug 2002 23:04:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EC8389127D for <[e-mail]>; Tue, 13 Aug 2002 23:04:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D331D5DE8B; Tue, 13 Aug 2002 23:04:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from ep_mailout1 (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 830CD5DE06 for <[e-mail]>; Tue, 13 Aug 2002 23:04:31 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) id <[e-mail]> for [e-mail]; Wed, 14 Aug 2002 12:07:38 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 14 Aug 2002 12:07:38 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 14 Aug 2002 12:07:54 +0900 (KST)
Date: Wed, 14 Aug 2002 08:29:26 +0530
From: Manav Bhatia <[e-mail]>
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l restart
To: Mathew Richardson <[e-mail]>, [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <002d01c2433e$9ae16010$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]> <003101c24276$bde1a110$[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

|
| However, while changes of this nature are a good idea, in my opinion,
| they should be made if, and only if, deployed implementations are
| actually updating the Hold Timer/KeepAlive timer based on messages
| other than UPDATEs/KEEPALIVEs.
|

I don't think any of the current implementations out there in the field
update their Hold Timer/Keep Alive timer based on messages other than
UPDATEs/KEEPALIVEs. But I propose that we must start doing so.

There can be issues in interoperatability between two implementations ..
one of which supports the above extension and the other one not. For the
migration purposes an interim solution can be for an implementation to
provide a knob which switches this feature ON and OFF till all the other
implementations adhere to this standard.

This too can be mentioned in the draft.

Regards,
Manav





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA12906 for <[e-mail]>; Tue, 13 Aug 2002 11:24:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8562E9126C; Tue, 13 Aug 2002 11:23:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4EF3B9126D; Tue, 13 Aug 2002 11:23:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 32B8F9126C for <[e-mail]>; Tue, 13 Aug 2002 11:23:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0D6C05DFF6; Tue, 13 Aug 2002 11:23:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 765EC5DDD4 for <[e-mail]>; Tue, 13 Aug 2002 11:23:39 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7DFNcI74321 for [e-mail]; Tue, 13 Aug 2002 11:23:38 -0400 (EDT) (envelope-from [e-mail])
Received: from paradigm.nexthop.com (mrichardson.nexthop.com [64.211.218.45]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7DFNY174308 for <[e-mail]>; Tue, 13 Aug 2002 11:23:34 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g7DFNXH11814 for [e-mail]; Tue, 13 Aug 2002 11:23:33 -0400 (EDT)
Date: Tue, 13 Aug 2002 11:23:33 -0400
From: Mathew Richardson <[e-mail]>
To: [e-mail]
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l restart
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <003101c24276$bde1a110$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Aug 13, 2002 at 10:32:34AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

> Jeffrey Haas <[e-mail]> [Tue, Aug 13, 2002 at 10:32:34AM -0400]:
>Manav,
>
>On Tue, Aug 13, 2002 at 08:38:45AM +0530, Manav Bhatia wrote:
>> Infact i had proposed this in a mail thread some time back wherein I stated
>> that we include other BGP messages (Route Refresh, Dynamic Capability,
>> INFORM) which when received by the local system should act as surrogate for
>> the KEEPALIVE messages it would expect from the remote end. The local
>> system upon receiving such messages should then restart its Hold Timer.
>> 
>> Is there any problem with this?
>
>I believe what we're really waiting for at this point is for Sue to
>finish off her rev of the BGP FSM.  Once we have that done, we
>can start adding FSM extention ID's.

<snip>

This doesn't actually need an extension to the FSM.  The base
spec could be altered as follows:

Under the description of Hold Time, change:

  The calculated value indicates the maximum number of
  seconds that may elapse between the receipt of successive
  KEEPALIVE, and/or UPDATE messages by the sender.

to:

  The calculated value indicates the maximum number of
  seconds that may elapse between the receipt of successive
  messages.

In section 6.5, change:

  If a system does not receive successive KEEPALIVE and/or UPDATE
  and/or NOTIFICATION messages within the period specified 

to:

  If a system does not receive successive protocol messages within
  the period specified

Additionally, some text explaining that _any_ valid message, either
from the base spec. or from an extension, is sufficient to reset
the Hold Timer should be added.

However, while changes of this nature are a good idea, in my opinion,
they should be made if, and only if, deployed implementations are
actually updating the Hold Timer/KeepAlive timer based on messages
other than UPDATEs/KEEPALIVEs.

mrr


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA11284 for <[e-mail]>; Tue, 13 Aug 2002 10:33:24 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 45DAE91244; Tue, 13 Aug 2002 10:33:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1950E9126C; Tue, 13 Aug 2002 10:33:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0375791244 for <[e-mail]>; Tue, 13 Aug 2002 10:32:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D316B5DE50; Tue, 13 Aug 2002 10:32:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 4D5C25DE4A for <[e-mail]>; Tue, 13 Aug 2002 10:32:42 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7DEWbD71846; Tue, 13 Aug 2002 10:32:37 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7DEWY171839; Tue, 13 Aug 2002 10:32:34 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7DEWYc23999; Tue, 13 Aug 2002 10:32:34 -0400 (EDT)
Date: Tue, 13 Aug 2002 10:32:34 -0400
From: Jeffrey Haas <[e-mail]>
To: Manav Bhatia <[e-mail]>
Cc: [e-mail]
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l restart
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <003101c24276$bde1a110$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <003101c24276$bde1a110$[e-mail]>; from [e-mail] on Tue, Aug 13, 2002 at 08:38:45AM +0530
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Manav,

On Tue, Aug 13, 2002 at 08:38:45AM +0530, Manav Bhatia wrote:
> Infact i had proposed this in a mail thread some time back wherein I stated
> that we include other BGP messages (Route Refresh, Dynamic Capability,
> INFORM) which when received by the local system should act as surrogate for
> the KEEPALIVE messages it would expect from the remote end. The local
> system upon receiving such messages should then restart its Hold Timer.
> 
> Is there any problem with this?

I believe what we're really waiting for at this point is for Sue to
finish off her rev of the BGP FSM.  Once we have that done, we
can start adding FSM extention ID's.

Sue can use reviewers.  Have you volunteered? :-)

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA18851 for <[e-mail]>; Mon, 12 Aug 2002 23:14:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 26EA291260; Mon, 12 Aug 2002 23:13:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8A3F9126A; Mon, 12 Aug 2002 23:13:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 97ADA91260 for <[e-mail]>; Mon, 12 Aug 2002 23:13:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 839145DFE9; Mon, 12 Aug 2002 23:13:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from ep_mailout1 (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 2BFC15DFE8 for <[e-mail]>; Mon, 12 Aug 2002 23:13:48 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) id <[e-mail]> for [e-mail]; Tue, 13 Aug 2002 12:16:54 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 13 Aug 2002 12:16:53 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) with ESMTPA id <[e-mail]> for [e-mail]; Tue, 13 Aug 2002 12:17:07 +0900 (KST)
Date: Tue, 13 Aug 2002 08:38:45 +0530
From: Manav Bhatia <[e-mail]>
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l restart
To: Jeffrey Haas <[e-mail]>, [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <003101c24276$bde1a110$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Hi Jeff,

|
| To give just one example, say a speaker is about to hit its timeout
| to send a keepalive.  In place of the keepalive, it sends a route
| refresh message.  Should the FSM treat the route refresh in the
| same sense that a keepalive or an update would be treated for
| purposes of resetting the relevant timers?

IMHO Yes.
Infact i had proposed this in a mail thread some time back wherein I stated
that we include other BGP messages (Route Refresh, Dynamic Capability,
INFORM) which when received by the local system should act as surrogate for
the KEEPALIVE messages it would expect from the remote end. The local
system upon receiving such messages should then restart its Hold Timer.

Is there any problem with this?

| --
| Jeff Haas
| NextHop Technologies

Regards,
Manav



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA25015 for <[e-mail]>; Mon, 12 Aug 2002 11:28:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id AC3E39125E; Mon, 12 Aug 2002 11:28:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7BF5B9125F; Mon, 12 Aug 2002 11:28:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1EB549125E for <[e-mail]>; Mon, 12 Aug 2002 11:28:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0A6A45DE14; Mon, 12 Aug 2002 11:28:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cmail.packetcom.com (unknown [63.108.173.139]) by segue.merit.edu (Postfix) with ESMTP id A553C5DE10 for <[e-mail]>; Mon, 12 Aug 2002 11:28:02 -0400 (EDT)
Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ACD05881 (AUTH [e-mail]); Mon, 12 Aug 2002 08:28:01 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 12 Aug 2002 10:27:39 -0700
From: Jeff Pickering <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: bgp route oscillation]
Content-Type: multipart/mixed; boundary="------------77F398A660CAF1D028C64F87"
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.
--------------77F398A660CAF1D028C64F87
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------77F398A660CAF1D028C64F87
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Message-ID: <[e-mail]>
Date: Thu, 08 Aug 2002 11:17:53 -0700
From: Jeff Pickering <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: bgp route oscillation
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Just a question on draft-walton as an oscillation solution:

Using the example 2.1 in RFC345, we have in router Ra 3 routes in
step 3):

                 AS-Path         MED        IGP-cost
x               6 100              0              13
y               6 100              1               4
z               10 100             10            5

Oscillations in this example occur because the preference rules result
in
a non-deterministic choice, more specifically because the rules result
in
choices between more than 2 routes that are non-transitive. In the
example
above:

x beats y
y beats z
z beats x

The proposal in draft-walton suggests avoiding oscillation by enabling
Ra
to always have knowledge of all three routes. However, this seems
insufficient since x can be chosen best one time and z chosen another.
To prevent oscillation,
it would seem an additional requirement to always choose the same route,
given
the same set of choices.

If this requirement is applied to the rfc3345 example, and the
draft-walton
solution applied, Ra could always choose route z as best and prevent
oscilliation.
It could also choose x as best with the same result.

But this leads me to question the usefullness of the
neighbor-as-best-path
information. For the example in question, if we required Ra to make
consistent
choices, and dont use the proposed new info, in step 1) we say y beats
z.
Step 2 remains unchanged. In step 3), we force consistency and say y
still beats z.
x then beats y so we send send a withdraw to Rd. This breaks the loop
and
there is no oscillation.

So, it would seem that the draft-walton solution is neither necessary
nor sufficient
unless of course I am missing something, which seems likely. Can anyone
enlighten me?

Jeff

--------------77F398A660CAF1D028C64F87--



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA24914 for <[e-mail]>; Mon, 12 Aug 2002 11:25:15 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BB89391255; Mon, 12 Aug 2002 11:24:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B3C69125E; Mon, 12 Aug 2002 11:24:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 770E391255 for <[e-mail]>; Mon, 12 Aug 2002 11:24:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 486595DE14; Mon, 12 Aug 2002 11:24:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id D28635DFE7 for <[e-mail]>; Mon, 12 Aug 2002 11:24:45 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7CFOjc27613 for [e-mail]; Mon, 12 Aug 2002 11:24:45 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7CFOg127606 for <[e-mail]>; Mon, 12 Aug 2002 11:24:42 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7CFOgI20533 for [e-mail]; Mon, 12 Aug 2002 11:24:42 -0400 (EDT)
Date: Mon, 12 Aug 2002 11:24:42 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Re: Proposal to support dynamic capability negotiation of graceful restart
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Aug 06, 2002 at 11:52:36AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

All strictly IMO:

On Tue, Aug 06, 2002 at 11:52:36AM -0700, Yakov Rekhter wrote:
> > How about adding the text to the Dynamic Capability draft?
> 
> That would be much better.

I think it would be better to keep the dynamic capability draft
as simple as possible.  It should, however, discuss that for
each capability that can be dynamically altered that the
implications to the FSM and other issues must be documented.

> It depends. For capabilities that are ahead (along the standards
> track) of dynamic capability, documenting this should probably
> go into either (a) dynamic capability negotiation draft, or (b)
> a separate draft. For capabilities that would be behind the dynamic
> capability documenting this should go into the capability draft.

I'd suggest that, for "stable" features that are unlikely to get
an updated rfc any time soon that a ID be done to document the
relevant implications to that feature.  For features in need of
an update, it should go in the update.

> Yakov.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA24246 for <[e-mail]>; Mon, 12 Aug 2002 11:04:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3165591209; Mon, 12 Aug 2002 11:03:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 015FD91213; Mon, 12 Aug 2002 11:03:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5FD6C91209 for <[e-mail]>; Mon, 12 Aug 2002 11:03:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4CB555DE0B; Mon, 12 Aug 2002 11:03:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id BD86A5DDE0 for <[e-mail]>; Mon, 12 Aug 2002 11:03:32 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g7CF3VM26811 for [e-mail]; Mon, 12 Aug 2002 11:03:31 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g7CF3S126804 for <[e-mail]>; Mon, 12 Aug 2002 11:03:28 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g7CF3Sn20452 for [e-mail]; Mon, 12 Aug 2002 11:03:28 -0400 (EDT)
Date: Mon, 12 Aug 2002 11:03:28 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l restart
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Aug 06, 2002 at 03:05:30PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Aug 06, 2002 at 03:05:30PM -0400, Abarbanel, Benjamin wrote:
> Is it fair to assume that if a capability is "dynamic" in nature than it 
> can be activated or deactived "dynamically" without disturbance to the
> peering session or FSM state.

My guess would be "no".
However, this is hard to discuss because most of the recent
extensions (route refresh, etc.) don't bother to document their
FSM implications.

To give just one example, say a speaker is about to hit its timeout
to send a keepalive.  In place of the keepalive, it sends a route
refresh message.  Should the FSM treat the route refresh in the
same sense that a keepalive or an update would be treated for
purposes of resetting the relevant timers?

> Ben

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA08931 for <[e-mail]>; Fri, 9 Aug 2002 13:49:27 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5E21D9123B; Fri,  9 Aug 2002 13:46:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A449D91321; Fri,  9 Aug 2002 13:45:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EA99D9123B for <[e-mail]>; Fri,  9 Aug 2002 13:45:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4E1CB5DEEF; Fri,  9 Aug 2002 13:45:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id ED1855DDFE for <[e-mail]>; Fri,  9 Aug 2002 13:45:47 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g79HjlS27556 for [e-mail]; Fri, 9 Aug 2002 13:45:47 -0400 (EDT) (envelope-from [e-mail])
Received: from nexthop.com (triscuit.nexthop.com [64.211.218.61]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g79Hjh127549 for <[e-mail]>; Fri, 9 Aug 2002 13:45:43 -0400 (EDT) (envelope-from [e-mail])
Received: (from swright@localhost) by nexthop.com (8.11.0/8.11.0) id g79HjhE11265 for [e-mail]; Fri, 9 Aug 2002 13:45:43 -0400 (EDT)
Date: Fri, 9 Aug 2002 13:45:43 -0400
From: Shane Wright <[e-mail]>
To: [e-mail]
Subject: RFC2918 comments
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Hi All,

I have a couple of comments about the route refresh document:

1) There is no defined behavior for a malformed route refresh message. 
Possible solutions could be to send a Cease notification or introducing a
new error code for the route refresh message.

2) From section 4:

   A BGP speaker may send a ROUTE-REFRESH message to its peer only if it
   has received the Route Refresh Capability from its peer.  The <AFI,
   SAFI> carried in such a message should be one of the <AFI, SAFI> that
   the peer has advertised to the speaker at the session establishment
   time via capability advertisement.

   If a BGP speaker receives from its peer a ROUTE-REFRESH message with
   the <AFI, SAFI> that the speaker didn't advertise to the peer at the
   session establishment time via capability advertisement, the speaker
   shall ignore such a message. 

This wording would seem to add the requirement that multiprotocol
capabilities are necessary for route refresh, even for the IPv4 unicast case. 
Adding text to address the special case of IPv4 unicast announced in the
non-multiprotocol fashion would be helpful here.

--
Shane Wright


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA08435 for <[e-mail]>; Wed, 7 Aug 2002 15:36:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 519309120F; Wed,  7 Aug 2002 15:35:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2170491231; Wed,  7 Aug 2002 15:35:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 216729120F for <[e-mail]>; Wed,  7 Aug 2002 15:35:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EC1795DE16; Wed,  7 Aug 2002 15:35:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id 2FFFD5DDCE for <[e-mail]>; Wed,  7 Aug 2002 15:35:43 -0400 (EDT)
Received: from [171.69.182.142] (dhcp-171-69-182-142.cisco.com [171.69.182.142]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA14297 for <[e-mail]>; Wed, 7 Aug 2002 15:35:42 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a23b977261bba7d@[171.69.182.142]>
Date: Wed, 7 Aug 2002 15:35:39 -0400
To: [e-mail]
From: "John G. Scudder" <[e-mail]>
Subject: Graceful Restart implementation report
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Folks,

As part of advancing BGP Graceful Restart, we need to provide an 
implementation report.  With this in mind I am asking folks who have 
implemented BGP Graceful Restart and are willing to participate in 
the report to drop me an e-mail ([e-mail]).

Participation in the report means answering a small number of 
questions.  While the report itself is going to be public, the 
identity of the folks who participate in the report need not be 
public.

Thanks in advance,

--John


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA24444 for <[e-mail]>; Tue, 6 Aug 2002 17:53:36 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7F7179127E; Tue,  6 Aug 2002 17:53:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 512F3912B0; Tue,  6 Aug 2002 17:53:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D1BD49127E for <[e-mail]>; Tue,  6 Aug 2002 17:53:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B89C15DDB2; Tue,  6 Aug 2002 17:53:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 783B25DDA8 for <[e-mail]>; Tue,  6 Aug 2002 17:53:14 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6KFPPX>; Tue, 6 Aug 2002 17:53:14 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: capability 
Date: Tue, 6 Aug 2002 17:53:13 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Great.  So there is plenty of time till the next round.  

Thanks.

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Tuesday, August 06, 2002 4:43 PM
To: Natale, Jonathan
Cc: '[e-mail]'
Subject: Re: capability 

Jonathan,

> I would like to propose:
> 
> >"If a BGP speaker that supports a certain capability determines that
> >    its peer doesn't support this capability, the speaker MAY send a
> >    NOTIFICATION message to the peer, and terminate peering (see Section
> >    "Extensions to Error Handling" for more details). The Error Subcode
> >    in the message is set to Unsupported Capability. The message SHOULD
> >    contain the capability (capabilities) that causes the speaker to send
> >    the message.  The decision to send the message and terminate peering
> >    is local to the speaker. If terminated, such peering SHOULD NOT be
> >    re-established automatically."
> >
> >be changed to:
> >
> >"If a BGP speaker that **does not want its peer to support** a certain 
> >capability determines that
> >    its peer **does** support this capability, the speaker MAY send a
> >    NOTIFICATION message to the peer, and terminate peering (see Section
> >    "Extensions to Error Handling" for more details). The Error Subcode
> >    in the message is set to Unsupported Capability. The message SHOULD
> >    contain the capability (capabilities) that causes the speaker to send
> >    the message.  The decision to send the message and terminate peering
> >    is local to the speaker. **If terminated, the peer MAY re-open the
> >    connection without the offending capability-this is known as
capability
> >    negotiation.**"
> >
> >
> >...comments???

Too late for the current round (see attached).

Yakov.
--------------------------------------------------------------------

Date:    Fri, 03 May 2002 15:40:03 EDT
To:      IETF-Announce: ;
cc:      RFC Editor <[e-mail]>, Internet Architecture Board
<iab@isi.
     ***edu>,
	 [e-mail]
From:    The IESG <[e-mail]>
Subject: Protocol Action: Capabilities Advertisement with BGP-4 to Draft
Standa
     ***rd



The IESG has approved the Internet-Draft 'Capabilities Advertisement
with BGP-4' <draft-ietf-idr-rfc2842bis-02.txt> as a Draft Standard.
This action will obsolete RFC2842. This document is the product of the
Inter-Domain Routing Working Group.  The IESG contact persons are Bill
Fenner and Randy Bush.

 
Technical Summary
 
This document defines an Optional BGP-4 HELLO Parameter, called
  Capabilities, that facilitates introduction of new capabilities
  in BGP by providing graceful capability advertisement without
  requiring that the BGP peering be terminated if new capabilities
  are not supported.
 
Working Group Summary
 
  There was broad consensus in the IDR WG to advance this document
  to Draft Standard.
 
Protocol Quality
 
  Bill Fenner reviewed the specification for the IESG. This
  protocol is widely implemented, as it is the basis for many
  heavily used BGP-4 extensions, such as the Multiprotocol
  Extensions (RFC 2858) and Route Refresh (RFC 2918).


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA22320 for <[e-mail]>; Tue, 6 Aug 2002 16:46:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0F85091298; Tue,  6 Aug 2002 16:43:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D32A8912AE; Tue,  6 Aug 2002 16:43:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 116F491298 for <[e-mail]>; Tue,  6 Aug 2002 16:43:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E5CFE5DDA8; Tue,  6 Aug 2002 16:43:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 5CD075DD8F for <[e-mail]>; Tue,  6 Aug 2002 16:43:21 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g76KhKm13201; Tue, 6 Aug 2002 13:43:20 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: capability 
In-Reply-To: Your message of "Tue, 06 Aug 2002 16:18:47 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 06 Aug 2002 13:43:20 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> I would like to propose:
> 
> >"If a BGP speaker that supports a certain capability determines that
> >    its peer doesn't support this capability, the speaker MAY send a
> >    NOTIFICATION message to the peer, and terminate peering (see Section
> >    "Extensions to Error Handling" for more details). The Error Subcode
> >    in the message is set to Unsupported Capability. The message SHOULD
> >    contain the capability (capabilities) that causes the speaker to send
> >    the message.  The decision to send the message and terminate peering
> >    is local to the speaker. If terminated, such peering SHOULD NOT be
> >    re-established automatically."
> >
> >be changed to:
> >
> >"If a BGP speaker that **does not want its peer to support** a certain 
> >capability determines that
> >    its peer **does** support this capability, the speaker MAY send a
> >    NOTIFICATION message to the peer, and terminate peering (see Section
> >    "Extensions to Error Handling" for more details). The Error Subcode
> >    in the message is set to Unsupported Capability. The message SHOULD
> >    contain the capability (capabilities) that causes the speaker to send
> >    the message.  The decision to send the message and terminate peering
> >    is local to the speaker. **If terminated, the peer MAY re-open the
> >    connection without the offending capability-this is known as capability
> >    negotiation.**"
> >
> >
> >...comments???

Too late for the current round (see attached).

Yakov.
--------------------------------------------------------------------

Date:    Fri, 03 May 2002 15:40:03 EDT
To:      IETF-Announce: ;
cc:      RFC Editor <[e-mail]>, Internet Architecture Board <iab@isi.
     ***edu>,
	 [e-mail]
From:    The IESG <[e-mail]>
Subject: Protocol Action: Capabilities Advertisement with BGP-4 to Draft Standa
     ***rd



The IESG has approved the Internet-Draft 'Capabilities Advertisement
with BGP-4' <draft-ietf-idr-rfc2842bis-02.txt> as a Draft Standard.
This action will obsolete RFC2842. This document is the product of the
Inter-Domain Routing Working Group.  The IESG contact persons are Bill
Fenner and Randy Bush.

 
Technical Summary
 
This document defines an Optional BGP-4 HELLO Parameter, called
  Capabilities, that facilitates introduction of new capabilities
  in BGP by providing graceful capability advertisement without
  requiring that the BGP peering be terminated if new capabilities
  are not supported.
 
Working Group Summary
 
  There was broad consensus in the IDR WG to advance this document
  to Draft Standard.
 
Protocol Quality
 
  Bill Fenner reviewed the specification for the IESG. This
  protocol is widely implemented, as it is the basis for many
  heavily used BGP-4 extensions, such as the Multiprotocol
  Extensions (RFC 2858) and Route Refresh (RFC 2918).



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA21422 for <[e-mail]>; Tue, 6 Aug 2002 16:19:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6035D912B3; Tue,  6 Aug 2002 16:18:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60215912BF; Tue,  6 Aug 2002 16:18:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0845B912B3 for <[e-mail]>; Tue,  6 Aug 2002 16:18:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E580E5DDB2; Tue,  6 Aug 2002 16:18:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 944EC5DD8F for <[e-mail]>; Tue,  6 Aug 2002 16:18:48 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6KFPGP>; Tue, 6 Aug 2002 16:18:48 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: capability
Date: Tue, 6 Aug 2002 16:18:47 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I would like to propose:

>"If a BGP speaker that supports a certain capability determines that
>    its peer doesn't support this capability, the speaker MAY send a
>    NOTIFICATION message to the peer, and terminate peering (see Section
>    "Extensions to Error Handling" for more details). The Error Subcode
>    in the message is set to Unsupported Capability. The message SHOULD
>    contain the capability (capabilities) that causes the speaker to send
>    the message.  The decision to send the message and terminate peering
>    is local to the speaker. If terminated, such peering SHOULD NOT be
>    re-established automatically."
>
>be changed to:
>
>"If a BGP speaker that **does not want its peer to support** a certain 
>capability determines that
>    its peer **does** support this capability, the speaker MAY send a
>    NOTIFICATION message to the peer, and terminate peering (see Section
>    "Extensions to Error Handling" for more details). The Error Subcode
>    in the message is set to Unsupported Capability. The message SHOULD
>    contain the capability (capabilities) that causes the speaker to send
>    the message.  The decision to send the message and terminate peering
>    is local to the speaker. **If terminated, the peer MAY re-open the
>    connection without the offending capability-this is known as capability
>    negotiation.**"
>
>
>...comments???


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA19022 for <[e-mail]>; Tue, 6 Aug 2002 15:08:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 34ECE912A8; Tue,  6 Aug 2002 15:08:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90C3A912A4; Tue,  6 Aug 2002 15:08:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 54F76912A3 for <[e-mail]>; Tue,  6 Aug 2002 15:07:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3D9DD5DD99; Tue,  6 Aug 2002 15:07:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id B84B95DD8F for <[e-mail]>; Tue,  6 Aug 2002 15:07:32 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA14345; Tue, 6 Aug 2002 15:07:30 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA09415; Tue, 6 Aug 2002 15:07:31 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3W993L5P>; Tue, 6 Aug 2002 15:07:30 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, Bruno Rijsman <[e-mail]>
Cc: [e-mail]
Subject: RE: Proposal to support dynamic capability negotiation of gracefu l restart 
Date: Tue, 6 Aug 2002 15:05:30 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hi All,

Is it fair to assume that if a capability is "dynamic" in nature than it 
can be activated or deactived "dynamically" without disturbance to the
peering session or FSM state. If not, then the capability should be marked
as "static" only to be initiated at session initialization time. 

Would this clear up all the assumptions?

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Tuesday, August 06, 2002 2:53 PM
> To: Bruno Rijsman
> Cc: [e-mail]
> Subject: Re: Proposal to support dynamic capability negotiation of
> graceful restart 
> 
> 
> Bruno,
> 
> > Okay, no need to hold up the graceful restart draft for this if
> > it is that far along.
> > 
> > How about adding the text to the Dynamic Capability draft?
> 
> That would be much better.
> 
> > In general, what is the propor place for documenting "Dynamic
> > negotation of capabilty Foo"?  Is is the draft for Foo, the
> > dynamic capability negotiation draft, or some other place?
> 
> It depends. For capabilities that are ahead (along the standards
> track) of dynamic capability, documenting this should probably
> go into either (a) dynamic capability negotiation draft, or (b)
> a separate draft. For capabilities that would be behind the dynamic
> capability documenting this should go into the capability draft.
> 
> Yakov.
> 
> > 
> > 
> > 
> > >From: Yakov Rekhter <[e-mail]>
> > >To: "Bruno Rijsman" <[e-mail]>
> > >CC: [e-mail]
> > >Subject: Re: Proposal to support dynamic capability 
> negotiation of graceful 
> > >restart Date: Tue, 06 Aug 2002 11:23:55 -0700
> > >
> > >Bruno,
> > >
> > >If we are to insert the text you suggested below into the graceful
> > >restart draft, we would create dependency on the dynamic 
> capacbility
> > >negotiation.  Please note that while graceful restart draft already
> > >passed the working group last call and is ready for the IESG last
> > >call, the dynamic capability negotiation didn't even pass the
> > >working group last call.
> > >
> > >Yakov.
> > >
> > > > All of the few people who responded to my question 
> "should graceful
> > > > restart be dynamically negotiable" answered "yes" and 
> they gave two
> > > > reasons:
> > > >
> > > > 1. It is convenient from an operational point of view 
> to be able to
> > > >    enable graceful restart or to change the restart 
> timer without
> > > >    needing to bounce the session.
> > > >
> > > > 2. What is the point of being able to dynamically 
> advertise address
> > > >    families using multi-protocol dynamic capability 
> negotiation if you
> > > >    cannot also dynamically advertise the ability to 
> preserve forwarding
> > > >    state for those address families using 
> graceful-restart dynamic
> > > >    capability negotiation?
> > > >
> > > > Thus, I'd like to propose that the following text be added to
> > > > draft-ietf-idr-restart:
> > > >
> > > > ---< Start of proposed text for draft-ietf-idr-restart 
> >---------------
> > > >
> > > > X. Dynamic capability negotiation.
> > > >
> > > > The graceful-restart capability can be dynamically negotiated as
> > > > described in [dyn-cap].
> > > >
> > > > The < AFI, SAFI, Flags for Address Family > tuples in 
> the graceful-
> > > > restart capability in CAPABILITY messages with action set to
> > > > "advertise" are not cummulative: the information in 
> such an advertised
> > > > graceful-restart capability invalidates and replaces all of the
> > > > information in all graceful-restart capabilities in 
> previously sent
> > > > OPEN and CAPABILITY messages.
> > > >
> > > > The graceful-restart capability in a CAPABILITY message 
> with action set
> > > > to "withdraw" MUST NOT contain any < AFI, SAFI, Flags 
> for Address
> > > > Family > tuples. If there are any < AFI, SAFI, Flags for Address
> > > > Family > tuples a NOTIFICATION message MUST be sent with error
> > > > code "CAPABILITY Message Error", error subcode 
> "Malformed Capability
> > > > Value", and the offending graceful-restart capability 
> in the data field
> > > > of the NOTIFICATION.
> > > >
> > > > A router which advertises the 
> dynamic-capability-negotiation capability
> > > >
> > > > 1. MUST send an End-of-RIB marker when it completes 
> sending the initial
> > > >    updates even if it has not received the 
> graceful-restart capability
> > > >    from its peer at that point in time.
> > > >
> > > > 2. MUST be prepared to receive an End-of-RIB marker 
> even if it has not
> > > >    advertised the graceful-restart capability to its 
> peer at that
> > > >    point in time.
> > > >
> > > > This is to avoid confusion about the state of 
> convergence if graceful
> > > > restart is dynamically renegotiated later on.
> > > >
> > > > Reference:
> > > >
> > > > [dyn-cap] draft-ietf-idr-dynamic-cap-02.txt
> > > >
> > > > ---< End of proposed text for draft-ietf-idr-restart 
> >-----------------
> > > >
> > > >
> > >
> > > > 
> _________________________________________________________________
> > > > Send and receive Hotmail on your mobile device: 
http://mobile.msn.com
> > >
> 
> 
> 
> 
> _________________________________________________________________
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA18417 for <[e-mail]>; Tue, 6 Aug 2002 14:53:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4425D9129D; Tue,  6 Aug 2002 14:52:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 104A19129E; Tue,  6 Aug 2002 14:52:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C112C9129D for <[e-mail]>; Tue,  6 Aug 2002 14:52:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id ADECD5DDA6; Tue,  6 Aug 2002 14:52:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 57AAD5DD8F for <[e-mail]>; Tue,  6 Aug 2002 14:52:45 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g76Iqam95510; Tue, 6 Aug 2002 11:52:36 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Bruno Rijsman" <[e-mail]>
Cc: [e-mail]
Subject: Re: Proposal to support dynamic capability negotiation of graceful restart 
In-Reply-To: Your message of "Tue, 06 Aug 2002 14:43:08 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 06 Aug 2002 11:52:36 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Bruno,

> Okay, no need to hold up the graceful restart draft for this if
> it is that far along.
> 
> How about adding the text to the Dynamic Capability draft?

That would be much better.

> In general, what is the propor place for documenting "Dynamic
> negotation of capabilty Foo"?  Is is the draft for Foo, the
> dynamic capability negotiation draft, or some other place?

It depends. For capabilities that are ahead (along the standards
track) of dynamic capability, documenting this should probably
go into either (a) dynamic capability negotiation draft, or (b)
a separate draft. For capabilities that would be behind the dynamic
capability documenting this should go into the capability draft.

Yakov.

> 
> 
> 
> >From: Yakov Rekhter <[e-mail]>
> >To: "Bruno Rijsman" <[e-mail]>
> >CC: [e-mail]
> >Subject: Re: Proposal to support dynamic capability negotiation of graceful 
> >restart Date: Tue, 06 Aug 2002 11:23:55 -0700
> >
> >Bruno,
> >
> >If we are to insert the text you suggested below into the graceful
> >restart draft, we would create dependency on the dynamic capacbility
> >negotiation.  Please note that while graceful restart draft already
> >passed the working group last call and is ready for the IESG last
> >call, the dynamic capability negotiation didn't even pass the
> >working group last call.
> >
> >Yakov.
> >
> > > All of the few people who responded to my question "should graceful
> > > restart be dynamically negotiable" answered "yes" and they gave two
> > > reasons:
> > >
> > > 1. It is convenient from an operational point of view to be able to
> > >    enable graceful restart or to change the restart timer without
> > >    needing to bounce the session.
> > >
> > > 2. What is the point of being able to dynamically advertise address
> > >    families using multi-protocol dynamic capability negotiation if you
> > >    cannot also dynamically advertise the ability to preserve forwarding
> > >    state for those address families using graceful-restart dynamic
> > >    capability negotiation?
> > >
> > > Thus, I'd like to propose that the following text be added to
> > > draft-ietf-idr-restart:
> > >
> > > ---< Start of proposed text for draft-ietf-idr-restart >---------------
> > >
> > > X. Dynamic capability negotiation.
> > >
> > > The graceful-restart capability can be dynamically negotiated as
> > > described in [dyn-cap].
> > >
> > > The < AFI, SAFI, Flags for Address Family > tuples in the graceful-
> > > restart capability in CAPABILITY messages with action set to
> > > "advertise" are not cummulative: the information in such an advertised
> > > graceful-restart capability invalidates and replaces all of the
> > > information in all graceful-restart capabilities in previously sent
> > > OPEN and CAPABILITY messages.
> > >
> > > The graceful-restart capability in a CAPABILITY message with action set
> > > to "withdraw" MUST NOT contain any < AFI, SAFI, Flags for Address
> > > Family > tuples. If there are any < AFI, SAFI, Flags for Address
> > > Family > tuples a NOTIFICATION message MUST be sent with error
> > > code "CAPABILITY Message Error", error subcode "Malformed Capability
> > > Value", and the offending graceful-restart capability in the data field
> > > of the NOTIFICATION.
> > >
> > > A router which advertises the dynamic-capability-negotiation capability
> > >
> > > 1. MUST send an End-of-RIB marker when it completes sending the initial
> > >    updates even if it has not received the graceful-restart capability
> > >    from its peer at that point in time.
> > >
> > > 2. MUST be prepared to receive an End-of-RIB marker even if it has not
> > >    advertised the graceful-restart capability to its peer at that
> > >    point in time.
> > >
> > > This is to avoid confusion about the state of convergence if graceful
> > > restart is dynamically renegotiated later on.
> > >
> > > Reference:
> > >
> > > [dyn-cap] draft-ietf-idr-dynamic-cap-02.txt
> > >
> > > ---< End of proposed text for draft-ietf-idr-restart >-----------------
> > >
> > >
> >
> > > _________________________________________________________________
> > > Send and receive Hotmail on your mobile device: http://mobile.msn.com
> > >
> 
> 
> 
> 
> _________________________________________________________________
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA18086 for <[e-mail]>; Tue, 6 Aug 2002 14:43:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CB4299129B; Tue,  6 Aug 2002 14:43:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 502DF912A2; Tue,  6 Aug 2002 14:43:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B3C559129B for <[e-mail]>; Tue,  6 Aug 2002 14:43:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 93E6F5DDB1; Tue,  6 Aug 2002 14:43:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from hotmail.com (f138.law4.hotmail.com [216.33.149.138]) by segue.merit.edu (Postfix) with ESMTP id 2F9AE5DDA7 for <[e-mail]>; Tue,  6 Aug 2002 14:43:09 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Aug 2002 11:43:08 -0700
Received: from 65.194.140.2 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 06 Aug 2002 18:43:08 GMT
X-Originating-IP: [65.194.140.2]
From: "Bruno Rijsman" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Proposal to support dynamic capability negotiation of graceful restart
Date: Tue, 06 Aug 2002 14:43:08 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 06 Aug 2002 18:43:08.0835 (UTC) FILETIME=[1BE86F30:01C23D79]
Sender: [e-mail]
Precedence: bulk

Okay, no need to hold up the graceful restart draft for this if
it is that far along.

How about adding the text to the Dynamic Capability draft?

In general, what is the propor place for documenting "Dynamic
negotation of capabilty Foo"?  Is is the draft for Foo, the
dynamic capability negotiation draft, or some other place?



>From: Yakov Rekhter <[e-mail]>
>To: "Bruno Rijsman" <[e-mail]>
>CC: [e-mail]
>Subject: Re: Proposal to support dynamic capability negotiation of graceful 
>restart Date: Tue, 06 Aug 2002 11:23:55 -0700
>
>Bruno,
>
>If we are to insert the text you suggested below into the graceful
>restart draft, we would create dependency on the dynamic capacbility
>negotiation.  Please note that while graceful restart draft already
>passed the working group last call and is ready for the IESG last
>call, the dynamic capability negotiation didn't even pass the
>working group last call.
>
>Yakov.
>
> > All of the few people who responded to my question "should graceful
> > restart be dynamically negotiable" answered "yes" and they gave two
> > reasons:
> >
> > 1. It is convenient from an operational point of view to be able to
> >    enable graceful restart or to change the restart timer without
> >    needing to bounce the session.
> >
> > 2. What is the point of being able to dynamically advertise address
> >    families using multi-protocol dynamic capability negotiation if you
> >    cannot also dynamically advertise the ability to preserve forwarding
> >    state for those address families using graceful-restart dynamic
> >    capability negotiation?
> >
> > Thus, I'd like to propose that the following text be added to
> > draft-ietf-idr-restart:
> >
> > ---< Start of proposed text for draft-ietf-idr-restart >---------------
> >
> > X. Dynamic capability negotiation.
> >
> > The graceful-restart capability can be dynamically negotiated as
> > described in [dyn-cap].
> >
> > The < AFI, SAFI, Flags for Address Family > tuples in the graceful-
> > restart capability in CAPABILITY messages with action set to
> > "advertise" are not cummulative: the information in such an advertised
> > graceful-restart capability invalidates and replaces all of the
> > information in all graceful-restart capabilities in previously sent
> > OPEN and CAPABILITY messages.
> >
> > The graceful-restart capability in a CAPABILITY message with action set
> > to "withdraw" MUST NOT contain any < AFI, SAFI, Flags for Address
> > Family > tuples. If there are any < AFI, SAFI, Flags for Address
> > Family > tuples a NOTIFICATION message MUST be sent with error
> > code "CAPABILITY Message Error", error subcode "Malformed Capability
> > Value", and the offending graceful-restart capability in the data field
> > of the NOTIFICATION.
> >
> > A router which advertises the dynamic-capability-negotiation capability
> >
> > 1. MUST send an End-of-RIB marker when it completes sending the initial
> >    updates even if it has not received the graceful-restart capability
> >    from its peer at that point in time.
> >
> > 2. MUST be prepared to receive an End-of-RIB marker even if it has not
> >    advertised the graceful-restart capability to its peer at that
> >    point in time.
> >
> > This is to avoid confusion about the state of convergence if graceful
> > restart is dynamically renegotiated later on.
> >
> > Reference:
> >
> > [dyn-cap] draft-ietf-idr-dynamic-cap-02.txt
> >
> > ---< End of proposed text for draft-ietf-idr-restart >-----------------
> >
> >
>
> > _________________________________________________________________
> > Send and receive Hotmail on your mobile device: http://mobile.msn.com
> >




_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA17908 for <[e-mail]>; Tue, 6 Aug 2002 14:37:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3685A91299; Tue,  6 Aug 2002 14:37:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9F989129A; Tue,  6 Aug 2002 14:37:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA02D91299 for <[e-mail]>; Tue,  6 Aug 2002 14:37:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B83215DD99; Tue,  6 Aug 2002 14:37:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 06D005DDB9 for <[e-mail]>; Tue,  6 Aug 2002 14:37:33 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g76IbNg13700; Tue, 6 Aug 2002 14:37:23 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g76IbK113692; Tue, 6 Aug 2002 14:37:20 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g76IbKf12824; Tue, 6 Aug 2002 14:37:20 -0400 (EDT)
Date: Tue, 6 Aug 2002 14:37:20 -0400
From: Jeffrey Haas <[e-mail]>
To: Bruno Rijsman <[e-mail]>
Cc: [e-mail]
Subject: Re: Proposal to support dynamic capability negotiation of graceful restart
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Aug 06, 2002 at 01:55:31PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Aug 06, 2002 at 01:55:31PM -0400, Bruno Rijsman wrote:
> A router which advertises the dynamic-capability-negotiation capability
> 
> 1. MUST send an End-of-RIB marker when it completes sending the initial
>    updates even if it has not received the graceful-restart capability
>    from its peer at that point in time.
> 
> 2. MUST be prepared to receive an End-of-RIB marker even if it has not
>    advertised the graceful-restart capability to its peer at that
>    point in time.

While I don't find either of these two problematic since the
current BGP spec allows for empty UPDATE messages, I'm concerned
about the precedent this sets.

Advertising (or not advertising) capabilities implicitly states
that some messages are either valid or invalid for that speaker's
FSM.  For example, not advertising route refresh as a capability
means that you really should treat a route refresh message as
a FSM error and close the connection - or send a bad message type
if you don't support route refresh at all.

I would be more in favor of making things valid for some transition
period to give time for a dynamic capability message to move
down the pipeline, get flushed from the speaker's buffers, etc. etc.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA16522 for <[e-mail]>; Tue, 6 Aug 2002 13:56:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5E9A891281; Tue,  6 Aug 2002 13:55:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2584191293; Tue,  6 Aug 2002 13:55:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 03B7A91281 for <[e-mail]>; Tue,  6 Aug 2002 13:55:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E53815DDC2; Tue,  6 Aug 2002 13:55:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from hotmail.com (f89.law4.hotmail.com [216.33.149.89]) by segue.merit.edu (Postfix) with ESMTP id A0D605DDC1 for <[e-mail]>; Tue,  6 Aug 2002 13:55:32 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Aug 2002 10:55:32 -0700
Received: from 65.194.140.2 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 06 Aug 2002 17:55:31 GMT
X-Originating-IP: [65.194.140.2]
From: "Bruno Rijsman" <[e-mail]>
To: [e-mail]
Subject: Proposal to support dynamic capability negotiation of graceful restart
Date: Tue, 06 Aug 2002 13:55:31 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 06 Aug 2002 17:55:32.0242 (UTC) FILETIME=[753EEF20:01C23D72]
Sender: [e-mail]
Precedence: bulk

All of the few people who responded to my question "should graceful
restart be dynamically negotiable" answered "yes" and they gave two
reasons:

1. It is convenient from an operational point of view to be able to
   enable graceful restart or to change the restart timer without
   needing to bounce the session.

2. What is the point of being able to dynamically advertise address
   families using multi-protocol dynamic capability negotiation if you
   cannot also dynamically advertise the ability to preserve forwarding
   state for those address families using graceful-restart dynamic
   capability negotiation?

Thus, I'd like to propose that the following text be added to
draft-ietf-idr-restart:

---< Start of proposed text for draft-ietf-idr-restart >---------------

X. Dynamic capability negotiation.

The graceful-restart capability can be dynamically negotiated as
described in [dyn-cap].

The < AFI, SAFI, Flags for Address Family > tuples in the graceful-
restart capability in CAPABILITY messages with action set to
"advertise" are not cummulative: the information in such an advertised
graceful-restart capability invalidates and replaces all of the
information in all graceful-restart capabilities in previously sent
OPEN and CAPABILITY messages.

The graceful-restart capability in a CAPABILITY message with action set
to "withdraw" MUST NOT contain any < AFI, SAFI, Flags for Address
Family > tuples. If there are any < AFI, SAFI, Flags for Address
Family > tuples a NOTIFICATION message MUST be sent with error
code "CAPABILITY Message Error", error subcode "Malformed Capability
Value", and the offending graceful-restart capability in the data field
of the NOTIFICATION.

A router which advertises the dynamic-capability-negotiation capability

1. MUST send an End-of-RIB marker when it completes sending the initial
   updates even if it has not received the graceful-restart capability
   from its peer at that point in time.

2. MUST be prepared to receive an End-of-RIB marker even if it has not
   advertised the graceful-restart capability to its peer at that
   point in time.

This is to avoid confusion about the state of convergence if graceful
restart is dynamically renegotiated later on.

Reference:

[dyn-cap] draft-ietf-idr-dynamic-cap-02.txt

---< End of proposed text for draft-ietf-idr-restart >-----------------



_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA11226 for <[e-mail]>; Fri, 2 Aug 2002 15:07:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2E8249121A; Fri,  2 Aug 2002 15:07:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F27C99121E; Fri,  2 Aug 2002 15:06:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC2739121A for <[e-mail]>; Fri,  2 Aug 2002 15:06:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C9C385DF40; Fri,  2 Aug 2002 15:06:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 812AE5DF3F for <[e-mail]>; Fri,  2 Aug 2002 15:06:58 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA08570; Fri, 2 Aug 2002 15:06:50 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA13657; Fri, 2 Aug 2002 15:06:52 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3W99LLD5>; Fri, 2 Aug 2002 15:06:50 -0400
Message-ID: <[e-mail]>
From: "Krishnan, Vijay G." <[e-mail]>
To: [e-mail], "'Bruno Rijsman'" <[e-mail]>
Subject: RE: Graceful-restart dynamically negotiable?
Date: Fri, 2 Aug 2002 15:06:40 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

If it is a dynamic capability, its useful for planned restarts also.

regards
Vijay


-----Original Message-----
From: Wei Cao [mailto:[e-mail]]
Sent: Friday, August 02, 2002 1:20 PM
To: [e-mail]; 'Bruno Rijsman'; Abarbanel, Benjamin
Subject: Re: Graceful-restart dynamically negotiable?


 Hi, Bruno;

      I agree the dynamic capability negotiation is useful to graceful
restart
capability advertisement.  The BGP speaker advertise the graceful restart
capability is just to express its ability  to preserve its forwarding state

when it do restart. And at the end of graceful restart procedure,  its
preserved
states will be replaced by the initial updates received from all its BGP
peers,
no matter its BGP peers cooperation or not.

   So, since no harm to its peers,  terminating the peer session when BGP
speaker detect one of its peer doesn't support graceful restart is  not a
good
behavior. Unnecessary withdrawn routes cause the routing flap and
affect the internet.

   Dynamic advertising the graceful restart capability without broken the
peering session can prevent this problem since the decision is done by
receiver side: ignore or accept.

    Regards;

  -- wei

"Abarbanel, Benjamin" wrote:

> My 1.99 cents worth:
>
> If the implementation can configure the Graceful-restart mechanism
> dynamically
> (after the peering session is up), they I would expect the dynamic
> capability negotiation to be able to negotiate the graceful-restart
> capability dynamically
> without causing a session reset.
>
> Ben
>
> > -----Original Message-----
> > From: Bruno Rijsman [mailto:[e-mail]]
> > Sent: Thursday, August 01, 2002 3:55 PM
> > To: [e-mail]
> > Subject: Graceful-restart dynamically negotiable?
> >
> >
> > Could we add some text to draft-ietf-idr-restart-05.txt to document
> > whether or not dynamic capability negotiation is supported for the
> > graceful-restart capability?
> >
> > I vaguely remember an earlier post on this mailing list stating that
> > graceful-restart cannot be dynamically negotiated. If that is the
> > case we only need to state this in the graceful restart draft.
> >
> > On the other hand, we may decide that dynamic capability negotiation
> > of graceful restart is useful. It allows us to turn graceful
> > restart on
> > or off and it allows us the change the restart-time without needing to
> > bounce the session. In this case we need to add some more
> > elaborate text
> > to draft-ietf-idr-restart-05.txt. Some issues to be covered
> > in this case
> > include:
> > - Are the < AFI, SAFI > values in the graceful-restart capability in a
> >   capability message cumulative or not?
> > - What to do about the End-of-RIB marker if graceful restart is turned
> >   on or off in the middle of a session?
> >
> > If there is enough interest in making graceful restart dynamically
> > negotiable I could propose some specific text.
> >
> > If there is no response I will assume that dynamic capability
> > negotiation of is not considered useful. In this case, receiving a
> > capability message containing the "graceful-restart"
> > capability message
> > will be considered an error and will result in a notification.
> >
> >
> >
> >
> > _________________________________________________________________
> > Chat with friends online, try MSN Messenger: http://messenger.msn.com
> >


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA07700 for <[e-mail]>; Fri, 2 Aug 2002 13:22:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DC9BF91213; Fri,  2 Aug 2002 13:21:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC79291214; Fri,  2 Aug 2002 13:21:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4B03391213 for <[e-mail]>; Fri,  2 Aug 2002 13:21:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 26FAD5DF38; Fri,  2 Aug 2002 13:21:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from gateway.ipinfusion.com (unknown [65.223.109.2]) by segue.merit.edu (Postfix) with ESMTP id ABDFF5DF37 for <[e-mail]>; Fri,  2 Aug 2002 13:21:44 -0400 (EDT)
Received: from ipinfusion.com (cway.ipinfusion.com [10.10.0.24] (may be forged)) by gateway.ipinfusion.com (8.11.0/8.11.0) with ESMTP id g72HIpc30699; Fri, 2 Aug 2002 10:18:51 -0700
Message-ID: <[e-mail]>
Date: Fri, 02 Aug 2002 10:20:24 -0700
From: Wei Cao <[e-mail]>
Reply-To: [e-mail]
Organization: IP Infusion Inc
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], "'Bruno Rijsman'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Subject: Re: Graceful-restart dynamically negotiable?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

 Hi, Bruno;

      I agree the dynamic capability negotiation is useful to graceful
restart
capability advertisement.  The BGP speaker advertise the graceful restart
capability is just to express its ability  to preserve its forwarding state

when it do restart. And at the end of graceful restart procedure,  its
preserved
states will be replaced by the initial updates received from all its BGP
peers,
no matter its BGP peers cooperation or not.

   So, since no harm to its peers,  terminating the peer session when BGP
speaker detect one of its peer doesn't support graceful restart is  not a
good
behavior. Unnecessary withdrawn routes cause the routing flap and
affect the internet.

   Dynamic advertising the graceful restart capability without broken the
peering session can prevent this problem since the decision is done by
receiver side: ignore or accept.

    Regards;

  -- wei

"Abarbanel, Benjamin" wrote:

> My 1.99 cents worth:
>
> If the implementation can configure the Graceful-restart mechanism
> dynamically
> (after the peering session is up), they I would expect the dynamic
> capability negotiation to be able to negotiate the graceful-restart
> capability dynamically
> without causing a session reset.
>
> Ben
>
> > -----Original Message-----
> > From: Bruno Rijsman [mailto:[e-mail]]
> > Sent: Thursday, August 01, 2002 3:55 PM
> > To: [e-mail]
> > Subject: Graceful-restart dynamically negotiable?
> >
> >
> > Could we add some text to draft-ietf-idr-restart-05.txt to document
> > whether or not dynamic capability negotiation is supported for the
> > graceful-restart capability?
> >
> > I vaguely remember an earlier post on this mailing list stating that
> > graceful-restart cannot be dynamically negotiated. If that is the
> > case we only need to state this in the graceful restart draft.
> >
> > On the other hand, we may decide that dynamic capability negotiation
> > of graceful restart is useful. It allows us to turn graceful
> > restart on
> > or off and it allows us the change the restart-time without needing to
> > bounce the session. In this case we need to add some more
> > elaborate text
> > to draft-ietf-idr-restart-05.txt. Some issues to be covered
> > in this case
> > include:
> > - Are the < AFI, SAFI > values in the graceful-restart capability in a
> >   capability message cumulative or not?
> > - What to do about the End-of-RIB marker if graceful restart is turned
> >   on or off in the middle of a session?
> >
> > If there is enough interest in making graceful restart dynamically
> > negotiable I could propose some specific text.
> >
> > If there is no response I will assume that dynamic capability
> > negotiation of is not considered useful. In this case, receiving a
> > capability message containing the "graceful-restart"
> > capability message
> > will be considered an error and will result in a notification.
> >
> >
> >
> >
> > _________________________________________________________________
> > Chat with friends online, try MSN Messenger: http://messenger.msn.com
> >



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA06178 for <[e-mail]>; Fri, 2 Aug 2002 12:36:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 430EA91212; Fri,  2 Aug 2002 12:35:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10E4A91213; Fri,  2 Aug 2002 12:35:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EEAE991212 for <[e-mail]>; Fri,  2 Aug 2002 12:35:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CCB435DEFD; Fri,  2 Aug 2002 12:35:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 44EA15DD8F for <[e-mail]>; Fri,  2 Aug 2002 12:35:44 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g72GZaU72417; Fri, 2 Aug 2002 12:35:36 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g72GZX172409; Fri, 2 Aug 2002 12:35:33 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g72GZWx17623; Fri, 2 Aug 2002 12:35:32 -0400 (EDT)
Date: Fri, 2 Aug 2002 12:35:32 -0400
From: Jeffrey Haas <[e-mail]>
To: Stephen Waters <[e-mail]>
Cc: [e-mail]
Subject: Re: Planned BGP Graceful Restart
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Aug 02, 2002 at 03:16:37PM +0100
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

If I recall the answer from the last time this was asked:
(and please wrap your lines! :-)

On Fri, Aug 02, 2002 at 03:16:37PM +0100, Stephen Waters wrote:
> When a manager wishes to force a planned bounce with BGP
> graceful-restart to glue the bits back together, it seems there is
> scope (not covered in the draft as far as I can see) to send a
> message to the peer to say that you are going down.

Said message is called a TCP RST or TCP FIN. :-)

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA01548 for <[e-mail]>; Fri, 2 Aug 2002 10:17:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B1F0C9120F; Fri,  2 Aug 2002 10:16:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7BB7291210; Fri,  2 Aug 2002 10:16:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 62F109120F for <[e-mail]>; Fri,  2 Aug 2002 10:16:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3BB255DF24; Fri,  2 Aug 2002 10:16:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from rs-eu-exc1.rs.riverstonenet.com (unknown [193.128.15.220]) by segue.merit.edu (Postfix) with ESMTP id C4A995DF0A for <[e-mail]>; Fri,  2 Aug 2002 10:16:41 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: Planned BGP Graceful Restart
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Fri, 2 Aug 2002 15:16:37 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Planned BGP Graceful Restart
Thread-Index: AcI6L/2bmRPl+qX1EdaEsQDAT0MeLQ==
From: "Stephen Waters" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id KAA01548

Hi,

When a manager wishes to force a planned bounce with BGP graceful-restart to glue the bits back together, it seems there is scope (not covered in the draft as far as I can see) to send a message to the peer to say that you are going down.  

This message would be a cue to the helper peer to start the previously exchanged Restart Time timer.

As things stand, it may be a long time (e.g. three minutes) before the helper peer spots that a peer has gone - at which point the restart timer is started. And then, possibly another three minutes later, spot that they have really gone.

In the spec, if a NOTIFICATION is received from a peer, normal session termination is followed, i.e. no graceful restart function is used. 

Perhaps this could be amended to include support for a new notification cause of 'Graceful Restart', which allow the helper to run graceful restart procedures instead?

Thanks, Steve. 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA27105 for <[e-mail]>; Thu, 1 Aug 2002 16:58:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 57EA991262; Thu,  1 Aug 2002 16:57:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2999E91272; Thu,  1 Aug 2002 16:57:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E13991262 for <[e-mail]>; Thu,  1 Aug 2002 16:57:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 293D15DEA7; Thu,  1 Aug 2002 16:57:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id D3C4C5DDAB for <[e-mail]>; Thu,  1 Aug 2002 16:57:47 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA23354; Thu, 1 Aug 2002 16:57:45 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22258; Thu, 1 Aug 2002 16:57:46 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3W99KFZX>; Thu, 1 Aug 2002 16:57:46 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Bruno Rijsman'" <[e-mail]>, [e-mail]
Subject: RE: Graceful-restart dynamically negotiable?
Date: Thu, 1 Aug 2002 16:57:44 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

My 1.99 cents worth:  

If the implementation can configure the Graceful-restart mechanism
dynamically
(after the peering session is up), they I would expect the dynamic
capability negotiation to be able to negotiate the graceful-restart
capability dynamically 
without causing a session reset.

Ben



> -----Original Message-----
> From: Bruno Rijsman [mailto:[e-mail]]
> Sent: Thursday, August 01, 2002 3:55 PM
> To: [e-mail]
> Subject: Graceful-restart dynamically negotiable?
> 
> 
> Could we add some text to draft-ietf-idr-restart-05.txt to document
> whether or not dynamic capability negotiation is supported for the
> graceful-restart capability?
> 
> I vaguely remember an earlier post on this mailing list stating that
> graceful-restart cannot be dynamically negotiated. If that is the
> case we only need to state this in the graceful restart draft.
> 
> On the other hand, we may decide that dynamic capability negotiation
> of graceful restart is useful. It allows us to turn graceful 
> restart on
> or off and it allows us the change the restart-time without needing to
> bounce the session. In this case we need to add some more 
> elaborate text
> to draft-ietf-idr-restart-05.txt. Some issues to be covered 
> in this case
> include:
> - Are the < AFI, SAFI > values in the graceful-restart capability in a
>   capability message cumulative or not?
> - What to do about the End-of-RIB marker if graceful restart is turned
>   on or off in the middle of a session?
> 
> If there is enough interest in making graceful restart dynamically
> negotiable I could propose some specific text.
> 
> If there is no response I will assume that dynamic capability
> negotiation of is not considered useful. In this case, receiving a
> capability message containing the "graceful-restart" 
> capability message
> will be considered an error and will result in a notification.
> 
> 
> 
> 
> _________________________________________________________________
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA25110 for <[e-mail]>; Thu, 1 Aug 2002 15:56:06 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A154A9122D; Thu,  1 Aug 2002 15:55:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F22B9123A; Thu,  1 Aug 2002 15:55:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 364AE9122D for <[e-mail]>; Thu,  1 Aug 2002 15:55:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1896C5DE87; Thu,  1 Aug 2002 15:55:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from hotmail.com (f140.law4.hotmail.com [216.33.149.140]) by segue.merit.edu (Postfix) with ESMTP id CA1EB5DDAB for <[e-mail]>; Thu,  1 Aug 2002 15:55:26 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 1 Aug 2002 12:55:26 -0700
Received: from 65.194.140.2 by lw4fd.law4.hotmail.msn.com with HTTP; Thu, 01 Aug 2002 19:55:26 GMT
X-Originating-IP: [65.194.140.2]
From: "Bruno Rijsman" <[e-mail]>
To: [e-mail]
Subject: Graceful-restart dynamically negotiable?
Date: Thu, 01 Aug 2002 15:55:26 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 01 Aug 2002 19:55:26.0436 (UTC) FILETIME=[61411240:01C23995]
Sender: [e-mail]
Precedence: bulk

Could we add some text to draft-ietf-idr-restart-05.txt to document
whether or not dynamic capability negotiation is supported for the
graceful-restart capability?

I vaguely remember an earlier post on this mailing list stating that
graceful-restart cannot be dynamically negotiated. If that is the
case we only need to state this in the graceful restart draft.

On the other hand, we may decide that dynamic capability negotiation
of graceful restart is useful. It allows us to turn graceful restart on
or off and it allows us the change the restart-time without needing to
bounce the session. In this case we need to add some more elaborate text
to draft-ietf-idr-restart-05.txt. Some issues to be covered in this case
include:
- Are the < AFI, SAFI > values in the graceful-restart capability in a
  capability message cumulative or not?
- What to do about the End-of-RIB marker if graceful restart is turned
  on or off in the middle of a session?

If there is enough interest in making graceful restart dynamically
negotiable I could propose some specific text.

If there is no response I will assume that dynamic capability
negotiation of is not considered useful. In this case, receiving a
capability message containing the "graceful-restart" capability message
will be considered an error and will result in a notification.




_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA24525 for <[e-mail]>; Thu, 1 Aug 2002 15:36:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7AA7E91226; Thu,  1 Aug 2002 15:36:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4C8CE9122D; Thu,  1 Aug 2002 15:36:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0B95691226 for <[e-mail]>; Thu,  1 Aug 2002 15:36:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E48B15DEA3; Thu,  1 Aug 2002 15:36:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 59BE55DDAB for <[e-mail]>; Thu,  1 Aug 2002 15:36:30 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g71JaUm89359 for <[e-mail]>; Thu, 1 Aug 2002 12:36:30 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: ext communities implementation report
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 01 Aug 2002 12:36:30 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

The attached is the announcement of the Internet Draft
that contains an implementation survey for BGP Extended Communities.

Yakov.
------- Forwarded Message

Date:    Tue, 30 Jul 2002 07:54:33 -0400
From:    [e-mail]
To:      IETF-Announce: ;
Subject: I-D ACTION:draft-rekhter-ext-communities-survey-01.txt

- --NextPart

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


	Title		: BGP Extended Communities Attribute - Implementation 
                          Survey
	Author(s)	: Y. Rekhter
	Filename	: draft-rekhter-ext-communities-survey-01.txt
	Pages		: 12
	Date		: 29-Jul-02
	
This document provides a survey of BGP-4 Extended Communities
implementations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rekhter-ext-communities-survey-01.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-rekhter-ext-communities-survey-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-rekhter-ext-communities-survey-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-rekhter-ext-communities-survey-01.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-rekhter-ext-communities-survey-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

- --OtherAccess--

- --NextPart--



------- End of Forwarded Message



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA23301 for <[e-mail]>; Thu, 1 Aug 2002 14:59:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 29A7191220; Thu,  1 Aug 2002 14:59:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E173391222; Thu,  1 Aug 2002 14:59:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C711F91220 for <[e-mail]>; Thu,  1 Aug 2002 14:59:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A67F75DE9E; Thu,  1 Aug 2002 14:59:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 03FAB5DE9C; Thu,  1 Aug 2002 14:59:00 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g71Iw3m86474; Thu, 1 Aug 2002 11:58:58 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Bill Fenner <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: ext communities to Proposed Standard
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 01 Aug 2002 11:58:03 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Bill,

The IDR WG would like to request the IESG to advance
draft-ietf-idr-bgp-ext-communities-05.txt to Proposed Standard.

draft-rekhter-ext-communities-survey-01.txt contains the
implementation report.

Yakov.