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:[email protected]] On Behalf Of Dhananjay Patki (dhpatki) Sent: Monday, December 4, 2023 12:55 PM To: Paolo Lucente <[email protected]>; John Scudder <[email protected]> Cc: Rex Fernando (rex) <[email protected]>; [email protected]; Warren Kumari <[email protected]> Subject: Re: [GROW] [Technical Errata Reported] RFC7854 (7703) Thanks, Paolo! -- Regards, Dhananjay From: Paolo Lucente <[email protected]<mailto:[email protected]>> Date: Sunday, 3 December 2023 at 5:08 AM To: Dhananjay Patki (dhpatki) <[email protected]<mailto:[email protected]>>, John Scudder <[email protected]<mailto:[email protected]>> Cc: Rex Fernando (rex) <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Warren Kumari <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> > *Date: *Wednesday, 29 November 2023 at 1:00 AM > *To: *Dhananjay Patki (dhpatki) <[email protected]<mailto:[email protected]>> > *Cc: *Rex Fernando (rex) <[email protected]<mailto:[email protected]>>, > [email protected]<mailto:[email protected]> > <[email protected]<mailto:[email protected]>>, Warren Kumari > <[email protected]<mailto:[email protected]>>, Rob Wilton > (rwilton) <[email protected]<mailto:[email protected]>>, > [email protected]<mailto:[email protected]> > <[email protected]<mailto:[email protected]>>, > [email protected]<mailto:[email protected]> > <[email protected]<mailto:[email protected]>>, > [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> > *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 >> <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> >> >> 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 > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/grow
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
