Re: [GROW] [Technical Errata Reported] RFC7854 (7703)

Hi All,

I'm a little confused about the usage of L flag in Statistics Report messages.
When Statistics Report message is used to report the statistics of Adj-RIB-Out, I agree that the L flag is not required, for the pre-policy or post-policy is clearly specified for each statistics type:

# The following text is quoted from rfc8671:
# Stat Type = 14: Number of routes in pre-policy Adj-RIB-Out. This statistics type is 64-bit Gauge.
# Stat Type = 15: Number of routes in post-policy Adj-RIB-Out. This statistics type is 64-bit Gauge.
# Stat Type = 16: Number of routes in per-AFI/SAFI pre-policy Adj-RIB-Out. The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.
# Stat Type = 17: Number of routes in per-AFI/SAFI post-policy Adj-RIB-Out. The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.

But for Stat Type 7 & 9 in RFC7854, if the L flag is not used, how to distinguish pre-policy Adj-RIBs-In statistics from post-policy Adj-RIBs-In statistics ?

# The following text is quoted from rfc7854:
# o  Stat Type = 7: (64-bit Gauge) Number of routes in Adj-RIBs-In.
# o  Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In.  The
#     value is structured as: 2-byte Address Family Identifier (AFI),
#     1-byte Subsequent Address Family Identifier (SAFI), followed by a
#     64-bit Gauge.

I don't know if my understanding is correct, hope to get your advice!

Thanks,
Shunwan

From: GROW [mailto:grow-bounces@ietf.org] On Behalf Of Dhananjay Patki (dhpatki)
Sent: Monday, December 4, 2023 12:55 PM
To: Paolo Lucente <paolo@ntt.net>; John Scudder <jgs@juniper.net>
Cc: Rex Fernando (rex) <rex@cisco.com>; grow@ietf.org; Warren Kumari <warren@kumari.net>
Subject: Re: [GROW] [Technical Errata Reported] RFC7854 (7703)

Thanks, Paolo!
--
Regards,
Dhananjay

From: Paolo Lucente <paolo@ntt.net<mailto:paolo@ntt.net>>
Date: Sunday, 3 December 2023 at 5:08 AM
To: Dhananjay Patki (dhpatki) <dhpatki@cisco.com<mailto:dhpatki@cisco.com>>, John Scudder <jgs@juniper.net<mailto:jgs@juniper.net>>
Cc: Rex Fernando (rex) <rex@cisco.com<mailto:rex@cisco.com>>, grow@ietf.org<mailto:grow@ietf.org> <grow@ietf.org<mailto:grow@ietf.org>>, Warren Kumari <warren@kumari.net<mailto:warren@kumari.net>>
Subject: Re: [GROW] [Technical Errata Reported] RFC7854 (7703)
Thanks for having filed this errata; this also seems right to me.

Paolo

On 30/11/23 18:06, Dhananjay Patki (dhpatki) wrote:
> Thanks John. Waiting to hear other opinions, if any.
>
> --
>
> Regards,
>
> Dhananjay
>
> *From: *John Scudder <jgs@juniper.net<mailto:jgs@juniper.net>>
> *Date: *Wednesday, 29 November 2023 at 1:00 AM
> *To: *Dhananjay Patki (dhpatki) <dhpatki@cisco.com<mailto:dhpatki@cisco.com>>
> *Cc: *Rex Fernando (rex) <rex@cisco.com<mailto:rex@cisco.com>>, sstuart@google.com<mailto:sstuart@google.com>
> <sstuart@google.com<mailto:sstuart@google.com>>, Warren Kumari <warren@kumari.net<mailto:warren@kumari.net>>, Rob Wilton
> (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>, job@fastly.com<mailto:job@fastly.com> <job@fastly.com<mailto:job@fastly.com>>,
> christopher.morrow@gmail.com<mailto:christopher.morrow@gmail.com> <christopher.morrow@gmail.com<mailto:christopher.morrow@gmail.com>>,
> grow@ietf.org<mailto:grow@ietf.org> <grow@ietf.org<mailto:grow@ietf.org>>
> *Subject: *Re: [Technical Errata Reported] RFC7854 (7703)
>
> This seems right. Unless anyone else sees a problem with it, I’d say
> verify the erratum.
>
> —John
>
>> On Nov 16, 2023, at 5:24 AM, RFC Errata System <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>> wrote:
>>
>>
>> The following errata report has been submitted for RFC7854,
>> "BGP Monitoring Protocol (BMP)".
>>
>> --------------------------------------
>> You may review the report below and at:
>> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7703__;!!NEt6yMaO-gk!HnufjFK0wFIcNIN5-34vQMqmG8yvUaw6eoTAdyMYnTxkogc1LdAbUJOb_Guugi2ASer_uq6Aaaowjtulif7zJQ$<https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid7703__;!!NEt6yMaO-gk!HnufjFK0wFIcNIN5-34vQMqmG8yvUaw6eoTAdyMYnTxkogc1LdAbUJOb_Guugi2ASer_uq6Aaaowjtulif7zJQ$> <https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid7703__;!!NEt6yMaO-gk!HnufjFK0wFIcNIN5-34vQMqmG8yvUaw6eoTAdyMYnTxkogc1LdAbUJOb_Guugi2ASer_uq6Aaaowjtulif7zJQ$>
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Dhananjay S. Patki <dhpatki@cisco.com<mailto:dhpatki@cisco.com>>
>>
>> Section: 4.2
>>
>> Original Text
>> -------------
>>      *  The L flag, if set to 1, indicates that the message reflects
>>         the post-policy Adj-RIB-In (i.e., its path attributes reflect
>>         the application of inbound policy).  It is set to 0 if the
>>         message reflects the pre-policy Adj-RIB-In.  Locally sourced
>>         routes also carry an L flag of 1.  See Section 5 for further
>>         detail.  This flag has no significance when used with route
>>         mirroring messages (Section 4.7).
>>
>> Corrected Text
>> --------------
>>      *  The L flag, if set to 1, indicates that the message reflects
>>         the post-policy Adj-RIB-In (i.e., its path attributes reflect
>>         the application of inbound policy).  It is set to 0 if the
>>         message reflects the pre-policy Adj-RIB-In.  Locally sourced
>>         routes also carry an L flag of 1.  See Section 5 for further
>>         detail.  This flag has significance only when used with Route
>>         Monitoring messages.
>>
>> Notes
>> -----
>> The L flag is used to indicate whether the route monitoring update reflects Adj-RIB-In pre-policy or post-policy (RFC 7854), or Adj-RIB-Out pre-policy or post-policy (RFC 8671). It does not apply to any message other than the Route Monitoring message.
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". (If it is spam, it
>> will be removed shortly by the RFC Production Center.) Please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> will log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC7854 (draft-ietf-grow-bmp-17)
>> --------------------------------------
>> Title               : BGP Monitoring Protocol (BMP)
>> Publication Date    : June 2016
>> Author(s)           : J. Scudder, Ed., R. Fernando, S. Stuart
>> Category            : PROPOSED STANDARD
>> Source              : Global Routing Operations
>> Area                : Operations and Management
>> Stream              : IETF
>> Verifying Party     : IESG
>
>
> _______________________________________________
> GROW mailing list
> GROW@ietf.org<mailto:GROW@ietf.org>
> https://www.ietf.org/mailman/listinfo/grow