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 +0000, 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 > > @[email protected]<mailto:[email protected]> > > I am looking for early code point assignment. Pls help in the assignment. > > @[email protected]<mailto:[email protected]> > Let me know if you want to combine your work with my draft. > > Thanks > Mukul > > > > Juniper Business Use Only > From: GROW <[email protected]> on behalf of Mukul Srivastava > <[email protected]> > Date: Friday, March 22, 2024 at 9:43 AM > To: [email protected] <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, > [email protected] <[email protected]> > Cc: [email protected] <[email protected]> > 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: [email protected] <[email protected]> > Date: Tuesday, March 19, 2024 at 9:04 PM > To: [email protected] <[email protected]>, [email protected] > <[email protected]>, [email protected] > <[email protected]>, [email protected] > <[email protected]>, Mukul Srivastava <[email protected]> > Cc: [email protected] <[email protected]>, > [email protected] <[email protected]> > 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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
