Dear Mukul, Thanks a lot for addressing my comments in https://mailarchive.ietf.org/arch/msg/grow/oDgVmZgZpcxuPcKnjkMZzLLcEGo/. I reviewed. All perfect thanks.
Regarding my comments in https://mailarchive.ietf.org/arch/msg/grow/s55XlMStBXpq0BYTAFubg9aOdL8/, which received feedback from https://mailarchive.ietf.org/arch/msg/grow/Pmt5tf9vyw2av_ULnXJcbuimWuM/ and https://mailarchive.ietf.org/arch/msg/grow/LjgjpzEsaeCe_gYm9QunMTkEIpg/, I suggest to add another stats counter. I hope we gather more feedback from the mailing list which approach would be best. My favorite is: How many prefixes until upper bound is being reached Best wishes Thomas From: Mukul Srivastava <m...@juniper.net> Sent: Tuesday, April 30, 2024 6:37 PM To: Mukul Srivastava <msri=40juniper....@dmarc.ietf.org>; Graf Thomas, INI-NET-VNC-HCS <thomas.g...@swisscom.com>; grow@ietf.org; liuyis...@chinamobile.com; linchangwang.04...@h3c.com; lijinm...@chinamobile.com; grow-cha...@ietf.org Cc: pa...@pmacct.net Subject: Re: IETF 119, GROW, draft-ietf-grow-bmp-bgp-rib-stats-01, draft-liu-grow-bmp-stats-reports-00 Be aware: This is an external email. Hi All All comments have been addressed and the new doc has been posted. Feel free to review and provide comments. https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-bgp-rib-stats-02 @grow-cha...@ietf.org<mailto:grow-cha...@ietf.org> I am looking for early code point assignment. Pls help in the assignment. @lijinm...@chinamobile.com<mailto:lijinm...@chinamobile.com> Let me know if you want to combine your work with my draft. Thanks Mukul Juniper Business Use Only From: GROW <grow-boun...@ietf.org<mailto:grow-boun...@ietf.org>> on behalf of Mukul Srivastava <msri=40juniper....@dmarc.ietf.org<mailto:msri=40juniper....@dmarc.ietf.org>> Date: Friday, March 22, 2024 at 9:43 AM To: thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>>, grow@ietf.org<mailto:grow@ietf.org> <grow@ietf.org<mailto:grow@ietf.org>>, liuyis...@chinamobile.com<mailto:liuyis...@chinamobile.com> <liuyis...@chinamobile.com<mailto:liuyis...@chinamobile.com>>, linchangwang.04...@h3c.com<mailto:linchangwang.04...@h3c.com> <linchangwang.04...@h3c.com<mailto:linchangwang.04...@h3c.com>>, lijinm...@chinamobile.com<mailto:lijinm...@chinamobile.com> <lijinm...@chinamobile.com<mailto:lijinm...@chinamobile.com>> Cc: pa...@pmacct.net<mailto:pa...@pmacct.net> <pa...@pmacct.net<mailto:pa...@pmacct.net>> Subject: Re: [GROW] IETF 119, GROW, draft-ietf-grow-bmp-bgp-rib-stats-01, draft-liu-grow-bmp-stats-reports-00 [External Email. Be cautious of content] Hi Thomas All good points and I appreciate your feedback. I will update the doc with your comment. Jinming, I think we should connect to combine both docs in one. Thanks Mukul Juniper Business Use Only Juniper Business Use Only From: thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>> Date: Tuesday, March 19, 2024 at 9:04 PM To: grow@ietf.org<mailto:grow@ietf.org> <grow@ietf.org<mailto:grow@ietf.org>>, liuyis...@chinamobile.com<mailto:liuyis...@chinamobile.com> <liuyis...@chinamobile.com<mailto:liuyis...@chinamobile.com>>, linchangwang.04...@h3c.com<mailto:linchangwang.04...@h3c.com> <linchangwang.04...@h3c.com<mailto:linchangwang.04...@h3c.com>>, lijinm...@chinamobile.com<mailto:lijinm...@chinamobile.com> <lijinm...@chinamobile.com<mailto:lijinm...@chinamobile.com>>, Mukul Srivastava <m...@juniper.net<mailto:m...@juniper.net>> Cc: ahmed.elhass...@swisscom.com<mailto:ahmed.elhass...@swisscom.com> <ahmed.elhass...@swisscom.com<mailto:ahmed.elhass...@swisscom.com>>, pa...@pmacct.net<mailto:pa...@pmacct.net> <pa...@pmacct.net<mailto:pa...@pmacct.net>> Subject: IETF 119, GROW, draft-ietf-grow-bmp-bgp-rib-stats-01, draft-liu-grow-bmp-stats-reports-00 Dear Mukul and Jinming, I have reviewed both documents and have a few comments. Speaking as a network operator, first of all I believe as previous stated it is very much valued that you intend not only to update existing BMP statistics but also much needed new statistics. Thank you very much for this. I agree that it would be helpful if both documents could be merged into 1 before the working group adoption. https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-bgp-rib-stats-01#section-2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-bgp-rib-stats-01*section-2.1__;Iw!!NEt6yMaO-gk!F4OnvDrVEmFPBIPEuhc5-zGQRKko8qfQMbODK5PoaQapCcQyidwbEK7IlD5ngucdbLlwVqGSyNz9NOkROk9fkYnKo81H$> TBD1, TBD2, TBD3 and TBD4: I appreciate that you are changing from counter to gauge, having statistics for pre and post policy in adj-rib as a summary for all address families and for each address family. I value this granularity. TBD5, TBD6 and TBD11: This gives visibility in how many routes have been accepted or dropped by the route policy. I value that you changed from counter to gauge since an operator is typically not interested in the route event count, they are interested in the amount of routes within the rib. TBD7: The term "active route" is not well defined to my understanding. I suggest to align to https://datatracker.ietf.org/doc/html/draft-cppy-grow-bmp-path-marking-tlv-12#section-2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-cppy-grow-bmp-path-marking-tlv-12*section-2.1__;Iw!!NEt6yMaO-gk!F4OnvDrVEmFPBIPEuhc5-zGQRKko8qfQMbODK5PoaQapCcQyidwbEK7IlD5ngucdbLlwVqGSyNz9NOkROk9fkcg-b13N$> and define a gauge for primary and backup path. TBD8: I suggest to use the term " Suppressed" instead of "Dampened" and make a reference to https://www.rfc-editor.org/rfc/rfc2439#section-2.2<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc2439*section-2.2__;Iw!!NEt6yMaO-gk!F4OnvDrVEmFPBIPEuhc5-zGQRKko8qfQMbODK5PoaQapCcQyidwbEK7IlD5ngucdbLlwVqGSyNz9NOkROk9fkfakWsBH$> to be aligned with https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-path-marking-tlv-01#section-2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-path-marking-tlv-01*section-2.1__;Iw!!NEt6yMaO-gk!F4OnvDrVEmFPBIPEuhc5-zGQRKko8qfQMbODK5PoaQapCcQyidwbEK7IlD5ngucdbLlwVqGSyNz9NOkROk9fkbEH5Zx1$> TBD9. I suggest to be more specific with the reference to https://www.rfc-editor.org/rfc/rfc4724.html#section-4.1<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc4724.html*section-4.1__;Iw!!NEt6yMaO-gk!F4OnvDrVEmFPBIPEuhc5-zGQRKko8qfQMbODK5PoaQapCcQyidwbEK7IlD5ngucdbLlwVqGSyNz9NOkROk9fkdGiG8Lm$> to be aligned with https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-path-marking-tlv-01#section-2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-path-marking-tlv-01*section-2.1__;Iw!!NEt6yMaO-gk!F4OnvDrVEmFPBIPEuhc5-zGQRKko8qfQMbODK5PoaQapCcQyidwbEK7IlD5ngucdbLlwVqGSyNz9NOkROk9fkbEH5Zx1$> TBD10: I suggest to reference https://datatracker.ietf.org/doc/html/rfc9494#section-4.3<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc9494*section-4.3__;Iw!!NEt6yMaO-gk!F4OnvDrVEmFPBIPEuhc5-zGQRKko8qfQMbODK5PoaQapCcQyidwbEK7IlD5ngucdbLlwVqGSyNz9NOkROk9fkcLEzk06$>. https://datatracker.ietf.org/doc/html/draft-liu-grow-bmp-stats-reports-00#section-3<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-liu-grow-bmp-stats-reports-00*section-3__;Iw!!NEt6yMaO-gk!F4OnvDrVEmFPBIPEuhc5-zGQRKko8qfQMbODK5PoaQapCcQyidwbEK7IlD5ngucdbLlwVqGSyNz9NOkROk9fkb4rAmoJ$> I share the comments from Jeff on TBD5 and TBD6 in https://datatracker.ietf.org/doc/html/draft-liu-grow-bmp-stats-reports-00#section-3.1.2<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-liu-grow-bmp-stats-reports-00*section-3.1.2__;Iw!!NEt6yMaO-gk!F4OnvDrVEmFPBIPEuhc5-zGQRKko8qfQMbODK5PoaQapCcQyidwbEK7IlD5ngucdbLlwVqGSyNz9NOkROk9fkTHhYax2$>. A reference to the specific section of https://datatracker.ietf.org/doc/html/rfc4271<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4271__;!!NEt6yMaO-gk!F4OnvDrVEmFPBIPEuhc5-zGQRKko8qfQMbODK5PoaQapCcQyidwbEK7IlD5ngucdbLlwVqGSyNz9NOkROk9fkTVAeTza$> describing this behavior is needed. I share the comments from Jeff on TBD3 and TBD4 in https://datatracker.ietf.org/doc/html/draft-liu-grow-bmp-stats-reports-00#section-3.1.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-liu-grow-bmp-stats-reports-00*section-3.1.1__;Iw!!NEt6yMaO-gk!F4OnvDrVEmFPBIPEuhc5-zGQRKko8qfQMbODK5PoaQapCcQyidwbEK7IlD5ngucdbLlwVqGSyNz9NOkROk9fkX-ZkXSm$> since this is vendor specific. Therefore I object. I suggest to use an enterprise specific TLV instead as described https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-ebit-05#section-3.3<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-ebit-05*section-3.3__;Iw!!NEt6yMaO-gk!F4OnvDrVEmFPBIPEuhc5-zGQRKko8qfQMbODK5PoaQapCcQyidwbEK7IlD5ngucdbLlwVqGSyNz9NOkROk9fkVBHnq_5$> Regarding TBD1 and TBD2. I believe the description is ambiguous. Based on my feedback from https://mailarchive.ietf.org/arch/msg/grow/s55XlMStBXpq0BYTAFubg9aOdL8/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/grow/s55XlMStBXpq0BYTAFubg9aOdL8/__;!!NEt6yMaO-gk!F4OnvDrVEmFPBIPEuhc5-zGQRKko8qfQMbODK5PoaQapCcQyidwbEK7IlD5ngucdbLlwVqGSyNz9NOkROk9fkQQLDtrK$> I suggest the following: * Stat Type = TBD1: (64-bit Gauge) How many routes left until configured prefix limit threshold as defined in Section 6.7 of RFC 4271 is reached. This value increases or decreases based when prefix limit threshold is being changed. * Stat Type = TBD2: (64-bit Gauge) How many routes in per-AFI/SAFI left until configured prefix limit threshold as defined in Section 6.7 of RFC 4271 is reached. This value increases or decreases based when prefix limit threshold is being changed. The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge. Best wishes Thomas
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
