Subject: [Idr] draft-scholl-idr-advisory-00

From: Robert Raszuk <[email-masked]>
Date: Tue, 24 Mar 2009 09:01:36 -0700

Tom, John and all,

The presented draft demonstrates the need for more automation as well as
more signaling between providers. While I am always in support of more
automation let me point out number of issues with the proposed approach
and suggest an alternative solution.

First let's focus on the goal of the proposal. As I understand it and as 
it is spelled out quite clearly in the draft this is to inform 
respective administrator of the peering side about BGP events either 
planned (maintenance) or unplanned threshold based (example maximum 
prefix, applied dampening etc). It is also to automate existing fully 
manual way of critical or less critical bgp information distribution 
between peers.

So the flow of the events is as follows:

NOC_A -> ISP_A @ ASBR_A == EBGP == ASBR_B @ ISP_B -> NOC_B

Planned events:
---------------

* Operator A is generating a message at the CLI to a peer or group of 
EBGP peers
* Message get's propagates via EBGP sessions
* ASBR_B receives the message and it logs it to a syslog/local log file
* Automated daemon parses the syslog or local log file, filters the 
message and provided it understands it sends to NOC_B

In unplanned threshold based events the only difference is that this is 
not NOC_A but ASBR_A generating the msg.

Issues:
-------

* The proposed mechanism should be per SAFI. For one this is due to the 
reason that each SAFI may have it's own set of configured thresholds. 
For the second is that operational groups responsible for different 
network services are very often a separate groups of people. One could 
embed the info in the text itself, but it must be standardized so the 
parsing can be automated.

* Parsing is an issue on the receiving side. Imagine the case how 
efficient and doable this solution is considering that your ASBR may be 
peering to 4000 up/down-stream peers as pointed out by Vijay. Each of 
those 4000 peers would first need to be able to support such parsing, 
understand to notify it's own administrator or NOC.

* The proposed solution is very difficult deployment wise as both 
peering sides must support the functionality.

* The most important issue I see with this approach in general is that 
enhancing protocol for new functionality is fine as long as both sides 
are educated how to use the information. Also it is fine as long as this 
is really necessary and any other solution would be either too difficult 
or impossible.

As pointed out yesterday by Keyur Patel or for that matter by Pedro 
Marques when in July 2002 INFORM draft was discussed we are in no 
position to automate all possible actions on the receiver of such 
warning. This is the other side's operator which can in turn make some 
decisions. (Note that for the reload itself there are other proposals 
for example one by Bruno - on how to make it graceful).

Suggested alternative:
----------------------

So what I would propose instead ....

* To simplify the solution as well as avoid the must for protocol 
changes to make it working. There is one protocol enhancement I will 
propose instead which could be just an optimization ie solution can work 
without it.

* To use automated out of band email based notification directly 
targeting corresponding NOC or admin of the peer, but auto generated 
from the router itself

* To optionally allow for auto-receive of the per SAFI remote peer's 
admin/noc email address where the advisory messages should be send to

Coming back to our original diagram:

                    ___________________________________
                   |                                   |
                   ^                                   v
NOC_A -> ISP_A @ ASBR_A == EBGP == ASBR_B @ ISP_B -> NOC_B

Planned events:
---------------

* NOC is performing some critical action on ASBR_A which triggers 
auto-generating a message at the CLI to a peers which are enabled for 
such notification

* Operator at NOC_A does not need to worry to whom to send such message

* Message get's propagates out of band directly to the most interested 
parties at the peering point (It could be usually a mailer alias of NOC 
engineers). Done !

* There is no need to maintain any parsing of syslog at the border ASBRs.

In unplanned threshold based events the only difference is that this is 
not NOC_A's operator but ASBR_A generating the msg itself.

Examples of planned messages/warnings:

# router reload
# peer hard clear

Examples of unplanned threshold based messages:

# prefix-limit reaching X%
# dampening applied or about to be applied on prefix Z
etc...

What is required to support the above:
--------------------------------------

* The implementation could be enhanced to allow to configure in the cli 
local admin_A@domain_isp_a as well as per peer/safi admin_B@domain_isp_b

* The implementation should allow to pipe any delayed reload or clear 
command via a notifier function

* For threshold based events today's implementation I am familiar with 
already have support for handling dynamic events (event scripts or 
embedded event manager) which could easily be instructed to do so and 
auto generate proper email notification msg.

*OPTIONAL* To allow for dynamic update of such peer's email address we 
could indeed have an optional BGP capability just exchanged at the 
session establishment which would allow for dynamic per SAFI update of 
such email address fields on the peering side. But there is no need for 
any new BGP message type.

Benefits summary of the alternative suggestion:
-----------------------------------------------

* No need to modify BGP protocol (only if at all as an option we would 
see as a useful thing)

* Deployable today via already existing operating systems

* Works well for both planned maintenance or threshold based event 
driven notifications

* Easy to enhance for more friendly operator's use via few cli changes

* Follows other standard industry practices where for example unix hosts 
or good firewalls have such admin email configurable already ... why 
router's don't ?

* Can be easily extended via the very same mechanism to other protocols 
.. not only BGP (Think about dynamic caching distribution protocol 
across admin boundaries)

* Source NOC already has an option to also receive the auto-generated 
email confirmation as opposed to search syslog to find if, when and 
where such BGP embedded msg has been send out. Failure in receiver 
address is also automatically recognized.

* No need to modify and parse anything at the potential 1000s of peers.

Cheers,
R.

---

From: Richard A Steenbergen <[email-masked]>
Date: Tue, 24 Mar 2009 13:58:14 -0500

> understand to notify it's own administrator or NOC.

One thing to keep in mind is that for every Google sized network on the
Internet, there are thousands of smaller sized networks with very
different needs. I'm not arguing that it doesn't make sense for Google
to try and design a system which keeps humans off the routers, but for
the vast majority of the world when something goes down there is a human
who logs into a router and does a "show log" to figure out why. In fact,
one could argue that the vast majority of Google's peers operate this
way, therefore Google could still see significant advantages when
sending messages to other networks, even if they don't when receiving
messages from them.

Plus, this is the kind of thing that could easily be initiated via snmp
or netconf, and picked up via an snmp trap or other monitoring tool
which already exist.

> peering sides must support the functionality.

I don't see the difficulty. The best case is that the extra level of
communication helps operators run their networks, the worst case is that
it is unsupported or ignored by the other side because they aren't
expecting it. This is no worse off than we are today. I don't think
anyone is under any delusions that this will ever completely replace out
of band communications, and certainly not from day 1.

That said, it seems a little odd to argue against standardizing and
implementing a tool which currently doesn't help you because it hasn't
been standardized and implemented. Over time more and more devices will
be able to support it, as networks upgrade their router code. Until
then, it causes no harm, generates no additional work-load, and the 
sending party will know if the other side supports the advisory 
capability and is even capable of receiving the message.

> for example one by Bruno - on how to make it graceful).

I was actually afraid that this might be the reaction when I saw the
example use of signaling the approach of a max-prefix limit. Clearly a
structured message such as the INFORM draft is a better way to go about
signaling something like this, but I think the point being made is that
an advisory message would at least provide a possible mechanism for
communicating this where today there is none. The ability to send a
free-form message has the advantage of being able to adapt to any
situation that operators might find, instead of requiring the IETF to 
think up every possible message type beforehand.

> propose instead which could be just an optimization ie solution can work 

This feature seems to trivial and easy to implement that I have a hard 
time thinking of it as a true protocol change. Think of it as an 
extremely simple method of interprovider communication which just 
happens to piggyback on the existing BGP protocol for no other reason 
than that BGP is the only real interprovider protocol to piggyback on.

> Coming back to our original diagram:

One significant advantage to in-band signaling over BGP is the built in
authentication mechanism. By its very nature it is impossible to send to
or receive from someone who is not a directly connected and configured
BGP peer. The existence of the BGP session itself proves both the direct 
relationship, and simply and securely associates the message with a 
specific peer and BGP session. It also serves to get the message 
delivered directly to the people who are most interested in seeing it, 
the engineering/operations staff on the other side of the connection who 
have access to the router in question.

To implement this via an out-of-band signaling method, you would need
yet another layer 8 signaling to negotiate NOC contact information and
an authentication mechanism, which must then be kept up to date using
more layer 8 signaling. This is essentially the system of inter-network
communication we use today, it just takes the form of e-mails, telephone
numbers, and the occasional post to operators mailing lists trying to
negotiate a signaling path to someone clueful. You would also need to
deliver the out of band message via some other mechanism such as the
Internet, which one could consider less secure than delivering it via
the existing direct connection between the two routers in question. This 
might also require a full table, which is intentionally not configured 
on many border routers as an anti-traffic injection mechanism.

I believe most large networks with a complex management structure
already have existing (plus working and vetted) mechanisms for
collecting data coming in from distributed routers and feeding it back
to centralized monitoring systems, so this would be a natural extension
of that functionality. Adding another out of band communications 
infrastructure seems significantly more complex, and significantly less 
likely to be implementable in the near future.

As any network operator who lived through the great BGP MD5 scare is
well aware, communication with third party networks is difficult at
best, and painful or impossible at worst. Consider for example the
process that goes on every time a BGP session flaps. NOC_A receives a
monitoring alert/trap about the session, then tries to determine if this
is an event they were expecting (by checking for layer 8 communication
such as e-mails on the subject), and if they can't find it they then
initiate communication with NOC_B via a mechanism like e-mail or
telephone inquiring about the event. NOC_B then has to determine if this
is an event they were expecting, by searching their own e-mails or
maintenance calendars, or talking to their engineering/ops group. Anyone
who has ever done maintenance on an exchange point router with a few
hundred peers is well aware of the dozens of unnecessary e-mails or
calls this will generate, even if a maintenance notification was sent
out. This also does nothing to address the case of an emergency
maintenance, such as an unscheduled but engineering initiated reload.

> # dampening applied or about to be applied on prefix Z

I agree that structured messages certainly have their place, and I agree 
that prefix-limit reaching/exceeded/etc is certainly best served by that 
type of message, but I don't think this replaces the benefits of a 
free-form text message. There are already notification messages for a 
peer hard clear, but they aren't capable of telling the other side WHY 
the session was cleared.

This issue reaches beyond the world of protocol design, and plants
itself firmly in the realm of the network operator community. Certainly
every network operator I've talked to has all but jumped for joy at the
prospect of having this functionality, and I'm certain we can find a few
of them to state as much on this list. The only thing the IETF needs to
do is provide the communication mechanism (which is fortunately
extremely simple to do), and then leave the network operators to use the
tool as they see fit.

-- 
Richard A Steenbergen <[email-masked]>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

---

From: "Seely, Ted A [CTO]" <[email-masked]>
Date: Tue, 24 Mar 2009 14:43:22 -0500

+1

________________________________
From: Richard A Steenbergen <[email-masked]>
Date: Tue, 24 Mar 2009 13:58:14 -0500
To: Robert Raszuk <[email-masked]>
Cc: "SCHOLL, TOM (ATTLABS)" <[email-masked]>, idr <[email-masked]>
Subject: Re: [Idr] draft-scholl-idr-advisory-00

--
Richard A Steenbergen <[email-masked]>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

________________________________
This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Marcelo Schmidt <[email-masked]>
Date: Tue, 24 Mar 2009 13:01:52 -0700

+1

On Tue, Mar 24, 2009 at 11:58:14AM -0700, Richard A Steenbergen wrote:
>    Richard A Steenbergen <[email-masked]>
>    [1]http://www.e-gerbil.net/ras
>    [2]https://www.ietf.org/mailman/listinfo/idr
> 
> References
> 
>    1. http://www.e-gerbil.net/ras
>    2. https://www.ietf.org/mailman/listinfo/idr

-- 
-m

====================================================================
Key fingerprint = 8E48 6CD0 6D2B 538E 264B  D1D0 21E2 E7EE A40F 2A0B
gpg --keyserver wwwkeys.pgp.net --recv-keys 0xA40F2A0B
====================================================================

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 24 Mar 2009 13:16:16 -0700

Hi Richard & others,

> sending messages to other networks, even if they don't when receiving

I fully agree with this as well. I know there are thousands of smaller 
networks. I hope nothing what I said contradicts this.

The goal is to find a solution which works for all networks sizes not 
just for the small ones. And IMHO the solution I proposed does work for 
both .. large and small networks equally well.

> or netconf, and picked up via an snmp trap or other monitoring tool

Agreed too.

> capability and is even capable of receiving the message.

I am not arguing against standardizing a tool. If you read my mail right 
I in fact proposed to standardize and enhancement which will make 
similar tool, as flexible as the one proposed with more benefits more 
accurate then what we have today.

I just don't see a benefit to use routing protocol (here BGP) to send an 
SMS to a peering router when we know ahead of time that the router will 
not do anything with it other then log to a syslog.

Email based auto generated messages from one ASBR to end up in many 
places automatically ... at peer's admin NOC, at pager, at syslog all 
automated. This is in contrast to grabbing them from syslog and 
distributing to all of the above interested parties.

> think up every possible message type beforehand.

100% agreed !!! I am in full favor and support to send auto generated 
free form messages. All discussion here is just about in what envelope 
to put such message not if to put it or not.

> more layer 8 signaling. 

Nope .. as I indicated NOC info can be auto-negotiated inbound. I see no 
reason why not. That would be just one new BGP capability as opposed to 
new BGP message which will need to be parsed, which will take room of 
your ever starving BGP IO input queues, which will keep real routing 
information behind not too mention bgp keepalives etc ...

I have seen so many BGP input queues issues in different BGP 
implementations that putting free form text even in the new message type 
into the same queue where is does not really belong seems to me as an 
unnecessary risk.

To summarize I am all for introducing automation and making operators 
life easier. I was one myself in the past :) My point is that if we make 
a decision on what envelope to put such free text messages into let's 
just consider all factors and risks involved in any choice which is made.

Cheers,
R.

PS. I am not arguing that emial is the best out of band vehicle for this 
  either .. it was the simplest I could think about. But I don't think 
that BGP4 protocol is. Perhaps there will be other suggestions .....

---

From: David McKay <[email-masked]>
Date: Tue, 24 Mar 2009 13:24:12 -0700

Again, +1.

2009/3/24 Marcelo Schmidt <[email-masked]>:
>>    >
>>    > * Parsing is an issue on the receiving side. Imagine the case how
>>    > efficient and doable this solution is considering that your ASBR may
>>    be
>>    >  peering  to 4000 up/down-stream peers as pointed out by Vijay. Each
>>    of
>>    >  those  4000  peers  would  first  need  to  be able to support such
>>    parsing,
>>    > understand to notify it's own administrator or NOC.
>>    > * The proposed solution is very difficult deployment wise as both
>>    > peering sides must support the functionality.
>>    > As pointed out yesterday by Keyur Patel or for that matter by Pedro
>>    > Marques when in July 2002 INFORM draft was discussed we are in no
>>    > position to automate all possible actions on the receiver of such
>>    >  warning.  This  is the other side's operator which can in turn make
>>    some
>>    >  decisions.  (Note  that  for  the  reload  itself  there  are other
>>    proposals
>>    > for example one by Bruno - on how to make it graceful).
>>    > * To simplify the solution as well as avoid the must for protocol
>>    > changes to make it working. There is one protocol enhancement I will
>>    >  propose instead which could be just an optimization ie solution can
>>    work
>>    > without it.
>>    > * To use automated out of band email based notification directly
>>    > targeting corresponding NOC or admin of the peer, but auto generated
>>    > from the router itself
>>    >
>>    > * To optionally allow for auto-receive of the per SAFI remote peer's
>>    >  admin/noc  email address where the advisory messages should be send
>>    to
>>    >
>>    > Coming back to our original diagram:
>>    >
>>    >                    ___________________________________
>>    >                   |                                   |
>>    >                   ^                                   v
>>    > NOC_A -> ISP_A @ ASBR_A == EBGP == ASBR_B @ ISP_B -> NOC_B
>>    > In unplanned threshold based events the only difference is that this
>>    is
>>    > not NOC_A's operator but ASBR_A generating the msg itself.
>>    >
>>    > Examples of planned messages/warnings:
>>    >
>>    > # router reload
>>    > # peer hard clear
>>    >
>>    > Examples of unplanned threshold based messages:
>>    >
>>    > # prefix-limit reaching X%
>>    > # dampening applied or about to be applied on prefix Z
>>    > etc...

-- 
Dave McKay
[email-masked]

---

From: kris foster <[email-masked]>
Date: Tue, 24 Mar 2009 13:34:18 -0700

I support Richard's comments

---

From: "SCHOLL, TOM (ATTLABS)" <[email-masked]>
Date: Tue, 24 Mar 2009 17:08:20 -0400

> that BGP4 protocol is. Perhaps there will be other suggestions .....

During the session yesterday, Dave Ward brought up that syslog was a
potentially viable option. However, I disagree that opening up UDP/514
to BGP neighbors is the right thing to do.

The problem with this is how do you know the datagrams you are receiving
are from the BGP neighbor and are not spoofed? Sure, one could say that
with TTL-security, you could only accept datagrams with TTL=255. But a
large amount of peering is done on broadcast LANs where everyone is
directly connected to each other (and would appear to be 1-hop away).
This is the common configuration at popular Internet exchange locations
(AMSIX, LINX, Equinix, Switch & Data aka PAIX). There's no way to
guarantee that datagram didn't come from someone else. 

Also, eBGP-multihop is used at times to peer with devices more than one
hop away in settlement-free environments. TTL security would not be
useful in this example as the TTL would come in < 255 from the
legitimate neighbor.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 24 Mar 2009 14:17:03 -0700

Hi Tom,

> guarantee that datagram didn't come from someone else. 

Actually why not ? If we make it MD5 or IPSec secured ?

> useful in this example as the TTL would come in < 255 from the

Again MD5 or IPSec syslog protocol would be just fine for those as well.

Thinking about good comments from Richard on the security aspect of 
using email as the envelope I have two comments ...

* I did not say that this communication should be done in open full of 
spam internet email system. One can over couple of hours build a private 
  set of smtp hosts fully isolated from reception of the external spam :)

* Even if this WG insists on using BGP .. just because it is there 
already .. I would strongly suggest not to mix is with routing 
information over the same session.

Cheers,
R.

---

From: Will Hargrave <[email-masked]>
Date: Wed, 25 Mar 2009 00:34:28 +0000

Richard A Steenbergen wrote:
> itself firmly in the realm of the network operator community.
> Certainly every network operator I've talked to has all but jumped
> for joy at the prospect of having this functionality, and I'm certain
> we can find a few of them to state as much on this list. The only
> thing the IETF needs to do is provide the communication mechanism
> (which is fortunately extremely simple to do), and then leave the
> network operators to use the tool as they see fit.

+1 from here.

A good comparison which could be drawn here is the 'interface
description' sub-TLV in pseudowire signalling [1]. Absolutely no use to
routers, but is an optional human-readable string provided solely for
the benefit of the humans attached to the router.

It is carried alongside existing NLRI using a routing protocol - in this
case LDP - as an extension for the operator's convenience.

IMO syslog, email, md5, ipsec, are unnecessary complexities in this case
 - as proposed this solution would be immediately useful with no further
complex infrastructure deployment necessary. It might even build real
demand for more advanced features in this area in future.

[1] for example, see RFC4447 section 5.5

---

From: Danny McPherson <[email-masked]>
Date: Tue, 24 Mar 2009 19:21:41 -0600

On Mar 24, 2009, at 3:08 PM, SCHOLL, TOM (ATTLABS) wrote:

> potentially viable option.

Tom,
I _think he was being facetious...

-danny

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Tue, 24 Mar 2009 22:09:29 -0700

The authors would like to request that draft-rosen-idr-aigp-00.txt
be adopted as an IDR WG document. We presented it yesterday @ IDR.

---

From: Dong Jie <[email-masked]>
Date: Wed, 25 Mar 2009 16:13:43 +0800

Hi Robert and others, 

> not do anything with it other then log to a syslog.

Agreed. IMO, the concern is whether to send advisory messages in-band or
out-band, and it should depend on the purpose of the message. If the message
requires instant feedback of the peer, it should be sent in-band, and the
peering router should have the capability to parse that message. If it's not
this case, as Robert said, just some information to be logged, the message
should be sent out-band, and stored somewhere, so the operators can check it
when needed.

> information behind not too mention bgp keepalives etc ...
Agreed.

Best regards,
Dong Jie

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 Mar 2009 01:40:10 -0700

Hi Dong,

Agreed !

There is in fact one observation I forgot to mention ...

It seems perfectly feasible that some operators would like to allow to 
accept not all of such messages, but subset of them. If such message is 
sent in-band the practical filtering point would your BGP inbound policy.

Do operators really want to add advisory free form text clauses into 
your real BGP inbound routing policy ? Aren't we already running today 
with issues about load associated with your BGP policy processing ?

If we go along the lines of using BGP in-band do we also need to 
consider defining new ORF type for it ?

Cheers,
R.

PS: IMHO procmail is a much more efficient tool then your favorite BGP 
regex policy engine in filtering for free form text.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 25 Mar 2009 11:32:38 -0400

Without taking a position on this draft, I would like to make a comment.

> I  agree that structured  messages certainly  have their  place ...  but I
> don't think this replaces the benefits of a free-form text message

There are protocols that convey  errors and/or advisory notices in free-from
text messages.  SMTP is one prominent example.

The result is that for every condition of note, there are dozens of possible
text strings  you might  get.  Further, the  identical text string  from two
different implementations  might mean two completely  different things.  Not
only that,  the text  string might be  in a  language not understood  by the
recipient, or even in a language that can't be meaningfully displayed at the
receiving end. 

There's also the  prospect of text strings which  do not accurately describe
the  condition that  elicited  them.  E.g.,  ever  have a  browser tell  you
"cannot contact  host" when the  problem is that  the local DNS  resolver is
down?

> Certainly every network operator I've talked to has all but jumped for joy
> at the prospect of having this functionality

All I  can say  is that when  I was  managing a large  international mailing
list, I  would have jumped for joy  at the prospect of  eliminating the SMTP
text strings in favor of a set of well-defined error codes ;-)

So  I tend  to  think that  getting real  utility  out of  a free-form  text
capability is not as straightforward as it seems.

---

From: Marcelo Schmidt <[email-masked]>
Date: Wed, 25 Mar 2009 08:52:47 -0700

I support this comment.  The technical issues we are discussing in this 
advisory draft were discussed and some of them resolved in SNMP, STMP, SIP, 
HTTP, IRC, etc.  If with all these other tools plus the legacy of phone 
lines we cannot communicate better, then the problem is not going to be 
solved by adding a new type of message.  I think we have enough tools but 
we lack of a standardization in the language we use to communicate events.  
If we can define a draft with these standardization first, then we could 
revisit the delivery method again IMHO.

-m

On Wed, Mar 25, 2009 at 08:32:38AM -0700, Eric Rosen wrote:
>    for joy
>    [1]https://www.ietf.org/mailman/listinfo/idr
> 
> References
> 
>    1. https://www.ietf.org/mailman/listinfo/idr

-- 
-m

---

From: Will Hargrave <[email-masked]>
Date: Wed, 25 Mar 2009 16:19:41 +0000

Eric Rosen wrote:
[snip]
> text strings in favor of a set of well-defined error codes ;-)

RFC2821 says that the numerical portion is intended for machines and the free
form text is intended for humans to aid with troubleshooting. It sounds like
your problems resulted more from a lack of available numerical reply code types
to describe the problem at hand, rather than a requirement to parse the text
portion. But I was not there, so feel free to correct me on this :-)

I think a key part of the proposal is the ability to convey messages about a
situation we haven't come across yet, so cannot yet standardise or form process
for.

Will

---

From: Richard A Steenbergen <[email-masked]>
Date: Wed, 25 Mar 2009 11:27:37 -0500

> recipient, or even in a language that can't be meaningfully displayed at the

You're talking about specific errors with specific causes, which I
completely agree should be reported with specific standardized error
codes. I don't think it would be appropriate to replace all NOTIFICATION
messages with free form text either, for example. SMTP is also not an 
always connected protocol which is synchronizing state for the routing 
of potentially many tens of billions of bits/sec on every session, with 
serious technical and financial consequences if it becomes disconnected 
for even a few seconds. These are very different protocols with very 
different goals.

The one thing I really don't understand the arguments being made against
this draft from a theoretical "protocol purity" perspective. To me this
seems to have as much logic as saying "we shouldn't send notification
codes because this is a routing protocol and sending messages like this 
does not help routing, we should send ipsec authenticated syslog to 
convey the reason for the notification to keep the protocol pure". 

The argument that "$x is an existing method for doing something therefore 
we should always use it" also strikes me as incorrect. SMTP is a method 
for sending communication between devices on the Internet, therefore we 
should use it implement routing protocols? No, SMTP is a method for 
delivering e-mail to an extremely large base of users on the Internet, 
but it is not necessarily the only or best way to communicate between 
two devices on the Internet.

This isn't about using BGP as a chat system, this is about adding a
mechanism to better operate and troubleshoot the protocol, using the
protocol itself as a pre-configured and pre-authenticated way to convey
these messages. In my mind it is little different from a NOTIFICATION
message being used to the same effect, and it has the bonus of being
remarkably simple to implement. These other proposals look like horrible
kludges to accomplish the same goal, but they're so complicated and
introduce so many new inter-network communication hassles that I don't
see a way anyone would ever implement them. At the end of the day, are
we trying to design a "pure" protocol, or are we trying to help network
operators make BGP work better for its intended goal as a routing
protocol?

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 25 Mar 2009 10:41:05 -0700

This is what management protocols were invented for.
A management protocol is sepatated from the equipment it's
managing, so that it can operate when that equipment is faulty.
Also called "out of band".
It can be maintained separately from the managed equipment. Eg, load a 
new MIB.
It can be hooked into other automated processes: network management systems.
The management protocol for internet equipment is SNMP, not email.
Use it.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 Mar 2009 10:55:56 -0700

Hi Jakob,

> The management protocol for internet equipment is SNMP, not email.

I think SNMP works well intra-domain. This little thread is focusing on 
inter-domian tools.

I have a lot of sympathy for Tom, Richard and others for asking for a 
tool which would provide them automated easy ability to communicate with 
peers.

Apparently there is not enough of good management tools which would 
focus on inter-AS communication. All I know I pretty contain to your own 
AS.

We need to keep in mind that today's most routers while quite capable of 
don't have fully automated way or well documented for that matter to 
auto generate information and even send it out of band to interested 
parties. Maintaining a valid list of those interested parties is also a 
good exercise if we keep this as a manual process.

Let's start with that.

Phase II would be to worry about how to distribute those information 
inter-as. I will still argue that they should not mixed with routing, 
but I see a need for other ways and the pendulum of choices is wide and 
I think we could satisfy the need without exposing any risk on current 
BGP4 as a routing protocol.

Cheers,
R.

---

From: Gargi Nalawade <[email-masked]>
Date: Wed, 25 Mar 2009 14:24:12 -0700

Actually that was what the WG had suggested using instead in 2002/3, when the draft on the INFORM message was not accepted as a WG item.

-Gargi
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Danny McPherson [[email-masked]]
Sent: Tuesday, March 24, 2009 6:21 PM
To: SCHOLL, TOM (ATTLABS)
Cc: idr
Subject: Re: [Idr] draft-scholl-idr-advisory-00

Tom,

-danny

---

From: Gargi Nalawade <[email-masked]>
Date: Wed, 25 Mar 2009 15:45:28 -0700

>"cannot contact  host" when the  problem is that  the local DNS  resolver is

Isnt that what standardization is for? So that all implementations could agree
on what to send and interpret?  

In which case we would be talking about standardizing text strings now or
abbreviating them and we are back to message codes.

-Gargi

---

From: Kristian Larsson <[email-masked]>
Date: Wed, 1 Apr 2009 00:00:09 +0200

+1 in favor of the draft.
 
  -K

---

From: Adam Rothschild <[email-masked]>
Date: Tue, 31 Mar 2009 18:15:31 -0400

+1 here.

We're sufficiently deep in commentary on this thread; usual pedantry
aside, I've yet to see a clear explanation of what Bad Things would
happen if we were to move forward with Mr. Scholl's proposal.

As a network heavily invested in exchange peering, out-of-band
communication is all well and good on paper, but in practice, often
easier said than done when attempting to interface with a wide variety
of remote networks (of varying competence, staffing/coverage, language
comprehension, ...) in real time.  Tom's implementation augments the
protocol with a much-needed last resort.

-a