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

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:paolo@ntt.net]
> Sent: Sunday, December 31, 2023 7:28 AM
> To: Zhuangshunwan <zhuangshunwan@huawei.com>; Dhananjay Patki
> (dhpatki) <dhpatki=40cisco.com@dmarc.ietf.org>; 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)
> 
> 
> 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: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/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 <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
> > <https://www.ietf.org/mailman/listinfo/grow>
> >