[GROW]Re: IETF 119, GROW, draft-ietf-grow-bmp-bgp-rib-stats-01, draft-liu-grow-bmp-stats-reports-00

[Mukul Srivastava]

Sure, will add then in next update.

Thanks
Mukul



Juniper Business Use Only
From: thomas.g...@swisscom.com 
Date: Wednesday, May 1, 2024 at 2:27 AM
To: Mukul Srivastava , Mukul Srivastava , 
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
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 fami

Re: [GROW] IETF 119, GROW, draft-ietf-grow-bmp-bgp-rib-stats-01, draft-liu-grow-bmp-stats-reports-00

[Mukul Srivastava]

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

[Mukul Srivastava]

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

Re: [GROW] Internet-Draft draft-liu-grow-bmp-stats-reports-00

[Mukul Srivastava]

Hi Jinming Li

Will it make sense to merge these stats with another stats related draft �C “ 
draft-ietf-grow-bmp-bgp-rib-stats-01.txt” that I published a while ago?

Thanks
Mukul



Juniper Business Use Only
From: GROW  on behalf of 李金铭 
Date: Monday, February 26, 2024 at 8:25 PM
To: grow 
Subject: [GROW] Internet-Draft draft-liu-grow-bmp-stats-reports-00
[External Email. Be cautious of content]


Hi all,

We have submitted a new Internet-Draft draft-liu-grow-bmp-stats-reports-00 
which is about BMP Statistics Types.

As the BGP protocol continues to expand, more and more functional features are 
implemented through the BGP protocol, which adds more event information to 
monitor these functional features.This document lists some new statistics types 
to update RFC 7854 for growing BGP features.
The New BMP statistics types are used by the monitoring station to observe more 
interesting events that occur on the router.
New types Include RIB-IN Statistics Types for Route Threshold, RIB-IN/RIB-OUT 
Statistics Types for AS-Path Length Threshold, and RIB-IN/RIB-OUT Statistics 
Types for Route Origin Validation.

If you have some comments and suggestions, please provide feedback.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-liu-grow-bmp-stats-reports/

Best regards,
Jinming Li

___

GROW mailing list

GROW@ietf.org

https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)

[Mukul Srivastava]

Thankyou Paolo and Shunwan for your input.
With the extra details about the errata 7703, that was provided below, I see 
your point very clearly.

I will add new counters for rib-in-pre-policy as mentioned by Shunwan below.

Thanks
Mukul



Juniper Business Use Only
From: Paolo Lucente 
Date: Sunday, January 21, 2024 at 9:06 PM
To: Zhuangshunwan , Mukul Srivastava 
, Job Snijders , grow@ietf.org 

Subject: Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats 
(start 06/Dec/2023 end 06/Jan/2024)
[External Email. Be cautious of content]


Hi Mukul,

I would like to express +1 to Shunwan request. A few more thoughts,
including where the request comes from are captured in this previous
email thread about errata 7703:
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/grow/nQm-lyKSZSaSdIhUQlTa6n-U0tA/__;!!NEt6yMaO-gk!BgWI055OLz5BkhuhpOdOlZSgAgm1tWKlhAMrUM1xQnUqysGknt40nLSy2b368miqAB8uK_r_DQ$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/grow/nQm-lyKSZSaSdIhUQlTa6n-U0tA/__;!!NEt6yMaO-gk!BgWI055OLz5BkhuhpOdOlZSgAgm1tWKlhAMrUM1xQnUqysGknt40nLSy2b368miqAB8uK_r_DQ$>

Paolo


On 20/01/2024 03:45, Zhuangshunwan wrote:
> Hi Mukul,
>
> I have read draft-ietf-grow-bmp-bgp-rib-stats-00 and I think the
> description in your document is very clear and accurate. I think it's
> great to explicitly define Stat Type 7 and Stat Type 9 as counters for
> rib-in-pre-policy and also define counters for rib-in-post-policy.
>
> Thanks,
>
> Shunwan
>
> *From:*Mukul Srivastava [mailto:msri=40juniper@dmarc.ietf.org]
> *Sent:* Friday, January 19, 2024 11:01 PM
> *To:* Zhuangshunwan ; Job Snijders
> ; grow@ietf.org
> *Subject:* Re: [GROW] Working Group Call for
> draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)
>
> Hi Shunwan
>
> I looked at your proposed counter and I feel that they are already
> present in RFC 7854 for rib-in-pre-policy.
>
> Copying it here from RFC 7854.
>
> *4.8 
> <https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc7854.html*section-4.8__;Iw!!NEt6yMaO-gk!BgWI055OLz5BkhuhpOdOlZSgAgm1tWKlhAMrUM1xQnUqysGknt40nLSy2b368miqAB8VyMdHlQ$
>  >.  Stats
> Reports*
>
>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.
>
> For rib-in-post-policy, we don’t have those counters and can be added. I
> will add them.
>
> Let me know if you have any further comments.
>
> Thanks
>
> Mukul
>
> Juniper Business Use Only
>
> *From: *Mukul Srivastava mailto:m...@juniper.net>>
> *Date: *Wednesday, January 17, 2024 at 9:15 AM
> *To: *Zhuangshunwan  <mailto:zhuangshunwan=40huawei@dmarc.ietf.org>>, Job Snijders
>  <mailto:job=40fastly@dmarc.ietf.org>>, grow@ietf.org
> <mailto:grow@ietf.org> mailto:grow@ietf.org>>
> *Subject: *Re: [GROW] Working Group Call for
> draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)
>
> Thanks for the comments.  I will go over it and update docs accordingly.
>
> Thanks
>
> Mukul
>
> *From: *GROW mailto:grow-boun...@ietf.org>> on
> behalf of Zhuangshunwan  <mailto:zhuangshunwan=40huawei@dmarc.ietf.org>>
> *Date: *Saturday, December 9, 2023 at 3:27 AM
> *To: *Zhuangshunwan  <mailto:zhuangshunwan=40huawei@dmarc.ietf.org>>, Job Snijders
>  <mailto:job=40fastly@dmarc.ietf.org>>, grow@ietf.org
> <mailto:grow@ietf.org> mailto:grow@ietf.org>>
> *Subject: *Re: [GROW] Working Group Call for
> draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)
>
> [External Email. Be cautious of content]
>
>
> Hi GROW,
>
> I've noticed this errata report under discussion:
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/grow/g1d3cJhNMuSnchQiqX0lkQCnQkk/__;!!NEt6yMaO-gk!GcBz8ozUcDW3DcFms2m15hiJUwCN7bBXSR3wS_UdvGYS603ApxdNMc2XqFW9jpNp1XgyHbKnvQqlauvtUtmAov7CA-Pm$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/grow/g1d3cJhNMuSnchQiqX0lkQCnQkk/__;!!NEt6yMaO-gk!GcBz8ozUcDW3DcFms2m15hiJUwCN7bBXSR3wS_UdvGYS603ApxdNMc2XqFW9jpNp1XgyHbKnvQqlauvtUtmAov7CA-Pm$>
>  
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/grow/g1d3cJhNMuSnchQiqX0lkQCnQkk/__;!!NEt6yMaO-gk!GcBz8ozUcDW3DcFms2m15hiJUwCN7bBXSR3wS_UdvGYS603ApxdNMc2XqFW9jpNp1XgyHbKnvQqlauvtUtmAov7CA-Pm$>
> If GROW agrees that "the L flag is only applied to Route Monitoring
> messages", to distinguish between pre-policy statistics and post-policy
> statistics of the Adj-RIBs-I

Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)

[Mukul Srivastava]

Hi Job

I have submitted 'draft-ietf-grow-bmp-bgp-rib-stats-00'.

Thanks
Mukul



Juniper Business Use Only
From: GROW  on behalf of Job Snijders 

Date: Monday, January 8, 2024 at 4:46 AM
To: grow@ietf.org 
Subject: Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats 
(start 06/Dec/2023 end 06/Jan/2024)
[External Email. Be cautious of content]


Dear Working Group,

Thank you all for your comments and feedback. The
draft-msri-grow-bmp-bgp-rib-stats document has been adopted by the GROW
working group.

Mukul, please re-submit as 'draft-ietf-grow-bmp-bgp-rib-stats-00'

Additionally, we can work on IANA Early Allocation for codepoints.

Kind regards,

Job
GROW co-chair


On Wed, Dec 06, 2023 at 04:48:32PM +0100, Job Snijders wrote:
> Dear GROW,
>
> The author of draft-msri-grow-bmp-bgp-rib-stats asked whether the
> GROW working group could consider adoption of their internet-draft.
>
> This message is a request to the group for feedback on whether this
> internet-draft should be adopted.
>
> Title: Definition For New BMP Statistics Type
> Abstract:
>   RFC 7854 defined different BMP statistics messages types to observe
>   interesting events that occur on the router.  This document updates
>   RFC 7854 by adding new statistics type.
>
> The Internet-Draft can be found here:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-msri-grow-bmp-bgp-rib-stats-00.html__;!!NEt6yMaO-gk!CPNC-mMNBnGxYEXZ-0R4WfX06dFeVenDZTG8gpdhwnZIYAW6ynLyOUQi9JXZ9AAEJ4liWArbJ2AP37WYEXgvSSQ3VSde$
>
> *** NOTE *** This draft has nothing other than BMP code point requests
> for counters. If adoption fails, the authors can go off an request FCFS
> instead.
>
> Please share with the mailing list if you would like this work to be
> adopted by GROW, are willing to review and/or otherwise contribute to
> this draft!
>
> WG Adoption call ends January 6th, 2024.
>
> Kind regards,
>
> Job / Chris
> GROW co-chairs

___
GROW mailing list
GROW@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/grow__;!!NEt6yMaO-gk!CPNC-mMNBnGxYEXZ-0R4WfX06dFeVenDZTG8gpdhwnZIYAW6ynLyOUQi9JXZ9AAEJ4liWArbJ2AP37WYEXgvSebUR3Zj$
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)

[Mukul Srivastava]

Hi Shunwan

I looked at your proposed counter and I feel that they are already present in 
RFC 7854 for rib-in-pre-policy.
Copying it here from RFC 7854.

4.8<https://www.rfc-editor.org/rfc/rfc7854.html#section-4.8>.  Stats Reports


  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.

For rib-in-post-policy, we don’t have those counters and can be added. I will 
add them.
Let me know if you have any further comments.

Thanks
Mukul



Juniper Business Use Only
From: Mukul Srivastava 
Date: Wednesday, January 17, 2024 at 9:15 AM
To: Zhuangshunwan , Job Snijders 
, grow@ietf.org 
Subject: Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats 
(start 06/Dec/2023 end 06/Jan/2024)
Thanks for the comments.  I will go over it and update docs accordingly.

Thanks
Mukul

From: GROW  on behalf of Zhuangshunwan 

Date: Saturday, December 9, 2023 at 3:27 AM
To: Zhuangshunwan , Job Snijders 
, grow@ietf.org 
Subject: Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats 
(start 06/Dec/2023 end 06/Jan/2024)
[External Email. Be cautious of content]


Hi GROW,

I've noticed this errata report under discussion: 
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/grow/g1d3cJhNMuSnchQiqX0lkQCnQkk/__;!!NEt6yMaO-gk!GcBz8ozUcDW3DcFms2m15hiJUwCN7bBXSR3wS_UdvGYS603ApxdNMc2XqFW9jpNp1XgyHbKnvQqlauvtUtmAov7CA-Pm$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/grow/g1d3cJhNMuSnchQiqX0lkQCnQkk/__;!!NEt6yMaO-gk!GcBz8ozUcDW3DcFms2m15hiJUwCN7bBXSR3wS_UdvGYS603ApxdNMc2XqFW9jpNp1XgyHbKnvQqlauvtUtmAov7CA-Pm$>
If GROW agrees that "the L flag is only applied to Route Monitoring messages", 
to distinguish between pre-policy statistics and post-policy statistics of the 
Adj-RIBs-In, I think the following types could be added for RIB-IN Statistics:

*  Type = TBD8: (64-bit Gauge) Number of routes in pre-policy Adj-RIBs-In.
*  Type = TBD9: (64-bit Gauge) Number of routes in post-policy Adj-RIBs-In.
*  Type = TBD10: Number of routes in per-AFI/SAFI pre-policy 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.
*  Type = TBD11: Number of routes in per-AFI/SAFI post-policy 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.

Waiting to hear your opinions, thanks.

Best regards,
Shunwan

> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Zhuangshunwan
> Sent: Saturday, December 9, 2023 3:15 PM
> To: Job Snijders ; grow@ietf.org
> Subject: Re: [GROW] Working Group Call for
> draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)
>
>
> Hi Job, GROW,
>
> I have read the draft and support its adoption.
>
> Best regards,
> Shunwan
>
> > -Original Message-
> > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
> > Sent: Wednesday, December 6, 2023 11:49 PM
> > To: grow@ietf.org
> > Subject: [GROW] Working Group Call for
> > draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)
> >
> > Dear GROW,
> >
> > The author of draft-msri-grow-bmp-bgp-rib-stats asked whether the GROW
> > working group could consider adoption of their internet-draft.
> >
> > This message is a request to the group for feedback on whether this
> > internet-draft should be adopted.
> >
> > Title: Definition For New BMP Statistics Type
> > Abstract:
> >   RFC 7854 defined different BMP statistics messages types to observe
> >   interesting events that occur on the router.  This document updates
> >   RFC 7854 by adding new statistics type.
> >
> > The Internet-Draft can be found here:
> > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-msri-grow-bmp-bgp-rib-stats-00.h__;!!NEt6yMaO-gk!GcBz8ozUcDW3DcFms2m15hiJUwCN7bBXSR3wS_UdvGYS603ApxdNMc2XqFW9jpNp1XgyHbKnvQqlauvtUtmAohLYbTUy$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-msri-grow-bmp-bgp-rib-stats-00.h__;!!NEt6yMaO-gk!GcBz8ozUcDW3DcFms2m15hiJUwCN7bBXSR3wS_UdvGYS603ApxdNMc2XqFW9jpNp1XgyHbKnvQqlauvtUtmAohLYbTUy$>
> > tml
> >
> > *** NOTE *** This draft has nothing other than BMP code point requests
> > for counters. If adoption fails, the authors can go off an request FCFS
> instead.
> >
> > Please share with the mailing list if you would like this work to be
> > adopted by GROW, are willing to review and/or otherwise contribute to
&

Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)

[Mukul Srivastava]

Thanks for the comments.  I will go over it and update docs accordingly.

Thanks
Mukul



Juniper Business Use Only
From: GROW  on behalf of Zhuangshunwan 

Date: Saturday, December 9, 2023 at 3:27 AM
To: Zhuangshunwan , Job Snijders 
, grow@ietf.org 
Subject: Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats 
(start 06/Dec/2023 end 06/Jan/2024)
[External Email. Be cautious of content]


Hi GROW,

I've noticed this errata report under discussion: 
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/grow/g1d3cJhNMuSnchQiqX0lkQCnQkk/__;!!NEt6yMaO-gk!GcBz8ozUcDW3DcFms2m15hiJUwCN7bBXSR3wS_UdvGYS603ApxdNMc2XqFW9jpNp1XgyHbKnvQqlauvtUtmAov7CA-Pm$
If GROW agrees that "the L flag is only applied to Route Monitoring messages", 
to distinguish between pre-policy statistics and post-policy statistics of the 
Adj-RIBs-In, I think the following types could be added for RIB-IN Statistics:

*  Type = TBD8: (64-bit Gauge) Number of routes in pre-policy Adj-RIBs-In.
*  Type = TBD9: (64-bit Gauge) Number of routes in post-policy Adj-RIBs-In.
*  Type = TBD10: Number of routes in per-AFI/SAFI pre-policy 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.
*  Type = TBD11: Number of routes in per-AFI/SAFI post-policy 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.

Waiting to hear your opinions, thanks.

Best regards,
Shunwan

> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Zhuangshunwan
> Sent: Saturday, December 9, 2023 3:15 PM
> To: Job Snijders ; grow@ietf.org
> Subject: Re: [GROW] Working Group Call for
> draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)
>
>
> Hi Job, GROW,
>
> I have read the draft and support its adoption.
>
> Best regards,
> Shunwan
>
> > -Original Message-
> > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
> > Sent: Wednesday, December 6, 2023 11:49 PM
> > To: grow@ietf.org
> > Subject: [GROW] Working Group Call for
> > draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)
> >
> > Dear GROW,
> >
> > The author of draft-msri-grow-bmp-bgp-rib-stats asked whether the GROW
> > working group could consider adoption of their internet-draft.
> >
> > This message is a request to the group for feedback on whether this
> > internet-draft should be adopted.
> >
> > Title: Definition For New BMP Statistics Type
> > Abstract:
> >   RFC 7854 defined different BMP statistics messages types to observe
> >   interesting events that occur on the router.  This document updates
> >   RFC 7854 by adding new statistics type.
> >
> > The Internet-Draft can be found here:
> > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-msri-grow-bmp-bgp-rib-stats-00.h__;!!NEt6yMaO-gk!GcBz8ozUcDW3DcFms2m15hiJUwCN7bBXSR3wS_UdvGYS603ApxdNMc2XqFW9jpNp1XgyHbKnvQqlauvtUtmAohLYbTUy$
> > tml
> >
> > *** NOTE *** This draft has nothing other than BMP code point requests
> > for counters. If adoption fails, the authors can go off an request FCFS
> instead.
> >
> > Please share with the mailing list if you would like this work to be
> > adopted by GROW, are willing to review and/or otherwise contribute to
> this draft!
> >
> > WG Adoption call ends January 6th, 2024.
> >
> > Kind regards,
> >
> > Job / Chris
> > GROW co-chairs
> >
> > ___
> > GROW mailing list
> > GROW@ietf.org
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/grow__;!!NEt6yMaO-gk!GcBz8ozUcDW3DcFms2m15hiJUwCN7bBXSR3wS_UdvGYS603ApxdNMc2XqFW9jpNp1XgyHbKnvQqlauvtUtmAolGoROJy$
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/grow__;!!NEt6yMaO-gk!GcBz8ozUcDW3DcFms2m15hiJUwCN7bBXSR3wS_UdvGYS603ApxdNMc2XqFW9jpNp1XgyHbKnvQqlauvtUtmAolGoROJy$

___
GROW mailing list
GROW@ietf.org

Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)

[Mukul Srivastava]

Thanks, I will go over the comments that I received and update the new version.

Thanks
Mukul



Juniper Business Use Only
From: GROW  on behalf of Job Snijders 

Date: Monday, January 8, 2024 at 4:46 AM
To: grow@ietf.org 
Subject: Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats 
(start 06/Dec/2023 end 06/Jan/2024)
[External Email. Be cautious of content]


Dear Working Group,

Thank you all for your comments and feedback. The
draft-msri-grow-bmp-bgp-rib-stats document has been adopted by the GROW
working group.

Mukul, please re-submit as 'draft-ietf-grow-bmp-bgp-rib-stats-00'

Additionally, we can work on IANA Early Allocation for codepoints.

Kind regards,

Job
GROW co-chair


On Wed, Dec 06, 2023 at 04:48:32PM +0100, Job Snijders wrote:
> Dear GROW,
>
> The author of draft-msri-grow-bmp-bgp-rib-stats asked whether the
> GROW working group could consider adoption of their internet-draft.
>
> This message is a request to the group for feedback on whether this
> internet-draft should be adopted.
>
> Title: Definition For New BMP Statistics Type
> Abstract:
>   RFC 7854 defined different BMP statistics messages types to observe
>   interesting events that occur on the router.  This document updates
>   RFC 7854 by adding new statistics type.
>
> The Internet-Draft can be found here:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-msri-grow-bmp-bgp-rib-stats-00.html__;!!NEt6yMaO-gk!CPNC-mMNBnGxYEXZ-0R4WfX06dFeVenDZTG8gpdhwnZIYAW6ynLyOUQi9JXZ9AAEJ4liWArbJ2AP37WYEXgvSSQ3VSde$
>
> *** NOTE *** This draft has nothing other than BMP code point requests
> for counters. If adoption fails, the authors can go off an request FCFS
> instead.
>
> Please share with the mailing list if you would like this work to be
> adopted by GROW, are willing to review and/or otherwise contribute to
> this draft!
>
> WG Adoption call ends January 6th, 2024.
>
> Kind regards,
>
> Job / Chris
> GROW co-chairs

___
GROW mailing list
GROW@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/grow__;!!NEt6yMaO-gk!CPNC-mMNBnGxYEXZ-0R4WfX06dFeVenDZTG8gpdhwnZIYAW6ynLyOUQi9JXZ9AAEJ4liWArbJ2AP37WYEXgvSebUR3Zj$
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] IETF draft - BMP BGP RIB statistics

[Mukul Srivastava]

Hi All

I wanted to bring your attention for a new draft that I submitted to report BGP 
rib statistics.
https://datatracker.ietf.org/doc/draft-msri-grow-bmp-bgp-rib-stats/

Will appreciate your feedback on it.

Thanks
Mukul


Juniper Business Use Only
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BMP compression Draft

[Mukul Srivastava]

Hello GROW,


Looks like the link in my previous mail is wrong.

Corrected link:
https://tools.ietf.org/id/draft-msri-grow-bmp-compression-00.txt

Thanks
Mukul

From: Mukul Srivastava 
Date: Wednesday, October 16, 2019 at 9:46 AM
To: "grow@ietf.org" 
Cc: Paolo Lucente , Mukul Srivastava 
Subject: BMP compression Draft


Hello GROW,


Myself and Paolo have submitted 
https://www.ietf.org/id/draft-msri-grow-bmp-compression-00.txt<https://urldefense.com/v3/__https:/www.ietf.org/id/draft-lucente-bmp-tlv-00.txt__;!8WoA6RjC81c!Ve6VOxjMty-V1IHnsYIbwkFNeemoNfQZHSV_wmwIEB33caxtUSW6gjozn7v6QA$>
 .
We would like to get opportunity to present it in Singapore (IETF 106) and 
would much welcome feedback on list meanwhile.

Abstract below for your convenience:

“This document provides specification for an optional compressed BMP Feed from 
a router to BMP station.”

Thanks
Mukul

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] BMP compression Draft

[Mukul Srivastava]

Hello GROW,


Myself and Paolo have submitted 
https://www.ietf.org/id/draft-msri-grow-bmp-compression-00.txt
 .
We would like to get opportunity to present it in Singapore (IETF 106) and 
would much welcome feedback on list meanwhile.

Abstract below for your convenience:

“This document provides specification for an optional compressed BMP Feed from 
a router to BMP station.”

Thanks
Mukul

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Value of timestamps in BMP header for rib-out monitoring

[Mukul Srivastava]

Thanks Tim.

Thanks
Mukul

From: "Tim Evens (tievens)" 
Date: Thursday, June 13, 2019 at 12:01 PM
To: Mukul Srivastava , 
"draft-ietf-grow-bmp-adj-rib-...@ietf.org" 

Cc: "grow@ietf.org" , Jeff Haas , John 
Scudder 
Subject: Re: Value of timestamps in BMP header for rib-out monitoring

Thanks Mukul, I'll update that as noted.

On 6/13/19, 6:17 AM, "Mukul Srivastava" 
mailto:m...@juniper.net>> wrote:

Hi All

The current BMP Adj-RIB-Out draft doesn’t define what timestamp should be used 
in Per-Peer header for BMP ADJ-RIB-OUT monitoring.

BMP RFC 7854 defines “Timestamp” in Per-Peer header as below:

Timestamp: The time when the encapsulated routes were received (one may also 
think of this as the time when they were installed in the Adj-RIB-In), 
expressed in seconds and microseconds since midnight (zero hour), January 1, 
1970 (UTC).  If zero, the time is unavailable.  Precision of the timestamp is 
implementation-dependent.

The above timestamp use doesn’t make much sense for Adj-RIB-Out case. A better 
value for timestamp, would be the time when a prefix was advertised to a peer. 
Collector can use this time stamp to get some sense of “when a given prefix was 
advertised to a peer”.

Otherwise the definition of “timestamp” would be the same as in RFC 7854. So, 
something like this should be added in the for BMP ADJ-RIB-OUT draft:

   o  Timestamp: The time when the encapsulated routes were advertised
  (one may also think of this as the time when they were installed
  in the Adj-RIB-Out), expressed in seconds and microseconds since
  midnight (zero hour), January 1, 1970 (UTC).  If zero, the time is
  unavailable.  Precision of the timestamp is implementation-
  dependent.

Thanks
Mukul
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Value of timestamps in BMP header for local-rib monitoring

[Mukul Srivastava]

Hi All

The current BMP Local-RIb draft doesn’t define what timestamp should be used in 
Per-Peer header for BMP local RIB monitoring.

BMP RFC 7854 defines “Timestamp” in Per-Peer header as below:

Timestamp: The time when the encapsulated routes were received(one may also 
think of this as the time when they were installed in the Adj-RIB-In), 
expressed in seconds and microseconds since midnight (zero hour), January 1, 
1970 (UTC).  If zero, the time is unavailable.  Precision of the timestamp is 
implementation-dependent.

The above timestamp use doesn’t make much sense for local RIB monitoring case.

Proposal:

  1.  Since local RIB is not specific to a peer, the time stamp could be the 
time when BMP RM message was created or sent to BMP collector.

  1.  Another option would be that the timestamp value be the time when this 
prefix was installed in local RIB.

Otherwise the definition of “timestamp” would be the same as in RFC 7854. So, 
something like this:

   o  Timestamp: The time when the encapsulated routes were installed in
  The Loc-RIB, expressed in seconds and microseconds since
  midnight (zero hour), January 1, 1970 (UTC).  If zero, the time is
  unavailable.  Precision of the timestamp is implementation-
  dependent.
Thanks
Mukul
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Value of timestamps in BMP header for rib-out monitoring

[Mukul Srivastava]

Hi All

The current BMP Adj-RIB-Out draft doesn’t define what timestamp should be used 
in Per-Peer header for BMP ADJ-RIB-OUT monitoring.

BMP RFC 7854 defines “Timestamp” in Per-Peer header as below:

Timestamp: The time when the encapsulated routes were received (one may also 
think of this as the time when they were installed in the Adj-RIB-In), 
expressed in seconds and microseconds since midnight (zero hour), January 1, 
1970 (UTC).  If zero, the time is unavailable.  Precision of the timestamp is 
implementation-dependent.

The above timestamp use doesn’t make much sense for Adj-RIB-Out case. A better 
value for timestamp, would be the time when a prefix was advertised to a peer. 
Collector can use this time stamp to get some sense of “when a given prefix was 
advertised to a peer”.

Otherwise the definition of “timestamp” would be the same as in RFC 7854. So, 
something like this should be added in the for BMP ADJ-RIB-OUT draft:

   o  Timestamp: The time when the encapsulated routes were advertised
  (one may also think of this as the time when they were installed
  in the Adj-RIB-Out), expressed in seconds and microseconds since
  midnight (zero hour), January 1, 1970 (UTC).  If zero, the time is
  unavailable.  Precision of the timestamp is implementation-
  dependent.

Thanks
Mukul
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow