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

From: [email-masked]
Date: Sat, 17 Oct 2009 06:00:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title           : BGP Advisory Message
	Author(s)       : T. Scholl, et al.
	Filename        : draft-ietf-idr-advisory-00.txt
	Pages           : 7
	Date            : 2009-10-16

The BGP routing protocol is used with external as well as internal
neighbors to propagate route advertisements.  In the case of external
BGP sessions, there is typically a demarcation of administrative
responsibility between the two entities.  Provisioning, maintenance
and administrative actions are communicated via off-line methods such
as email or telephone calls.  While these methods have been used for
many years, it can be troublesome for an operator to correlate a BGP-
related event in the network with a notice that was transmitted in
email.

This document proposes a new BGP message type, the Advisory message,
which can be used to convey advisory information to a BGP speaker's
peer.  A capability is used to ensure that the recipient of the
Advisory message is capable of supporting it.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-advisory-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Tue, 20 Oct 2009 09:26:20 +0200

Hello,

> This document proposes a new BGP message type, the Advisory 
> message, which can be used to convey advisory information to 
> a BGP speaker's peer.  A capability is used to ensure that 

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?

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.

Cheers,
iLya

---

From: Rob Shakir <[email-masked]>
Date: Tue, 27 Oct 2009 19:37:03 +0000

Hi,

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

> 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                      <[email-masked]>
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