Subject: BGP INFORM message

From: Yakov Rekhter <[email-masked]>
Date: Thu, 15 Aug 2002 07:00:49 -0700

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]>
Date: Thu, 15 Aug 2002 13:31:22 -0400

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,

Yakov.

- --NextPart

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

Send a message to:
	[email-masked].
In the body type:

- --NextPart

- --OtherAccess

Content-Type: text/plain

ENCODING mime

- --OtherAccess

Content-Type: text/plain

- --OtherAccess--

- --NextPart--

---

From: "Natale, Jonathan" <[email-masked]>
Date: Wed, 21 Aug 2002 11:15:20 -0400

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.

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

Folks,

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

- - --NextPart

	

Send a message to:
	[email-masked].
In the body type:

- - --NextPart

- - --OtherAccess

Content-Type: text/plain

ENCODING mime

- - --OtherAccess

Content-Type: text/plain

- - --OtherAccess--

- - --NextPart--

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

---

From: "George Sheng" <[email-masked]>
Date: Wed, 21 Aug 2002 15:18:57 +0000

NO.

>Date: Wed, 21 Aug 2002 07:37:21 -0700
>
>Folks,
>

george

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

---

From: Russ White <[email-masked]>
Date: Wed, 21 Aug 2002 18:34:59 -0400 (EDT)

Yes.

Russ

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

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

---

From: "Martin, Christian" <[email-masked]>
Date: Wed, 21 Aug 2002 18:35:44 -0400

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

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 21 Aug 2002 23:38:09 +0100

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

directories.

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 26 Aug 2002 12:03:09 -0400

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.