--- 1/draft-ietf-grow-bmp-14.txt	2015-08-11 15:15:01.518645398 -0700
+++ 2/draft-ietf-grow-bmp-15.txt	2015-08-11 15:15:01.574646752 -0700
@@ -1,21 +1,21 @@
 
 Network Working Group                                    J. Scudder, Ed.
 Internet-Draft                                          Juniper Networks
 Intended status: Standards Track                             R. Fernando
-Expires: February 8, 2016                                  Cisco Systems
+Expires: February 12, 2016                                 Cisco Systems
                                                                S. Stuart
                                                                   Google
-                                                          August 7, 2015
+                                                         August 11, 2015
 
                         BGP Monitoring Protocol
-                         draft-ietf-grow-bmp-14
+                         draft-ietf-grow-bmp-15
 
 Abstract
 
    This document defines a protocol, BMP, that can be used to monitor
    BGP sessions.  BMP is intended to provide a convenient interface for
    obtaining route views.  Prior to introduction of BMP, screen-scraping
    was the most commonly-used approach to obtaining such views.  The
    design goals are to keep BMP simple, useful, easily implemented, and
    minimally service-affecting.  BMP is not suitable for use as a
    routing protocol.
@@ -28,21 +28,21 @@
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.
 
    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."
 
-   This Internet-Draft will expire on February 8, 2016.
+   This Internet-Draft will expire on February 12, 2016.
 
 Copyright Notice
 
    Copyright (c) 2015 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
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
@@ -834,21 +834,24 @@
    the authors envision this list may grow in the future with new
    applications that require BMP-style monitoring.
 
 8.  Other Considerations
 8.1.  Multiple Instances
 
    Some routers may support multiple instances of the BGP protocol, for
    example as "logical routers" or through some other facility.  The BMP
    protocol relates to a single instance of BGP; thus, if a router
    supports multiple BGP instances it should also support multiple BMP
-   instances (one per BGP instance).
+   instances (one per BGP instance).  Different BMP instances SHOULD
+   generate Initiation Messages that are distinct from one another, for
+   example by using distinguishable sysNames or by inclusion of
+   instance-identifying information in a string TLV.
 
 8.2.  Locally-Originated Routes
 
    Some consideration is required for routes originated into BGP by the
    local router, whether as a result of redistribution from a another
    protocol or for some other reason.
 
    Such routes can be modeled as having been sent by the router to
    itself, placing the router's own address in the Peer Address field of
    the header.  It is RECOMMENDED that when doing so the router should
@@ -1046,25 +1049,25 @@
 
    Where the security considerations outlined above are a concern, users
    of this protocol should consider using some type of transport that
    provides mutual authentication, data integrity and transport
    protection, such as IPsec [RFC4303] or TCP-AO [RFC5925].  If
    confidentiality is considered a concern, a transport providing that
    as well could be selected.
 
 12.  Acknowledgements
 
-   Thanks to Ebben Aries, Michael Axelrod, Tim Evens, Pierre Francois,
-   Jeffrey Haas, John ji Ioannidis, John Kemp, Mack McBride, Danny
-   McPherson, David Meyer, Dimitri Papadimitriou, Tom Petch, Robert
-   Raszuk, Erik Romijn, and the members of the GROW working group for
-   their comments.
+   Thanks to Ebben Aries, Michael Axelrod, Serpil Bayraktar, Tim Evens,
+   Pierre Francois, Jeffrey Haas, John ji Ioannidis, John Kemp, Mack
+   McBride, Danny McPherson, David Meyer, Dimitri Papadimitriou, Tom
+   Petch, Robert Raszuk, Erik Romijn, Peter Schoenmaker and the members
+   of the GROW working group for their comments.
 
 13.  References
 
 13.1.  Normative References
 
    [I-D.ietf-idr-error-handling]
               Chen, E., Scudder, J., Mohapatra, P., and K. Patel,
               "Revised Error Handling for BGP UPDATE Messages", draft-
               ietf-idr-error-handling-19 (work in progress), April 2015.