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

From: Jeff S Wheeler <[email-masked]>
Date: Tue, 24 Mar 2009 20:11:19 -0400

On Tue, Mar 24, 2009 at 09:01:36AM -0700, Robert Raszuk wrote:
> * 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
You want the router to write email to "4000" NOCs informing them of
pending maintenance?  I'm pretty sure there are better tools available
for that.  I like the idea that the same person who logs onto the router
to find out why a neighbor is down will have information about that
maintenance available in their log or `show bgp neighbor` output.  Then
they won't generate a useless email to your NOC asking why the session
to you is down, only to receive an "read the maintenance notice" reply.

> * 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
Why are we adding all this complexity to get information into an email
when it can be on the router?  While you're at it, let's process BGP
NLRI off-line because making something more convenient and accessible is
obviously against the nature of computing systems.

> * No need to modify BGP protocol (only if at all as an option we
Unless you want those email addresses to be learnt from the BGP neighbor
as you suggest.

> * Deployable today via already existing operating systems
Really?  I didn't know IOS knew how to write and send email.

> * Follows other standard industry practices where for example unix
> hosts or good firewalls have such admin email configurable already ...
> why router's don't ?
I didn't know there were firewalls that send email to third-parties, but
it wouldn't surprise me if someone developed a product this stupid.
What surprises me is that a network operator would think this is a good
idea.  Your email notion is not as crazy as a Sonicwall that looks up
abuse addresses in the RIR whois and sends a nasty-gram every time it
detects a port scan, but I don't think firewalls that know how to send
email are necessarily an example of good behavior.

> * No need to modify and parse anything at the potential 1000s of peers.
Your email-based solution has an advantage over BGP advisory because of
message parsing?  Wait, are we going to parse those NOC emails and do
something useful with them?  If so, we better write a tool for that,
just like we would need one to parse information from the router syslog
messages or `show bgp neighbor`.  If not, a human is going to have to
read those messages.  How does your proposal have an advantage in either
parsing work or savings in man-hours vs the Scholl plan?

-- 
Jeff S Wheeler <[email-masked]> +1-212-981-0607
Sr Network Operator  /  Innovative Network Concepts

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 24 Mar 2009 18:00:22 -0700

Hi Jeff,

> I like the idea that the same person who logs onto the router
 > when it can be on the router?

Do you keep your syslog on the router ?

I know operators who expressed interest in having a sort of BGP history 
database as their customers can month later come and ask why my sessions 
were down, why I was not able to reach ABC via your AS 4 weeks back 
between Mon 4:30-5:30 AM etc ...

I don't know why in particular session down/reset is the only BGP event 
that should be logged in no matter what mechanism is chosen to be used. 
Wouldn't you like to know who is behind at any given moment some prefix 
flapping ? Wouldn't you be curios why your ASBR is being bombarded by 
stream of bgp route refresh messages, why some peers are are falling 
from your peer group as too slow ?

On the other hand the model you suggest to receive a message, keep it 
"on the router" and only when logged in have it handy there for 
troubleshooting seems not in the spirit of passing warning like 
notifications for example prefix-limit reaching threshold.

As I know that many operators are very creative I am sure the list of 
such text events to pass between peers will just grow. The solution 
should be robust to accommodate it.

> Unless you want those email addresses to be learnt from the BGP neighbor

But the slight difference is that this is done once at the session 
establishment, the amount of information is limited, it does not 
interfere with routing information and it's optional.

> Really?  I didn't know IOS knew how to write and send email.

Last time I checked IOS you could pipe any output of a command to http 
cgi handler. The same basic mechanism can be used here.

> parsing work or savings in man-hours vs the Scholl plan?

I am not strongly suggesting email - it was just one example of out of 
band communication. I am just not seeing good fit to carry this inbound 
in BGP itself. Perhaps as suggested by Dave secure syslog to syslog 
channel is a good compromise ?

In the email case you don't need to parse anything in real time. It can 
after basic validation end-up in syslog, netlog, bgplog etc - any 
database and just like you look in the syslog for BGP received message 
when needed to troubleshoot a problem just query in the exact same way 
for the event advisory msg received from the given peer.

Now I am going to sit back, relax and watch how this thing evolves :)

Cheers,
R.