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/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$ <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 
> <https://www.ietf.org/mailman/listinfo/grow>
> 