Subject: BGP INFORM message

From: Yakov Rekhter <[email-masked]>
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.
------- 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]>
Date: Wed, 21 Aug 2002 08:29:13 -0700

> 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: Robert Raszuk <[email-masked]>
Date: Wed, 21 Aug 2002 17:32:03 +0200

yes

R.

> Yakov Rekhter wrote:

---

From: Enke Chen <[email-masked]>
Date: Wed, 21 Aug 2002 08:45:14 -0700

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

> Message-Id: <[email-masked]>
> To: [email-masked]
> Date: Wed, 21 Aug 2002 07:37:21 -0700
> Sender: [email-masked]
> Precedence: bulk
> 
> Folks,
>

---

From: vrishab sikand <[email-masked]>
Date: Wed, 21 Aug 2002 10:29:56 -0700 (PDT)

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

> From: Yakov Rekhter 
> From: Yakov Rekhter 

---------------------------------
Do You Yahoo!?
HotJobs, a Yahoo! service - Search Thousands of New Jobs

---

From: Alex Zinin <[email-masked]>
Date: Wed, 21 Aug 2002 10:39:00 -0700

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

---

From: PamSri <[email-masked]>
Date: Wed, 21 Aug 2002 11:16:02 -0700 (PDT)

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

sri

--- vrishab sikand <[email-masked]> wrote:
> > Message-Id:
> <[email-masked]>
> > To: [email-masked]
> > "FILE
> /internet-drafts/draft-nalawade-bgp-inform-02.txt".
> > 
> > FILE
> /internet-drafts/draft-nalawade-bgp-inform-02.txt
> > 
> > - - --OtherAccess

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

---

From: [email-masked]
Date: Wed, 21 Aug 2002 11:29:48 -0700

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]
> X-OriginalArrivalTime: 21 Aug 2002 14:40:26.0949 (UTC) FILETIME=[B08B3750:01C24920]
> 
> Folks,
>

---

From: "Srihari R. Sangli" <[email-masked]>
Date: Wed, 21 Aug 2002 11:54:42 -0700 (PDT)

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

srihari...

---

From: john heasley <[email-masked]>
Date: Wed, 21 Aug 2002 12:04:18 -0700

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.

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 21 Aug 2002 15:08:19 -0400

>esp. when it means not needing to rely upon the remote's operator, who

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

---

From: john heasley <[email-masked]>
Date: Wed, 21 Aug 2002 12:57:39 -0700

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

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 21 Aug 2002 16:42:25 -0400

> 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

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 21 Aug 2002 15:15:47 -0700 (PDT)

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.

---

From: Alex Zinin <[email-masked]>
Date: Wed, 21 Aug 2002 18:28:00 -0700

Pedro,

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

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

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

> people that are considering this issue would otherwise go work on the

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.

> should be based on technical rather than procedural grounds.

See my 1st comment, pls.

> whole lot of effort on it), i often wonder if the WG is actually going

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

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 22 Aug 2002 10:27:49 +0530

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

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 22 Aug 2002 10:29:05 +0530

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
|

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Thu, 22 Aug 2002 16:07:24 -0700

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

---

From: Manav Bhatia <[email-masked]>
Date: Fri, 23 Aug 2002 09:23:09 +0530

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

---

From: Vincent Gillet <[email-masked]>
Date: Sun, 25 Aug 2002 16:14:04 +0200

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