--- 1/draft-ietf-idr-bgp-ls-segment-routing-msd-10.txt	2020-02-28 18:13:25.784279988 -0800
+++ 2/draft-ietf-idr-bgp-ls-segment-routing-msd-11.txt	2020-02-28 18:13:25.812280697 -0800
@@ -6,21 +6,21 @@
                                                            K. Talaulikar
                                                            Cisco Systems
                                                                G. Mirsky
                                                                ZTE Corp.
                                                         N. Triantafillis
                                                      Amazon Web Services
                                                        February 28, 2020
 
  Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link
                                  State
-              draft-ietf-idr-bgp-ls-segment-routing-msd-10
+              draft-ietf-idr-bgp-ls-segment-routing-msd-11
 
 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.
@@ -155,29 +155,31 @@
 
    This document describes extensions that enable BGP-LS speakers to
    signal the MSD capabilities (described in [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.  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/RouterReflectors for iBGP
-   or regular eBGP connectivity between every node in the topology.
+   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.
 
    The extensions introduced in this document allow for advertisement of
    different MSD-Types.  This document does not define these MSD-Types
    but leverages the definition, guidelines and the code-point registry
    specified in [RFC8491].  This enables sharing of MSD-Types that may
    be defined in the future by the IGPs in BGP-LS.
 
 3.  Node MSD TLV
 
    Node MSD is encoded in a new Node Attribute TLV [RFC7752] using the