Re: [GROW] IETF 119, GROW, draft-ietf-grow-bmp-bgp-rib-stats-01, draft-liu-grow-bmp-stats-reports-00
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 Sent: Tuesday, April 30, 2024 6:37 PM To: Mukul Srivastava ; Graf Thomas, INI-NET-VNC-HCS ; 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 mailto:grow-boun...@ietf.org>> on behalf of Mukul Srivastava 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> mailto:thomas.g...@swisscom.com>>, grow@ietf.org<mailto:grow@ietf.org> mailto:grow@ietf.org>>, liuyis...@chinamobile.com<mailto:liuyis...@chinamobile.com> mailto:liuyis...@chinamobile.com>>, linchangwang.04...@h3c.com<mailto:linchangwang.04...@h3c.com> mailto:linchangwang.04...@h3c.com>>, lijinm...@chinamobile.com<mailto:lijinm...@chinamobile.com> mailto:lijinm...@chinamobile.com>> Cc: pa...@pmacct.net<mailto: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> mailto:thomas.g...@swisscom.com>> Date: Tuesday, March 19, 2024 at 9:04 PM To: grow@ietf.org<mailto:grow@ietf.org> mailto:grow@ietf.org>>, liuyis...@chinamobile.com<mailto:liuyis...@chinamobile.com> mailto:liuyis...@chinamobile.com>>, linchangwang.04...@h3c.com<mailto:linchangwang.04...@h3c.com> mailto:linchangwang.04...@h3c.com>>, lijinm...@chinamobile.com<mailto:lijinm...@chinamobile.com> mailto:lijinm...@chinamobile.com>>, Mukul Srivastava mailto:m...@juniper.net>> Cc: ahmed.elhass...@swisscom.com<mailto:ahmed.elhass...@swisscom.com> mailto:ahmed.elhass...@swisscom.com>>, pa...@pmacct.net<mailto: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
Re: [GROW] IETF 119, GROW, draft-ietf-grow-bmp-bgp-rib-stats-01, draft-liu-grow-bmp-stats-reports-00
perhaps the abstract can say a wee bit about what the heck the new stats are beyond that they are new? :) randy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] IETF 119, GROW, draft-ietf-grow-bmp-bgp-rib-stats-01, draft-liu-grow-bmp-stats-reports-00
Dear Mukul, Thanks for posting a new version of the document. Can you expand the "IANA Considerations" section a bit more? Precise instructions from which sub-registries exactly codepoints need to be allocated with what names would be good. Right now the section reads: "This document requests that IANA assign the following new parameters to the BMP parameters name space." So it seems some piece is missing Kind regards, Job On Tue, Apr 30, 2024 at 04:36:32PM +, Mukul Srivastava wrote: > 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 on behalf of Mukul Srivastava > > Date: Friday, March 22, 2024 at 9:43 AM > To: thomas.g...@swisscom.com , grow@ietf.org > , liuyis...@chinamobile.com , > linchangwang.04...@h3c.com , > lijinm...@chinamobile.com > Cc: 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 > Date: Tuesday, March 19, 2024 at 9:04 PM > To: grow@ietf.org , liuyis...@chinamobile.com > , linchangwang.04...@h3c.com > , lijinm...@chinamobile.com > , Mukul Srivastava > Cc: ahmed.elhass...@swisscom.com , > 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
Re: [GROW] IETF 119, GROW, draft-ietf-grow-bmp-bgp-rib-stats-01, draft-liu-grow-bmp-stats-reports-00
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 on behalf of Mukul Srivastava Date: Friday, March 22, 2024 at 9:43 AM To: thomas.g...@swisscom.com , grow@ietf.org , liuyis...@chinamobile.com , linchangwang.04...@h3c.com , lijinm...@chinamobile.com Cc: 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 Date: Tuesday, March 19, 2024 at 9:04 PM To: grow@ietf.org , liuyis...@chinamobile.com , linchangwang.04...@h3c.com , lijinm...@chinamobile.com , Mukul Srivastava Cc: ahmed.elhass...@swisscom.com , 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
Re: [GROW] IETF 119, GROW, draft-ietf-grow-bmp-bgp-rib-stats-01, draft-liu-grow-bmp-stats-reports-00
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 From: thomas.g...@swisscom.com Date: Tuesday, March 19, 2024 at 9:04 PM To: grow@ietf.org , liuyis...@chinamobile.com , linchangwang.04...@h3c.com , lijinm...@chinamobile.com , Mukul Srivastava Cc: ahmed.elhass...@swisscom.com , 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 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 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 to be aligned with https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-path-marking-tlv-01#section-2.1 TBD9. I suggest to be more specific with the reference to https://www.rfc-editor.org/rfc/rfc4724.html#section-4.1 to be aligned with https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-path-marking-tlv-01#section-2.1 TBD10: I suggest to reference https://datatracker.ietf.org/doc/html/rfc9494#section-4.3. https://datatracker.ietf.org/doc/html/draft-liu-grow-bmp-stats-reports-00#section-3 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. A reference to the specific section of https://datatracker.ietf.org/doc/html/rfc4271 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 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 Regarding TBD1 and TBD2. I believe the description is ambiguous. Based on my feedback from https://mailarchive.ietf.org/arch/msg/grow/s55XlMStBXpq0BYTAFubg9aOdL8/ 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 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] 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 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 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 to be aligned with https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-path-marking-tlv-01#section-2.1 TBD9. I suggest to be more specific with the reference to https://www.rfc-editor.org/rfc/rfc4724.html#section-4.1 to be aligned with https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-path-marking-tlv-01#section-2.1 TBD10: I suggest to reference https://datatracker.ietf.org/doc/html/rfc9494#section-4.3. https://datatracker.ietf.org/doc/html/draft-liu-grow-bmp-stats-reports-00#section-3 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. A reference to the specific section of https://datatracker.ietf.org/doc/html/rfc4271 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 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 Regarding TBD1 and TBD2. I believe the description is ambiguous. Based on my feedback from https://mailarchive.ietf.org/arch/msg/grow/s55XlMStBXpq0BYTAFubg9aOdL8/ 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
