Dear group,
Yesterday we had the pleasure to hear a report from Thomas Graf on new
BMP work.
The https://datatracker.ietf.org/doc/html/draft-tppy-bmp-seamless-session-00
document outlines a concept to allow BMP clients to resume 'an existing'
session with the BMP server, reducing the need to
Sriram:
If IDR adopts the draft, you can ask for early allocation on the registry.
Before that point, let me chat with the IDR co-chairs and ADs to what other
options you have.
Cheers, Sue
-Original Message-
From: Sriram, Kotikalapudi (Fed) [mailto:kotikalapudi.sri...@nist.gov]
thomas.g...@swisscom.com wrote on 08/03/2021 06:19:
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
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 wrote:
> On Tue, 9 Mar
I've seen this session resumption technique in the '90s.
BMP is a one-way protocol. The BMP server sends nothing.
Thus adding this is a significant rework of BMP.
On the router, it will require remembering all the withdraws
that occurred in the BMP serial number window, so that window will
need to
Dear GROW,
(Removed sidrops@ from CC)
*Wearing a Working Group participant hat*
I reviewed draft-ietf-grow-route-leak-detection-mitigation-04 and it
appears to me there is a shortcut possible in the mitigation algorithm.
This shortcut in turn negates the need to specify any ASN in the "DO
Dear Sriram, Sue,
Working Group Last Call is possible, but I suspect after WGLC it will
not be possible for the document to progress beyond the Shepherd
Write-up step, because the current -04 version essentially is blocking
on a normative dependency on 'draft-heitz-idr-wklc' (or any successor).
On Tue, 9 Mar 2021 20:44:18 +
"Jakob Heitz \(jheitz\)" 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
Job, your suggestion kicks a different goal than
draft-ietf-grow-route-leak-detection-mitigation does.
draft-ietf-grow-route-leak-detection-mitigation tries to determine
if your neighbor leaked the route to you.
To do that, you need to know how your neighbor received the route
before he sent it
>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
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 proposal at hand, the BMP server would send a client-specific
TCP_FAST_OPEN cookie (on top of TCP ACKs), and possibly eventually a TCP
RST, which is slightly
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
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
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
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 On Behalf Of thomas.g...@swisscom.com
Sent: Tuesday, March 9, 2021 10:21 PM
To:
15 matches
Mail list logo
