Subject: [GROW] AD Review of draft-ietf-grow-bmp-local-rib

From: Warren Kumari <[email-masked]>
Date: Mon, 22 Feb 2021 12:26:31 -0500

Hi authors and WG,

Thank you for this document, I believe that allowing BMP to share Loc-RIB
is clearly a good thing.

I do have a few comments/nits that addressing now should help the IETF
LC and IESG eval go more smoothly.

Please SHOUT loudly once you've had a chance to address these.

AD Review of draft-ietf-grow-bmp-local-rib
--------------------------------------------

1: "As shown in Figure 2, Locally originated section 9.4 of [RFC4271]"
I'm unable to parse this - changing "As shown in Figure 2, Locally
originated" into "As shown in Figure 2, Locally Originated into Loc-RIB,
..." doesn't fix it, because the figure doesn't really "show what Sec 9.4
of RFC4271" says.
Perhaps something like: "Figure 2 (Locally Originated into Loc-RIB)
illustrates how redistributed or otherwise originated routes get installed
into the Loc-RIB based on the decision process selection in [RFC4271]"

2: In Section 1.1 the document says things like: "The current method
introduces the need..."
Once the document is published, the phrase "the current method" seems
incorrect, but I don't have a better suggestion...

3: "Locally sourced routes MUST be conveyed using the Loc-RIB instance peer
type."
Should this be "locally sourced BGP routes"? It would be silly to think
that this might carry e.g OSPF only routes, but you have a MUST, so
important to be explicit.
This also seems to conflict with "The F flag indicates that the Loc-RIB is
filtered". Perhaps that above is better worded something like:
"If locally sourced routes are communicated using BMP, they MUST be
conveyed using the Loc-RIB instance peer type." ?

4: " The Loc-RIB contains all routes selected by the BGP protocol Decision
Process section 9.1 of [RFC4271]."
Similar to #1 - perhaps this is just missing a "in section of..."? Still
needs rewording.

5: "These routes include those learned from BGP peers via its Adj-RIBs-In
post-policy, as well as routes learned by other means section 9.4 of
[RFC4271]."
Similar -- I suspect that there was an errant search and replace which
clobbered some text?

6: "Peer AS: Set to the BGP instance global or default ASN value."
Erm, what's this default ASN value?

7: "5.1.  Per-Peer Header"
I think that this section needs a pointer to RFC7854 Sec 4.2.

8: "Capabilities MUST include 4-octet ASN"
s/include 4/include the 4/

9: "For example, prefix 10.0.0.0/8 is updated "
Please use RFC5737 examples instead.

Nit:
1: "This is overly complex for such a simple application that only needed
to have access to the Loc-RIB."
s/needed/needs/

2: It can greatly reduce time to troubleshoot and resolve issues if
operators had the history of Loc-RIB changes.
s/had/have/

3: "BGP Instance: it refers to an"
s/it//

-- 
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Wed, 24 Feb 2021 20:22:04 +0000

Hi Warren,

Thank you so much for the review.   We agree with those changes. We have made the requested changes, but we cannot submit them until after Mar-8th.  Until then, I have attached a text diff output.  You can also see the changes at https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib.  You can compare tag revisions.

Thanks,
Tim

On 2/22/21, 9:27 AM, "Warren Kumari" <[email-masked]> wrote:

Hi authors and WG,

Thank you for this document, I believe that allowing BMP to share Loc-RIB is clearly a good thing.

1: "As shown in Figure 2, Locally originated section 9.4 of [RFC4271]"
I'm unable to parse this - changing "As shown in Figure 2, Locally originated" into "As shown in Figure 2, Locally Originated into Loc-RIB, ..." doesn't fix it, because the figure doesn't really "show what Sec 9.4 of RFC4271" says.
Perhaps something like: "Figure 2 (Locally Originated into Loc-RIB) illustrates how redistributed or otherwise originated routes get installed into the Loc-RIB based on the decision process selection in [RFC4271]"

2: In Section 1.1 the document says things like: "The current method introduces the need..."
Once the document is published, the phrase "the current method" seems incorrect, but I don't have a better suggestion...

3: "Locally sourced routes MUST be conveyed using the Loc-RIB instance peer type."
Should this be "locally sourced BGP routes"? It would be silly to think that this might carry e.g OSPF only routes, but you have a MUST, so important to be explicit.
This also seems to conflict with "The F flag indicates that the Loc-RIB is filtered". Perhaps that above is better worded something like:
"If locally sourced routes are communicated using BMP, they MUST be conveyed using the Loc-RIB instance peer type." ?

4: " The Loc-RIB contains all routes selected by the BGP protocol Decision Process section 9.1 of [RFC4271]."
Similar to #1 - perhaps this is just missing a "in section of..."? Still needs rewording.

5: "These routes include those learned from BGP peers via its Adj-RIBs-In post-policy, as well as routes learned by other means section 9.4 of [RFC4271]."
Similar -- I suspect that there was an errant search and replace which clobbered some text?

9: "For example, prefix 10.0.0.0/8<http://10.0.0.0/8> is updated "
Please use RFC5737 examples instead.

Nit:
1: "This is overly complex for such a simple application that only needed to have access to the Loc-RIB."
s/needed/needs/

2: It can greatly reduce time to troubleshoot and resolve issues if operators had the history of Loc-RIB changes.
s/had/have/

--
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky
diff --git a/draft-ietf-grow-bmp-local-rib.txt b/draft-ietf-grow-bmp-local-rib.txt
index 2a3d66f..2f69495 100644
--- a/draft-ietf-grow-bmp-local-rib.txt
+++ b/draft-ietf-grow-bmp-local-rib.txt
@@ -6,13 +6,13 @@ Global Routing Operations                                       T. Evens
 Internet-Draft                                              S. Bayraktar
 Updates: 7854 (if approved)                                  M. Bhardwaj
 Intended status: Standards Track                           Cisco Systems
-Expires: 18 July 2021                                         P. Lucente
+Expires: 28 August 2021                                       P. Lucente
                                                       NTT Communications
-                                                         14 January 2021
+                                                        24 February 2021

          Support for Local RIB in BGP Monitoring Protocol (BMP)
-                    draft-ietf-grow-bmp-local-rib-09
+                    draft-ietf-grow-bmp-local-rib-10
 
 Abstract
 
@@ -37,7 +37,7 @@ Status of This Memo
    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 18 July 2021.
+   This Internet-Draft will expire on 28 August 2021.
 
 Copyright Notice
 
@@ -53,9 +53,9 @@ Copyright Notice

-Evens, et al.             Expires 18 July 2021                  [Page 1]
+Evens, et al.            Expires 28 August 2021                 [Page 1]
 
-Internet-Draft                 BMP Loc-RIB                  January 2021
+Internet-Draft                 BMP Loc-RIB                 February 2021

    This document is subject to BCP 78 and the IETF Trust's Legal
@@ -109,9 +109,9 @@ Table of Contents

-Evens, et al.             Expires 18 July 2021                  [Page 2]
+Evens, et al.            Expires 28 August 2021                 [Page 2]
 
-Internet-Draft                 BMP Loc-RIB                  January 2021
+Internet-Draft                 BMP Loc-RIB                 February 2021

 1.  Introduction
@@ -150,10 +150,10 @@ Internet-Draft                 BMP Loc-RIB                  January 2021
 
                Figure 1: BGP peering Adj-RIBs-In into Loc-RIB
 
-   As shown in Figure 2, Locally originated section 9.4 of [RFC4271]
-   follows a similar flow where the redistributed or otherwise
-   originated routes get installed into the Loc-RIB based on the
-   decision process selection.
+   Figure 2 (Locally Originated into Loc-RIB) illustrates how
+   redistributed or otherwise originated routes get installed into the
+   Loc-RIB based on the decision process selection in RFC 4271
+   [RFC4271].

@@ -165,9 +165,9 @@ Internet-Draft                 BMP Loc-RIB                  January 2021

-Evens, et al.             Expires 18 July 2021                  [Page 3]
+Evens, et al.            Expires 28 August 2021                 [Page 3]
 
-Internet-Draft                 BMP Loc-RIB                  January 2021
+Internet-Draft                 BMP Loc-RIB                 February 2021

         /--------------------------------------------------------\
@@ -206,14 +206,14 @@ Internet-Draft                 BMP Loc-RIB                  January 2021
       metrics.  While it is possible to obtain the IGP topology
       information using BGP-LS, it requires the application to implement
       SPF and possibly CSPF based on additional policies.  This is
-      overly complex for such a simple application that only needed to
+      overly complex for such a simple application that only needs to
       have access to the Loc-RIB.
 
    *  It is common to see frequent changes over many BGP peers, but
       those changes do not always result in the router's Loc-RIB
       changing.  The change in the Loc-RIB can have a direct impact on
       the forwarding state.  It can greatly reduce time to troubleshoot
-      and resolve issues if operators had the history of Loc-RIB
+      and resolve issues if operators have the history of Loc-RIB
       changes.  For example, a performance issue might have been seen
       for only a duration of 5 minutes.  Post troubleshooting this issue
       without Loc-RIB history hides any decision based routing changes
@@ -221,9 +221,9 @@ Internet-Draft                 BMP Loc-RIB                  January 2021

-Evens, et al.             Expires 18 July 2021                  [Page 4]
+Evens, et al.            Expires 28 August 2021                 [Page 4]
 
-Internet-Draft                 BMP Loc-RIB                  January 2021
+Internet-Draft                 BMP Loc-RIB                 February 2021

    *  Operators may wish to validate the impact of policies applied to
@@ -277,9 +277,9 @@ Internet-Draft                 BMP Loc-RIB                  January 2021

-Evens, et al.             Expires 18 July 2021                  [Page 5]
+Evens, et al.            Expires 28 August 2021                 [Page 5]
 
-Internet-Draft                 BMP Loc-RIB                  January 2021
+Internet-Draft                 BMP Loc-RIB                 February 2021

          /------------------------------------------------------\
@@ -323,7 +323,8 @@ Internet-Draft                 BMP Loc-RIB                  January 2021
    peering session.  The BMP router then forwards Adj-RIB-In Pre-Policy
    to the BMP receiver.
 
-   The current method introduces the need for additional resources:
+   BMP lacking access to Loc-RIB introduces the need for additional
+   resources:
 
    *  Requires at least two routers when only one router was to be
       monitored.
@@ -332,10 +333,9 @@ Internet-Draft                 BMP Loc-RIB                  January 2021

-
-Evens, et al.             Expires 18 July 2021                  [Page 6]
+Evens, et al.            Expires 28 August 2021                 [Page 6]
 
-Internet-Draft                 BMP Loc-RIB                  January 2021
+Internet-Draft                 BMP Loc-RIB                 February 2021

    *  Requires additional BGP peering to collect the received updates
@@ -344,8 +344,8 @@ Internet-Draft                 BMP Loc-RIB                  January 2021
       peers, segment routing egress peer engineering where no peers have
       link-state address family enabled.
 
-   Complexities introduced with current method in order to derive (e.g.
-   correlate) peer to router Loc-RIB:
+   Complexities introduced by the lack of access to Loc-RIB in order to
+   derive (e.g. correlate) peer to router Loc-RIB:
 
    *  Adj-RIB-Out received as Adj-RIB-In from another router may have a
       policy applied that filters, generates aggregates, suppresses more
@@ -389,12 +389,12 @@ Internet-Draft                 BMP Loc-RIB                  January 2021

-Evens, et al.             Expires 18 July 2021                  [Page 7]
+Evens, et al.            Expires 28 August 2021                 [Page 7]
 
-Internet-Draft                 BMP Loc-RIB                  January 2021
+Internet-Draft                 BMP Loc-RIB                 February 2021

-   *  BGP Instance: it refers to an instance of an instance of BGP-4
+   *  BGP Instance: refers to an instance of an instance of BGP-4
       [RFC4271] and considerations in section 8.1 of [RFC7854] do apply
       to it.
 
@@ -437,19 +437,22 @@ Internet-Draft                 BMP Loc-RIB                  January 2021
 4.2.  Peer Flags
 
    In section 4.2 of [RFC7854], the "locally sourced routes" comment
-   under the L flag description is removed.  Locally sourced routes MUST
-   be conveyed using the Loc-RIB instance peer type.
+   under the L flag description is removed.  If locally sourced routes
+   are communicated using BMP, they MUST be conveyed using the Loc-RIB
+   instance peer type.
 
-   The per-peer header flags for Loc-RIB Instance Peer type are defined
-   as follows:

-Evens, et al.             Expires 18 July 2021                  [Page 8]
+
+Evens, et al.            Expires 28 August 2021                 [Page 8]
 
-Internet-Draft                 BMP Loc-RIB                  January 2021
+Internet-Draft                 BMP Loc-RIB                 February 2021

+   The per-peer header flags for Loc-RIB Instance Peer type are defined
+   as follows:
+
                               0 1 2 3 4 5 6 7
                              +-+-+-+-+-+-+-+-+
                              |F|  Reserved   |
@@ -465,19 +468,20 @@ Internet-Draft                 BMP Loc-RIB                  January 2021
 5.  Loc-RIB Monitoring
 
    The Loc-RIB contains all routes selected by the BGP protocol Decision
-   Process section 9.1 of [RFC4271].  These routes include those learned
-   from BGP peers via its Adj-RIBs-In post-policy, as well as routes
-   learned by other means section 9.4 of [RFC4271].  Examples of these
-   include redistribution of routes from other protocols into BGP or
-   otherwise locally originated (ie. aggregate routes).
+   Process as described in section 9.1 of [RFC4271].  These routes
+   include those learned from BGP peers via its Adj-RIBs-In post-policy,
+   as well as routes learned by other means as per section 9.4 of
+   [RFC4271].  Examples of these include redistribution of routes from
+   other protocols into BGP or otherwise locally originated (ie.
+   aggregate routes).
 
    As mentioned in Section 4.2 a subset of Loc-RIB routes MAY be sent to
    a BMP collector by setting the F flag.
 
 5.1.  Per-Peer Header
 
-   All peer messages that include a per-peer header MUST use the
-   following values:
+   All peer messages that include a per-peer header section 4.2 of
+   [RFC7854] MUST use the following values:
 
    *  Peer Type: Set to 3 to indicate Loc-RIB Instance Peer.
 
@@ -490,20 +494,16 @@ Internet-Draft                 BMP Loc-RIB                  January 2021
       The V flag is not applicable with Loc-RIB Instance peer type
       considering addresses are zero-filed.
 
-   *  Peer AS: Set to the BGP instance global or default ASN value.
+   *  Peer AS: Set to the primary router BGP ASN.
 
    *  Peer BGP ID: Set to the BGP instance global or RD (e.g.  VRF)
       specific router-id section 1.1 of [RFC7854].

-
-
-
-
-Evens, et al.             Expires 18 July 2021                  [Page 9]
+Evens, et al.            Expires 28 August 2021                 [Page 9]
 
-Internet-Draft                 BMP Loc-RIB                  January 2021
+Internet-Draft                 BMP Loc-RIB                 February 2021

    *  Timestamp: The time when the encapsulated routes were installed in
@@ -524,7 +524,7 @@ Internet-Draft                 BMP Loc-RIB                  January 2021
    *  Remote Port: Set to 0, remote port is not applicable.
 
    *  Sent OPEN Message: This is a fabricated BGP OPEN message.
-      Capabilities MUST include 4-octet ASN and all necessary
+      Capabilities MUST include the 4-octet ASN and all necessary
       capabilities to represent the Loc-RIB route monitoring messages.
       Only include capabilities if they will be used for Loc-RIB
       monitoring messages.  For example, if add-paths is enabled for
@@ -557,9 +557,9 @@ Internet-Draft                 BMP Loc-RIB                  January 2021

-Evens, et al.             Expires 18 July 2021                 [Page 10]
+Evens, et al.            Expires 28 August 2021                [Page 10]
 
-Internet-Draft                 BMP Loc-RIB                  January 2021
+Internet-Draft                 BMP Loc-RIB                 February 2021

    Multiple TLVs of the same type can be repeated as part of the same
@@ -601,7 +601,7 @@ Internet-Draft                 BMP Loc-RIB                  January 2021
    to BMP receivers.  With state compression, only the final resultant
    updates are sent.
 
-   For example, prefix 10.0.0.0/8 is updated in the Loc-RIB 5 times
+   For example, prefix 192.0.2.0/24 is updated in the Loc-RIB 5 times
    within 1 second.  State compression of BMP route monitor messages
    results in only the final change being transmitted.  The other 4
    changes are suppressed because they fall within the compression
@@ -613,9 +613,9 @@ Internet-Draft                 BMP Loc-RIB                  January 2021

-Evens, et al.             Expires 18 July 2021                 [Page 11]
+Evens, et al.            Expires 28 August 2021                [Page 11]
 
-Internet-Draft                 BMP Loc-RIB                  January 2021
+Internet-Draft                 BMP Loc-RIB                 February 2021

 5.5.  Route Mirroring
@@ -669,9 +669,9 @@ Internet-Draft                 BMP Loc-RIB                  January 2021

-Evens, et al.             Expires 18 July 2021                 [Page 12]
+Evens, et al.            Expires 28 August 2021                [Page 12]
 
-Internet-Draft                 BMP Loc-RIB                  January 2021
+Internet-Draft                 BMP Loc-RIB                 February 2021

 6.1.2.  Filtering Loc-RIB to BMP Receivers
@@ -725,9 +725,9 @@ Internet-Draft                 BMP Loc-RIB                  January 2021

-Evens, et al.             Expires 18 July 2021                 [Page 13]
+Evens, et al.            Expires 28 August 2021                [Page 13]
 
-Internet-Draft                 BMP Loc-RIB                  January 2021
+Internet-Draft                 BMP Loc-RIB                 February 2021

 8.3.  Peer UP Information TLV
@@ -781,9 +781,9 @@ Authors' Addresses

-Evens, et al.             Expires 18 July 2021                 [Page 14]
+Evens, et al.            Expires 28 August 2021                [Page 14]
 
-Internet-Draft                 BMP Loc-RIB                  January 2021
+Internet-Draft                 BMP Loc-RIB                 February 2021

    Seattle, WA 98121
@@ -837,4 +837,4 @@ Internet-Draft                 BMP Loc-RIB                  January 2021

-Evens, et al.             Expires 18 July 2021                 [Page 15]
+Evens, et al.            Expires 28 August 2021                [Page 15]
diff --git a/draft-ietf-grow-bmp-local-rib.xml b/draft-ietf-grow-bmp-local-rib.xml
index e0ff7da..4009918 100644
--- a/draft-ietf-grow-bmp-local-rib.xml
+++ b/draft-ietf-grow-bmp-local-rib.xml
@@ -8,12 +8,12 @@
 <?rfc sortrefs="yes" ?>
 <?rfc compact="yes" ?>
 <?rfc subcompact="no" ?>
-<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-grow-bmp-local-rib-09" ipr="trust200902" submissionType="IETF" updates="7854" obsoletes="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
+<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-grow-bmp-local-rib-10" ipr="trust200902" submissionType="IETF" updates="7854" obsoletes="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
   <!-- xml2rfc v2v3 conversion 3.3.0 -->
   <front>
     <title abbrev="BMP Loc-RIB">
             Support for Local RIB in BGP Monitoring Protocol (BMP)</title>
-    <seriesInfo name="Internet-Draft" value="draft-ietf-grow-bmp-local-rib-09"/>
+    <seriesInfo name="Internet-Draft" value="draft-ietf-grow-bmp-local-rib-10"/>
     <author fullname="Tim Evens" initials="T" surname="Evens">
       <organization>Cisco Systems</organization>
       <address>
@@ -127,10 +127,10 @@
 ]]></artwork>
       </figure>
       <t>
-        As shown in <xref target="FigLocallyOriginated" format="default"/>, Locally originated
-		<xref target="RFC4271" format="default">section 9.4 of</xref> follows a similar flow where the
-		redistributed or otherwise originated routes get installed into the Loc-RIB
-		based on the decision process selection.
+        <xref target="FigLocallyOriginated" format="default"/> (Locally Originated into Loc-RIB)
+	illustrates how redistributed or otherwise originated routes get installed into the
+	Loc-RIB based on the decision process selection in
+	<xref target="RFC4271" format="default">RFC 4271</xref>.
       </t>
       <figure anchor="FigLocallyOriginated">
         <name>Locally Originated into Loc-RIB</name>
@@ -178,7 +178,7 @@
                         information using BGP-LS, it requires the application to
                         implement SPF and possibly CSPF based on additional policies.
                         This is overly complex for such a simple application that only
-                        needed to have access to the Loc-RIB.
+                        needs to have access to the Loc-RIB.
             </t>                        
 
         </li>
@@ -187,7 +187,7 @@
                         those changes do not always result in the router's Loc-RIB
                         changing. The change in the Loc-RIB can have a direct impact
                         on the forwarding state. It can greatly reduce time to
-                        troubleshoot and resolve issues if operators had the history of
+                        troubleshoot and resolve issues if operators have the history of
                         Loc-RIB changes. For example, a performance issue might have
                         been seen for only a duration of 5 minutes. Post
                         troubleshooting this issue without Loc-RIB history hides any
@@ -269,8 +269,8 @@
                     router then forwards Adj-RIB-In Pre-Policy to the BMP receiver.
         </t>
         <t>
-                    The current method introduces the need for additional resources:
-
+                    BMP lacking access to Loc-RIB introduces the need for additional
+		    resources:
         </t>
         <ul spacing="normal">
           <li>
@@ -286,8 +286,8 @@
           </li>
         </ul>
         <t>
-                    Complexities introduced with current method in order to derive
-                    (e.g. correlate) peer to router Loc-RIB:
+                    Complexities introduced by the lack of access to Loc-RIB in
+		    order to derive (e.g. correlate) peer to router Loc-RIB:
 
         </t>
         <ul spacing="normal">
@@ -339,7 +339,7 @@
       <name>Definitions</name>
       <ul spacing="normal">
         <li>
-			BGP Instance: it refers to an instance of an instance of BGP-4 <xref target="RFC4271" format="default"/>
+			BGP Instance: refers to an instance of an instance of BGP-4 <xref target="RFC4271" format="default"/>
 			and considerations in <xref target="RFC7854" format="default">section 8.1 of</xref> do apply to it.
         </li>
         <li>
@@ -395,8 +395,8 @@
         <name>Peer Flags</name>
         <t>
             In <xref target="RFC7854" format="default">section 4.2 of</xref>, the "locally sourced routes"
-            comment under the L flag description is removed.  Locally sourced routes MUST
-            be conveyed using the Loc-RIB instance peer type.
+            comment under the L flag description is removed. If locally sourced routes are communicated
+	    using BMP, they MUST be conveyed using the Loc-RIB instance peer type.
         </t>
         <t>
             The per-peer header flags for Loc-RIB Instance Peer type are defined
@@ -428,13 +428,12 @@
     <section numbered="true" toc="default">
       <name>Loc-RIB Monitoring</name>
       <t>
-		The Loc-RIB contains all routes selected by the BGP protocol Decision Process
-		<xref target="RFC4271" format="default">section 9.1 of</xref>. These routes include those learned
-		from BGP peers via its Adj-RIBs-In post-policy, as well as routes learned by
-		other means <xref target="RFC4271" format="default">section 9.4 of</xref>. Examples of these
-		include redistribution of routes from other protocols into BGP or otherwise
-		locally originated (ie. aggregate routes).
-
+		The Loc-RIB contains all routes selected by the BGP protocol Decision Process as
+		described in  <xref target="RFC4271" format="default">section 9.1 of</xref>. These
+		routes include those learned from BGP peers via its Adj-RIBs-In post-policy, as
+		well as routes learned by other means as per <xref target="RFC4271" format="default">section 9.4 of</xref>.
+		Examples of these include redistribution of routes from other protocols into BGP
+		or otherwise locally originated (ie. aggregate routes).
       </t>
       <t>
 		As mentioned in <xref target="PeerFlags" format="default"/> a subset of Loc-RIB routes MAY be
@@ -443,8 +442,8 @@
       <section numbered="true" toc="default">
         <name>Per-Peer Header</name>
         <t>
-            All peer messages that include a per-peer header MUST use the
-            following values:
+            All peer messages that include a per-peer header <xref target="RFC7854" format="default">section 4.2 of</xref>
+	    MUST use the following values:
 
         </t>
         <ul spacing="normal">
@@ -457,22 +456,22 @@
                 unique locally defined value of the particular instance the Loc-RIB belongs to.
           </li>
           <li>
-			    Peer Address: Zero-filled.  Remote peer address is not applicable.
-			    The V flag is not applicable with Loc-RIB Instance peer type
-			    considering addresses are zero-filed.
+		Peer Address: Zero-filled.  Remote peer address is not applicable.
+		The V flag is not applicable with Loc-RIB Instance peer type
+		considering addresses are zero-filed.
           </li>
           <li>
-                Peer AS: Set to the BGP instance global or default ASN value.
+                Peer AS: Set to the primary router BGP ASN.
           </li>
           <li>
                 Peer BGP ID: Set to the BGP instance global or RD (e.g. VRF)
                 specific router-id <xref target="RFC7854" format="default">section 1.1 of</xref>.
           </li>
           <li>
-			    Timestamp: The time when the encapsulated routes were installed in
-			    The Loc-RIB, expressed in seconds and microseconds since midnight
-			    (zero hour), January 1, 1970 (UTC).  If zero, the time is unavailable.
-	 		    Precision of the timestamp is implementation-dependent.
+		Timestamp: The time when the encapsulated routes were installed in
+		The Loc-RIB, expressed in seconds and microseconds since midnight
+		(zero hour), January 1, 1970 (UTC).  If zero, the time is unavailable.
+		Precision of the timestamp is implementation-dependent.
           </li>
         </ul>
       </section>
@@ -495,7 +494,7 @@
           </li>
           <li>
                 Sent OPEN Message: This is a fabricated BGP OPEN message.
-                Capabilities MUST include 4-octet ASN and all necessary
+                Capabilities MUST include the 4-octet ASN and all necessary
                 capabilities to represent the Loc-RIB route monitoring messages.
                 Only include capabilities if they will be used for Loc-RIB
                 monitoring messages.  For example, if add-paths is enabled for
@@ -587,7 +586,7 @@
             final resultant updates are sent.
           </t>
           <t>
-            For example, prefix 10.0.0.0/8 is updated in the Loc-RIB 5 times
+            For example, prefix 192.0.2.0/24 is updated in the Loc-RIB 5 times
             within 1 second. State compression of BMP route monitor messages
             results in only the final change being transmitted. The other 4
             changes are suppressed because they fall within the compression

---

From: Warren Kumari <[email-masked]>
Date: Wed, 24 Feb 2021 18:17:35 -0500

On Wed, Feb 24, 2021 at 3:22 PM Tim Evens (tievens) <[email-masked]>
wrote:

> Hi Warren,
>
>
>
> Thank you so much for the review.   We agree with those changes. We have
> made the requested changes, but we cannot submit them until after Mar-8th.
> Until then, I have attached a text diff output.  You can also see the
> changes at https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib.  You
> can compare tag revisions.
>

Awesome, thank you very much. Please let me know LOUDLY once
you've submitted, and I'll kick off IETF LC. It will probably have to wait
until just after IETF ends, so that people can pay attention...

Thank again for the quick turn around,
W

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra