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,
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
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
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
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
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:
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
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
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.
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:
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.
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
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:
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
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
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
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
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
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
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
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
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
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]
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
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:
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:
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
43 matches
Mail list logo
