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 connection) may require a full refresh of PEER
UPs and RIB dumps, partial refresh on a subset of peers, only new peers since
last reconnect time, and/or no refresh at all for any of the given peers.
Unless a refresh/RIB dump is requested or needed, messages should continue
where they left off based on buffer allocations (e.g., offsets or similar).
IMO, the fast reconnect does not address the set of peers, especially
considering the peers that changed during the no-connect period.
2) Regardless of quick restarts or transient network problems, sometimes a RIB
dump and PEER UP is not needed. It would be nice to pick up where we left off,
if that is possible. This should be per-peer instead of being binary at the
session level due chatty peers causing an issue with buffering. This can
include use-cases for logging, where the logging process does not actually care
for a RIB dump at all. Instead, it only wants new messages starting at BMP
receiver connect time (based on peer and afi/safi).
3) BMP receivers (like routers when needing to reapply a policy) sometimes need
to get a refresh for a subset of peers. For example, a DB change that results
in some peers needing to be added again. Currently, the method to refresh
are:
a) go to the router and initiate a route-refresh, which is intrusive and
requires auth to do this. Not great.
b) reset the BMP TCP connection to trigger the router to refresh everything.
This is not ideal as there can be hundreds of peers and only a small set
needed to be refreshed.
IMO, the same solution can be used to solve for all of the above. I would
like to see a new BMP message that the receiver sends on initial connect to
indicate what's needed. It's important to call out that not all peers (by
afi/safi) are equal in terms of buffer exhaustion during connection loss to a
receiver. For example, link-state, public/private peering with customers,
etc… do not have many updates over several minutes. An all-or-nothing approach
based on short-time is not a desired solution (IMO) and leaves many other RIB
dump use-cases unaddressed.
Thanks,
Tim
On 3/11/21, 8:45 PM, "GROW" <[email protected]> wrote:
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) <[email protected]>
Sent: Thursday, March 11, 2021 11:29 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 <[email protected]>;
[email protected]; [email protected]; [email protected]
Cc: [email protected]
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:[email protected]> On Behalf Of
mailto:[email protected]
Sent: Thursday, March 11, 2021 4:59 AM
To: mailto:[email protected]; mailto:[email protected];
mailto:[email protected]
Cc: mailto:[email protected]
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:[email protected]>
Sent: Thursday, March 11, 2021 3:00 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 <mailto:[email protected]>;
mailto:[email protected]; mailto:[email protected]
Cc: mailto:[email protected]
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: mailto:[email protected] [mailto:[email protected]]
Sent: Wednesday, March 10, 2021 11:11 PM
To: Wanghaibo (Rainsword) <mailto:[email protected]>;
mailto:[email protected]; mailto:[email protected]
Cc: mailto:[email protected]
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:[email protected]>
Sent: Wednesday, March 10, 2021 12:48 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 <mailto:[email protected]>;
mailto:[email protected]; mailto:[email protected]
Cc: mailto:[email protected]
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:[email protected]] On Behalf Of
mailto:[email protected]
Sent: Wednesday, March 10, 2021 2:21 PM
To: mailto:[email protected]; mailto:[email protected]
Cc: mailto:[email protected]
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:[email protected]> On Behalf Of Robert Raszuk
Sent: Tuesday, March 9, 2021 10:38 PM
To: John Kristoff <mailto:[email protected]>
Cc: mailto:[email protected] mailto:[email protected] <mailto:[email protected]>
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:[email protected]> wrote:
On Tue, 9 Mar 2021 20:44:18 +0000
"Jakob Heitz \(jheitz\)" <jheitz=mailto:[email protected]> 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
mailto:[email protected]
https://eur03.safelinks.protection.outlook.com/?url=https://www.ietf.org/mailman/listinfo/grow&data=04|01|[email protected]|6cb61add8d894edc4c6808d8e4dd1fe9|364e5b87c1c7420d9beec35d19b557a1|1|0|637510985664476602|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0=|1000&sdata=dSv5IiC+WqR44gCcPlr9/rYqnZwOCWQr7wx2/Xe/yKY=&reserved=0
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
