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

[Job Snijders]

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

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

Re: [GROW] An alternative approach to draft-ietf-grow-route-leak-detection-mitigation

[Job Snijders]

Dear Jakob,

On Wed, Mar 10, 2021 at 02:10:24AM +, Jakob Heitz (jheitz) wrote:
> Job, your suggestion kicks a different goal than
> draft-ietf-grow-route-leak-detection-mitigation does.

Yes, I'm aware I am suggesting a different approach to solve the problem
of route leaks.

> 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 to you.
> That's what the ASN in the LC is for.

Right, so my proposal is that the neighbor does not (knowingly) leak 
routes to you, negating the need to additionally tag routes with more
information than "this route is intended for not-for-peers (Down Only)"

I believe the Section 6 'Only To Customer' Attribute described in
https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-15 can be
implemented using the existing well-known NOPEER Attribute.

Kind regards,

Job

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

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

[Douglas Fischer]

I'm not sure about what I'm going to say... But.

BMP would transfer sensible data.
Then some cryptographic layer would be recommended/necessary.

Considering that, following on this approach of "fast connection", will not
have time/space to negotiate some crypto on those fast reconnections.
So I presume something above(separate from the transport layer) will need
to deal with that cryptographic layer, right?




Em qua., 10 de mar. de 2021 às 06:04, Job Snijders  escreveu:

> 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
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Douglas Fischer]

sed ´s/sensible/sensitive´

In pt_BR both words are "Sensível", and what defines the real meaning is
the phrase context.
Same with Safety and Security, both are "segurança" in pt_BR.

Dã... Sorry!

Em qua., 10 de mar. de 2021 às 07:16, Douglas Fischer <
fischerdoug...@gmail.com> escreveu:

> I'm not sure about what I'm going to say... But.
>
> BMP would transfer sensible data.
> Then some cryptographic layer would be recommended/necessary.
>
> Considering that, following on this approach of "fast connection", will
> not have time/space to negotiate some crypto on those fast reconnections.
> So I presume something above(separate from the transport layer) will need
> to deal with that cryptographic layer, right?
>
>
>
>
> Em qua., 10 de mar. de 2021 às 06:04, Job Snijders  40fastly@dmarc.ietf.org> escreveu:
>
>> 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
>>
>> ___
>> GROW mailing list
>> GROW@ietf.org
>> https://www.ietf.org/mailman/listinfo/grow
>>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Wanghaibo (Rainsword)]

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
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Jakob Heitz (jheitz)]

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

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

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

[Jared Mauch]

A primary use-case of the BMP data is to provide information to a route 
collector/optimizer to determine what feasible paths may be sent to a router by 
these offline computational systems.  This requires a reliable transport where 
messages are delivered in order.

I understand others may be fine with missed or out of order messages, but this 
isn’t something that there is a lot of room to discuss.

I’m not a fan of QUIC but if it provides the ability to resume the session and 
preserve the order when there’s a [brief] network disruption that may be 
helpful for other use cases.

- Jared

> On Mar 10, 2021, at 1:47 AM, Jakob Heitz (jheitz) 
>  wrote:
> 
> 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: 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  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  wrote:
> 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 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
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

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

Re: [GROW] 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-6&data=04%7C01%7CThomas.Graf%40swisscom.com%7Cdba64e44152c438cbab708d8e38f7972%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637509552641063005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fPQYYJPEYnfYwyC7bT4LZCfkUZUdlz1ZuLN9F3oT7Kg%3D&reserved=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 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 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] An alternative approach to draft-ietf-grow-route-leak-detection-mitigation

[Jakob Heitz (jheitz)]

Then your proposal is not an alternative to Sriram's, but a complement. No?

Regards,
Jakob.

-Original Message-
From: Job Snijders  
Sent: Wednesday, March 10, 2021 1:12 AM
To: Jakob Heitz (jheitz) 
Cc: grow@ietf.org
Subject: Re: [GROW] An alternative approach to 
draft-ietf-grow-route-leak-detection-mitigation

Dear Jakob,

On Wed, Mar 10, 2021 at 02:10:24AM +, Jakob Heitz (jheitz) wrote:
> Job, your suggestion kicks a different goal than
> draft-ietf-grow-route-leak-detection-mitigation does.

Yes, I'm aware I am suggesting a different approach to solve the problem
of route leaks.

> 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 to you.
> That's what the ASN in the LC is for.

Right, so my proposal is that the neighbor does not (knowingly) leak 
routes to you, negating the need to additionally tag routes with more
information than "this route is intended for not-for-peers (Down Only)"

I believe the Section 6 'Only To Customer' Attribute described in
https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-15 can be
implemented using the existing well-known NOPEER Attribute.

Kind regards,

Job

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

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

[Wanghaibo (Rainsword)]

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) ; 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 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
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Jakob Heitz (jheitz)]

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

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