[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-scholl-idr-advisory) 00

Internet Engineering Task Force                                T. Scholl
Internet-Draft                                                       ATT
Intended status: Standards Track                              J. Scudder
Expires: April 20, 2010                                 Juniper Networks
                                                          R. Steenbergen
                                                 Server Central / nLayer
                                                             D. Freedman
                                                        Claranet Limited
                                                        October 17, 2009

                          BGP Advisory Message

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 20, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Scholl, et al.           Expires April 20, 2010                 [Page 1]

Internet-Draft            BGP Advisory Message              October 2009


   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

   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.

1.  Introduction

   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.  While initial configuration
   and troubleshooting of these sessions is handled via offline means
   such as email or telephone calls, there is gap when it comes to
   advising a BGP neighbor of a behavior that is occurring or will occur
   momentarily.  There is a need for operators to transmit a message to
   a BGP neighbor to notify them of a variety of types of messages.
   These messages typically would include those related to a planned or
   unplanned maintenance action.  These advisory messages could then be
   interpreted by the remote party and either parsed via logging
   mechanisms or viewed by a human on the remote end via the CLI.  This
   capability will improve operator NOC-to-NOC communication by
   providing a communications medium on an established and trusted BGP
   session between two autonomous systems.

   The reason that this method is preferred for NOC-to-NOC
   communications is that other offline methods do fail for a variety of
   reasons.  Emails to NOC aliases ahead of a planned maintanance may
   have ignored the mail or may have not of recorded it properly within
   an internal tracking system.  Even if the message was recorded
   properly, the staff that is on-duty at the time of the maintenance
   event typically was not the same staff who received the maintenance
   notice several days prior.  In addition, the staff on duty at the
   time of the event may not even be able to find the recorded event in
   their internal tracking systems.  The end result is that during a
   planned event, some subset of eBGP peers will respond to a session/

Scholl, et al.           Expires April 20, 2010                 [Page 2]

Internet-Draft            BGP Advisory Message              October 2009

   peer down event with additional communications to the operator who is
   initiating the maintenance action.  This can be via telephone or via
   email, but either way, it may result in a sizable amount of replies
   inquiring as to why the session is down.  The result of this is that
   the NOC responsible for initiating the maintenance can be innundated
   with calls/emails from a variety of parties inquiring as to the
   status of the BGP session.  The NOC initating the maintenance may
   have to further inquire with engineering staff (if they are not
   already aware) to find out the extent of the maintenance and
   communicate this back to all of the NOCs calling for additional
   information.  The above scenario outlines what is typical in a
   planned maintenance event.  In an unplanned maintenance event (the
   need for and immediate router upgrade/reload), the number of calls
   and emails will dramatically increase as more parties are unaware of
   the event.

   With the BGP advisory capability, an operator can transmit an
   advisory message just prior to initiating the maintenance specifying
   what event will happen, what ticket number this event is associated
   with and the expected duration of the event.  This message would be
   received by BGP peers and stored in their router syslog as well as
   any monitoring system if they have this capability.  Now, all of the
   BGP peers have immediate access to the information about this
   session, why it went down, what ticket number this is being tracked
   under and how long they should wait before assuming there is an
   actual problem.  Even smaller networks without the network management
   capabilities to corrolate BGP events and advisory messages would
   typically have an operator login to a router and examine the logs via
   the CLI.

   There are several problems with e-mail only notifications:

         Up-to-date contact information is fairly difficult to maintain.
         Some networks who have very open peering policies may peer with
         up to 1,000 unique ASNs.

         A NOC e-mail address does not always reach its way to the
         proper individuals at the NOC.  A large amount of e-mail
         received at NOC aliases are typically spam or issues not
         appropriate for a typical NOC queue.

         E-mail is not real time.  In some environments, e-mail
         processing can be delayed and when looking at unplanned
         maintenances, some operators do not have the time to draft an
         e-mail as well as the distribution list.

   There are several advantages to the advisory capability to operators:

Scholl, et al.           Expires April 20, 2010                 [Page 3]

Internet-Draft            BGP Advisory Message              October 2009

         There is no requirement for an external contact database.
         Contact databases are important, but this capability provides a
         way for an operator to transmit a message about a specific BGP
         session with no external contact information being required.

         The very existance of the BGP session itself has inherent
         authentication and message routing properties.  An operator
         immediately knows for every advisory message that it is coming
         from someone you are directly connected to (and thus have a
         relationship with) and which particular BGP session this is
         regarding.  This is all completed without any additional human
         parsing required.

         Because there is a BGP session that exists, an operator already
         has an authenticated session.  There is no requirement for
         further authentication of the BGP session (key exchange).

         The advisory message provides for real-time delivery of a
         message to a BGP neighbor.  This will provide a rapid option in
         comparison to drafting an email to all BGP peers and waiting
         for the receipt before commencing with an unplanned maintenance

   This draft aims to provide operators with the capability to transmit
   an advisory message to BGP peers to assist with daily network

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Capability

   A new BGP capability [RFC5492] called Advisory is introduced, with
   type code TBD.  This capability indicates that the router advertising
   it is capable of receiving and parsing Advisory messages.  The
   capability is of variable length.  The data portion of the capability
   lists the Advisory message subtypes which are supported.  The String
   subtype MUST be supported, which implies that the length MUST be at
   least 2 if the capability is advertised.

3.  Advisory Message

   The Advisory message is a BGP message of type TBD.  It consists of a

Scholl, et al.           Expires April 20, 2010                 [Page 4]

Internet-Draft            BGP Advisory Message              October 2009

   BGP fixed header followed by a two-byte subtype and a data portion of
   variable length, calculated according to the Length field in the
   fixed header.  The format of the data portion is dependent on the
   subtype.  This document defines the following subtypes:

      0 - Reserved:

         MUST NOT be sent, MUST be ignored (other than optionally
         logging an error) on receipt.

      1 - Advisory String:

         A message comprised of a string of ASCII characters.  The
         string's length is given by the length of the message, there is
         no null termination.  Upon reception, the string SHOULD be
         reported to the router's administrator.  The means of reporting
         the string are implementation-specific but could include
         methods such as syslog.

      2 - Static String:

         A message comprised of a string of ASCII characters.  The
         string's length is given by the length of the message, there is
         no null termination.  Upon reception, the string SHOULD be
         stored in a BGP neighbor statistics field within the router.
         This string would then be accessable to the operator by
         executing CLI commands or any other remote method to obtain BGP
         neighbor statistics (NETCONF, SNMP).  The expectation is that
         the last static message received from a BGP neighbor will be
         the message visible to the operator (the most current static

   While this document mandates no particular events for which advisory
   messages should be generated, there are a variety of applications
   where the advisory message may be used.  Implementations SHOULD
   provide its users the ability to transmit a free form text message
   generated by user input.

   Implementations MAY choose to define a standard set of advisory
   messages that are automatically driven rather than requiring a human
   to enter specific reasons.  These messages may be automatically
   transmitted based upon specific router functions such as a router
   reload, administrative action (neighbor shutdown) or reconfiguration
   (new BGP address-family support).

   Implementations SHOULD provide router administrators with the ability
   to filter out specific BGP Advisory message types on a per neighbor
   or per peer-group basis.  This interface should be provided to the

Scholl, et al.           Expires April 20, 2010                 [Page 5]

Internet-Draft            BGP Advisory Message              October 2009

   operator to clearly define if they want advisory, static or both
   types of messages.

   Implementations MUST rate-limit the rate in which they transmit and
   receieve advisory messages.  Specifically, an implementation MUST NOT
   allow the handling of advisory messages to negatively impact any
   other functions on a router such as regular BGP message handling or
   other routing protocols.

   As its name implies the Advisory message is intended to be used to
   advise a peer of some condition which may be of interest to that peer
   (or its administrator).  It MUST NOT be used as a replacement for the
   Notification message in fatal error situations (i.e., situations
   where the integrity of the BGP peering is violated or suspect),
   although an Advisory message MAY precede a Notification message.

4.  Error Handling

   An Advisory message MUST NOT be sent to any peer which has not
   advertised the Advisory capability indicating support for the
   relevant subtype.  If a router which has advertised the Advisory
   capability receives an Advisory message with a subtype for which it
   has not advertised support, it MUST accept and discard that message.
   It MAY locally log an error when this occurs.

5.  IANA Considerations

   IANA is requested to allocate a type code for the Advisory message
   from the BGP Message Types registry, to allocate a type code for the
   Advisory Capability from the Capability Codes registry, and to
   establish and maintain a registry for BGP Advisory message subtypes,
   to be allocated according to the First Come First Served policy
   defined in [RFC5226].

6.  Security Considerations

   No new security issues are introduced to the BGP protocol by this

7.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Scholl, et al.           Expires April 20, 2010                 [Page 6]

Internet-Draft            BGP Advisory Message              October 2009

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5492]  Scudder, J. and R. Chandra, "Capabilities Advertisement
              with BGP-4", RFC 5492, February 2009.

Authors' Addresses

   Tom Scholl

   Email: tom.scholl@att.com

   John Scudder
   Juniper Networks

   Email: jgs@juniper.net

   Richard Steenbergen
   Server Central / nLayer

   Email: ras@e-gerbil.net

   David Freedman
   Claranet Limited

   Email: david.freedman@uk.clara.net

Scholl, et al.           Expires April 20, 2010                 [Page 7]

Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/