Re: [Idr] I-D Action:draft-ietf-idr-advisory-00.txt

[Rob Shakir <rjs at eng.gxn.net>]

Hi,

On 20 Oct 2009, at 08:26, Ilya Varlashkin wrote:
> The document proposes two sub-types (1&2) which appear to be very
> similar in format but somewhat different in expected reaction of the
> router. Is there sufficient need to separate on protocol level such
> messages? From operator prospective I see value in making any message
> visible among other neighbor-related information (in some sort of  
> 'show'
> command output) and any message may generate notification to caretaker
> (e.g. via syslog or snmp trap). Could both sub-types be combined into
> one and left upto operator to decide whether to log/trap them or not?

I am unsure as to whether I agree with this point - the types that are  
defined seem to set a precedent that for each type that is defined  
under ADVISORY, there is a requirement to define two types - one of  
which is 'static' and the other is limited in lifetime. There is  
definitely operational value in my eyes of being able to have a  
message that can be seen for a neighbour in a 'show ip bgp neigh  
x.y.z.a' type output, but as to whether this should be defined in the  
standard I am undecided.

Can the authors shed any light on the differentiation of these two  
messages, and why this detail should be defined in the standard, or  
require separate types, rather than some 'lifetime' flag that can be  
passed with the message? (I'm not sure I'd advocate this, but I am  
interested in why the current draft is as written).

> As for "standard set of advisory messages", it's probably good idea to
> document them in a separate draft/rfc rather than leaving it up to
> implementations to come up each with their own set of "standard
> messages". The list could be settled by asking network operators to
> submit their proposals, then have vendors say what's feasible or not.
> Such list should not be too long, but should cover most typical
> scenarios where advisory messages would be helpful.

I agree here -- it'd be good to have a separate draft that defined  
some common ADVISORY types that can be handled by an NMS system.

This continues to look like a really useful draft, thanks for the work  
thus far on it!

Kind regards,
Rob

--
Rob Shakir                      <rjs at eng.gxn.net>
Network Development Engineer    GX Networks/Vialtus Solutions
ddi: +44208 587 6077            mob: +44797 155 4098
pgp: 0xc07e6deb                 nic-hdl: RJS-RIPE

This email is subject to: http://www.vialtus.com/disclaimer.html