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

[Robert Raszuk <[e-mail]>]

Hi Richard & others,

> On Tue, Mar 24, 2009 at 09:01:36AM -0700, Robert Raszuk wrote:
>> * 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.
> 
> 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.

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.

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

Agreed too.

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

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.

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

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.

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

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