--- 1/draft-ietf-idr-bgp-ls-segment-routing-msd-12.txt	2020-03-03 09:13:39.214736439 -0800
+++ 2/draft-ietf-idr-bgp-ls-segment-routing-msd-13.txt	2020-03-03 09:13:39.250737355 -0800
@@ -1,26 +1,26 @@
 
 IDR Working Group                                            J. Tantsura
 Internet-Draft                                              Apstra, Inc.
 Intended status: Standards Track                             U. Chunduri
-Expires: September 2, 2020                        Futurewei Technologies
+Expires: September 4, 2020                        Futurewei Technologies
                                                            K. Talaulikar
                                                            Cisco Systems
                                                                G. Mirsky
                                                                ZTE Corp.
                                                         N. Triantafillis
                                                      Amazon Web Services
-                                                           March 1, 2020
+                                                           March 3, 2020
 
  Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link
                                  State
-              draft-ietf-idr-bgp-ls-segment-routing-msd-12
+              draft-ietf-idr-bgp-ls-segment-routing-msd-13
 
 Abstract
 
    This document defines a way for a Border Gateway Protocol - Link
    State (BGP-LS) speaker to advertise multiple types of supported
    Maximum SID Depths (MSDs) at node and/or link granularity.
 
    Such advertisements allow entities (e.g., centralized controllers) to
    determine whether a particular Segment Identifier (SID) stack can be
    supported in a given network.
@@ -33,21 +33,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 https://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 September 2, 2020.
+   This Internet-Draft will expire on September 4, 2020.
 
 Copyright Notice
 
    Copyright (c) 2020 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
    (https://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
@@ -149,26 +149,26 @@
    "OPTIONAL" in this document are to be interpreted as described in BCP
    14 [RFC2119] [RFC8174] when, and only when, they appear in all
    capitals, as shown here .
 
 2.  Advertisement of MSD via BGP-LS
 
    This document describes extensions that enable BGP-LS speakers to
    signal the MSD capabilities ([RFC8491] ) of nodes and their links in
    a network to a BGP-LS consumer of network topology such as a
    centralized controller.  The centralized controller can leverage this
-   information in computation of SR paths and their instantiation on
-   network nodes based on their MSD capabilities.  When a BGP-LS speaker
-   is originating the topology learnt via link-state routing protocols
-   like OSPF or IS-IS, the MSD information for the nodes and their links
-   is sourced from the underlying extensions as defined in [RFC8476] and
-   [RFC8491] respectively.
+   information in computation of SR paths based on their MSD
+   capabilities.  When a BGP-LS speaker is originating the topology
+   learnt via link-state routing protocols like OSPF or IS-IS, the MSD
+   information for the nodes and their links is sourced from the
+   underlying extensions as defined in [RFC8476] and [RFC8491]
+   respectively.
 
    The BGP-LS speaker may also advertise the MSD information for the
    local node and its links when not running any link-state IGP protocol
    e.g. when running BGP as the only routing protocol.  The Protocol-ID
    field should be set to BGP since the link and node attributes have
    BGP based identifiers.  Deployment model for such case would be: a
    limited number (meeting resiliecy requirements) of BGP-LS speakers
    exposing the topology to the controller, full-mesh/RouteReflectors
    for iBGP(Internal Border Gateway Protocol) or regular eBGP(External
    Border Gateway Protocol) connectivity between nodes in the topology.