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

From: "David Freedman" <[email-masked]>
Date: Wed, 25 Mar 2009 23:34:16 -0000

>If a protocol- 
>supported identification of planned maintenance is truely necessary

Can we please stop limiting the scope of this to simply conveying planned maintenance announcements, 
I want a non-terminal NOTIFICATION to be carried INSIDE BGP, that is my main care here. 
Give me a nonterminal NOTIFICATION and I'll be happy.

Dave.

------------------------------------------------
David Freedman
Group Network Engineering 
Claranet Limited
http://www.clara.net

---

From: "Neil J. McRae" <[email-masked]>
Date: Thu, 26 Mar 2009 08:44:02 -0000 (GMT)

> Give me a nonterminal NOTIFICATION and I'll be happy.

On this point I agree with Dave its something that is long overdue.

Neil.
--
Neil J. McRae -- Alive and Kicking.
[email-masked]

---

From: Jeff S Wheeler <[email-masked]>
Date: Thu, 26 Mar 2009 05:21:05 -0400

> On this point I agree with Dave its something that is long overdue.
This is not really the intent of the Scholl Plan, but if you are going
to imagine up some more convenience features, I would like the remote
BGP speaker to occasionally inform me of the number of BGP prefixes I
advertise which were rejected by policy, e.g. prefix-list has not been
updated.  I don't propose that the router send back an acknowledgment
each time it chooses to accept a route, but an update at similar
interval to keep-alive messages would be a nice capability.

To put it in context, how many times have you thought, hrm, I expected
more traffic from this neighbor, only to learn that they were rejecting
half of your advertisements due to misconfiguration or wrong information
supplied to the neighbor?

On Wed, 2009-03-25 at 13:47 -0700, Robert Raszuk wrote:
> It is still the same idea. It just requires an open mind to grasp it 
> apparently. Router generates notifications out-of-band of routing 
> information, those end up in syslogs of the peers, routers can display 
> the info just by retrieving it from syslog.
Well, I guess I'm suggesting another thing that can already be done
out-of-band by writing email to the neighbor's NOC or using a web-based
route server or well-connected router looking-glass.  Consider the time
savings and improvement in information availability, though.  I'm pretty
sure routing protocols were invented to automate the distribution of
routing information, reducing work and improving reliability.

On Thu, 2009-03-26 at 01:54 +0100, Elmar K. Bins wrote:
> I agree, something like Tom envisioned is definitely needed. It should be
> drafted and then implemented, and that needs to be done outside IDR, in a
> group that's more operations-focused, but at the same time not limited to
I agree with you that the IETF is entirely too focused on process and
not enough on accomplishing things.

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

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 26 Mar 2009 08:07:57 -0400

Sounds like the need for soft-notify is back -
http://tools.ietf.org/html/draft-nalawade-bgp-soft-notify-01

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jeff S Wheeler
> Sent: Thursday, March 26, 2009 5:21 AM
> To: [email-masked]
> Subject: Re: [Idr] draft-scholl-idr-advisory-00
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Richard A Steenbergen <[email-masked]>
Date: Thu, 26 Mar 2009 09:58:37 -0500

> On this point I agree with Dave its something that is long overdue.

In reality, the goals of the advisory msg draft and a soft NOTIFICATION
message are almost precisely the same. I suspect the reason the advisory
message was drafted this way was to say "here is something extremely
trivial to implement, that provides some solution to the problem, free
form is better than no message at all even in the cases where it isn't
perfect, and we can do it now".

I absolutely agree that structured messages for things like max-prefix
warnings and other automated router-generated events are the way to go
if possible, but I absolutely disagree that implementing a complex out
of band message delivery system is the right way to solve what is
essentially a need to deliver simple messages in-band. Maybe the right
way to approach this is to add soft notifications, define a slew of
message types that make sense for all the normal conditions that can be 
thought of, and just add a message type for free-form text as well.

The only feature in the advisory message draft that this wouldn't cover
is the "sticky note" concept. It seems like the goal here is to provide
a mechanism similar to a SONET path trace but for the BGP session, where
you would set a static message in your router config rather than via a
CLI operational command, and it would be transmitted and made available
in a "show bgp" rather than syslogged as an event requiring immediate
action. Some ideas for usage of this include NOC contact information,
"circuit id" type information, descriptions of the session (particularly
useful in the case of multiple sessions between networks, some
configured differently from others), etc. I still like this idea, but I
for one would be willing to live without it if it got the support of the
protocol purists for implementing the soft notifications above.

-- 
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: David Freedman <[email-masked]>
Date: Thu, 26 Mar 2009 15:06:27 +0000

I still like this idea, but I
> protocol purists for implementing the soft notifications above.

+1, I'm happy with SOFT-NOTIFICATION although it is a shame to miss out
on some of the features of ADVISORY

We could perhaps resurrect SOFT-NOTIFICATION and have the ADVISORY
"Sticky" messages be a vendor implementation using SOFT-NOTIFICATION
messages

Dave.