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

[john heasley <heas at shrubbery.net>]

Thu, Jul 02, 2009 at 12:58:49PM -0400, Dorian Kim:
> On Thu, Jul 02, 2009 at 09:04:52AM -0700, Robert Raszuk wrote:
> > Hi Dorian,
> > 
> >> Given the actual practices of operators today, and the realities of poor 
> >> coordination in most cases, this proposal will provide a net benefit
> >> to day to day operations of the Internet.
> > 
> > It will - I agree. But it will by a sort of patch and accept the actual 
> > practices and realities of poor coordination isn't it ?
> 
> I think too much discussions down this path will lead us into varying
> degress of organisational pathologies and not very useful. IDR will not
> and cannot change the way ISPs operate nor will it be able to  address the 
> root cause of the disfunction in inter-ISP and even intra-ISP communications. 
> 
> That's almost entirely in the realm of social engineering and we've been down
> that road many times before to no fruitful end.
> 
> Leaving that aside, people who run networks are asking for this because it solves
> a real world problem they encounter. That by itself should in my opinion be enough
> for the working group to decide on "should this be discussed and worked on here"
> question.
>  
> > I think some people at last IETF proposed to look into INFORM draft ... It 
> > can be extended with as many pre-defined messages as required. I have not 
> > see much discussion comparing both.
> > 
> > I think we here are essentially making the call if free form text to 
> > syslog/show command is something we should endorse in the BGP protocol or 
> > not.
> > 
> > If we do let's proceed with the advisory draft making it just a bit more 
> > robust, if not let's resubmit INFORM and make sure it will address all BGP 
> > messaging requirements in a well pre-defined form.
> > 
> > Or perhaps both should be done ?
> 
> I'm most likely not the best advocate for this draft since I'm somewhat lukewarm
> about its benefit given the cost. However, allow me to bring up and analogy
> with all the usual caveats inherent in anaologies. CLNS host info doesn't by 
> itself amount to much, but has shown itself to be of many time saving operational
> uses. So to that extent, some facilities for having a limited free form text
> to syslog command tied to BGP may be of more use than we can think of at the moment.

this would be a far more useful capability if
a) it were generated automatically by the router when possible; eg:
	send advisory 'over prefix limit'
	send cease
   OR
	send advisory 'reboot'
	send cease
   etc.
b) it had a non-freeform prefix defined by the draft that can be interpretted
   programmatically, like smtp, and the remainder freeform left for humans.
c) were included in the bgp state change or a advisory-specific snmp trap
   and mandated by the draft