Subject: BGP INFORM message

From: Yakov Rekhter <[email-masked]>
Date: Fri, 30 Aug 2002 09:08:58 -0700

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 <[email-masked]>
To:      [email-masked]
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 <[email-masked]>
To:      [email-masked]
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:    [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

- - - --OtherAccess--

- - - --NextPart--

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

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

------- End of Forwarded Message

To: [email-masked]
Subject: BGP INFORM message
Date: Fri, 30 Aug 2002 09:08:58 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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 <[email-masked]>
To:      [email-masked]
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 <[email-masked]>
To:      [email-masked]
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:    [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

- - - --OtherAccess--

- - - --NextPart--

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

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

------- End of Forwarded Message

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "idr" <[email-masked]>, "Susan Hares" <[email-masked]>
Cc: "yakov Rekhter" <[email-masked]>, <[email-masked]>, <[email-masked]>, "randy Bush" <[email-masked]>
Subject: Re: Words - in ASCII text
Date: Fri, 30 Aug 2002 10:25:49 +0100
Sender: [email-masked]

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.

From: "Natale, Jonathan" <[email-masked]>
To: "'Tom Petch'" <[email-masked]>, idr <[email-masked]>, Susan Hares <[email-masked]>
Cc: yakov Rekhter <[email-masked]>, [email-masked], [email-masked], randy Bush <[email-masked]>
Subject: RE: Words - in ASCII text
Date: Thu, 29 Aug 2002 17:34:49 -0400
Sender: [email-masked]

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:[email-masked]] 
Sent: Thursday, August 29, 2002 5:01 PM
To: idr; Susan Hares
Cc: yakov Rekhter; [email-masked]; [email-masked]; 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.
>

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "idr" <[email-masked]>, "Susan Hares" <[email-masked]>
Cc: "yakov Rekhter" <[email-masked]>, <[email-masked]>, <[email-masked]>, "randy Bush" <[email-masked]>
Subject: Re: Words - in ASCII text
Date: Thu, 29 Aug 2002 22:01:04 +0100
Sender: [email-masked]

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

From: "Natale, Jonathan" <[email-masked]>
To: "'Abarbanel, Benjamin'" <[email-masked]>, "'Susan Hares'" <[email-masked]>
Cc: yakov Rekhter <[email-masked]>, [email-masked]
Subject: RE: Working Group last call
Date: Wed, 28 Aug 2002 17:28:52 -0400
Sender: [email-masked]

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

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[email-masked]] 
Sent: Wednesday, August 28, 2002 3:15 PM
To: 'Susan Hares'; Abarbanel, Benjamin
Cc: yakov Rekhter; [email-masked]
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:[email-masked]]
> Sent: Wednesday, August 28, 2002 12:51 PM
> To: Abarbanel, Benjamin
> Cc: 'Susan Hares'; yakov Rekhter; [email-masked]
> 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:[email-masked]]
> > > Sent: Monday, August 26, 2002 2:12 PM
> > > To: yakov Rekhter
> > > Cc: [email-masked]
> > > 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
> > >
> 
> 

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Susan Hares'" <[email-masked]>, "Abarbanel, Benjamin" <[email-masked]>
Cc: yakov Rekhter <[email-masked]>, [email-masked]
Subject: RE: Working Group last call
Date: Wed, 28 Aug 2002 15:14:34 -0400
Sender: [email-masked]

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:[email-masked]]
> Sent: Wednesday, August 28, 2002 12:51 PM
> To: Abarbanel, Benjamin
> Cc: 'Susan Hares'; yakov Rekhter; [email-masked]
> 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:[email-masked]]
> > > Sent: Monday, August 26, 2002 2:12 PM
> > > To: yakov Rekhter
> > > Cc: [email-masked]
> > > 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
> > >
> 
> 

Date: Wed, 28 Aug 2002 12:50:44 -0400
To: "Abarbanel, Benjamin" <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: RE: Working Group last call
Cc: "'Susan Hares'" <[email-masked]>, yakov Rekhter <[email-masked]>, [email-masked]
Sender: [email-masked]

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:[email-masked]]
> > Sent: Monday, August 26, 2002 2:12 PM
> > To: yakov Rekhter
> > Cc: [email-masked]
> > 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
> >

Date: Tue, 27 Aug 2002 19:00:48 -0400
To: Tian Fang <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: One case is missing in confederation RFC 3065
Cc: [email-masked]
Sender: [email-masked]

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

From: Tian Fang <[email-masked]>
To: [email-masked]
Subject: One case is missing in confederation RFC 3065
Date: Tue, 27 Aug 2002 17:24:14 -0400
Sender: [email-masked]

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

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Susan Hares'" <[email-masked]>, yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: RE: Working Group last call
Date: Mon, 26 Aug 2002 15:22:54 -0400
Sender: [email-masked]

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:[email-masked]]
> Sent: Monday, August 26, 2002 2:12 PM
> To: yakov Rekhter
> Cc: [email-masked]
> 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
> 

Date: Mon, 26 Aug 2002 14:13:14 -0400
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Words - in ASCII text
Cc: yakov Rekhter <[email-masked]>, [email-masked], [email-masked], randy Bush <[email-masked]>
Sender: [email-masked]

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.

Date: Mon, 26 Aug 2002 14:12:28 -0400
To: yakov Rekhter <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Working Group last call
Cc: [email-masked]
Sender: [email-masked]

--=====================_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==_--

Date: Mon, 26 Aug 2002 13:47:59 -0400
To: lidefeng <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: A draft about BGP protection,Please review
Cc: [email-masked]
Sender: [email-masked]

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)

Date: Mon, 26 Aug 2002 10:42:11 -0700 (PDT)
From: Pedro Roque Marques <[email-masked]>
To: lidefeng <[email-masked]>
Cc: [email-masked]
Subject: A draft about BGP protection,Please review
Sender: [email-masked]

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.

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Pedro Roque Marques'" <[email-masked]>, Alex Zinin <[email-masked]>
Cc: Randy Bush <[email-masked]>, [email-masked]
Subject: RE: BGP INFORM message
Date: Mon, 26 Aug 2002 12:03:09 -0400
Sender: [email-masked]

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.

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: IDR WG charter
Date: Mon, 26 Aug 2002 11:44:25 -0400
Sender: [email-masked]

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:[email-masked]]
> Sent: Monday, August 26, 2002 10:18 AM
> To: [email-masked]
> Cc: [email-masked]
> 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 <[email-masked]>
> To:      [email-masked]
> 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
> 

To: Jeffrey Haas <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked], [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: IDR WG charter 
Date: Mon, 26 Aug 2002 09:38:23 -0600
Sender: [email-masked]

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.

Date: Mon, 26 Aug 2002 11:33:15 -0400
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: IDR WG charter
Sender: [email-masked]

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 [email-masked] 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

To: [email-masked]
Cc: [email-masked]
Subject: IDR WG charter
Date: Mon, 26 Aug 2002 07:18:00 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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 <[email-masked]>
To:      [email-masked]
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

Date: Mon, 26 Aug 2002 14:28:54 +0800
From: lidefeng <[email-masked]>
Subject: A draft about BGP protection,Please review
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

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 : [email-masked]
    
    Deng Qiulin  
    C401 ,HuaWei Bld. No.3 Xinxi Rd.
    Shang-Di Information Industry Base,
    Hai-Dian District BeiJing P.R.China
    Zip : 100085
    Email : [email-masked]
  
    Ni Hui
    C401 ,HuaWei Bld. No.3 Xinxi Rd.
    Shang-Di Information Industry Base,
    Hai-Dian District BeiJing P.R.China
    Zip : 100085
    Email : [email-masked]

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

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

Date: Sun, 25 Aug 2002 16:14:04 +0200
From: Vincent Gillet <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP INFORM message
Sender: [email-masked]

[email-masked] 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.

From: "Natale, Jonathan" <[email-masked]>
To: "'Bill Fenner'" <[email-masked]>
Cc: [email-masked]
Subject: RE: BGP spec and IDR WG charter
Date: Fri, 23 Aug 2002 13:01:06 -0400
Sender: [email-masked]

Bill,

OK,  thank you for replying.

-Jonathan

-----Original Message-----
From: Bill Fenner [mailto:[email-masked]] 
Sent: Friday, August 23, 2002 12:12 PM
To: [email-masked]
Cc: [email-masked]
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

From: Bill Fenner <[email-masked]>
To: [email-masked]
Subject: RE: BGP spec and IDR WG charter
Cc: [email-masked]
Date: Fri, 23 Aug 2002 09:12:01 -0700
Versions: dmail (solaris) 2.5a/makemail 2.9d
Sender: [email-masked]

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

From: "Natale, Jonathan" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>, "Natale, Jonathan" <[email-masked]>
Cc: "'Bill Fenner'" <[email-masked]>, [email-masked]
Subject: RE: BGP spec and IDR WG charter 
Date: Fri, 23 Aug 2002 11:34:17 -0400
Sender: [email-masked]

Yakov,

Ok, thank you for replying.

-Jonathan

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Friday, August 23, 2002 10:18 AM
To: Natale, Jonathan
Cc: 'Bill Fenner'; [email-masked]
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.

Date: Fri, 23 Aug 2002 11:11:00 -0400
From: Jeffrey Haas <[email-masked]>
To: Avi Freedman <[email-masked]>
Cc: [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

Date: Fri, 23 Aug 2002 10:36:12 -0400
From: Jeffrey Haas <[email-masked]>
To: Avi Freedman <[email-masked]>
Cc: [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

To: "Natale, Jonathan" <[email-masked]>
Cc: "'Bill Fenner'" <[email-masked]>, [email-masked]
Subject: Re: BGP spec and IDR WG charter 
Date: Fri, 23 Aug 2002 07:18:17 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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.

Date: Fri, 23 Aug 2002 09:46:29 -0400
From: Jeffrey Haas <[email-masked]>
To: "Abarbanel, Benjamin" <[email-masked]>
Cc: [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

From: "Natale, Jonathan" <[email-masked]>
To: "'Bill Fenner'" <[email-masked]>, [email-masked]
Subject: RE: BGP spec and IDR WG charter
Date: Fri, 23 Aug 2002 09:26:22 -0400
Sender: [email-masked]

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:[email-masked]] 
Sent: Thursday, August 22, 2002 7:11 PM
To: [email-masked]
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.

Date: Fri, 23 Aug 2002 07:42:34 -0700
From: Jeff Pickering <[email-masked]>
To: "Martin, Christian" <[email-masked]>
Cc: "'Yakov Rekhter'" <[email-masked]>, [email-masked]
Subject: Re: BGP INFORM message
Sender: [email-masked]

yes

"Martin, Christian" wrote:

> yes
>
> >-----Original Message-----
> >From: Yakov Rekhter [mailto:[email-masked]]
> >Sent: Wednesday, August 21, 2002 10:37 AM
> >To: [email-masked]
> >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 <[email-masked]>
> >To:      [email-masked]
> >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:    [email-masked]
> >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:
> >       [email-masked].
> >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="[email-masked]"
> >
> >Content-Type: text/plain
> >Content-ID:    <[email-masked]>
> >
> >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:    <[email-masked]>
> >
> >- - --OtherAccess--
> >
> >- - --NextPart--
> >
> >
> >
> >- ------- End of Forwarded Message
> >
> >
> >------- End of Forwarded Message
> >

Date: Fri, 23 Aug 2002 09:23:09 +0530
From: Manav Bhatia <[email-masked]>
Subject: Re: BGP INFORM message
To: Chandrashekhar Appanna <[email-masked]>
Cc: [email-masked]
Reply-To: Manav Bhatia <[email-masked]>
Sender: [email-masked]

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

Date: Thu, 22 Aug 2002 16:11:10 -0700 (PDT)
From: Bill Fenner <[email-masked]>
To: [email-masked]
Subject: BGP spec and IDR WG charter
Sender: [email-masked]

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.

Date: Thu, 22 Aug 2002 16:07:24 -0700
From: Chandrashekhar Appanna <[email-masked]>
To: Manav Bhatia <[email-masked]>
Cc: Pedro Roque Marques <[email-masked]>, [email-masked]
Subject: Re: BGP INFORM message
Sender: [email-masked]

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

Date: Thu, 22 Aug 2002 13:13:07 -0400
To: "Tom Petch" <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: TCP state machine doubts
Cc: "Abarbanel, Benjamin" <[email-masked]>, "'Susan Hares'" <[email-masked]>, "'Jeffrey Haas'" <[email-masked]>, "Abarbanel, Benjamin" <[email-masked]>, "Kunihiro Ishiguro" <[email-masked]>, "BGP mailing list" <[email-masked]>
Sender: [email-masked]

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
>[email-masked]
>+(44) 192 575 3018
>-----Original Message-----
>From: Abarbanel, Benjamin <[email-masked]>
>To: 'Susan Hares' <[email-masked]>
>Cc: 'Jeffrey Haas' <[email-masked]>; Abarbanel, Benjamin
><[email-masked]>; Kunihiro Ishiguro
><[email-masked]>; BGP mailing list <[email-masked]>
>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
> >

Date: Thu, 22 Aug 2002 10:29:05 +0530
From: Manav Bhatia <[email-masked]>
Subject: Re: BGP INFORM message
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Reply-To: Manav Bhatia <[email-masked]>
Sender: [email-masked]

yes

----- Original Message -----
From: "Yakov Rekhter" <[email-masked]>
To: <[email-masked]>
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 <[email-masked]>
| To:      [email-masked]
| 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:    [email-masked]
| 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:
| [email-masked].
| 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="[email-masked]"
|
| Content-Type: text/plain
| Content-ID: <[email-masked]>
|
| 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: <[email-masked]>
|
| - - --OtherAccess--
|
| - - --NextPart--
|
|
|
| - ------- End of Forwarded Message
|
|
| ------- End of Forwarded Message
|

Date: Thu, 22 Aug 2002 10:27:49 +0530
From: Manav Bhatia <[email-masked]>
Subject: Re: BGP INFORM message
To: Pedro Roque Marques <[email-masked]>
Cc: [email-masked]
Reply-To: Manav Bhatia <[email-masked]>
Sender: [email-masked]

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

Date: Wed, 21 Aug 2002 18:28:00 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: Randy Bush <[email-masked]>, [email-masked]
Subject: Re: BGP INFORM message
Sender: [email-masked]

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.

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "idr" <[email-masked]>, "Yakov Rekhter" <[email-masked]>
Subject: Re: BGP INFORM message
Date: Wed, 21 Aug 2002 23:38:09 +0100
Sender: [email-masked]

No

Tom Petch, Network Consultant
[email-masked]

-----Original Message-----
From: Yakov Rekhter <[email-masked]>
To: [email-masked] <[email-masked]>
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 <[email-masked]>
>To:      [email-masked]
>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:    [email-masked]
>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:
> [email-masked].
>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="[email-masked]"
>
>Content-Type: text/plain
>Content-ID: <[email-masked]>
>
>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: <[email-masked]>
>
>- - --OtherAccess--
>
>- - --NextPart--
>
>
>
>- ------- End of Forwarded Message
>
>
>------- End of Forwarded Message
>

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "Abarbanel, Benjamin" <[email-masked]>, "'Susan Hares'" <[email-masked]>
Cc: "'Jeffrey Haas'" <[email-masked]>, "Abarbanel, Benjamin" <[email-masked]>, "Kunihiro Ishiguro" <[email-masked]>, "BGP mailing list" <[email-masked]>
Subject: Re: TCP state machine doubts
Date: Wed, 21 Aug 2002 23:33:28 +0100
Sender: [email-masked]

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
[email-masked]
+(44) 192 575 3018
-----Original Message-----
From: Abarbanel, Benjamin <[email-masked]>
To: 'Susan Hares' <[email-masked]>
Cc: 'Jeffrey Haas' <[email-masked]>; Abarbanel, Benjamin
<[email-masked]>; Kunihiro Ishiguro
<[email-masked]>; BGP mailing list <[email-masked]>
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

From: "Martin, Christian" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>, [email-masked]
Subject: RE: BGP INFORM message
Date: Wed, 21 Aug 2002 18:36:12 -0400
Sender: [email-masked]

yes

>-----Original Message-----
>From: Yakov Rekhter [mailto:[email-masked]] 
>Sent: Wednesday, August 21, 2002 10:37 AM
>To: [email-masked]
>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 <[email-masked]>
>To:      [email-masked]
>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:    [email-masked]
>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:
>	[email-masked].
>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="[email-masked]"
>
>Content-Type: text/plain
>Content-ID:	<[email-masked]>
>
>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:	<[email-masked]>
>
>- - --OtherAccess--
>
>- - --NextPart--
>
>
>
>- ------- End of Forwarded Message
>
>
>------- End of Forwarded Message
>

From: "Martin, Christian" <[email-masked]>
To: "'Pedro Roque Marques'" <[email-masked]>, Alex Zinin <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: BGP INFORM message
Date: Wed, 21 Aug 2002 18:35:44 -0400
Sender: [email-masked]

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

Date: Wed, 21 Aug 2002 18:34:59 -0400 (EDT)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: [email-masked]
Subject: Re: BGP INFORM message
Sender: [email-masked]

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 <[email-masked]>
> To:      [email-masked]
> 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:    [email-masked]
> 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:
> 	[email-masked].
> 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="[email-masked]"
> 
> Content-Type: text/plain
> Content-ID:	<[email-masked]>
> 
> 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:	<[email-masked]>
> 
> - - --OtherAccess--
> 
> - - --NextPart--
> 
> 
> 
> - ------- End of Forwarded Message
> 
> 
> ------- End of Forwarded Message
> 

__________________________________
[email-masked] CCIE <>< Grace Alone

Date: Wed, 21 Aug 2002 15:15:47 -0700 (PDT)
From: Pedro Roque Marques <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Randy Bush <[email-masked]>, [email-masked]
Subject: Re: BGP INFORM message
Sender: [email-masked]

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.

Date: Wed, 21 Aug 2002 16:42:25 -0400
From: Jeffrey Haas <[email-masked]>
To: john heasley <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP INFORM message
Sender: [email-masked]

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

Date: Wed, 21 Aug 2002 12:57:39 -0700
From: john heasley <[email-masked]>
To: "John G. Scudder" <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP INFORM message
Sender: [email-masked]

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?

Date: Wed, 21 Aug 2002 15:08:19 -0400
To: john heasley <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: BGP INFORM message
Cc: [email-masked]
Sender: [email-masked]

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

Date: Wed, 21 Aug 2002 12:04:18 -0700
From: john heasley <[email-masked]>
To: "Srihari R. Sangli" <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: BGP INFORM message
Sender: [email-masked]

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

Date: Wed, 21 Aug 2002 11:54:42 -0700 (PDT)
From: "Srihari R. Sangli" <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP INFORM message
Sender: [email-masked]

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.

Date: Wed, 21 Aug 2002 11:29:48 -0700
From: [email-masked]
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP INFORM message
Sender: [email-masked]

Yes.

Andrew

On Wed, Aug 21, 2002 at 07:37:21AM -0700, Yakov Rekhter wrote:
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> To: [email-masked]
> Subject: BGP INFORM message
> Date: Wed, 21 Aug 2002 07:37:21 -0700
> From: Yakov Rekhter <[email-masked]>
> 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 <[email-masked]>
> To:      [email-masked]
> 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:    [email-masked]
> 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:
> 	[email-masked].
> 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="[email-masked]"
> 
> Content-Type: text/plain
> Content-ID:	<[email-masked]>
> 
> 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:	<[email-masked]>
> 
> - - --OtherAccess--
> 
> - - --NextPart--
> 
> 
> 
> - ------- End of Forwarded Message
> 
> 
> ------- End of Forwarded Message

Date: Wed, 21 Aug 2002 11:16:02 -0700 (PDT)
From: PamSri <[email-masked]>
Subject: Re: BGP INFORM message 
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

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

sri

--- vrishab sikand <[email-masked]> wrote:
> 
> ditto
>  Enke Chen wrote:NO (too much work with very little
> benefit). -- Enke
> 
> > Message-Id:
> <[email-masked]>
> > To: [email-masked]
> > Subject: BGP INFORM message
> > Date: Wed, 21 Aug 2002 07:37:21 -0700
> > From: Yakov Rekhter 
> > Sender: [email-masked]
> > 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: [email-masked]
> > 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: [email-masked]
> > 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:
> > [email-masked].
> > 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="[email-masked]"
> > 
> > Content-Type: text/plain
> > Content-ID: <[email-masked]>
> > 
> > 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: <[email-masked]>
> > 
> > - - --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

Date: Wed, 21 Aug 2002 10:39:00 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Randy Bush <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: BGP INFORM message
Sender: [email-masked]

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

Date: Wed, 21 Aug 2002 10:29:56 -0700 (PDT)
From: vrishab sikand <[email-masked]>
Subject: Re: BGP INFORM message 
To: Enke Chen <[email-masked]>, Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

--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: <[email-masked]>
> To: [email-masked]
> Subject: BGP INFORM message
> Date: Wed, 21 Aug 2002 07:37:21 -0700
> From: Yakov Rekhter 
> Sender: [email-masked]
> 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: [email-masked]
> 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: [email-masked]
> 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:
> [email-masked].
> 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="[email-masked]"
> 
> Content-Type: text/plain
> Content-ID: <[email-masked]>
> 
> 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: <[email-masked]>
> 
> - - --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 <[email-masked]></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;[email-masked]&gt;<BR>&gt; To: [email-masked]<BR>&gt; Subject: BGP INFORM message<BR>&gt; Date: Wed, 21 Aug 2002 07:37:21 -0700<BR>&gt; From: Yakov Rekhter <[email-masked]><BR>&gt; Sender: [email-masked]<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 <[email-masked]><BR>&gt; To: [email-masked]<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: [email-masked]<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; [email-masked].<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="[email-masked]"<BR>&gt; <BR>&gt; Content-Type: text/plain<BR>&gt; Content-ID: &lt;[email-masked]&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;[email-masked]&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--

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Jeffrey Haas'" <[email-masked]>, "Abarbanel, Benjamin" <[email-masked]>
Cc: [email-masked]
Subject: RE: questions on INFORM draft
Date: Wed, 21 Aug 2002 12:05:27 -0400
Sender: [email-masked]

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

Date: Wed, 21 Aug 2002 11:50:54 -0400
From: Jeffrey Haas <[email-masked]>
To: "Abarbanel, Benjamin" <[email-masked]>
Cc: [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: BGP INFORM message 
Date: Wed, 21 Aug 2002 08:45:14 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

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

> Message-Id: <[email-masked]>
> To: [email-masked]
> Subject: BGP INFORM message
> Date: Wed, 21 Aug 2002 07:37:21 -0700
> From: Yakov Rekhter <[email-masked]>
> Sender: [email-masked]
> 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 <[email-masked]>
> To:      [email-masked]
> 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:    [email-masked]
> 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:
> 	[email-masked].
> 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="[email-masked]"
> 
> Content-Type: text/plain
> Content-ID:	<[email-masked]>
> 
> 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:	<[email-masked]>
> 
> - - --OtherAccess--
> 
> - - --NextPart--
> 
> 
> 
> - ------- End of Forwarded Message
> 
> 
> ------- End of Forwarded Message
> 

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Susan Hares'" <[email-masked]>
Cc: "'Jeffrey Haas'" <[email-masked]>, "Abarbanel, Benjamin" <[email-masked]>, Kunihiro Ishiguro <[email-masked]>, BGP mailing list <[email-masked]>
Subject: RE: TCP state machine doubts
Date: Wed, 21 Aug 2002 11:41:12 -0400
Sender: [email-masked]

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

Date: Wed, 21 Aug 2002 17:32:03 +0200
From: Robert Raszuk <[email-masked]>
Reply-To: [email-masked]
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: [email-masked]
Subject: Re: BGP INFORM message
Sender: [email-masked]

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 <[email-masked]>
> To:      [email-masked]
> 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:    [email-masked]
> 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:
>         [email-masked].
> 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="[email-masked]"
> 
> Content-Type: text/plain
> Content-ID:     <[email-masked]>
> 
> 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:     <[email-masked]>
> 
> - - --OtherAccess--
> 
> - - --NextPart--
> 
> - ------- End of Forwarded Message
> 
> ------- End of Forwarded Message

From: Randy Bush <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP INFORM message
Date: Wed, 21 Aug 2002 08:29:13 -0700
Sender: [email-masked]

> 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

From: Igor Lasic <[email-masked]>
Date: Wed, 21 Aug 2002 11:27:51 -0400
To: "Abarbanel, Benjamin" <[email-masked]>
Cc: "'Yakov Rekhter'" <[email-masked]>, [email-masked]
Subject: RE: BGP INFORM message
Sender: [email-masked]

No.

Abarbanel, Benjamin writes:
 > Yes
 > 
 > Ben
 > 
 > > -----Original Message-----
 > > From: Yakov Rekhter [mailto:[email-masked]]
 > > Sent: Wednesday, August 21, 2002 10:37 AM
 > > To: [email-masked]
 > > 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 <[email-masked]>
 > > To:      [email-masked]
 > > 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:    [email-masked]
 > > 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:
 > > 	[email-masked].
 > > 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="[email-masked]"
 > > 
 > > Content-Type: text/plain
 > > Content-ID:	<[email-masked]>
 > > 
 > > 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:	<[email-masked]>
 > > 
 > > - - --OtherAccess--
 > > 
 > > - - --NextPart--
 > > 
 > > 
 > > 
 > > - ------- End of Forwarded Message
 > > 
 > > 
 > > ------- End of Forwarded Message
 > > 

Date: Wed, 21 Aug 2002 15:27:57 -0400
To: "Abarbanel, Benjamin" <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: RE: TCP state machine doubts
Cc: "'Jeffrey Haas'" <[email-masked]>, "Abarbanel, Benjamin" <[email-masked]>, "'Susan Hares'" <[email-masked]>, Kunihiro Ishiguro <[email-masked]>, BGP mailing list <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
> > 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
> >

From: "George Sheng" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: BGP INFORM message
Date: Wed, 21 Aug 2002 15:18:57 +0000
Sender: [email-masked]

NO.

>From: Yakov Rekhter <[email-masked]>
>To: [email-masked]
>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

Date: Wed, 21 Aug 2002 15:15:56 -0400
To: "Tom Petch" <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: BGP FSM transport primitives
Cc: "idr" <[email-masked]>
Sender: [email-masked]

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
>[email-masked]

From: "Natale, Jonathan" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>, [email-masked]
Subject: RE: BGP INFORM message
Date: Wed, 21 Aug 2002 11:15:20 -0400
Sender: [email-masked]

yes

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Wednesday, August 21, 2002 10:37 AM
To: [email-masked]
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 <[email-masked]>
To:      [email-masked]
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:    [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

- - --OtherAccess--

- - --NextPart--

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

------- End of Forwarded Message

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>, [email-masked]
Subject: RE: BGP INFORM message
Date: Wed, 21 Aug 2002 11:02:07 -0400
Sender: [email-masked]

Yes

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Wednesday, August 21, 2002 10:37 AM
> To: [email-masked]
> 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 <[email-masked]>
> To:      [email-masked]
> 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:    [email-masked]
> 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:
> 	[email-masked].
> 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="[email-masked]"
> 
> Content-Type: text/plain
> Content-ID:	<[email-masked]>
> 
> 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:	<[email-masked]>
> 
> - - --OtherAccess--
> 
> - - --NextPart--
> 
> 
> 
> - ------- End of Forwarded Message
> 
> 
> ------- End of Forwarded Message
> 

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

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 <[email-masked]>
To:      [email-masked]
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:    [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

- - --OtherAccess--

- - --NextPart--

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

------- End of Forwarded Message

Date: Tue, 20 Aug 2002 18:35:01 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

Date: Tue, 20 Aug 2002 14:50:10 -0400 (EDT)
From: Susan Harris <[email-masked]>
To: [email-masked]
Subject: Research/ops forum at October NANOG
Sender: [email-masked]

                     * * * * * * * * * * * * * * * * *
   
			   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 [email-masked].  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.
---------------------------------------------------------------------------

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Jeffrey Haas'" <[email-masked]>, Avi Freedman <[email-masked]>
Cc: George Sheng <[email-masked]>, [email-masked]
Subject: RE: questions on INFORM draft
Date: Tue, 20 Aug 2002 10:44:01 -0400
Sender: [email-masked]

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

Date: Tue, 20 Aug 2002 10:26:35 -0400
From: Jeffrey Haas <[email-masked]>
To: George Sheng <[email-masked]>
Cc: [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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 [email-masked] (wg list for distributed
> mangement) :-)

Well, you might be able to. :-)

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 20 Aug 2002 10:17:43 -0400
From: Jeffrey Haas <[email-masked]>
To: Avi Freedman <[email-masked]>
Cc: George Sheng <[email-masked]>, [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

From: "George Sheng" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: questions on INFORM draft
Date: Tue, 20 Aug 2002 04:56:56 +0000
Sender: [email-masked]

>
> > * 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 [email-masked] (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

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "idr" <[email-masked]>
Subject: BGP FSM transport primitives
Date: Mon, 19 Aug 2002 17:55:59 +0100
Sender: [email-masked]

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
[email-masked]

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Jeffrey Haas'" <[email-masked]>, "Abarbanel, Benjamin" <[email-masked]>
Cc: "'John G. Scudder'" <[email-masked]>, [email-masked]
Subject: RE: questions on INFORM draft
Date: Mon, 19 Aug 2002 12:59:11 -0400
Sender: [email-masked]

> 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

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'John G. Scudder'" <[email-masked]>, "Abarbanel, Benjamin" <[email-masked]>
Cc: "Abarbanel, Benjamin" <[email-masked]>, "'Jeffrey Haas'" <[email-masked]>, [email-masked]
Subject: RE: questions on INFORM draft
Date: Mon, 19 Aug 2002 12:51:24 -0400
Sender: [email-masked]

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:[email-masked]]
> Sent: Monday, August 19, 2002 12:47 PM
> To: Abarbanel, Benjamin
> Cc: Abarbanel, Benjamin; 'Jeffrey Haas'; [email-masked]
> 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
> 

Date: Mon, 19 Aug 2002 12:49:16 -0400
From: Jeffrey Haas <[email-masked]>
To: "Abarbanel, Benjamin" <[email-masked]>
Cc: "'John G. Scudder'" <[email-masked]>, [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

Date: Mon, 19 Aug 2002 12:47:01 -0400
To: "Abarbanel, Benjamin" <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: RE: questions on INFORM draft
Cc: "Abarbanel, Benjamin" <[email-masked]>, "'Jeffrey Haas'" <[email-masked]>, [email-masked]
Sender: [email-masked]

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

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'John G. Scudder'" <[email-masked]>, "Abarbanel, Benjamin" <[email-masked]>
Cc: "'Jeffrey Haas'" <[email-masked]>, "Abarbanel, Benjamin" <[email-masked]>, [email-masked]
Subject: RE: questions on INFORM draft
Date: Mon, 19 Aug 2002 12:44:05 -0400
Sender: [email-masked]

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:[email-masked]]
> Sent: Monday, August 19, 2002 12:18 PM
> To: Abarbanel, Benjamin
> Cc: 'Jeffrey Haas'; Abarbanel, Benjamin; [email-masked]
> 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
> ...
> 

Date: Mon, 19 Aug 2002 12:17:38 -0400
To: "Abarbanel, Benjamin" <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: RE: questions on INFORM draft
Cc: "'Jeffrey Haas'" <[email-masked]>, "Abarbanel, Benjamin" <[email-masked]>, [email-masked]
Sender: [email-masked]

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

Date: Mon, 19 Aug 2002 12:00:26 -0400
From: Jeffrey Haas <[email-masked]>
To: "Abarbanel, Benjamin" <[email-masked]>
Cc: [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

From: "Abarbanel, Benjamin" <[email-masked]>
To: "Abarbanel, Benjamin" <[email-masked]>, "'Jeffrey Haas'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: questions on INFORM draft
Date: Mon, 19 Aug 2002 11:55:31 -0400
Sender: [email-masked]

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: [email-masked]
> 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:[email-masked]]
> > Sent: Monday, August 19, 2002 11:18 AM
> > To: Abarbanel, Benjamin
> > Cc: [email-masked]
> > 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
> > 
> 

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Jeffrey Haas'" <[email-masked]>, "Abarbanel, Benjamin" <[email-masked]>
Cc: [email-masked]
Subject: RE: questions on INFORM draft
Date: Mon, 19 Aug 2002 11:53:43 -0400
Sender: [email-masked]

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:[email-masked]]
> Sent: Monday, August 19, 2002 11:18 AM
> To: Abarbanel, Benjamin
> Cc: [email-masked]
> 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
> 

Date: Mon, 19 Aug 2002 11:18:12 -0400
From: Jeffrey Haas <[email-masked]>
To: "Abarbanel, Benjamin" <[email-masked]>
Cc: [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Jeffrey Haas'" <[email-masked]>, "Abarbanel, Benjamin" <[email-masked]>
Cc: George Sheng <[email-masked]>, [email-masked]
Subject: RE: questions on INFORM draft
Date: Mon, 19 Aug 2002 11:11:53 -0400
Sender: [email-masked]

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

Date: Mon, 19 Aug 2002 11:04:43 -0400
From: Jeffrey Haas <[email-masked]>
To: "Abarbanel, Benjamin" <[email-masked]>
Cc: George Sheng <[email-masked]>, [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

Date: Mon, 19 Aug 2002 11:03:30 -0400
From: Jeffrey Haas <[email-masked]>
To: George Sheng <[email-masked]>
Cc: [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Jeffrey Haas'" <[email-masked]>, George Sheng <[email-masked]>
Cc: [email-masked]
Subject: RE: questions on INFORM draft
Date: Mon, 19 Aug 2002 10:59:36 -0400
Sender: [email-masked]

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:[email-masked]]
> Sent: Saturday, August 17, 2002 2:19 PM
> To: George Sheng
> Cc: [email-masked]
> 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
> 

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'John G. Scudder'" <[email-masked]>, Pedro Roque Marques <[email-masked]>
Cc: Manav Bhatia <[email-masked]>, Mathew Richardson <[email-masked]>, [email-masked]
Subject: RE: Proposal to support dynamic capability negotiation of gracefu l  restart
Date: Mon, 19 Aug 2002 10:20:43 -0400
Sender: [email-masked]

John:

> -----Original Message-----
> From: John G. Scudder [mailto:[email-masked]]
> Sent: Wednesday, August 14, 2002 3:05 PM
> To: Pedro Roque Marques
> Cc: Manav Bhatia; Mathew Richardson; [email-masked]
> 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

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Jeffrey Haas'" <[email-masked]>, [email-masked]
Subject: RE: Proposal to support dynamic capability negotiation of gracefu l restart
Date: Mon, 19 Aug 2002 09:55:44 -0400
Sender: [email-masked]

Jeffrey:

I have been on vacation, hence late response below.

Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Monday, August 12, 2002 11:03 AM
> To: [email-masked]
> 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

From: "George Sheng" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: questions on INFORM draft
Date: Mon, 19 Aug 2002 03:43:50 +0000
Sender: [email-masked]

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

Date: Sun, 18 Aug 2002 01:49:22 -0700
From: Kunihiro Ishiguro <[email-masked]>
To: "Natale, Jonathan" <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP INFORM message
Sender: [email-masked]

>Are there any implementations?

You will see ;-).
--
Kunihiro Ishiguro

Date: Sat, 17 Aug 2002 14:19:27 -0400
From: Jeffrey Haas <[email-masked]>
To: George Sheng <[email-masked]>
Cc: [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

Date: Sat, 17 Aug 2002 14:07:58 -0400
From: Jeffrey Haas <[email-masked]>
To: Avi Freedman <[email-masked]>
Cc: George Sheng <[email-masked]>, [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

From: "George Sheng" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: questions on INFORM draft
Date: Sat, 17 Aug 2002 05:38:06 +0000
Sender: [email-masked]

Jeff,

>From: Jeffrey Haas <[email-masked]>
>To: George Sheng <[email-masked]>
>CC: [email-masked]
>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

Date: Fri, 16 Aug 2002 17:50:56 -0400
From: Jeffrey Haas <[email-masked]>
To: Russ White <[email-masked]>
Cc: [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

Date: Fri, 16 Aug 2002 17:13:55 -0400 (EDT)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

> 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

__________________________________
[email-masked] CCIE <>< Grace Alone

Date: Fri, 16 Aug 2002 14:24:40 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

On Fri, Aug 16, 2002 at 10:46:22AM -0700, [email-masked] 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

Date: Fri, 16 Aug 2002 10:46:22 -0700
From: [email-masked]
To: George Sheng <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

From: Randy Bush <[email-masked]>
To: Igor Faynberg <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: consult
Date: Fri, 16 Aug 2002 10:10:37 -0700
Sender: [email-masked]

> 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

Date: Fri, 16 Aug 2002 13:05:04 -0400
From: Igor Faynberg <[email-masked]>
Reply-To: [email-masked]
Organization: Lucent Technologies
To: "Natale, Jonathan" <[email-masked]>
Cc: "'lidefeng'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: consult
Sender: [email-masked]

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:[email-masked]]
> Sent: Thursday, August 15, 2002 10:33 PM
> To: [email-masked]
> Cc: [email-masked]
> 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

Date: Fri, 16 Aug 2002 12:57:49 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

Date: Fri, 16 Aug 2002 12:31:58 -0400
From: Jeffrey Haas <[email-masked]>
To: Igor Lasic <[email-masked]>
Cc: George Sheng <[email-masked]>, [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

Date: Fri, 16 Aug 2002 12:06:47 -0400
To: Igor Lasic <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: questions on INFORM draft
Cc: [email-masked]
Sender: [email-masked]

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

From: "Natale, Jonathan" <[email-masked]>
To: "'lidefeng'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: consult
Date: Fri, 16 Aug 2002 09:20:13 -0400
Sender: [email-masked]

I use http://rfc.sunsite.dk/
Can't say how accurate it is for sure.

-----Original Message-----
From: lidefeng [mailto:[email-masked]] 
Sent: Thursday, August 15, 2002 10:33 PM
To: [email-masked]
Cc: [email-masked]
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

Date: Fri, 16 Aug 2002 16:40:29 +0800
From: lidefeng <[email-masked]>
Subject: about:draft-jacquenet-qos-nlri-04.txt
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

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

Date: Fri, 16 Aug 2002 10:32:52 +0800
From: lidefeng <[email-masked]>
Subject: consult
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

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

From: "George Sheng" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: questions on INFORM draft
Date: Thu, 15 Aug 2002 22:21:16 +0000
Sender: [email-masked]

Andrew,

>From: [email-masked]
>To: George Sheng <[email-masked]>
>CC: [email-masked], [email-masked]
>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: [email-masked]
> > Delivered-To: [email-masked]
> > Delivered-To: [email-masked]
> > X-Originating-IP: [155.53.36.107]
> > From: "George Sheng" <[email-masked]>
> > To: [email-masked]
> > 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

From: Igor Lasic <[email-masked]>
Date: Thu, 15 Aug 2002 18:03:27 -0400
To: Jeffrey Haas <[email-masked]>
Cc: George Sheng <[email-masked]>, [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

Date: Thu, 15 Aug 2002 17:48:06 -0400
From: Jeffrey Haas <[email-masked]>
To: George Sheng <[email-masked]>
Cc: [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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

Date: Thu, 15 Aug 2002 14:43:39 -0700
From: [email-masked]
To: George Sheng <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: questions on INFORM draft
Sender: [email-masked]

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: [email-masked]
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> X-Originating-IP: [155.53.36.107]
> From: "George Sheng" <[email-masked]>
> To: [email-masked]
> 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

From: "George Sheng" <[email-masked]>
To: [email-masked]
Subject: questions on INFORM draft
Date: Thu, 15 Aug 2002 21:20:32 +0000
Sender: [email-masked]

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

Date: Thu, 15 Aug 2002 17:02:51 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l  restart
Sender: [email-masked]

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

From: "Natale, Jonathan" <[email-masked]>
To: [email-masked]
Subject: RE: BGP INFORM message
Date: Thu, 15 Aug 2002 13:40:34 -0400
Sender: [email-masked]

Are there any implementations?

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Thursday, August 15, 2002 10:01 AM
To: [email-masked]
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:    [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

From: "Natale, Jonathan" <[email-masked]>
To: [email-masked]
Subject: RE: BGP INFORM message
Date: Thu, 15 Aug 2002 13:31:22 -0400
Sender: [email-masked]

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:[email-masked]] 
Sent: Thursday, August 15, 2002 10:01 AM
To: [email-masked]
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:    [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

Date: Thu, 15 Aug 2002 11:29:08 -0400
From: Jeffrey Haas <[email-masked]>
To: "John G. Scudder" <[email-masked]>
Cc: Pedro Roque Marques <[email-masked]>, Manav Bhatia <[email-masked]>, Mathew Richardson <[email-masked]>, [email-masked]
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l  restart
Sender: [email-masked]

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

Date: Thu, 15 Aug 2002 07:30:53 -0700 (PDT)
From: PamSri <[email-masked]>
To: [email-masked]
Sender: [email-masked]

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

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

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:    [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

Date: Wed, 14 Aug 2002 15:05:26 -0400
To: Pedro Roque Marques <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l  restart
Cc: Manav Bhatia <[email-masked]>, Mathew Richardson <[email-masked]>, [email-masked]
Sender: [email-masked]

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

Date: Wed, 14 Aug 2002 11:18:18 -0700 (PDT)
From: Pedro Roque Marques <[email-masked]>
To: Manav Bhatia <[email-masked]>
Cc: Mathew Richardson <[email-masked]>, [email-masked]
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l restart
Sender: [email-masked]

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.

Date: Wed, 14 Aug 2002 08:29:26 +0530
From: Manav Bhatia <[email-masked]>
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l restart
To: Mathew Richardson <[email-masked]>, [email-masked]
Reply-To: Manav Bhatia <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 13 Aug 2002 11:23:33 -0400
From: Mathew Richardson <[email-masked]>
To: [email-masked]
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l restart
Sender: [email-masked]

> Jeffrey Haas <[email-masked]> [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

Date: Tue, 13 Aug 2002 10:32:34 -0400
From: Jeffrey Haas <[email-masked]>
To: Manav Bhatia <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l restart
Sender: [email-masked]

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

Date: Tue, 13 Aug 2002 08:38:45 +0530
From: Manav Bhatia <[email-masked]>
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l restart
To: Jeffrey Haas <[email-masked]>, [email-masked]
Reply-To: Manav Bhatia <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 12 Aug 2002 10:27:39 -0700
From: Jeff Pickering <[email-masked]>
To: [email-masked]
Subject: [Fwd: bgp route oscillation]
Sender: [email-masked]

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: <[email-masked]>
Date: Thu, 08 Aug 2002 11:17:53 -0700
From: Jeff Pickering <[email-masked]>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [email-masked]
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--

Date: Mon, 12 Aug 2002 11:24:42 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: Proposal to support dynamic capability negotiation of graceful restart
Sender: [email-masked]

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

Date: Mon, 12 Aug 2002 11:03:28 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: Proposal to support dynamic capability negotiation of gracefu l restart
Sender: [email-masked]

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

Date: Fri, 9 Aug 2002 13:45:43 -0400
From: Shane Wright <[email-masked]>
To: [email-masked]
Subject: RFC2918 comments
Sender: [email-masked]

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

Date: Wed, 7 Aug 2002 15:35:39 -0400
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: Graceful Restart implementation report
Sender: [email-masked]

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 ([email-masked]).

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

From: "Natale, Jonathan" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>, "Natale, Jonathan" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: capability 
Date: Tue, 6 Aug 2002 17:53:13 -0400 
Sender: [email-masked]

Great.  So there is plenty of time till the next round.  

Thanks.

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Tuesday, August 06, 2002 4:43 PM
To: Natale, Jonathan
Cc: [email-masked]'
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 <[email-masked]>, Internet Architecture Board
<iab@isi.
     ***edu>,
	 [email-masked]
From:    The IESG <[email-masked]>
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).

To: "Natale, Jonathan" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: capability 
Date: Tue, 06 Aug 2002 13:43:20 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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 <[email-masked]>, Internet Architecture Board <iab@isi.
     ***edu>,
	 [email-masked]
From:    The IESG <[email-masked]>
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).

From: "Natale, Jonathan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: capability
Date: Tue, 6 Aug 2002 16:18:47 -0400 
Sender: [email-masked]

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

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>, Bruno Rijsman <[email-masked]>
Cc: [email-masked]
Subject: RE: Proposal to support dynamic capability negotiation of gracefu l restart 
Date: Tue, 6 Aug 2002 15:05:30 -0400 
Sender: [email-masked]

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:[email-masked]]
> Sent: Tuesday, August 06, 2002 2:53 PM
> To: Bruno Rijsman
> Cc: [email-masked]
> 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 <[email-masked]>
> > >To: "Bruno Rijsman" <[email-masked]>
> > >CC: [email-masked]
> > >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
> 

To: "Bruno Rijsman" <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposal to support dynamic capability negotiation of graceful restart 
Date: Tue, 06 Aug 2002 11:52:36 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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 <[email-masked]>
> >To: "Bruno Rijsman" <[email-masked]>
> >CC: [email-masked]
> >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
> 

From: "Bruno Rijsman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Proposal to support dynamic capability negotiation of graceful restart
Date: Tue, 06 Aug 2002 14:43:08 -0400
Sender: [email-masked]

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 <[email-masked]>
>To: "Bruno Rijsman" <[email-masked]>
>CC: [email-masked]
>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

Date: Tue, 6 Aug 2002 14:37:20 -0400
From: Jeffrey Haas <[email-masked]>
To: Bruno Rijsman <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposal to support dynamic capability negotiation of graceful restart
Sender: [email-masked]

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

From: "Bruno Rijsman" <[email-masked]>
To: [email-masked]
Subject: Proposal to support dynamic capability negotiation of graceful restart
Date: Tue, 06 Aug 2002 13:55:31 -0400
Sender: [email-masked]

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

From: "Krishnan, Vijay G." <[email-masked]>
To: [email-masked], "'Bruno Rijsman'" <[email-masked]>
Subject: RE: Graceful-restart dynamically negotiable?
Date: Fri, 2 Aug 2002 15:06:40 -0400 
Sender: [email-masked]

If it is a dynamic capability, its useful for planned restarts also.

regards
Vijay

-----Original Message-----
From: Wei Cao [mailto:[email-masked]]
Sent: Friday, August 02, 2002 1:20 PM
To: [email-masked]; '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:[email-masked]]
> > Sent: Thursday, August 01, 2002 3:55 PM
> > To: [email-masked]
> > 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
> >

Date: Fri, 02 Aug 2002 10:20:24 -0700
From: Wei Cao <[email-masked]>
Reply-To: [email-masked]
Organization: IP Infusion Inc
To: [email-masked], "'Bruno Rijsman'" <[email-masked]>, "Abarbanel, Benjamin" <[email-masked]>
Subject: Re: Graceful-restart dynamically negotiable?
Sender: [email-masked]

 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:[email-masked]]
> > Sent: Thursday, August 01, 2002 3:55 PM
> > To: [email-masked]
> > 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
> >

Date: Fri, 2 Aug 2002 12:35:32 -0400
From: Jeffrey Haas <[email-masked]>
To: Stephen Waters <[email-masked]>
Cc: [email-masked]
Subject: Re: Planned BGP Graceful Restart
Sender: [email-masked]

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

content-class: urn:content-classes:message
Subject: Planned BGP Graceful Restart
Date: Fri, 2 Aug 2002 15:16:37 +0100
From: "Stephen Waters" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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. 

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Bruno Rijsman'" <[email-masked]>, [email-masked]
Subject: RE: Graceful-restart dynamically negotiable?
Date: Thu, 1 Aug 2002 16:57:44 -0400 
Sender: [email-masked]

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:[email-masked]]
> Sent: Thursday, August 01, 2002 3:55 PM
> To: [email-masked]
> 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
> 

From: "Bruno Rijsman" <[email-masked]>
To: [email-masked]
Subject: Graceful-restart dynamically negotiable?
Date: Thu, 01 Aug 2002 15:55:26 -0400
Sender: [email-masked]

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

To: [email-masked]
Subject: ext communities implementation report
Date: Thu, 01 Aug 2002 12:36:30 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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:    [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

To: Bill Fenner <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: ext communities to Proposed Standard
Date: Thu, 01 Aug 2002 11:58:03 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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.