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

[Thomas.Graf]

Dear Changwang,

Thanks a lot for addressing my comments by adding a new stats counter TBD12. 
All perfect.

I reviewed the new document and believe it is in a good shape now.

Best wishes
Thomas

From: linchangwang 
Sent: Thursday, May 9, 2024 3:39 AM
To: Mukul Srivastava ; Graf Thomas, INI-NET-VNC-HCS 
; grow@ietf.org; liuyis...@chinamobile.com; 
lijinm...@chinamobile.com; grow-cha...@ietf.org
Cc: pa...@pmacct.net
Subject: [GROW]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

Thank you for Mukul and WG's suggestions.
We have merged the content of draft-liu-grow-bmp-stats-reports-00 into 
draft-ietf-grow-bmp-bgp-rib-stats-03 and made modifications based on comments.

The new document has been posted.
https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-bgp-rib-stats-03

The main modifications are as follows:
1.Merged draft-liu-grow-bmp-stats-reports-00 into 
draft-ietf-grow-bmp-bgp-rib-stats-03
2.Updated the description in the abstract
3.Modified the reference to RFC4271
3.Changed the route specification statistics to be vendor-defined
4.Updated the statistical definition of route specifications


Feel free to review and provide comments.

Thanks,
Changwang


发件人: Mukul Srivastava mailto:m...@juniper.net>>
发送时间: 2024年5月7日 1:44
收件人: thomas.g...@swisscom.com; 
grow@ietf.org; 
liuyis...@chinamobile.com; linchangwang (RD) 
mailto:linchangwang.04...@h3c.com>>; 
lijinm...@chinamobile.com; 
grow-cha...@ietf.org
抄送: pa...@pmacct.net
主题: Re: IETF 119, GROW, draft-ietf-grow-bmp-bgp-rib-stats-01, 
draft-liu-grow-bmp-stats-reports-00

Sure, will add then in next update.

Thanks
Mukul



Juniper Business Use Only
From: thomas.g...@swisscom.com 
mailto:thomas.g...@swisscom.com>>
Date: Wednesday, May 1, 2024 at 2:27 AM
To: Mukul Srivastava mailto:m...@juniper.net>>, Mukul 
Srivastava mailto:m...@juniper.net>>, 
grow@ietf.org mailto:grow@ietf.org>>, 
liuyis...@chinamobile.com 
mailto:liuyis...@chinamobile.com>>, 
linchangwang.04...@h3c.com 
mailto:linchangwang.04...@h3c.com>>, 
lijinm...@chinamobile.com 
mailto:lijinm...@chinamobile.com>>, 
grow-cha...@ietf.org 
mailto:grow-cha...@ietf.org>>
Cc: pa...@pmacct.net 
mailto: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 mailto:m...@juniper.net>>
Sent: Tuesday, April 30, 2024 6:37 PM
To: Mukul Srivastava 
mailto:msri=40juniper@dmarc.ietf.org>>; 
Graf Thomas, INI-NET-VNC-HCS 
mailto: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

I am looking for early code point assignment. Pls help in the assignment.

@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>>, 
grow@ietf.org mailto:grow@ietf.org>>, 
liuyis...@chinamobile.com 

Re: [GROW] Working Group Call for Adoption for draft-hmntsharma-bmp-tcp-ao (start 29/Apr/2024 end 15/May/2024)

[Thomas.Graf]

Dear GROW,

I have read the document and support the adoption. 

Best wishes
Thomas

-Original Message-
From: GROW  On Behalf Of Job Snijders
Sent: Monday, April 29, 2024 11:54 PM
To: grow@ietf.org
Subject: [GROW] Working Group Call for Adoption for draft-hmntsharma-bmp-tcp-ao 
(start 29/Apr/2024 end 15/May/2024)


Be aware: This is an external email.



Dear GROW,

The author of draft-hmntsharma-bmp-tcp-ao 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: TCP-AO Protection for BGP Monitoring Protocol
Abstract:
  This document outlines the utilization of the TCP Authentication
  Option (TCP-AO), as specified in RFC5925, for the authentication of
  BGP Monitoring Protocol (BMP) sessions, as specified in RFC7854.
  TCP-AO provides for the authentication of BMP sessions established
  between routers and BMP stations at the TCP layer.

The Internet-Draft can be found here:
https://datatracker.ietf.org/doc/html/draft-hmntsharma-bmp-tcp-ao

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 May 15th, 2024.

Kind regards,

Job / Chris
GROW co-chairs

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

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Thomas.Graf]

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

I am looking for early code point assignment. Pls help in the assignment.

@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>>, 
grow@ietf.org mailto:grow@ietf.org>>, 
liuyis...@chinamobile.com 
mailto:liuyis...@chinamobile.com>>, 
linchangwang.04...@h3c.com 
mailto:linchangwang.04...@h3c.com>>, 
lijinm...@chinamobile.com 
mailto:lijinm...@chinamobile.com>>
Cc: 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>>
Date: Tuesday, March 19, 2024 at 9:04 PM
To: grow@ietf.org mailto:grow@ietf.org>>, 
liuyis...@chinamobile.com 
mailto:liuyis...@chinamobile.com>>, 
linchangwang.04...@h3c.com 
mailto:linchangwang.04...@h3c.com>>, 
lijinm...@chinamobile.com 
mailto:lijinm...@chinamobile.com>>, Mukul Srivastava 
mailto:m...@juniper.net>>
Cc: ahmed.elhass...@swisscom.com 
mailto:ahmed.elhass...@swisscom.com>>, 
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



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 

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

[Thomas.Graf]

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

Re: [GROW] Working Group Last Call (WGLC) for draft-ietf-grow-bmp-peer-up (start 22/Jan/2024 end 6/Feb/2024)

[Thomas.Graf]

Dear GROW,

Thanks a lot! I support the publication of the document.

Best wishs
Thomas

-Original Message-
From: GROW  On Behalf Of Job Snijders
Sent: Monday, January 22, 2024 8:21 PM
To: grow@ietf.org
Subject: [GROW] Working Group Last Call (WGLC) for draft-ietf-grow-bmp-peer-up 
(start 22/Jan/2024 end 6/Feb/2024)


Be aware: This is an external email.



Dear all,

As requested during the IETF 118 GROW session in Prague, Czechia, a "Working 
Group Last Call" is now issued for draft-ietf-grow-bmp-peer-up.
This phase will last about 2 weeks. We'd love to hear from you, especially from 
BMP implementers!

Please review the document, consider whether it should advance in the 
publication pipeline, and provide feedback! ... before February 6th, please :-)

The abstract for draft-ietf-grow-bmp-peer-up:

"""
RFC 7854, BMP, uses different message types for different purposes.
Most of these are Type, Length, Value (TLV) structured. One message
type, the Peer Up message, lacks a set of TLVs defined for its use,
instead sharing a namespace with the Initiation message. Subsequent
experience has shown that this namespace sharing was a mistake, as
it hampers the extension of the protocol.

This document updates RFC 7854 by creating an independent namespace
for the Peer Up message. It also updates RFC 8671 and RFC 9069 by
moving the defined codepoints in the newly introduced registry. The
changes in this document are formal only, compliant implementations
of RFC 7854, RFC 8671 and RFC 9069 also comply with this
specification.
"""

The internet-draft itself and associated information are available at:
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-peer-up/

Kind regards,

Job
GROW co-chair

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

smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] draft-tgraf-netconf-notif-sequencing-03, draft-tgraf-netconf-yang-push-observation-time-00

[Thomas.Graf]

Dear netconf,

The following two documents have been updated:


Name: draft-tgraf-netconf-notif-sequencing

Revision: 03

Title:Support of Hostname and Sequencing in YANG Notifications

Date: 2024-01-14

Group:Individual Submission

Pages:10

URL:  
https://www.ietf.org/archive/id/draft-tgraf-netconf-notif-sequencing-03.txt

Status:   https://datatracker.ietf.org/doc/draft-tgraf-netconf-notif-sequencing/

HTMLized: 
https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-notif-sequencing

Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-tgraf-netconf-notif-sequencing-03


Title:Support of Network Observation Timestamping in YANG Notifications

Date: 2024-01-14

Group:Individual Submission

Pages:13

URL:  
https://www.ietf.org/archive/id/draft-tgraf-netconf-yang-push-observation-time-00.txt

Status:   
https://datatracker.ietf.org/doc/draft-tgraf-netconf-yang-push-observation-time/

HTMLized: 
https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-yang-push-observation-time


draft-tgraf-netconf-notif-sequencing was presented in IETF 118 and received 
feedback from Jan Lindblad to expand the definition of the sysName object which 
we addressed in this revision. Feedback welcome if this addresses the concern.

In draft-tgraf-netconf-yang-push-observation-time we added a paragraph in the 
intro section describing a common network operator problem when the bucketing 
in a timeseries data base is equally long to the periodic YANG push 
subscription and eventTime is being used for timeseries data base indexing. 
Leading to inconsistent accounting errors in the time series database which is 
being resolved by using the observation-time instead.

I take the liberty to share two documents from the YANG Push to Apache Kafka 
side meeting at IETF 118. Giving the overall picture and the current state.

https://github.com/network-analytics/draft-daisy-kafka-yang-integration/blob/main/draft-daisy-kafka-yang-integration-05.md
https://github.com/network-analytics/draft-daisy-kafka-yang-integration/blob/main/yang-push-workflow-02.pdf

We received comments from the netconf chairs during the netconf sessions and 
also from the community during the side meeting that an IETF document 
describing the overall picture with the references to each draft document 
describing the changes to the netconf notification, YANG push header and the 
YANG library but also to Apache Kafka and its schema registry would be very 
helpful. That document is in the works to be ready for IETF 119.

I would appreciate your review and comments on the mailing list.

Best wishes
Thomas


smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] GROW, draft-lucente-grow-bmp-rel - BMP warning and upper bound event reason codes

[Thomas.Graf]

Dear Paolo and Camilo,

I have a comment on Section 3.3.1 of draft draft-lucente-grow-bmp-rel 
(https://datatracker.ietf.org/doc/html/draft-lucente-grow-bmp-rel-03#section-3.3.1).
 Please consider to add two additional event reason codes as described below.

As described in my previous post to the draft-msri-grow-bmp-bgp-rib-stats 
authors.


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 additional BMP stats counter in 
draft-msri-grow-bmp-bgp-rib-stats describing



- how many prefixes until upper bound is being reached

- how much percentage of the defined bound is currently being used


The network operator usually has the possibility to chose between taking the 
peer down when the upper bound is being reached, or filter the paths above the 
configured upper bound.


I suggest therefore to add two event reason codes in draft-lucente-grow-bmp-rel 
describing

- Crossed warning bound, path not being dropped
- Crossed upper bound, path being dropped

These two reasons codes enables the network operator to perform root cause 
analysis. Its not only enough to monitor proactively the capacity of the peer 
and being notified with the right reason code and upper bound value in the BGP 
notification message when peer is being proactively being taken down. The 
network operator also wants to understand who caused the crossing of the 
warning and upper bound. The who translates to paths being exported by BMP 
route-monitoring sharing the following BGP attributes:


  *   BGP origin (https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.1)
  *   BGP AS Path (https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.2)
  *   BGP next-hop (https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.3)

I hope that makes sense. Feedback and comments welcome.

I will also augment the control plane a list of common symptoms in Semantic 
Metadata Annotation for Network Anomaly Detection 
(https://datatracker.ietf.org/doc/html/draft-netana-opsawg-nmrg-network-anomaly-semantics-01#symptom_control_plane_actions_table)
 where we start defining an informational module for network symptoms for 
network anomaly detection describing network action, reason, cause. Was 
presented at NMRG and IEPG at IETF 118. 
https://datatracker.ietf.org/meeting/118/materials/slides-118-nmrg-semantic-metadata-annotation-for-network-anomaly-detection-01.pdf

Best wishes
Thomas


smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Thomas.Graf]

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' ; 
draft-msri-grow-bmp-bgp-rib-st...@ietf.org; grow-cha...@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  On Behalf Of IETF Secretariat
Sent: Wednesday, December 6, 2023 6:18 PM
To: draft-msri-grow-bmp-bgp-rib-st...@ietf.org; grow-cha...@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

smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Thomas.Graf]

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  On Behalf Of IETF Secretariat
Sent: Wednesday, December 6, 2023 6:18 PM
To: draft-msri-grow-bmp-bgp-rib-st...@ietf.org; grow-cha...@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

smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] The GROW WG has placed draft-fiebig-grow-bgpopsecupd in state "Call For Adoption By WG Issued"

[Thomas.Graf]

Dear GROW,

I support the adoption of document. It gives a network operator a good overview 
on BGP security considerations.

Best wishes
Thomas

-Original Message-
From: GROW  On Behalf Of IETF Secretariat
Sent: Wednesday, December 6, 2023 6:17 PM
To: draft-fiebig-grow-bgpopsec...@ietf.org; grow-cha...@ietf.org; grow@ietf.org
Subject: [GROW] The GROW WG has placed draft-fiebig-grow-bgpopsecupd in state 
"Call For Adoption By WG Issued"


Be aware: This is an external email.



The GROW WG has placed draft-fiebig-grow-bgpopsecupd in state Call For Adoption 
By WG Issued (entered by Job Snijders)

The document is available at
https://datatracker.ietf.org/doc/draft-fiebig-grow-bgpopsecupd/


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

smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] The GROW WG has placed draft-pels-grow-yang-bgp-communities in state "Call For Adoption By WG Issued"

[Thomas.Graf]

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  On Behalf Of IETF Secretariat
Sent: Wednesday, December 6, 2023 6:19 PM
To: draft-pels-grow-yang-bgp-communit...@ietf.org; grow-cha...@ietf.org; 
grow@ietf.org
Subject: [GROW] The GROW WG has placed draft-pels-grow-yang-bgp-communities in 
state "Call For Adoption By WG Issued"


Be aware: This is an external email.



The GROW WG has placed draft-pels-grow-yang-bgp-communities in state Call For 
Adoption By WG Issued (entered by Job Snijders)

The document was previously in state Candidate for WG Adoption

The document is available at
https://datatracker.ietf.org/doc/draft-pels-grow-yang-bgp-communities/


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

smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Call for Adoption draft-lucente-grow-bmp-rel (start 25/Oct/2023 end 08/Nov/2023)

[Thomas.Graf]

Dear GROW,

I support the adoption of the document. In particular useful are the events 
exposing paths being dropped due to policy configurations.

Best wishes
Thomas

-Original Message-
From: GROW  On Behalf Of Job Snijders
Sent: Wednesday, October 25, 2023 12:57 AM
To: grow@ietf.org
Subject: [GROW] Working Group Call for Adoption draft-lucente-grow-bmp-rel 
(start 25/Oct/2023 end 08/Nov/2023)

Dear GROW,

The authors of draft-lucente-grow-bmp-rel asked whether GROW working group 
could consider adoption of the internet-draft.

This message is a request to the group for feedback on whether this 
internet-draft should be adopted.

Title: Logging of routing events in BGP Monitoring Protocol (BMP)
Abstract:
  The BGP Monitoring Protocol (BMP) does provision for BGP session event
  logging (Peer Up, Peer Down), state synchronization (Route
  Monitoring), debugging (Route Mirroring) and Statistics messages,
  among the others. This document defines a new Route Event Logging
  (REL) message type for BMP with the aim of covering use-cases with
  affinity to alerting, reporting and on-change analysis.

The Internet-Draft can be found here:
https://datatracker.ietf.org/doc/draft-lucente-grow-bmp-rel/

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 November 8th, 2023.

Kind regards,

Job / Chris
GROW co-chairs

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

smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Call for Adoption draft-francois-grow-bmp-loc-peer (start 24/Oct/2023 end 07/Nov/2023)

[Thomas.Graf]

Dear GROW,

I reviewed the document and believe it is a very useful extension of BMP Local 
RIB for network operators. I support the adoption.

Best wishes
Thomas

-Original Message-
From: GROW  On Behalf Of Job Snijders
Sent: Tuesday, October 24, 2023 1:34 PM
To: grow@ietf.org
Subject: [GROW] Working Group Call for Adoption 
draft-francois-grow-bmp-loc-peer (start 24/Oct/2023 end 07/Nov/2023)

Dear GROW,

The authors of draft-francois-grow-bmp-loc-peer asked whether GROW working 
group could consider adoption of the internet-draft.

This message is a request to the group for feedback on whether this 
internet-draft should be adopted.

Title: BMP Loc-RIB: Peer address
Abstract:
   BMP Loc-RIB lets a BMP publisher set the Peer Address value of a path
   information to zero.  This document introduces the option to
   communicate the actual peer from which a path was received when
   advertising that path with BMP Loc-RIB.

The Internet-Draft can be found here:
https://datatracker.ietf.org/doc/draft-francois-grow-bmp-loc-peer/

Please share with the mailing list if you are think this work should be adopted 
by GROW, willing to review and/or otherwise contribute to this draft!

WG Adoption call ends November 7th, 2023.

Kind regards,

Job / Chris
GROW co-chairs

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

smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Call for Adoption draft-cppy-grow-bmp-path-marking-tlv (start 30/Mar/2023 end 21/Apr/2023)

[Thomas.Graf]

Dear GROW,

I support adoption. I think it is a very valuable extension of BMP. Enabling 
network operators to verify how the paths are being installed in RIB and 
consequently being able to verify redundancy.

Best wishes
Thomas

> On 30 Mar 2023, at 13:35, Job Snijders  
> wrote:
> 
> Dear GROW,
> 
> The authors of draft-cppy-grow-bmp-path-marking-tlv asked whether GROW
> working group could consider adoption of the internet-draft.
> 
> This message is a request to the group for feedback on whether this
> internet-draft should be adopted.
> 
> Title: BMP Extension for Path Status TLV
> Abstract: 
>  The BGP Monitoring Protocol (BMP) provides an interface for obtaining
>  BGP Path information. BGP Path Information is conveyed within BMP Route
>  Monitoring (RM) messages. This document proposes an extension to BMP to
>  convey the status of a path after being processed by the BGP process.
>  This extension makes use of the TLV mechanims described in
>  draft-ietf-grow-bmp-tlv and draft-ietf-grow-bmp-tlv-ebit.
> 
> The Internet-Draft can be found here:
> https://www.ietf.org/archive/id/draft-cppy-grow-bmp-path-marking-tlv-12.html
> 
> Please share with the mailing list if you are think this work should be
> adopted by GROW, willing to review and/or otherwise contribute to this
> draft!
> 
> WG Adoption call ends April 21th, 2023.
> 
> Kind regards,
> 
> Job / Chris
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow


smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Adoption Call: draft-cptb-grow-bmp-yang (Ends 15/Sep/2022)

[Thomas.Graf]

Hi GROW,

As one of the co-authors I support the adoption of the draft.

Best wishes
Thomas

-Original Message-
From: GROW  On Behalf Of Job Snijders
Sent: Thursday, August 25, 2022 4:20 PM
To: grow@ietf.org
Subject: [GROW] Working Group Adoption Call: draft-cptb-grow-bmp-yang (Ends 
15/Sep/2022)

Hi GROW,

At the IETF 114 GROW session Paolo asked whether this working group could 
consider adoption for draft-cptb-grow-bmp-yang.

This message is a request to the group for feedback on whether this 
internet-draft should be adopted.

Title: BMP YANG Module
Abstract: 
   This document proposes a YANG module for BMP (BGP Monitoring
   Protocol) configuration and monitoring. A complementary RPC triggers
   a refresh of the session of a BMP station.

The Internet-Draft can be found here: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cptb-grow-bmp-yang%2Fdata=05%7C01%7CThomas.Graf%40swisscom.com%7C0121b861cba14bea189c08da86a4fe06%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637970340441584489%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Mv1h%2B3R0WK4D4RpWZOqPhETi5EUZluTo2HE6FDmdYAw%3Dreserved=0

Please share with the mailing list if you are think this work should be adopted 
by GROW, willing to review and/or otherwise contribute to this draft!

WG Adoption call ends September 15th, 2022.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrowdata=05%7C01%7CThomas.Graf%40swisscom.com%7C0121b861cba14bea189c08da86a4fe06%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637970340441584489%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=H3cqVWMqxBrv8DB%2FvUNoTvh%2FGWGHk7SEa8DGpcJ9SyI%3Dreserved=0

smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Thomas.Graf]

Dear Robert,

I reviewed draft-raszuk-lsr-imp-00 and have some firsts comments and 
suggestions.

First of all, speaking as a network operator who is using BMP to gain 
visibility into the BGP control-plane, seeing the real benefits in operation 
every day, I was looking very forward at IETF seeing a similar debugging kind 
of approach being applied to IGP. You addressed that aspect very well. Thank 
you very much.

I would like to understand if data type 3-9 described in section 5 exporting 
the initial LSDB state when the transport session is being established and once 
fully exported, only the subsequential updates? Comparable to route-monitoring 
in BMP.

In section 5 you are describing data type 7, 8 and 9. Exporting LSDB as 
structured data in YANG. I like the idea in general but doubt that vendors will 
fancy implementations due to the additional I/O impact on the IGP process. 
However I think it is very valuable to have the LSDB modelled in YANG for data 
correlation purposes. I suggest that the YANG modelling can happen on the 
producer with data type 7, 8 and 9 or on the receiver side by converting data 
type 3-6 and 10-13 into JSON/XML with the YANG data model. I suspect that the 
YANG model itself for modelling the LSDB itself is not part of the document, 
therefore a reference to existing drafts such as draft-ietf-ospf-yang would 
help to better understand that context.


In section 5 you are describing in figure 2 the data message header. Here I 
suggest to add besides the "Router Identifier" also the "Process Identifier" to 
have the proper device context if more than one process is running.

Lessons learned from BMP is that knowing the control-plane state alone isn't 
enough for proper data correlation for IPFIX Flow Aggregation as described in 
RFC 7015. We need also to understand how (active, passive, ecmp, not considered 
etc.) the path is being installed into the RIB. At BMP we are addressing this 
with draft-cppy-grow-bmp-path-marking-tlv. I suggest to include this RIB aspect 
into IMP from day 1. If that makes sense to you as well, I gladly make a 
proposal.

Regarding the subscription aspect described in section 3. Here I would prefer a 
similar approach as draft-cptb-grow-bmp-yang, being done through a 
NETCONF/RESTCONF configured subscription. A YANG model gives the possibility 
not only to define but also to monitor the subscription which is fundamental 
for proper data collection. draft-arokiarajseda-ipfix-data-export-yang-model 
does the same for IPFIX. For YANG push this is defined in RFC 8641.

Regarding the terminology of "Producer" and "Receiver". I suggest to align the 
wording with existing Network Telemetry (RFC 9232) protocols. Unfortunately 
they aren't aligned among at all even though they are doing more or less all 
the same. Exporting monitoring data to a data collection. My personal favorite 
is Exporting and Collecting Process.

IPFIX:   Exporting Process, Collecting Process
BMP: Management Station, Monitoring Station
YANG push:   Publisher, Receiver
IMP:  Producer, Receiver

Best wishes
Thomas

From: GROW  On Behalf Of Robert Raszuk
Sent: Saturday, July 9, 2022 9:49 PM
To: Jeff Tantsura 
Cc: lsr ; grow@ietf.org grow@ietf.org ; idr@ietf. 
org 
Subject: Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

Thx Jeff !

Also I welcome more reviews and suggestions for additions or deletions of parts 
of it. For now I tried to keep it very simple for routers - essentially setup 
new p2p TCP or QUIC sessions and send over exactly what you put in BGP today. 
In the same time I see use cases beyond that so added few optional more DATA 
Types.

With basic DATA Types 1 or 2 there is zero changes needed on the receivers - 
some folks told me this is huge advantage.

Then two optional messages REQUEST and FILTER provide ability for trimming 
excessive data either on the Producer or Producer's Proxy.

Many thx,
Robert


On Sat, Jul 9, 2022 at 9:39 PM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Speaking as RTGWG chair:

Robert - I don’t think we’d have enough time to accommodate a good discussion 
during IETF114 (we got only 1 slot), however would be happy to provide a 
platform for an interim.
The topic is important and personally (being a very large BGP-LS user) I’d like 
to see it progressing.
Cheers,
Jeff


On Jul 8, 2022, at 14:44, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Hi Acee,

Yes, by all means input from the operator's community is needed. It can be 
collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We 
have already seen input from some operators and their opinion on adding and 
distributing more and more link state protocol and topology data in BGP. More 
such input is very welcome.

And to your point about RFC9086 - I see nothing wrong in keeping BGP 
information in BGP. So IGP Monitoring Protocol does not target to shut down 
BGP-LS. It only aims to remove 100% of non BGP 

[GROW] draft-lucente-grow-bmp-tlv-ebit-02 - review/comment

[Thomas.Graf]

Hi Paolo,

I reviewed

https://datatracker.ietf.org/doc/html/draft-lucente-grow-bmp-tlv-ebit-02

and have some minor nits and simplifications in wording to be considered.

Best wishes
Thomas


Change from


   Vendors need the ability to define proprietary Information Elements,

   because, for example, they are delivering a pre-standard product.


To



   Vendors need the ability to define proprietary Information Elements

   for various reasons such as delivering a pre-standard product.


Change from



   This This would align with Also for code point assignment to be

   eligible, an IETF document needs to be adopted at a Working Group and

   in a stable condition.


To



   This aligns also with code point assignments where a document

   needs to be at stable condition in IETF Working Group first.




Change from



   shipped to network operators to be tested there as well.


To



   shipped to network operators for testing.


Change from



   This would align with This document re-defines the format of IANA-

   registered TLVs in a backward compatible manner with respect to

   previous documents and existing IANA allocations;


To



   This document re-defines the format of IANA-

   registered TLVs in a backward compatible manner with respect to

   previous documents and existing IANA allocations;



Change from


   The encoding specified in this document applies to all existing BMP

   Message Types and their namespaces defined in Future BMP Message

   Types MUST make use of the TLV encoding defined in this document.



To



   The TLV encoding specified in this document applies to all existing

   and future BMP Message Types and their namespaces.

.



smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Adoption Call: draft-lucente-grow-bmp-tlv-ebit (Ends 02/May/2022)

[Thomas.Graf]

Dear GROW working group,

I read and support the draft-lucente-grow-bmp-tlv-ebit adoption.

The support of vendor-specific TLVs in the BMP application enables the 
development of new BMP extensions the same way as enterprise-specific 
Information Elements did in IPFIX. Therefore I agree with the authors that it 
is valuable contribution to the community and prevent that unused IANA code 
points are further misused for these purposes.

Best wishes
Thomas

-Original Message-
From: GROW  On Behalf Of Job Snijders
Sent: Friday, April 8, 2022 4:19 PM
To: grow@ietf.org
Subject: [GROW] Working Group Adoption Call: draft-lucente-grow-bmp-tlv-ebit 
(Ends 02/May/2022)

Hi GROW,

At the IETF 113 GROW session Paolo asked whether this working group could 
consider adoption for draft-lucente-grow-bmp-tlv-ebit.

This message is a request to the group for feedback on whether this 
internet-draft should be adopted.

Title:
   Support for Enterprise-specific TLVs in the BGP Monitoring Protocol
Abstract: 
   Message types defined by the BGP Monitoring Protocol (BMP) do
   provision for data in TLV - Type, Length, Value - format, either in
   the shape of optional TLVs at the end of a BMP message or Stats
   Reports TLVs.  However the space for Type value is unique and
   governed by IANA.  To allow the usage of vendor-specific TLVs, a
   mechanism to define per-vendor Type values is required.  In this
   document we introduce an Enterprise Bit, or E-bit, for such purpose.

The Internet-Draft can be found here: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-lucente-grow-bmp-tlv-ebitdata=04%7C01%7CThomas.Graf%40swisscom.com%7C02a7ebc6d92d424867a208da196ad88b%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637850243938463878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=nLkBTl1Ps1N8GAx6dnsDRPKGXpzJZpxkm0nUYlHDMHc%3Dreserved=0

Please share with the mailing list if you are think this work should be adopted 
by GROW, willing to review and/or otherwise contribute to this draft!

WG Adoption call ends May 2nd, 2022.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrowdata=04%7C01%7CThomas.Graf%40swisscom.com%7C02a7ebc6d92d424867a208da196ad88b%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637850243938463878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=odjJD%2FWxPYMikqe32cgcuPe833%2FEYaBQKP45%2FuLeVO0%3Dreserved=0

smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

[Thomas.Graf]

Dear GROW WG, dear authors

I have reviewed the draft. I think it is straight forward and ready for IESG. 

It is the next logical step to make the different BMP message types to be equal 
by supporting TLV's for BMP route-monitoring and peer_down messages as well.

Best wishes
Thomas

-Original Message-
From: GROW  On Behalf Of Job Snijders
Sent: Tuesday, November 16, 2021 5:16 PM
To: Paolo Lucente 
Cc: grow@ietf.org grow@ietf.org 
Subject: Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

Dear all,

This starts the formal WGLC period which will run from November 16th until 
December 1st 2021.

Please review 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-bmp-tlv-06data=04%7C01%7CThomas.Graf%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762697241609%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=JROJtoThUbY9PaWO19f6UGiudA9dli83mNdkjlhrhaE%3Dreserved=0
and provide comments or feedback on the grow@ietf.org mailing list!

Kind regards,

Job

On Tue, Nov 16, 2021 at 05:11:56PM +0100, Paolo Lucente wrote:
> Dear Colleagues, Dear Chairs,
> 
> A brief email to follow-up the presentation of draft-ietf-grow-bmp-tlv 
> last week at the WG meeting. We authors believe there are no more 
> items to work on for this draft, received inputs were processed and 
> any questions / concerns were addressed. I'd hence like to ask to LC this 
> work.
> 
> You may read motivation for this work in the draft itself, let me 
> supplement it saying that this is a key piece of work that would make 
> extensible every BMP message defined so far; this, in turn, would 
> bring BMP on par with other modern monitoring (/ telemetry) protocols (/ 
> stacks / solutions).
> 
> Paolo
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fgrowdata=04%7C01%7CThomas.Graf%40
> swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9bee
> c35d19b557a1%7C0%7C0%7C637726762697241609%7CUnknown%7CTWFpbGZsb3d8eyJW
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&
> amp;sdata=HFqIEZe4rv2aBdlxEzo9%2BRBriEkOaBbhPi70WCeIZ2U%3Dreserve
> d=0

___
GROW mailing list
GROW@ietf.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrowdata=04%7C01%7CThomas.Graf%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762697251563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=uemMUSyGVXFUQb1%2BKPZRyvrw%2BJp9fpjLJXjxpQyNPd4%3Dreserved=0

smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] is TCP the right layer for BMP session resumption?

[Thomas.Graf]

Hi Tim,

Many thanks for the feedback and input. Much appreciated. My apology for late 
reply.

In section 5 of draft-tppy-bmp-seamless-session
https://tools.ietf.org/html/draft-tppy-bmp-seamless-session-00#section-5

The BMP session lifecycle (not to be confused with TCP session lifecycle) is 
extended with this draft. The BMP session no longer closes with the TCP 
session. Once the TCP TFO session closes, a BMP session timeout counter starts 
counting down. If the TCP TFO session is re-established within this time frame, 
than the BMP session is considered to be "up" during the TCP TFO 
reestablishment time.

The TCP back pressure from BMP monitoring station to the router occurs under 
congestion. Therefore buffering at the monitored router for the BMP session 
occurs during normal BMP session lifetime. With 
draft-tppy-bmp-seamless-session, we make use of this buffer mechanism. 
Different is that it is being used not only in congestion, but also between 
re-establishment of the TCP TFO session (not to be confused with the BMP 
session).

As you pointed out, it is important that BMP message type peer_up and peer_down 
are not being lost during the re-establishment of the TCP TFO session. For that 
very purpose we described in section 5 that buffering must occur for all BMP 
message types which is including BMP peer_up, peer_down, statistics, 
route-mirroring and route-monitoring. I take that as an input to more clearly 
state that in the draft. Jakob made an interesting input that for BMP buffer 
optimization purposes only withdrawals of route-monitoring messages should be 
buffered.

I agree that BMP lacks of a mechanism that the monitoring station can request a 
BMP route-monitoring refresh to the monitored router. I agree as well that if 
that mechanism would be present, than the BMP session lifecycle should be 
re-adjusted to disable/enable initial BMP RIB dump with route-monitoring or 
not. Where I am unsure is wherever it makes sense to implement BMP 
route-refresh within the BMP session protocol or not. Therefore changing BMP to 
be a bi-directional protocol. 

Here I like to get the feedback from the GROW mailing list. If you do see value 
in BMP route-refresh as well, how granular it should be, and wherever it should 
be part of the BMP session or not. 

Best wishes
Thomas

-Original Message-
From: Tim Evens (tievens)  
Sent: Friday, March 12, 2021 10:36 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 ; Jakob Heitz 
(jheitz) ; rainsword.w...@huawei.com; rob...@raszuk.net; 
j...@dataplane.org
Cc: grow@ietf.org
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

The use of UDP vs TCP is use-case specific.  For example, are you logging and 
don't care if you miss messages or are you maintaining RIB states for 
applications like SDN?   

In terms of accurate logging (ordered regardless of timestamp) and maintaining 
state… TCP is required otherwise we introduce out-of-order and loss recovery 
complexities.  BGP PDU order is required in order to track changes and to 
maintain accurate RIB states.   While a SEQ number in BMP can help to 
re-sequence messages, that puts a lot on every BMP receiver/client. For 
example, BMP receivers will now have to buffer messages and re-sequence them to 
ensure proper ordering when processing.   If buffers are exceeded, what happens 
to those messages and how would the BMP receiver request those missing 
messages/pdus?  Regardless of how, this adds complexity to both the sender and 
receiver.  IMO, this is not addressing the problem of RIB dumps or picking up 
where you left off on reconnect.  

The draft suggests to use TCP_FAST_OPEN, which I believe adds more complexity 
while not solving the other challenges relating to RIB dumps/refreshes.   It 
doesn't address PEER UP handling on reconnect, how to handle peers that change 
or are new during the no-connection time,  and on how to request a peer refresh 
when needed.   It also doesn't address the buffer exhaustion problem on the 
sender (router) side.  IMO, the sender should be configured using buffer sizes 
per receiver and not based on time.   The amount of time is relative to the 
number of updates.  For example, a refresh to update policies will 
flood/exhaust buffers quickly in seconds while normal updates may last for 
minutes without buffer exhaustion.   

There are at least three problems with RIB dumps/reconnects to be solved:

1) Transient reconnects due to network failures, restarts of receivers, etc. 
are resulting in unnecessary INITs, RIB dumps, and PEER UPs.  A PEER UP 
normally means that the receiver invalidates all previous RIB entries as it 
does not know if things were changed/removed during the gap (from last PEER 
UP/DOWN) period.  A RIB dump is expected to refresh the peer RIB upon a PEER 
UP.  IMO, what we need is application level control so the BMP receiver can 
send a control message to the sender to indicate what's needed per-peer.  For 
example, a receiver restart (new 

Re: [GROW] is TCP the right layer for BMP session resumption?

[Thomas.Graf]

Hi Jakob,


  *   When processes abort unexpectedly, loss must be assumed unless data 
integrity can be specifically proven.

Absolutely. We need to distinguish between application and transport. At 
transport we do have sequence numbers and integrity on transport is ensured. On 
BMP application it is not. Here we need to distinguish between BMP application 
and BMP session. In a previous message to you I wrote:


  *   What I wondered if you could describe a bit more what benefit we would 
gain with BMP sequence numbers. At which point within the BMP client 
application loss technically could occur.

At BMP IETF hackathon where we BMP/BGP metric loss. As a tester I believe that 
first we need to describe the problem space carefully. Than analyze where, at 
which point, the sequence numbers should be applied. And then validate it with 
running code.
Best wishes
Thomas

From: Jakob Heitz (jheitz) 
Sent: Thursday, March 11, 2021 11:29 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 ; 
rainsword.w...@huawei.com; rob...@raszuk.net; j...@dataplane.org
Cc: grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

With draft-tppy-bmp-seamless-session, if TCP session is re-established within 
the timeout value and buffer is not full, no message lost occurs
This is a leap of faith. How can you be sure that the receiver has not lost any 
messages, even if the TCP session ends in FIN?
When processes abort unexpectedly, loss must be assumed unless data integrity 
can be specifically proven.

Regards,
Jakob.

From: GROW mailto:grow-boun...@ietf.org>> On Behalf Of 
thomas.g...@swisscom.com
Sent: Thursday, March 11, 2021 4:59 AM
To: rainsword.w...@huawei.com; 
rob...@raszuk.net; 
j...@dataplane.org
Cc: grow@ietf.org
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

Hi Haibo,


  *   Now we want to keep the BMP session active even the TCP session is 
closed, I think it means the BMP session state separate from the TCP session.
For the BMP session closing it is delayed. Yes.


  *   And in this scenario, we don't know whether the last message is sent to 
the server OK or not.
No. Without draft-tppy-bmp-seamless-session all BMP messages after TCP 
transport session closes are lost. With draft-tppy-bmp-seamless-session, if TCP 
session is re-established within the timeout value and buffer is not full, no 
message lost occurs. If TCP session is re-established outside the timeout value 
or buffer is full, than BMP session is considered new and initial BMP 
route-monitoring initial RIB dump starts. Under any circumstances, BMP message 
lost should occur while BMP session is considered to be up. Even during 
re-establishment window.

Does that make sense now?

Best wishes
Thomas

From: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Sent: Thursday, March 11, 2021 3:00 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 
mailto:thomas.g...@swisscom.com>>; 
rob...@raszuk.net; 
j...@dataplane.org
Cc: grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

Hi Tomas,

 According to the RFC7854, the BMP session is closely bound to the TCP 
session. So the BMP session will  end when TCP is closed.
 Now we want to keep the BMP session active even the TCP session is 
closed, I think it means the BMP session state separate from the TCP session.
 And in this scenario, we don't know whether the last message is sent 
to the server OK or not.
If we don't accept this, we should use a mechanisms like sequence no. to ensure 
that. But it will cause the BMP more complex.

Regards,
Haibo

From: thomas.g...@swisscom.com 
[mailto:thomas.g...@swisscom.com]
Sent: Wednesday, March 10, 2021 11:11 PM
To: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>; 
rob...@raszuk.net; 
j...@dataplane.org
Cc: grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

Hi Haibo,

Quite the contrary. draft-tppy-bmp-seamless-session is not about the separation 
of the transport session from the BMP session. It is about to delay the 
termination of the BMP session when transport session is closed and introducing 
a mechanism to re-establish the BMP session.

The authors chose a careful way not to re-invent the wheel. Use existing 
protocols, change as less as possible on the BMP application and preserve the 
original goal of BMP to be unidirectional. We believe by keeping the session 
handling on TCP transport, this goal can be best achieved. We are looking 
forward from the working group to receive feedback if they feel the same way or 
if the goal should be addressed rather on the application layer.

Best wishes
Thomas

From: 

Re: [GROW] is TCP the right layer for BMP session resumption?

[Thomas.Graf]

Hi Haibo,


  *   Now we want to keep the BMP session active even the TCP session is 
closed, I think it means the BMP session state separate from the TCP session.
For the BMP session closing it is delayed. Yes.


  *   And in this scenario, we don't know whether the last message is sent to 
the server OK or not.
No. Without draft-tppy-bmp-seamless-session all BMP messages after TCP 
transport session closes are lost. With draft-tppy-bmp-seamless-session, if TCP 
session is re-established within the timeout value and buffer is not full, no 
message lost occurs. If TCP session is re-established outside the timeout value 
or buffer is full, than BMP session is considered new and initial BMP 
route-monitoring initial RIB dump starts. Under any circumstances, BMP message 
lost should occur while BMP session is considered to be up. Even during 
re-establishment window.

Does that make sense now?

Best wishes
Thomas

From: Wanghaibo (Rainsword) 
Sent: Thursday, March 11, 2021 3:00 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 ; rob...@raszuk.net; 
j...@dataplane.org
Cc: grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

Hi Tomas,

 According to the RFC7854, the BMP session is closely bound to the TCP 
session. So the BMP session will  end when TCP is closed.
 Now we want to keep the BMP session active even the TCP session is 
closed, I think it means the BMP session state separate from the TCP session.
 And in this scenario, we don't know whether the last message is sent 
to the server OK or not.
If we don't accept this, we should use a mechanisms like sequence no. to ensure 
that. But it will cause the BMP more complex.

Regards,
Haibo

From: thomas.g...@swisscom.com 
[mailto:thomas.g...@swisscom.com]
Sent: Wednesday, March 10, 2021 11:11 PM
To: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>; 
rob...@raszuk.net; 
j...@dataplane.org
Cc: grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

Hi Haibo,

Quite the contrary. draft-tppy-bmp-seamless-session is not about the separation 
of the transport session from the BMP session. It is about to delay the 
termination of the BMP session when transport session is closed and introducing 
a mechanism to re-establish the BMP session.

The authors chose a careful way not to re-invent the wheel. Use existing 
protocols, change as less as possible on the BMP application and preserve the 
original goal of BMP to be unidirectional. We believe by keeping the session 
handling on TCP transport, this goal can be best achieved. We are looking 
forward from the working group to receive feedback if they feel the same way or 
if the goal should be addressed rather on the application layer.

Best wishes
Thomas

From: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Sent: Wednesday, March 10, 2021 12:48 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 
mailto:thomas.g...@swisscom.com>>; 
rob...@raszuk.net; 
j...@dataplane.org
Cc: grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

Hi Tomas,

 I think the main problem is how to separate the BMP session with the 
transport session. Even we choose a stateless transport, we also need to use 
some mechanism to ensure the message is succeed send to the sever, e.g., use 
sequence number in BMP RM message.

Regards,
Haibo

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of 
thomas.g...@swisscom.com
Sent: Wednesday, March 10, 2021 2:21 PM
To: rob...@raszuk.net; 
j...@dataplane.org
Cc: grow@ietf.org
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

Hi John and Robert,

Speaking as a network operator. I absolutely agree on your thoughts that a 
stateless transport would be preferred over a stateful.

Best wishes
Thomas

From: GROW mailto:grow-boun...@ietf.org>> On Behalf Of 
Robert Raszuk
Sent: Tuesday, March 9, 2021 10:38 PM
To: John Kristoff mailto:j...@dataplane.org>>
Cc: grow@ietf.org grow@ietf.org 
mailto:grow@ietf.org>>
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

I second John's comment with a bit more optimism.

As gRPC over QUIC is becoming a reality and de-facto messaging standard there 
is going to be hardly any choice for any router's vendor to resist to implement 
it.

Best,
R.


On Tue, Mar 9, 2021 at 9:57 PM John Kristoff 
mailto:j...@dataplane.org>> wrote:
On Tue, 9 Mar 2021 20:44:18 +
"Jakob Heitz \(jheitz\)" 
mailto:40cisco@dmarc.ietf.org>> wrote:

> I've seen this session resumption technique in the '90s.
> BMP is a one-way protocol. The BMP server sends nothing.

I kind of wish my BMP router monitor was able 

Re: [GROW] is TCP the right layer for BMP session resumption?

[Thomas.Graf]

Hi Jakob,

All ack. Perfect. Thanks

Regards,
Thomas

-Original Message-
From: Jakob Heitz (jheitz)  
Sent: Thursday, March 11, 2021 3:17 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 ; 
job=40fastly@dmarc.ietf.org
Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

For the router, it's not about the time, its about the buffer space.
Configure the buffer space allowed to buffer incoming updates during the down 
time. If the buffer runs out, new sesssion.

Regards,
Jakob.

-Original Message-
From: thomas.g...@swisscom.com 
Sent: Wednesday, March 10, 2021 6:56 AM
To: Jakob Heitz (jheitz) ; job=40fastly@dmarc.ietf.org
Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

Hi Jakob and Job,

Ack on all. I would define 60 seconds to be default and configurable.

Best wishes
Thomas

-Original Message-
From: Jakob Heitz (jheitz) 
Sent: Wednesday, March 10, 2021 1:12 PM
To: Job Snijders 
Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

I would say 60 seconds or until the client runs out of configured buffer space 
to save messages that need to be sent to the session once the new session comes 
up.

Regards,
Jakob.

-Original Message-
From: Job Snijders 
Sent: Wednesday, March 10, 2021 1:04 AM
To: Jakob Heitz (jheitz) 
Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

On Wed, Mar 10, 2021 at 03:08:34AM +, Jakob Heitz (jheitz) wrote:
> >From the BGP speaker (client) implementation point of view,
>
> I would do it like this:
> The client keeps a ring buffer of data it sent to the server.
> The bottom of the buffer is at a certain sequence number.
> As messages are created, that bottom moves up.
> If the server were to restart, it would send its last received 
> sequence number and session ID. If the buffer still contains the 
> sequence number, then you're in luck, else big bang restart.
> The content of the buffer could be optimized by retrieving some of the 
> information from the bgp table (adj-rib's are conceptual only) instead 
> of literally storing it. How and if any optimization is done is 
> implementation specific and not part of an RFC.

In the 'Sent: Tuesday, March 9, 2021 4:50 PM' email sequence/serial numbers are 
not required, only a 'session id' (which might remain the same over the 
lifetime of the BMP client's lifetime).

A full 'big bang' restart is achieved by the server disconnecting and allowing 
reconnection twice, within the 60 second window. When combined with 
TCP_FAST_OPEN resuming a session requires 2 packets (one each way) and 
restarting a session requires 4 packets.

This way BMP remains a 'read only' protocol, but I admit this is an 
unconventional approach.

Kind regards,

Job

smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] is TCP the right layer for BMP session resumption?

[Thomas.Graf]

Hi Haibo,

Quite the contrary. draft-tppy-bmp-seamless-session is not about the separation 
of the transport session from the BMP session. It is about to delay the 
termination of the BMP session when transport session is closed and introducing 
a mechanism to re-establish the BMP session.

The authors chose a careful way not to re-invent the wheel. Use existing 
protocols, change as less as possible on the BMP application and preserve the 
original goal of BMP to be unidirectional. We believe by keeping the session 
handling on TCP transport, this goal can be best achieved. We are looking 
forward from the working group to receive feedback if they feel the same way or 
if the goal should be addressed rather on the application layer.

Best wishes
Thomas

From: Wanghaibo (Rainsword) 
Sent: Wednesday, March 10, 2021 12:48 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 ; rob...@raszuk.net; 
j...@dataplane.org
Cc: grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

Hi Tomas,

 I think the main problem is how to separate the BMP session with the 
transport session. Even we choose a stateless transport, we also need to use 
some mechanism to ensure the message is succeed send to the sever, e.g., use 
sequence number in BMP RM message.

Regards,
Haibo

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of 
thomas.g...@swisscom.com
Sent: Wednesday, March 10, 2021 2:21 PM
To: rob...@raszuk.net; 
j...@dataplane.org
Cc: grow@ietf.org
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

Hi John and Robert,

Speaking as a network operator. I absolutely agree on your thoughts that a 
stateless transport would be preferred over a stateful.

Best wishes
Thomas

From: GROW mailto:grow-boun...@ietf.org>> On Behalf Of 
Robert Raszuk
Sent: Tuesday, March 9, 2021 10:38 PM
To: John Kristoff mailto:j...@dataplane.org>>
Cc: grow@ietf.org grow@ietf.org 
mailto:grow@ietf.org>>
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

I second John's comment with a bit more optimism.

As gRPC over QUIC is becoming a reality and de-facto messaging standard there 
is going to be hardly any choice for any router's vendor to resist to implement 
it.

Best,
R.


On Tue, Mar 9, 2021 at 9:57 PM John Kristoff 
mailto:j...@dataplane.org>> wrote:
On Tue, 9 Mar 2021 20:44:18 +
"Jakob Heitz \(jheitz\)" 
mailto:40cisco@dmarc.ietf.org>> wrote:

> I've seen this session resumption technique in the '90s.
> BMP is a one-way protocol. The BMP server sends nothing.

I kind of wish my BMP router monitor was able to transport data over UDP
to the listening station like syslog and flow data.  I would have
especially liked this after that time a blocked TCP port and the
inability to opena TCP connection once caused my BMP monitor router
doing the active open to crash (known and now fixed bug).

> Thus adding this is a significant rework of BMP.

I assume my desire for UDP above will never happen as a result.  Oh
well.

John

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


smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] is TCP the right layer for BMP session resumption?

[Thomas.Graf]

Hi Jakob and Job,

Ack on all. I would define 60 seconds to be default and configurable.

Best wishes
Thomas

-Original Message-
From: Jakob Heitz (jheitz)  
Sent: Wednesday, March 10, 2021 1:12 PM
To: Job Snijders 
Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

I would say 60 seconds or until the client runs out of configured buffer space 
to save messages that need to be sent to the session once the new session comes 
up.

Regards,
Jakob.

-Original Message-
From: Job Snijders 
Sent: Wednesday, March 10, 2021 1:04 AM
To: Jakob Heitz (jheitz) 
Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

On Wed, Mar 10, 2021 at 03:08:34AM +, Jakob Heitz (jheitz) wrote:
> >From the BGP speaker (client) implementation point of view,
>
> I would do it like this:
> The client keeps a ring buffer of data it sent to the server.
> The bottom of the buffer is at a certain sequence number.
> As messages are created, that bottom moves up.
> If the server were to restart, it would send its last received 
> sequence number and session ID. If the buffer still contains the 
> sequence number, then you're in luck, else big bang restart.
> The content of the buffer could be optimized by retrieving some of the 
> information from the bgp table (adj-rib's are conceptual only) instead 
> of literally storing it. How and if any optimization is done is 
> implementation specific and not part of an RFC.

In the 'Sent: Tuesday, March 9, 2021 4:50 PM' email sequence/serial numbers are 
not required, only a 'session id' (which might remain the same over the 
lifetime of the BMP client's lifetime).

A full 'big bang' restart is achieved by the server disconnecting and allowing 
reconnection twice, within the 60 second window. When combined with 
TCP_FAST_OPEN resuming a session requires 2 packets (one each way) and 
restarting a session requires 4 packets.

This way BMP remains a 'read only' protocol, but I admit this is an 
unconventional approach.

Kind regards,

Job

smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] is TCP the right layer for BMP session resumption?

[Thomas.Graf]

Hi Jakob,

Thats clear. Apology. I was not precise enough. I would prefer the reliability 
to be solved on application layer than on transport layer since in a large 
scale BMP data collection, multiple daemons collect the BMP messages and 
failover among can occur.

Best wishes
Thomas

From: Jakob Heitz (jheitz) 
Sent: Wednesday, March 10, 2021 7:47 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 ; rob...@raszuk.net; 
j...@dataplane.org
Cc: grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

QUIC is not stateless.
BMP over QUIC is not BMP over UDP.
BMP requires reliable transfer.
The state to provide reliability must exist somewhere.
If not in TCP (or QUIC), then in the app.

Regards,
Jakob.

From: GROW mailto:grow-boun...@ietf.org>> On Behalf Of 
thomas.g...@swisscom.com
Sent: Tuesday, March 9, 2021 10:21 PM
To: rob...@raszuk.net; 
j...@dataplane.org
Cc: grow@ietf.org
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

Hi John and Robert,

Speaking as a network operator. I absolutely agree on your thoughts that a 
stateless transport would be preferred over a stateful.

Best wishes
Thomas

From: GROW mailto:grow-boun...@ietf.org>> On Behalf Of 
Robert Raszuk
Sent: Tuesday, March 9, 2021 10:38 PM
To: John Kristoff mailto:j...@dataplane.org>>
Cc: grow@ietf.org grow@ietf.org 
mailto:grow@ietf.org>>
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

I second John's comment with a bit more optimism.

As gRPC over QUIC is becoming a reality and de-facto messaging standard there 
is going to be hardly any choice for any router's vendor to resist to implement 
it.

Best,
R.


On Tue, Mar 9, 2021 at 9:57 PM John Kristoff 
mailto:j...@dataplane.org>> wrote:
On Tue, 9 Mar 2021 20:44:18 +
"Jakob Heitz \(jheitz\)" 
mailto:40cisco@dmarc.ietf.org>> wrote:

> I've seen this session resumption technique in the '90s.
> BMP is a one-way protocol. The BMP server sends nothing.

I kind of wish my BMP router monitor was able to transport data over UDP
to the listening station like syslog and flow data.  I would have
especially liked this after that time a blocked TCP port and the
inability to opena TCP connection once caused my BMP monitor router
doing the active open to crash (known and now fixed bug).

> Thus adding this is a significant rework of BMP.

I assume my desire for UDP above will never happen as a result.  Oh
well.

John

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


smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] is TCP the right layer for BMP session resumption?

[Thomas.Graf]

Hi Jakob,

Ack on all. The difference between sequence numbers in TCP transport and BMP 
application is clear. What I wondered if you could describe a bit more what 
benefit we would gain with BMP sequence numbers. At which point within the BMP 
client application loss technically could occur.

Best wishes
Thomas

-Original Message-
From: Jakob Heitz (jheitz)  
Sent: Wednesday, March 10, 2021 7:38 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 ; 
job=40fastly@dmarc.ietf.org
Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

TCP sequence numbers are for TCP only.
It would be nice if TCP were to acknowledge received data only after all 
application layers have fully processed it.
However, TCP sequence numbers are only for TCP.
The application cannot acknowledge full processing of received data back to TCP 
through the socket layer.
If the application layer wants to signal full processing of received data back 
to the sender, then it needs its own sequence numbers.

It's these sequence numbers that I want to be in 64 bits, not the session ID.

Storing the withdraw messages is an optimization that would work for monitor 
mode. In general, the sender has to store all data that has not been 
acknowledged at the application layer (not the TCP layer) if it is going to be 
retransmitted in any subsequent TCP session. In monitor mode, the sender can 
retrieve the non-withdraw messages from the information stored in the BGP table.

Regards,
Jakob.

-Original Message-
From: thomas.g...@swisscom.com 
Sent: Tuesday, March 9, 2021 10:19 PM
To: Jakob Heitz (jheitz) ; job=40fastly@dmarc.ietf.org
Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

Hi Job and Jakob,

Many thanks for the good inputs which I consolidated in this reply.

In regards to TFO applicability to the BMP application.

During my initial research I was encouraged my section 6 of TFO RFC 7413 

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7413%23section-6data=04%7C01%7CThomas.Graf%40swisscom.com%7Cdba64e44152c438cbab708d8e38f7972%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637509552641063005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fPQYYJPEYnfYwyC7bT4LZCfkUZUdlz1ZuLN9F3oT7Kg%3Dreserved=0

It is well understood that the original intend of the RFC is two fold:

- allow to re-establish a TCP session
- performance gain for short-lived connections

While the first is the motivation why TFO was chosen in this draft, the second 
is a welcomed by product where BMP could benefit from.

Regarding the TCP_FAST_OPEN cookie handling and the separation between 
application (BMP) and transport (TCP). The goal of the draft is that both 
sides, the BMP client and the BMP server can decide wherever the new transport 
session belongs to the previous BMP session or not. This is done on the BMP 
client side by either clearing the TCP_FAST_OPEN cookie for transport or not. 
The BMP client does not need to know the previous value. It needs only to 
distinguish between establish a new session or re-establish an existing 
session. Different to the BMP client, the BMP server does the same but instead 
of clearing the TCP_FAST_OPEN cookie for transport it sets a new, different to 
the previous, cookie.  

I like to take your input Job about the TFO applicability to the BMP 
application and do my due diligence by going to the TCPM working group and get 
their opinion. I will also do my own research on applications using TFO and for 
which purpose. I will present then that to the GROW list and the next GROW 
session. Does that make sense?

As you already pointed out the goal can be achieved not only on the TCP 
transport layer but also on the BMP application layer. There with the drawback 
that BMP is strictly speaking no longer unidirectional.

Here my proposal would be to extend the BMP Initiation Message with another TLV 
containing the BMP session identifier. I agree that the size should large 
enough to be unique and I take the input being 64 bit as a proposal. The client 
set's the BMP session identifier and the server stores it. When a BMP session 
is established, a new BMP session identifier is set be the client and stored at 
the BMP server. When the BMP client establishes the BMP session, the server 
decides wherever to reply with the previously stored value (signaling its 
state) or 0 (a new session). BMP client acts wherever on exporting its queue or 
start a new RIB dump depending if BMP session identifier is different to the 
previous or not.

Regarding the input from Jakob that not all the BMP message types should be 
queued, only BGP withdrawals. This is an interesting proposal I like to follow 
up and further like to understand it. If I understand correctly, only 
withdrawals would be 

Re: [GROW] is TCP the right layer for BMP session resumption?

[Thomas.Graf]

Hi John and Robert,

Speaking as a network operator. I absolutely agree on your thoughts that a 
stateless transport would be preferred over a stateful.

Best wishes
Thomas

From: GROW  On Behalf Of Robert Raszuk
Sent: Tuesday, March 9, 2021 10:38 PM
To: John Kristoff 
Cc: grow@ietf.org grow@ietf.org 
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

I second John's comment with a bit more optimism.

As gRPC over QUIC is becoming a reality and de-facto messaging standard there 
is going to be hardly any choice for any router's vendor to resist to implement 
it.

Best,
R.


On Tue, Mar 9, 2021 at 9:57 PM John Kristoff 
mailto:j...@dataplane.org>> wrote:
On Tue, 9 Mar 2021 20:44:18 +
"Jakob Heitz \(jheitz\)" 
mailto:40cisco@dmarc.ietf.org>> wrote:

> I've seen this session resumption technique in the '90s.
> BMP is a one-way protocol. The BMP server sends nothing.

I kind of wish my BMP router monitor was able to transport data over UDP
to the listening station like syslog and flow data.  I would have
especially liked this after that time a blocked TCP port and the
inability to opena TCP connection once caused my BMP monitor router
doing the active open to crash (known and now fixed bug).

> Thus adding this is a significant rework of BMP.

I assume my desire for UDP above will never happen as a result.  Oh
well.

John

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


smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] is TCP the right layer for BMP session resumption?

[Thomas.Graf]

Hi Job and Jakob,

Many thanks for the good inputs which I consolidated in this reply.

In regards to TFO applicability to the BMP application.

During my initial research I was encouraged my section 6 of TFO RFC 7413 

https://tools.ietf.org/html/rfc7413#section-6

It is well understood that the original intend of the RFC is two fold:

- allow to re-establish a TCP session
- performance gain for short-lived connections

While the first is the motivation why TFO was chosen in this draft, the second 
is a welcomed by product where BMP could benefit from.

Regarding the TCP_FAST_OPEN cookie handling and the separation between 
application (BMP) and transport (TCP). The goal of the draft is that both 
sides, the BMP client and the BMP server can decide wherever the new transport 
session belongs to the previous BMP session or not. This is done on the BMP 
client side by either clearing the TCP_FAST_OPEN cookie for transport or not. 
The BMP client does not need to know the previous value. It needs only to 
distinguish between establish a new session or re-establish an existing 
session. Different to the BMP client, the BMP server does the same but instead 
of clearing the TCP_FAST_OPEN cookie for transport it sets a new, different to 
the previous, cookie.  

I like to take your input Job about the TFO applicability to the BMP 
application and do my due diligence by going to the TCPM working group and get 
their opinion. I will also do my own research on applications using TFO and for 
which purpose. I will present then that to the GROW list and the next GROW 
session. Does that make sense?

As you already pointed out the goal can be achieved not only on the TCP 
transport layer but also on the BMP application layer. There with the drawback 
that BMP is strictly speaking no longer unidirectional.

Here my proposal would be to extend the BMP Initiation Message with another TLV 
containing the BMP session identifier. I agree that the size should large 
enough to be unique and I take the input being 64 bit as a proposal. The client 
set's the BMP session identifier and the server stores it. When a BMP session 
is established, a new BMP session identifier is set be the client and stored at 
the BMP server. When the BMP client establishes the BMP session, the server 
decides wherever to reply with the previously stored value (signaling its 
state) or 0 (a new session). BMP client acts wherever on exporting its queue or 
start a new RIB dump depending if BMP session identifier is different to the 
previous or not.

Regarding the input from Jakob that not all the BMP message types should be 
queued, only BGP withdrawals. This is an interesting proposal I like to follow 
up and further like to understand it. If I understand correctly, only 
withdrawals would be queued during the re-establish time window and updates 
would be locally generated for the re-establish time window once the BMP 
session is re-established. Correct? 

Regarding the proposal of sequence numbers. It would imply that the BMP Common 
Header needs to be extended. Here I like to hear your thoughts why a session 
identifier is not enough and what benefit a sequence number would bring on the 
application layer when we already have sequence numbers on the TCP transport 
session. As you might recall, one of the objectives of the BMP hackathon was to 
detect loss of BMP messages.

Also many thanks to Jeff about the feedback in regards to BGP NSR. I agree that 
solving the goal on a TCP transport layer would prevent implications onto 
BGP/BMP application in such condition when BGP process is being restarted.

Best wishes
Thomas

-Original Message-
From: Jakob Heitz (jheitz)  
Sent: Wednesday, March 10, 2021 4:09 AM
To: Job Snijders 
Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

>From the BGP speaker (client) implementation point of view,
I would do it like this:
The client keeps a ring buffer of data it sent to the server.
The bottom of the buffer is at a certain sequence number.
As messages are created, that bottom moves up.
If the server were to restart, it would send its last received sequence number 
and session ID. If the buffer still contains the sequence number, then you're 
in luck, else big bang restart.
The content of the buffer could be optimized by retrieving some of the 
information from the bgp table (adj-rib's are conceptual only) instead of 
literally storing it. How and if any optimization is done is implementation 
specific and not part of an RFC.

Regards,
Jakob.

-Original Message-
From: Job Snijders 
Sent: Tuesday, March 9, 2021 4:50 PM
To: Jakob Heitz (jheitz) 
Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

On Tue, Mar 09, 2021 at 08:44:18PM +, Jakob Heitz (jheitz) wrote:
> BMP is a one-way protocol. The BMP server sends nothing.

In the 

Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt

[Thomas.Graf]

Dear authors,

Speaking as a network operator, I think your draft has merit and I agree BGP 
as-path prepending is misused on the Internet and a best common practice draft 
is welcomed.

I like to comment on section 3.4
https://tools.ietf.org/html/draft-ietf-grow-as-path-prepending-03#section-3.4

You are referring to the impact of BGP as-path length onto IPFIX.

To my current knowledge, there are only 4 well known IPFIX entities registered 
at IANA related to BGP as-path

https://www.iana.org/assignments/ipfix/ipfix.xhtml

IE16 bgpSourceAsNumber
IE17 bgpDestinationAsNumber
IE128 bgpNextAdjacentAsNumber
IE129 bgpPrevAdjacentAsNumber

None of them contain the entire BGP as-path array. Only the first or last BGP 
ASN of the path array for source and destination IPv4/6 address of the flow.

The reason to my knowledge is that for UDP transport, which is one of the 
options to export IPFIX and the most supported, does not support segmentation. 
Thus limiting IPFIX of the amount data records and values within a record which 
can be exposed per message even to a lower value than RFC 7011 defines with 
65535 bytes as maximum message size.

https://tools.ietf.org/html/rfc7011#section-10
https://tools.ietf.org/html/rfc7011#section-10.3.3

The BGP as-path array could be potentially be exposed with code points from the 
private enterprise number space. If that would be the case than same 
operational considerations would apply than in RFC 8549 section 7 described 
since BGP communities are also array's.

https://tools.ietf.org/html/rfc8549#section-7

Therefore I either recommend to remove the IPFIX/Netflow relevant part from the 
draft or clearly state the scenario where with private enterprise number BGP 
as-path array is exposed and refer to example implementations as they are 
nonstandard.

Best wishes
Thomas

-Original Message-
From: GROW  On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, February 9, 2021 1:30 AM
To: i-d-annou...@ietf.org
Cc: grow@ietf.org
Subject: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Global Routing Operations WG of the IETF.

Title   : AS Path Prepending
Authors : Mike McBride
  Doug Madory
  Jeff Tantsura
  Robert Raszuk
  Hongwei Li
  Jakob Heitz
Filename: draft-ietf-grow-as-path-prepending-03.txt
Pages   : 10
Date: 2021-02-08

Abstract:
   AS Path Prepending provides a tool to manipulate the BGP AS_Path
   attribute through prepending multiple entries of an AS.  AS Path
   Prepending is used to deprioritize a route or alternate path.  By
   prepending the local ASN multiple times, ASs can make advertised AS
   paths appear artificially longer.  Excessive AS Path Prepending has
   caused routing issues in the internet.  This document provides
   guidance,to the internet community, with how best to utilize AS Path
   Prepending in order to avoid negatively affecting the internet.


The IETF datatracker status page for this draft is:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-grow-as-path-prepending%2Fdata=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978557059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=7TnSGyVp7p7innNedC5FT5ssVVOzrxYVyW6Tw5B0N90%3Dreserved=0

There are also htmlized versions available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-03data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978567016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=2mJb%2B6acbTyMKNdkVy1UdsJQdxnELMqyh52GQkPFgm8%3Dreserved=0
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-03data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978567016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qIZAlo8WOj85dXLPqQu%2BMq6cILpMdAd%2Ffye2bWYNAac%3Dreserved=0

A diff from the previous version is available at:

[GROW] draft-tppy-bmp-seamless-session-00

[Thomas.Graf]

Dear GROW wg,

We submitted a new draft called BMP Seamless Session. Extending the current BMP 
session lifecycle to preserve the BMP session throughout 

- Brief loss of connectivity between BMP client and server
- Maintenance of BMP server

To prevent data duplication with the re-export of the initial RIB dump and 
prevent loss of metrics between the TCP re-establishment.

This draft will be presented at IETF 110 and we are also looking forward to 
collect feedback from the mailing list.

Best Wishes
Thomas


A new version of I-D, draft-tppy-bmp-seamless-session-00.txt
has been successfully submitted by Thomas Graf and posted to the IETF 
repository.

Name:   draft-tppy-bmp-seamless-session
Revision:   00
Title:  BMP (BGP Monitoring Protocol) Seamless Session
Document date:  2021-02-22
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/archive/id/draft-tppy-bmp-seamless-session-00.txt
Status:https://datatracker.ietf.org/doc/draft-tppy-bmp-seamless-session
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-tppy-bmp-seamless-session
Htmlized:   https://tools.ietf.org/html/draft-tppy-bmp-seamless-session-00


Abstract:
   This document describes an optional BMP session lifecycle extension
   to prevent data duplication of previously exported messages when TCP
   session is re-established.  It prevents loss of messages between TCP
   session re-establishments and increase overall BMP scalability.

smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] GROW Meeting @ IETF 107 / YVR

[Thomas.Graf]

Hi Job,

Same as at IETF 106, I like to request a 10 minute slot to bring an update from 
the BMP group at IETF 107 hackathon. We are planning to test and validate the 
following BMP RFC's and drafts

- RFC 7854 (​​https://tools.ietf.org/html/rfc7854)
- RFC 8671 (​https://tools.ietf.org/html/rfc8671)
- Support for Local RIB 
(​​https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib)
- TLV support for BMP Route Monitoring and Peer Down Messages 
(​​https://tools.ietf.org/html/draft-lucente-bmp-tlv)
- BMP Extension for Path Marking TLV 
(​​​https://tools.ietf.org/html/draft-cppy-grow-bmp-path-marking-tlv)
- BGP Route Policy and Attribute Trace 
(​​​https://tools.ietf.org/html/draft-xu-grow-bmp-route-policy-attr-trace)

and also verify the resource and performance impact of BMP on routers.

Due to the corona virus, we will have both, participants who will participate 
onsite or remotely depending on travel restrictions.

Best Wishes
Thomas

-Original Message-
From: GROW  On Behalf Of Job Snijders
Sent: Thursday, March 5, 2020 9:05 PM
To: Chris Morrow 
Cc: grow-cha...@ietf.org; grow-...@ietf.org; grow@ietf.org
Subject: Re: [GROW] GROW Meeting @ IETF 107 / YVR

Does anyone have agenda items for this specific meeting?

If things can wait a little bit we can request a virtual interim meeting to 
accomodate what should've been handled this IETF around.

Kind regards,

Job

On Thu, Mar 05, 2020 at 04:34:56PM +, Chris Morrow wrote:
> 
> Howdy folks!  It's looking like both chairs will not be able to attend 
> the meeting in Vancouver in ~20 days time. We won't know definitely 
> until about the 16th, however.
> 
> I'm going to put in cancel requests for the GROW meeting now, if 
> things change we can re-collect our room, I'm certain.
> 
> -chris
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fgrowdata=02%7C01%7CThomas.Graf%40
> swisscom.com%7Cbcb2478799f943bb8b7708d7c1407de5%7C364e5b87c1c7420d9bee
> c35d19b557a1%7C1%7C0%7C637190355045041666sdata=SqH%2BZD6B83pkbRpI
> l6optEOfcPau4mMtpZGhRDUq5WU%3Dreserved=0

___
GROW mailing list
GROW@ietf.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrowdata=02%7C01%7CThomas.Graf%40swisscom.com%7Cbcb2478799f943bb8b7708d7c1407de5%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637190355045051625sdata=wKti%2B6o1KunaZxN6qSckrZuAeaNmRk3JjpqzthYm4PY%3Dreserved=0


smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Proposed updates to GROW charter

[Thomas.Graf]

Hi Job,

Very good input regarding „Devise a BGP Community Description System to IESG.

I think a YANG informational BGP community modell might be the right thing to 
do. I would volunteer to support such an approach.

I think it is good to keep the charter generic. I like your proposal.

I would be interested to know if others on the mailing list share my opinion on 
using YANG information model.

Best Wishes
Thomas


> On 22 Nov 2019, at 09:44, Job Snijders  wrote:
> 
> Dear all,
> 
> Below is a revision of the charter proposal.
> 
> Kind regards,
> 
> Job
> 
> Charter for GROW Working Group
> ===
> 
> The Border Gateway Protocol (BGP) is fundamental to the operation of the
> Internet. In recent years, occurrences of BGP related operational issues
> have increased, and while overall understanding of the default-free
> routing system has improved, there is still a long and growing list of
> concerns. Among these are routing table growth rates, interaction of
> interior and exterior routing protocols, dynamic properties of the
> routing system, and the effects of routing policy on both the size and
> dynamic nature of the routing table. In addition, new and innovative
> uses of BGP, such as the use of BGP as a signaling protocol for some
> types of Virtual Private Networks, have created new and unexpected
> operational issues.
> 
> The purpose of the GROW is to consider the operational problems
> associated with the IPv4 and IPv6 global routing systems, including but
> not limited to routing table growth, the effects of the interactions
> between interior and exterior routing protocols, and the effect of
> address allocation policies and practices on the global routing system.
> Finally, where appropriate, the GROW documents the operational aspects
> of measurement, monitoring, policy, security, and VPN infrastructures,
> and safe default behavior of implementations.
> 
> GROW will also advise various working groups, specifically the IDR and
> SIDROPS working groups, with respect to whether it is addressing the
> relevant operational and routing security needs of networks, and where
> appropriate, suggest course corrections or intervene. Finally,
> operational requirements developed in GROW can also be used by any new
> working group charged with standardizing a next generation inter-domain
> routing protocol.
> 
> Goals
> =
> 
> * Develop and document Best Current Practises for operations in the
>  Internet routing system.
> * Develop and document the operational aspects of securing the Internet
>  routing system including management of filtering and routing leaks.
> * Analyse, document and provide best practice characteristics of running
>  BGP at large scale
> * Provide analysis, feedback and assistance for other IETF working
>  groups when their subject matter impacts on the global Internet
>  routing ecosystem.
> * Provide stewardship and maintenance for the BGP Monitoring Protocol (BMP)
> * Provide stewardship and maintenance for the Multi-Threaded Routing Toolkit 
> (MRT)
> 
> Milestones
> ==
> 
> Jan 2020 - "Support for Local RIB in BGP Monitoring Protocol (BMP)" to IESG
> Apr 2020 - "BMP Peer Up Message Namespace" to IESG
> Jun 2020 - "Revision to Registration Procedures for Multiple BMP Registries" 
> to IESG.
> Oct 2020 - "Document negative consequences of de-aggregating received routes 
> for traffic engineering purposes" to IESG
> Jan 2021 - "A BCP on using IRR and RPKI data to improve filtering of BGP 
> peering sessions" to IESG or via "Evolving Documents"
> Mar 2021 - "TLV support for BMP Route Monitoring and Peer Down Messages" to 
> IESG.
> Jul 2021 - "Devise a BGP Community Description System" to IESG
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow


smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BMP compression Draft

[Thomas.Graf]

Hi Mukul and Paolo,

Thank you very much for this draft. I think it is a welcoming contribution to 
the other BMP drafts with the aim to reduce the encapsulation costs of BMP.

Swisscom as service provider has seen by using BMP RFC 7854 configured on MPLS 
PE routers, the burstiness at the data collection. In average, the amount of 
metrics are relatively small compared to YANG push and IPFIX. But when BMP peer 
is established, or BGP route refresh is in action or simply a major 
re-convergence in the network is ongoing, we see a spike in metrics and TCP 
re-transmits on the router side due to the nature of synchronization. Nothing 
to be alarmed of, since buffer on router side takes care of such congestions, 
but it does give the impression that with the increase of prefixes and TLV's a 
mitigation would be a good idea. Using compression, especially by following the 
same path as draft-przygienda-idr-compressed-updates-07 makes completely sense.

Looking forward for the WG adoption.

Best Wishes
Thomas Graf


From: GROW  On Behalf Of Mukul Srivastava
Sent: Wednesday, October 16, 2019 3:57 PM
To: grow@ietf.org
Cc: Mukul Srivastava 
Subject: Re: [GROW] BMP compression Draft


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 mailto:m...@juniper.net>>
Date: Wednesday, October 16, 2019 at 9:46 AM
To: "grow@ietf.org" mailto:grow@ietf.org>>
Cc: Paolo Lucente mailto:pa...@ntt.net>>, Mukul Srivastava 
mailto:m...@juniper.net>>
Subject: BMP compression Draft


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



smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Request WG Adoption for draft-lucente-bmp-tlv

[Thomas.Graf]

I support adoption as an upcoming co-author.

Thanks,
Thomas


From: GROW  On Behalf Of Paolo Lucente
Sent: Thursday, July 25, 2019 8:06 PM
To: grow@ietf.org grow@ietf.org 
Subject: [GROW] Request WG Adoption for draft-lucente-bmp-tlv


Dear GROWers,

We would like to request WG adoption for 
https://datatracker.ietf.org/doc/draft-lucente-bmp-tlv/ that was presented (*) 
yesterday. Can you please let us know your thoughts?

Thanks,
Paolo

(*) 
https://datatracker.ietf.org/meeting/105/materials/slides-105-grow-draft-lucente-grow-bmp-tlv-00





smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Path marking using BMP - TLVs

[Thomas.Graf]

Hi Yunan,

> Regarding your suggestion of adding a "ECMP" path type, well, the currently 
> defined "0x0004 -- Primary Path" path type should do the work. In fact, the 
> so-called "Primary Path" in this draft refers to all the ECMP paths 
> (including the "Best path"). Of course, we can further work on the naming.

Just to clarify. There can be multiple primary paths and one of it will be the 
best path as well. Correct? If yes perfect. Thank you.

> May I ask the use case for your proposal of adding "the reason why it is 
> considered ECMP" reason string?
When troubleshooting BGP, one of the most use cases are why a path is not 
installed for forwarding. One reason can be because of various configuration 
knobs such as:

Configuration Guide - IP Unicast Routing - BGP Configuration - Configuring BGP 
Load Balancing
https://support.huawei.com/enterprise/en/doc/EDOC114198/19f9347b/configuring-bgp-load-balancing

- maximum load-balancing (maximum-path)
- load-balancing as-path-relax

At the end we will search within BMP local-RIB collected metrics the same way 
as you would do on CLI described in this document. The big difference is that 
we will do it across all the routing contexts and across the network. Thus, 
much more efficiently.

Configuration Guide - IP Unicast Routing - BGP Configuration - Verifying the 
BGP Route Selection and Load Balancing Configuration
https://support.huawei.com/enterprise/en/doc/EDOC114198/6efe04ed/verifying-the-bgp-route-selection-and-load-balancing-configuration

I always have the closed loop operation in mind as well. What BMP metrics do I 
need so that I can trigger a configuration change to achieve the desired 
intend. The intend is that I want a certain selection of paths be ECMP. Two 
possible use cases can happen:

- To many are installed. Some of them are undesired.
- To less are installed. Some should but aren't.

If they are not installed, we should see them in "Non-installed path" or 
perhaps "Backup path" or "Best external path".

> Do you have any specific reason string in mind for the ECMP paths?
If they are installed then it would be great to understand in the ECMP decision 
process of the router within the routing context which was the last decision 
step. For instance:

- AS-PATH relax
- eBGP multipath
- iBGP multipath
- eiBGP multipath

draft-lapukhov-bgp-ecmp-considerations-02 shows what possibilities we have.

If we see a route marked as ECMP with "eBGP multipath" but was not intend to be 
part of ECMP, we could remove the configuration line "maximum load-balancing 
ebgp" and verify if desired route is now marked as "Non-installed path" or 
perhaps "Backup path" or "Best external path".

I hope this makes sense. Feedback very welcome. 

Kind regards
Thomas Graf

Network Engineer
Datacenter Functions
Telefon +41-58-223 84 01
Mobile  +41-79-728 80 12
thomas.g...@swisscom.com

Swisscom (Schweiz) AG
IT, Network & Infrastructure
Datacenter Functions
Binzring 17
8045 Zürich
www.swisscom.com
Postadresse:
Binzring 17
8045 Zürich


-Original Message-
From: Guyunan (Yunan Gu, IP Technology Research Dept. NW)  
Sent: Monday, July 15, 2019 11:52 AM
To: Graf Thomas, INI-ONE-WSN-DCF ; 
juancamilo.card...@imdea.org; grow@ietf.org; pa...@ntt.net
Cc: draft-cppy-grow-bmp-path-marking-...@ietf.org
Subject: RE: [GROW] Path marking using BMP - TLVs

Hi Thomas,

Thanks a lot for your comments on the draft, and your elaboration on the usage 
of Path Marking TLV!

Regarding your suggestion of adding a "ECMP" path type, well, the currently 
defined "0x0004 -- Primary Path" path type should do the work. In fact, the 
so-called "Primary Path" in this draft refers to all the ECMP paths (including 
the "Best path"). Of course, we can further work on the naming.  

Thanks for sharing the ECMP reference: 
raft-lapukhov-bgp-ecmp-considerations-02. May I ask the use case for your 
proposal of adding "the reason why it is considered ECMP" reason string? Well, 
it's easy for me to understand that users may wonder why a path is "non-best". 
Do you have any specific reason string in mind for the ECMP paths?


BR,

Yunan 

-Original Message-
From: thomas.g...@swisscom.com [mailto:thomas.g...@swisscom.com] 
Sent: Friday, July 12, 2019 8:44 PM
To: juancamilo.card...@imdea.org; grow@ietf.org; pa...@ntt.net; Guyunan (Yunan 
Gu, IP Technology Research Dept. NW) 
Cc: draft-cppy-grow-bmp-path-marking-...@ietf.org
Subject: RE: [GROW] Path marking using BMP - TLVs

Hi Camilo, Paulo and Yunan,

Thank you very much for this exciting and very useful draft. This will make 
draft-ietf-grow-bmp-local-rib even more useful. On top of having access to all 
(not only to the best) BGP paths in BGP local RIB, thanks to this draft, we 
will finally understand how these BGP paths are installed in RIB/FIB. We will 
be able to get an network 

Re: [GROW] Path marking using BMP - TLVs

[Thomas.Graf]

Hi Camilo, Paulo and Yunan,

Thank you very much for this exciting and very useful draft. This will make 
draft-ietf-grow-bmp-local-rib even more useful. On top of having access to all 
(not only to the best) BGP paths in BGP local RIB, thanks to this draft, we 
will finally understand how these BGP paths are installed in RIB/FIB. We will 
be able to get an network wide overview on which routers which paths have 
redundancy and which not. And that with ONE single query in big data.

One remark I like to add to complete all the possible path types. In section 
2.1 Path Type, could you add ECMP (Equal-Cost Multipath) as path type and under 
Section 2.2 Reason String, the reason why it is considered ECMP. 

For BGP Equal-Cost Multipath reasons, please refer to this current draft:
https://www.ietf.org/id/draft-lapukhov-bgp-ecmp-considerations-02.txt

Kind regards
Thomas Graf

Network Engineer
Datacenter Functions
Telefon +41-58-223 84 01
Mobile  +41-79-728 80 12
thomas.g...@swisscom.com

Swisscom (Schweiz) AG
IT, Network & Infrastructure
Datacenter Functions
Binzring 17
8045 Zürich
www.swisscom.com
Postadresse:
Binzring 17
8045 Zürich


-Original Message-
From: GROW  On Behalf Of Camilo Cardona
Sent: Saturday, July 6, 2019 5:04 AM
To: grow@ietf.org grow@ietf.org 
Cc: draft-cppy-grow-bmp-path-marking-...@ietf.org
Subject: [GROW] Path marking using BMP - TLVs

Hello GROW,

We just submitted draft 
https://www.ietf.org/id/draft-cppy-grow-bmp-path-marking-tlv-00.txt. The idea 
of the draft is to signal the state of the path in the FIB using the mechanism 
described in draft-lucente-bmp-tlv-00 
(https://www.ietf.org/id/draft-lucente-bmp-tlv-00.txt), which was introduced 
this week. 

Feedback is, as always, welcome. 

If possible, we would like to have a couple of minutes to present it in 
Montreal (probably better if done next to the presentation of  
draft-lucente-bmp-tlv-00).

A good part of this document was inspired by other draft, 
https://tools.ietf.org/html/draft-bgp-path-marking-00, that we proposed some 
years ago. In that draft, similar information was signaled using communities. 
Back then, there were some concerns of this data potentially messing with the 
BGP decision process, something that should not be a problem when using BMP.

Thanks,
Camilo Cardona


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

smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Prefix limit ORF

[Thomas.Graf]

Hi Job,

Thanks for the input regarding draft-keyur-idr-bgp-prefix-limit-orf-03.

That’s what I meant. Incoming peer prefix limit needs to be advertised by BGP. 
I think it’s a bad idea to configure statically an outbound peer maximum prefix 
limit. The only reason why I want that is to align with my peer. Ideally, these 
parameters should be automatically exchanged between peers. John and Robert 
point out that both of them are in competition which should take precedence. 
This points usually to a bad design.

Let me go to the big picture and share my thoughts. The reason why we want 
inbound prefix limits is because we don't have endless resources in the BGP 
RIB's. Right? Thanks to

https://tools.ietf.org/html/rfc7854#section-4.8


we are able to monitor their usage. Great. But we don't have any IETF YANG 
model available giving us the maximum possible route count on each BGP RIB. 
Why? Therefore we don't know at which threshold we should alarm. Nor we don't 
know at which static threshold we should limit the amount of prefixes we 
receive from which peer. Nor thus this mechanism account for the BGP local RIB 
maximum capable routes. If my BGP local RIB supports 1'000'000 routes and I 
have 10 peers with an average of 70'000 routes each. How high should I set the 
inbound prefix limit? My answer: +10% more prefixes in BGP local RIB than 
alert, +20% more in BGP local RIB than limit the peer which caused the issue 
and alert. Should be monitored with BMP stats reports 
(https://tools.ietf.org/html/rfc7854#section-4.8) and orchestrated 
automatically within BGP YANG model (container prefix-limit). Monitored and 
orchestrated in a closed loop operation. Do we want' that logic to be built in 
routers? Does one router has the big picture of the network and their peerings? 
No. Therefore it needs to be solved outside the BGP router.



Kind regards
Thomas Graf

Network Engineer
Datacenter Functions
Telefon +41-58-223 84 01
Mobile  +41-79-728 80 12
thomas.g...@swisscom.com

Swisscom (Schweiz) AG
IT, Network & Infrastructure
Datacenter Functions
Binzring 17
8045 Zürich
www.swisscom.com
Postadresse:
Binzring 17
8045 Zürich


From: GROW  On Behalf Of Robert Raszuk
Sent: Tuesday, March 26, 2019 5:02 PM
To: John Scudder 
Cc: grow@ietf.org
Subject: Re: [GROW] Prefix limit ORF

And with this in mind the draft needs to define expected behaviour when locally 
configured outbound prefix limit is different from ORF pushed one (someone's 
inbound).

Lowest wins, static wins, latest wins etc ... otherwise each implementation may 
choose differently ;)

thx
R.

On Tue, Mar 26, 2019, 16:59 John Scudder 
mailto:40juniper@dmarc.ietf.org>> wrote:
Apropos Job’s talk just now —

draft-keyur-idr-bgp-prefix-limit-orf-03
https://tools.ietf.org/html/draft-keyur-idr-bgp-prefix-limit-orf-03

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


smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] New Version Notification for draft-xu-grow-bmp-route-policy-attr-trace-00.txt(Internet mail)

[Thomas.Graf]

Hi Yunan and co-authors of this draft,

First of all as network operator I welcome this extension to BMP to gain 
visibility how and how fast BGP prefixes are being processed through various 
route-policies within a router. Managing BGP route-policing configurations in a 
large and automated cloud/data-center environment with service function 
chaining and L3 MPLS VPN's is challenging without the proper tools.

I am supporting this draft to be adopted by the working group. My input as 
follow: 

In section 2.3 you describe

Policy ID, Policy Distinguisher, Peer ID, VRF/Table name
https://tools.ietf.org/html/draft-xu-grow-bmp-route-policy-attr-trace-00#section-2.3

For Network Telemetry closed loop operation this loose definition is not 
sufficient enough. We need the possibility to correlate to BGP device 
configuration to link configuration change to BGP route-policy processing and 
BGP RIB change event. We have with below ongoing drafts already two YANG models 
defining the route-policy attachment points and route-policy definitions. 

Policy configuration overview
https://tools.ietf.org/html/draft-ietf-idr-bgp-model-04#section-2.2

A YANG Data Model for Routing Policy Management
https://tools.ietf.org/html/draft-ietf-rtgwg-policy-model-06

These fields should be aligned between these drafts so they can be correlated 
at data-processing/data-storage within big data. This is aligned with the input 
I gave on the Network Telemetry Framework draft-song-opsawg-ntf 
https://mailarchive.ietf.org/arch/msg/opsawg/1kuI5xKDTkIa7q5jRKGDq1frFLU

Kind regards
Thomas Graf

Network Engineer
Datacenter Functions
Telefon +41-58-223 84 01
Mobile  +41-79-728 80 12
thomas.g...@swisscom.com

Swisscom (Schweiz) AG
IT, Network & Infrastructure
Datacenter Functions
Binzring 17
8045 Zürich
www.swisscom.com
Postadresse:
Binzring 17
8045 Zürich


-Original Message-
From: GROW  On Behalf Of oliverxu(??)
Sent: Tuesday, March 12, 2019 3:07 AM
To: internet-dra...@ietf.org; Shunwan Zhuang ; Yunan 
Gu ; Zhenbin Li 
Cc: grow@ietf.org
Subject: Re: [GROW] New Version Notification for 
draft-xu-grow-bmp-route-policy-attr-trace-00.txt(Internet mail)

Dear GROW members,

We have just submitted a new draft that extends BMP to collect the correlated 
BGP route policy and route attributes for route policy validation.

Comments are very welcome!


Oliver.


On [DATE], "[NAME]" <[ADDRESS]> wrote:


A new version of I-D, draft-xu-grow-bmp-route-policy-attr-trace-00.txt
has been successfully submitted by Yunan Gu and posted to the
IETF repository.

Name:   draft-xu-grow-bmp-route-policy-attr-trace
Revision:   00
Title:  BGP Route Policy and Attribute Trace Using BMP
Document date:  2019-03-09
Group:  Individual Submission
Pages:  12
URL:
https://www.ietf.org/internet-drafts/draft-xu-grow-bmp-route-policy-attr-trace-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-xu-grow-bmp-route-policy-attr-trace/
Htmlized:   
https://tools.ietf.org/html/draft-xu-grow-bmp-route-policy-attr-trace-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-xu-grow-bmp-route-policy-attr-trace


Abstract:
   The generation of BGP adj-rib-in, local-rib or adj-rib-out comes from
   BGP protocol communication, and route policy processing.  BGP
   Monitoring Protocol (BMP) provides the monitoring of BGP adj-rib-in
   [RFC7854], BGP local-rib [I-D.ietf-grow-bmp-local-rib] and BGP adj-
   rib-out [I-D.ietf-grow-bmp-adj-rib-out].  However, there lacks
   monitoring of how BGP routes are transformed from adj-rib-in into
   local-rib and then adj-rib-out (i.e., the BGP route policy processing
   procedures).  This document describes a method of using BMP to trace
   the change of BGP routes in correlation with responsible route
   policies.



  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




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


smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] working group last call draft-ietf-grow-bmp-local-rib (ends 2018.11.26)

[Thomas.Graf]

Dear GROW,

I fully support publication of both drafts. They are very useful and long 
awaited. We are looking forward to implement it on our network as soon as it is 
available from our vendors. 

Kind regards
Thomas Graf

Network Engineer
Tribe IT Clouds
thomas.g...@swisscom.com


-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
Sent: Friday, November 9, 2018 3:13 PM
To: grow@ietf.org
Subject: [GROW] working group last call draft-ietf-grow-bmp-local-rib (ends 
2018.11.26)

Dear GROW,

As suggested in the working group meeting in Bangkok, 
draft-ietf-grow-bmp-local-rib may ready for last call. The last call will be 2 
weeks, ending November 26th, 2018.

Abstract:

The BGP Monitoring Protocol (BMP) defines access to the Adj-RIB-In
and locally originated routes (e.g. routes distributed into BGP from
protocols such as static) but not access to the BGP instance
Loc-RIB. This document updates the BGP Monitoring Protocol (BMP)
RFC 7854 by adding access to the BGP instance Local-RIB, as defined
in RFC 4271 the routes that have been selected by the local BGP
speaker's Decision Process. These are the routes over all peers,
locally originated, and after best-path selection.

The document is at 
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-local-rib

Please review the document and provide feedback.

The internet-draft authors should note that Jeff Haas contributed a comment to 
the IETF 103 GROW jabber room that unfortunatly wasn't read out loud. This 
comment should be considered input into the last call
process:

jhaas> "For loc-rib draft, list discussion was over whether we should
advertise active route vs. best bgp route. Best bgp route means
that you still need an active bgp session to monitor actual bgp and
doesn't simplify use case."
https://www.ietf.org/jabber/logs/grow/2018-11-05.html

Kind regards,

Job & Chris

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

smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Dropped Updates in BMP?

[Thomas.Graf]

Hi all,

Thank you very much for the updated drafts and presentation at IETF 101 
regarding bmp and Adj-RIB-Out and Local-RIB support. I have been reading the 
updated draft and fully support them.

Regarding route filtering the comment from Reudiger Volk. From a network 
operator point of view, I share Serpil's comments. I also share Paolo's 
concerns bringing in more complexity could potentially lead being less adapted 
by vendors. I share Job's suggestion that this should if being addressed in a 
separate draft.

At current state BMP is able to answer the question at which point (Adj-RIB-In, 
Adj-RIB-Out, Local-RIB) how much and which routes are filtered, passed or when 
passed where the route attributes were modified. What BMP can't answer is why 
these routes where passed or when passed, why where the route attributes 
modified. And as Serpil already explained, for a network operator, if complex 
and historical evolved route-policy configuration is in place, can be quiet 
cumbersome to troubleshoot. Especially as route-policy configuration are not 
standardized and differ between vendors. An there, BMP could bring valuable 
insights in, which we should not ignore.

How about for instance adding three fields to each route in Adj-Post-RIB-In , 
Local-RIB and Adj-Post-RIB-Out:

Action:  Passed, Filtered, Modified
Place:   route-policy name or function within router. An example 
for functions could be: route-target filter
Debug: free text of what has been modified if modified. An example: 
modified next-hop to 1.1.1.1

I fully understood that adding these fields has its price and therefore it 
should be addressed and discussed in a new separate draft, especially since 
Adj-RIB-In is also affected. From my perspective, where I disagree, is that the 
a filtered flag alone would be enough to address the wish to get more visbility 
into the filter behavior since it would not explain why it has been filtered.

Regarding Serpil's question wherever it would be sufficient only to flag routes 
if filtered by route-policy. From my point of view I can confirm that this is 
the most interesting part, but as I described above, I fear that it might be 
not enough when we start going down that road.

Kind regards
Thomas Graf

Network Engineer
Tribe IT Clouds
Telefon +41-58-223 84 01
Mobile   +41-79-728 80 12
thomas.g...@swisscom.com

Swisscom (Schweiz) AG
IT, Network & Infrastructure
Tribe IT Clouds
Binzring 17
8045 Zürich
www.swisscom.com
Postadresse:
Binzring 17
8045 Zürich


From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Serpil Bayraktar (serpil)
Sent: Tuesday, March 20, 2018 7:54 PM
To: Paolo Lucente ; Job Snijders 
Cc: grow@ietf.org
Subject: Re: [GROW] Dropped Updates in BMP?

+1

Not knowing which policy is filtering which route has been the #1 reason for 
operators not wanting to touch existing policy configuration on the routers 
AFAIK. Hence the enormous size of policy configs. Not to mention not having an 
easy way to validate whether a new policy is filtering what it is intended to 
filter or not.
If there is any visibility into why a route was filtered that can be relayed 
via BMP, it’d be super useful. I do agree that it should probably be another 
draft as Job suggested.

As for those routes that are dropped before even hitting the policy filters 
(such as due to errors in the path attributes like AS path loops), I think the 
operators need to step in here to indicate how valuable this information is to 
them and whether the vendors can provide them without harming the operation of 
the router or not.

Serpil



From: GROW > on behalf of 
Paolo Lucente >
Date: Tuesday, March 20, 2018 at 11:20 AM
To: Job Snijders >
Cc: Grow Mailing List >
Subject: Re: [GROW] Dropped Updates in BMP?


Minor comment: my understanding is that Reudiger was interested in getting more 
visibility in what happens between Adj-RIB-In pre- and post- policy.

I concur with Tim Evens comment “In order to determine what was 
"dropped/filtered/rejected/whatever" we do a simple diff between pre-policy and 
post-policy", which is essentially the same i replied to Reudiger as in what 
can be done with what we have. Speaking to pmacct users using BMP, the ability 
to diff pre- and post- policy was found good enough as a starting point to 
further research what happened to missing routes (through means external to 
BMP).

It would be nice to get to some sort of increased visibility and have a kind of 
‘exit code’, as Jeff Haas described it, when a route is filtered (‘f’ flag to 
be ported to Adj-RIB-In and Adj-RIB-Out?) and I reckon 

Re: [GROW] WG LC for draft-ietf-opsawg-ipfix-bgp-community

[Thomas.Graf]

Hi Zhenqiang and the coauthors,

First of all I have to congratulate to this draft. I share the opinion that BGP 
communities are a very powerful information element. Correlated to the 
forwarding plane it gives a more detailed and granular view of the network 
usage then AS numbers or paths.

Looking from a MPLS VPN network provider perspective, which currently doing 
flow aggregation at the collector with BGP VPNv4/6 peerings to MPLS PE routers 
and encode inventory data into BGP communities, I have to agree with Paolo's 
opinion that this draft might not go far enough.

Looking just at the forwarding plane. We welcome the support of BGP standard 
and extended communities. To be useable for us, we would also need BGP 
route-distinguishers (IPFIX entity 90) and prefix/prefix length to be covered 
to be applicable in a MPLS VPN network. I agree with Jeffrey that the 
correlation from BGP local RIB to the RIB on the router is more accurate (lag, 
BGP local RIB vs. RIB), compared to the correlation between BGP local rib and 
IPFIX on a collector.

Looking at the big picture, IPFIX is just covering the forwarding plane. It is 
just a part of the puzzle to extract metrics from a router. The forwarding 
plane alone isn't enough to understand why the forwarding behavior changed in a 
network. BMP is covering well the routing control-plane, especially if BGP 
local RIB and adjacent RIB out will be covered. Streaming telemetry with yang 
config model covering the physical topology. From our point of view, where we 
want forwarding, control-plane and physical topology covered, I disagree that 
the BGP/BMP peering could be replaced by this draft. It will remain to cover 
the historical aspects of the BGP control-plane. It could be replaced if we 
only would care about the forwarding plane (for accounting as an example) 
though.

Kind regards
Thomas Graf

Network Engineer
Tribe IT Clouds
Telefon +41-58-223 84 01
Mobile   +41-79-728 80 12
thomas.g...@swisscom.com

Swisscom (Schweiz) AG
IT, Network & Infrastructure
Tribe IT Clouds
Binzring 17
8045 Zürich
www.swisscom.com
Postadresse:
Binzring 17
8045 Zürich


From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of li zhenqiang
Sent: Tuesday, February 27, 2018 5:06 PM
To: Jeffrey Haas ; Paolo Lucente 
Cc: grow ; Zhoutianran ; 
draft-ietf-opsawg-ipfix-bgp-community@ietf.org; opsawg 
Subject: Re: [GROW] WG LC for draft-ietf-opsawg-ipfix-bgp-community

Hi Jeffrey Haas and Paolo Lucente,

Thank you very much for your comments and opinions. Sorry for the late response 
due to Chinese new year holiday.

For the first concern of Paolo, at present I have no need to know the full as 
path related to a traffic flow. What I want to collect is the communities 
related to a traffic flow, which represent the the geographical and topological 
related information in finer granularity than the ASes.


When the working group called adoption of this doc, IPFIX doctor, PJ Aitken's 
opinion answered your second concern.  He said " Per section 6 of RFC7012, new 
IPFIX Information Elements can be added by direct application to IANA; there's 
no need for a draft or RFC. However, the introduction and examples may be 
valuable, especially for BGP experts who are less familiar with IPFIX. I've no 
objection to adopting the draft."


And I totally agree with Mr. Jeffrey Haas, running BGP is not trivial for all 
the IPFIX collectors. BGP is heavy and it runs well in the exporters, i.e. 
routers. If the collector can get the needed BGP information, it can do 
statistics and analysis directly.


Best Regards,
Zhenqiang Li from China Mobile Research Institute

li_zhenqi...@hotmail.com

From: Jeffrey Haas
Date: 2018-02-22 01:52
To: Paolo Lucente
CC: Tianran Zhou; 
grow@ietf.org; 
draft-ietf-opsawg-ipfix-bgp-community@ietf.org;
 opsawg
Subject: Re: [GROW] WG LC for draft-ietf-opsawg-ipfix-bgp-community
Paolo,

I don't speak for the authors here, just my opinion.

On Wed, Feb 21, 2018 at 05:37:59PM +0100, Paolo Lucente wrote:
> One concern is that this looks a very isolated effort, ie. why communities
> and not as-path? I remember the story of this draft, it comes from field
> needs and that is in short the answer to the cherry-picking.

Partly, the usual information that people want from flow for AS information
(origin or peer AS) is already available.  The full path, no.  One certainly
could make the argument that the full path could be sent.

Since flow analyzers mostly want the active 

[GROW] , feedback, draft-evens-grow-bmp-adj-rib-out-01, draft-evens-grow-bmp-local-rib-00

[Thomas.Graf]

Hi,

I would like to congratulate on these two drafts, share my opinions and our 
intention to use BMP local RIB and Adj RIB Out support as soon as it is 
available and look forward to test it.

We have BMP V3 and BGP VPNv4/VPNv6 eBGP peerings to MPLS PE routers from our 
collectors. We are using the Adj RIB out metrics, gathered by BGP VPNv4/VPNv6 
eBGP peering, to correlate/aggregate with Netflow/IPFIX. The Adj RIB In metrics 
collected by BMP V3 are used for BGP control-plane visualization and 
troubleshooting purposes.

To correlate BGP VPNv4/6 with IPFIX IPv4/IPv6 VRF name (IPFIX element id 236, 
VRFname) we are currently using SNMP OID 
mplsL3VpnVrfRD(1.3.6.1.2.1.10.166.11.1.2.2.1.4).

To simplify the current collection setup we like to reduce from two peerings 
(BMP + BGP VPNv4/6) to BMP only and improve Netflow/IPFIX correlation by using 
BMP local RIB instead of Adj RIB out.

We are pleased to see that the collection of BGP route-distinguishers have been 
covered in section 5.1 and the VRF name in section 6.1.1. We expect that with 
this, we are able to correlate to the VRF name contained in the IPFIX template 
(IPFIX element id 236, VRFname). That would further simplify our current setup 
since we would not need SNMP anymore. Correct?

The only question raised when reading through the IETF grow-bmp-local-rib draft 
was, if it would make sense to include an additional information, such as if a 
route was filtered through a table-map/distribute-list/admin distance when 
imported from BGP local RIB to the RIB. This could be seen similar as a peer 
route-policy in the Adj RIB in/out.

This could be a useful additional information since one of the application is 
to correlate IPFIX with the RIB and the only differences between the BGP local 
RIB and RIB could be due table-map/distribute-list/admin distance filtering.

I hope this makes sense. Please correct me if I misunderstood something. 
Feedback very welcome.

kind regards
Thomas Graf
___
Network Engineer
Cloud Connectivity Management

Phone   +41 58 223 84 01
Mobile   +41 79 728 80 12
thomas.g...@swisscom.com
___
Swisscom (Schweiz) AG
Binzring 17
CH-8045 Zürich
Switzerland
www.swisscom.ch



smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow