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-boun...@ietf.org] On Behalf Of Dhananjay Patki (dhpatki) Sent: Monday, December 4, 2023 12:55 PM To: Paolo Lucente <pa...@ntt.net>; John Scudder <j...@juniper.net> Cc: Rex Fernando (rex) <r...@cisco.com>; grow@ietf.org; Warren Kumari <war...@kumari.net> Subject: Re: [GROW] [Technical Errata Reported] RFC7854 (7703) Thanks, Paolo! -- Regards, Dhananjay From: Paolo Lucente <pa...@ntt.net<mailto:pa...@ntt.net>> Date: Sunday, 3 December 2023 at 5:08 AM To: Dhananjay Patki (dhpatki) <dhpa...@cisco.com<mailto:dhpa...@cisco.com>>, John Scudder <j...@juniper.net<mailto:j...@juniper.net>> Cc: Rex Fernando (rex) <r...@cisco.com<mailto:r...@cisco.com>>, grow@ietf.org<mailto:grow@ietf.org> <grow@ietf.org<mailto:grow@ietf.org>>, Warren Kumari <war...@kumari.net<mailto:war...@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 <j...@juniper.net<mailto:j...@juniper.net>> > *Date: *Wednesday, 29 November 2023 at 1:00 AM > *To: *Dhananjay Patki (dhpatki) <dhpa...@cisco.com<mailto:dhpa...@cisco.com>> > *Cc: *Rex Fernando (rex) <r...@cisco.com<mailto:r...@cisco.com>>, > sstu...@google.com<mailto:sstu...@google.com> > <sstu...@google.com<mailto:sstu...@google.com>>, Warren Kumari > <war...@kumari.net<mailto:war...@kumari.net>>, Rob Wilton > (rwilton) <rwil...@cisco.com<mailto:rwil...@cisco.com>>, > j...@fastly.com<mailto:j...@fastly.com> > <j...@fastly.com<mailto:j...@fastly.com>>, > christopher.mor...@gmail.com<mailto:christopher.mor...@gmail.com> > <christopher.mor...@gmail.com<mailto:christopher.mor...@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-edi...@rfc-editor.org<mailto:rfc-edi...@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 <dhpa...@cisco.com<mailto:dhpa...@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
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
