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

[Jakob Heitz (jheitz)]

Thanks Thomas.
I agree to remove the netflow reference.

Regards,
Jakob.

-Original Message-
From: thomas.g...@swisscom.com  
Sent: Sunday, March 7, 2021 10:20 PM
To: michael.mcbr...@futurewei.com; dmad...@kentik.com; jefftant.i...@gmail.com; 
rob...@raszuk.net; Jakob Heitz (jheitz) 
Cc: grow@ietf.org
Subject: RE: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt

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%2F&data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978557059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7TnSGyVp7p7innNedC5FT5ssVVOzrxYVyW6Tw5B0N90%3D&reserved=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-03&data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978567016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2mJb%2B6acbTyMKNdkVy1UdsJQdxnELMqyh52GQkPFgm8%3D&reserved=0
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-03&data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978567016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qIZAlo8WOj85dXLPqQu%2BMq6cILpMdAd%2Ffye2bWYNAac%3D&reserved=0

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: Wangh

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

[Jakob Heitz (jheitz)]

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  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: 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: Jo

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

[Wanghaibo (Rainsword)]

Hi Thomas,

   Yes,  it's clear.

Regards,
Haibo


--
王海波 Wang Haibo
Mobile: +86-13621091983
Email: rainsword.w...@huawei.com
发件人：Thomas.Graf 
收件人：Wanghaibo (Rainsword) ;robert 
;jtk 
抄 送：grow 
时 间：2021-03-11 21:00:05
主 题：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) 
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

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 t

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