Hi Paolo, Thank you for your detailed and comprehensive summary! I think your solution B is better.
Best Regards, Shunwan > -----Original Message----- > From: Paolo Lucente [mailto:[email protected]] > Sent: Sunday, December 31, 2023 7:28 AM > To: Zhuangshunwan <[email protected]>; Dhananjay Patki > (dhpatki) <[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) > > > Hi Shunwan, > > Thanks for your feedback, indeed you have a point. > > Let me summarize the situation, there are two parts to it: > > 1) rfc7854 defined Stats type 7 and 9 in a way that L flag is required whereas > rfc8671 went for distinct Pre-/Post-policy Stats types; so we currently have > an inconsistency; > > 2) Errata 7703, while meaning good, went one step too far: it correctly closed > the use of L flag in other messages where that would not apply (Init, Term, > Peer Up, Peer Down) while impairing these two Stats types 7 and 9; > > There are two intuitive solutions to remedy the current situation: > > a) Patch Errata 7703 and we live with issue #1 above -- low touch but rather > sub-optimal approach; > > b) Keep the Errata and do a micro draft to, in lack of better ideas, retire > and > mark reserved Stats types 7 and 9 and align those to rfc8671 style, so we > issue 4 new Stats types for Pre- and Post- policy -- a bit more work but a > neat > outcome. > > I am personally in favor of B, the micro draft path. Thoughts? > > Paolo > > > > On 9/12/23 08:47, Zhuangshunwan wrote: > > 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/eid770 > >>> > 3__;!!NEt6yMaO-gk!HnufjFK0wFIcNIN5-34vQMqmG8yvUaw6eoTAdyMYnTxk > ogc1Ld > >>> AbUJOb_Guugi2ASer_uq6Aaaowjtulif7zJQ$ > >>> <https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid770 > >>> > 3__;!!NEt6yMaO-gk!HnufjFK0wFIcNIN5-34vQMqmG8yvUaw6eoTAdyMYnTxk > ogc1Ld > >>> AbUJOb_Guugi2ASer_uq6Aaaowjtulif7zJQ$> > >>> <https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid770 > >>> > 3__;!!NEt6yMaO-gk!HnufjFK0wFIcNIN5-34vQMqmG8yvUaw6eoTAdyMYnTxk > ogc1Ld > >>> AbUJOb_Guugi2ASer_uq6Aaaowjtulif7zJQ$ > >>> <https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid770 > >>> > 3__;!!NEt6yMaO-gk!HnufjFK0wFIcNIN5-34vQMqmG8yvUaw6eoTAdyMYnTxk > ogc1Ld > >>> AbUJOb_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 > > <https://www.ietf.org/mailman/listinfo/grow> > > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
