Re: [GROW] The GROW WG has placed draft-msri-grow-bmp-bgp-rib-stats in state "Call For Adoption By WG Issued"

Hi Thomas,

I think the suggestions of yours are very good. If the network operator can obtain such information, they will have the opportunity to intervene in the network as soon as possible, which is better than waiting for the BGP session torn down.

Best Regards,
Shunwan

> -----Original Message-----
> From: GROW [mailto:grow-bounces@ietf.org] On Behalf Of
> Thomas.Graf@swisscom.com
> Sent: Saturday, January 6, 2024 7:36 PM
> To: ietf-secretariat-reply@ietf.org;
> draft-msri-grow-bmp-bgp-rib-stats@ietf.org; grow-chairs@ietf.org;
> grow@ietf.org
> Subject: Re: [GROW] The GROW WG has placed
> draft-msri-grow-bmp-bgp-rib-stats in state "Call For Adoption By WG Issued"
> 
> Dear Mukul,
> 
> One more comment I missed in my previous feedback.
> 
> A BGP speaker may have an prefix count upper bound as described in Section
> 6.7 of RFC 4271 (https://datatracker.ietf.org/doc/html/rfc4271#section-6.7)
> configured. When this upper bound is being reached, the BGP peer will be
> temporarely be teared down and a BGP NOTIFICATION message with reason
> subcode as described in Section 3 of RFC 4486
> (https://datatracker.ietf.org/doc/html/rfc4486#section-3) is being
> encapsulated in the BMP peer_down message with reason code 1 as
> described in Section 4.9 of RFC 7854
> (https://datatracker.ietf.org/doc/html/rfc7854#section-4.9).
> 
> However that the network operator is being notified when the upper bound
> is being reached is not sufficient, the network operator also wants to
> monitor the capacity, how many prefixes left until the upper bound is being
> reached.
> 
> I suggest therefore to add an aditional BMP stats counter describing
> 
> - how many prefixes until upper bound is being reached
> - how much percentage of the defined bound is currently being used
> 
> Thank you very much for consdering. Again very happy you take the initiaive
> to add additional BMP stats counters.
> 
> Best wishes
> Thomas
> 
> -----Original Message-----
> From: Graf Thomas, INI-NET-VNC-HCS
> Sent: Thursday, December 7, 2023 1:36 PM
> To: 'IETF Secretariat' <ietf-secretariat-reply@ietf.org>;
> draft-msri-grow-bmp-bgp-rib-stats@ietf.org; grow-chairs@ietf.org;
> grow@ietf.org
> Subject: RE: [GROW] The GROW WG has placed
> draft-msri-grow-bmp-bgp-rib-stats in state "Call For Adoption By WG Issued"
> 
> Dear GROW,
> 
> I support the adoption of the document.
> 
> Some comments for the authors:
> 
> I suggest to reference RFC 9494 in TBD6 of section 2.1 to clearly describe the
> meaning.
> 
> Regarding TBD5, the meaning of "marked as stale by any configuration" is
> unclear to me. Please describe in more detail.
> 
> Would you consider to align the proposed counters to what is being defined
> in section 2.1 of BMP path status
> https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-path-marking-tlv-
> 00#section-2.1 ?
> 
> >From an operator perspective, this would make a lot of sense since
> depending on use case a statistical peering or per path view is needed.
> 
> Best wishes
> Thomas
> 
> -----Original Message-----
> From: GROW <grow-bounces@ietf.org> On Behalf Of IETF Secretariat
> Sent: Wednesday, December 6, 2023 6:18 PM
> To: draft-msri-grow-bmp-bgp-rib-stats@ietf.org; grow-chairs@ietf.org;
> grow@ietf.org
> Subject: [GROW] The GROW WG has placed
> draft-msri-grow-bmp-bgp-rib-stats in state "Call For Adoption By WG Issued"
> 
> 
> Be aware: This is an external email.
> 
> 
> 
> The GROW WG has placed draft-msri-grow-bmp-bgp-rib-stats in state Call
> For Adoption By WG Issued (entered by Job Snijders)
> 
> The document is available at
> https://datatracker.ietf.org/doc/draft-msri-grow-bmp-bgp-rib-stats/
> 
> 
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow