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

[Curtis Villamizar <curtis at occnc.com>]

In message <20090707223132.GF26161 at shrubbery.net>
john heasley writes:
>  
> 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



I'm not sure why this could not be done with the existing
NOTIFICATION.  The Cease code has no subcodes, but 'over prefix limit'
and 'reboot' could certainly be added and there is already a data
field which is unused for Cease and could be defined as human readable
free form, zero padded.

As long as we can live with 256 Cease subcodes this should be OK.  The
catch is where we *don't* want to drop the session.

The original question was "should this be a WG draft".  The answer
seems to be "yes" and we are already debating the details.

Curtis