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

[Jakob Heitz (jheitz)]

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 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)]

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://tools.ietf.org/html/rfc7413#section-6

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 queued during the re-establish time window and updates 
would be locally generated for the re-establish time window once the BMP 
session is re-established. Correct? 

Regarding the proposal of sequence numbers. It would imply that the BMP Common 
Header needs to be extended. Here I like to hear your thoughts why a session 
identifier is not enough and what benefit a sequence number would bring on the 
application layer when we already have sequence numbers on the TCP transport 
session. As you might recall, one of the objectives of the BMP hackathon was to 
detect loss of BMP messages.

Also many thanks to Jeff about the feedback in regards to BGP NSR. I agree that 
solving the goal on a TCP transport layer would prevent implications onto 
BGP/BMP application in such condition when BGP process is being restarted.

Best wishes
Thomas

-Original Message-
From: Jakob Heitz (jheitz)  
Sent: Wednesday, March 10, 2021 4:09 AM
To: Job Snijders 
Cc: 

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

[Thomas.Graf]

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 
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 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 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 queued during the re-establish time window and updates 
would be locally generated for the re-establish time window once the BMP 
session is re-established. Correct? 

Regarding the proposal of sequence numbers. It would imply that the BMP Common 
Header needs to be extended. Here I like to hear your thoughts why a session 
identifier is not enough and what benefit a sequence number would bring on the 
application layer when we already have sequence numbers on the TCP transport 
session. As you might recall, one of the objectives of the BMP hackathon was to 
detect loss of BMP messages.

Also many thanks to Jeff about the feedback in regards to BGP NSR. I agree that 
solving the goal on a TCP transport layer would prevent implications onto 
BGP/BMP application in such condition when BGP process is being restarted.

Best wishes
Thomas

-Original Message-
From: Jakob Heitz (jheitz)  
Sent: Wednesday, March 10, 2021 4:09 AM
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?

>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.

Regards,
Jakob.

-Original Message-
From: Job Snijders 
Sent: Tuesday, March 9, 2021 4:50 PM
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 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 

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

[Jakob Heitz (jheitz)]

>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.

Regards,
Jakob.

-Original Message-
From: Job Snijders  
Sent: Tuesday, March 9, 2021 4:50 PM
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 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 more than 'nothing'... :-)

As TCP_FAST_OPEN already is a published RFC, existing BMP clients &
servers are free and able to opportunistically use TCP Fast Open. For
the sake of conversation I'll consider TCP_FAST_OPEN out-of-scope for
BMP and GROW in the rest this email.

BMP - one way protocol on reliable transport: are successive RSTs a signal?
===

In a one-way protocol where the recipient essentially is limited to 'TCP
ACK' and 'TCP RST' as response options, would it perhaps make sense to
outline a BMP protocol where both BMP client and BMP server assume more
delibrate intent from the timing of TCP reconnection events?

If the BMP client includes a 'session_id' message as its first message
towards the BMP server, then when the client loses its connection to the
BMP server, it can continue buffering messages destined for that
specific BMP server linked to the previously sent 'session_id'.

Then, if the BMP client manages to reconnect to the BMP server within 60
seconds, the client will flush all buffered messages associated with the
session_id also communicated in prior BMP sessions.

However if the BMP server closes the TCP session within that 60 seconds
buffer window, a subsequent successful reconnection would result
in the BGP client sending a new session_id followed by all 'Peer Up'
messages, because the previous BMP session (and buffer) were
terminated.

The BMP server can immediately disconnect when it receives a BMP
session_id it does not recognize (by issuing a TCP RST). When a BMP
client receives the 'second' TCP RST within 60 seconds, it can choose to
reconnect following an linear backoff model and for the duration of wait
periods exceeding 1 minute not bother buffering for 'unreachable' BMP
servers.

The heuristic is that the BMP client considers the BMP session
'resumed', iff a BMP server doesn't disconnect within 60 seconds.

The BMP server can use the session_id as input to its decision process
whether to disconnect within 60 seconds or not.

Blink once the BMP session survives... blink twice, game over!

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

[Jakob Heitz (jheitz)]

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

Regards,
Jakob.

-Original Message-
From: GROW  On Behalf Of Job Snijders
Sent: Tuesday, March 9, 2021 11:59 AM
To: grow@ietf.org
Subject: Re: [GROW] An alternative approach to 
draft-ietf-grow-route-leak-detection-mitigation

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
Community". Only requiring a single community opens up the path to use
existing well-known RFC 1997 community as signal between BGP nodes.

The section 4.1 leak mitigation algorithm could be revised such that if
a route path present in the Loc-RIB is considered the best path and
eligible for export to EBGP neighbors, an additional verification step
is performed.

The sender could check whether a 'DO community' is present on the route
in the Loc-RIB, and if the to-be-exported-to EBGP neigbhor is configured
as a 'lateral Peer' or as 'Provider', the route is rejected in the PIB
(Policy Information Base) and thus will not be present in Adj-RIB-Out -
thus blocking a leak from happening. This places the route leak
mitigation solution one step earlier in the BGP 'supply chain' process.

There is an existing well-known BGP Community known as 'NOPEER
Community for BGP Route Scope Control', described in RFC 3765.

Similar to how the mitigation does not truly differentiate between
'Providers' and 'Lateral Peers' (if one considers routing policy puzzles
often can be solved through multiple different combinations of policy in
either of EBGP-IN, IBGP-OUT, IBGP-IN, EBGP-OUT.

The recommendation then simplifies to the following three steps:

1/ Recommend network operators to never strip the RFC 3765 Community
   upon receiving a BGP route from either an IBGP or EBGP neighbor.

2/ Recommend network operators to manually configure (or have BGP OPENv2
   speakers automatically) *add* the NOPEER Community (if it wasn't
   already present) to route paths received from a Lateral Peer or
   Provider. Then proceed with whatever Import Policy applies.

3/ Recommend network operators (or have BGP OPENv2 speakers
   automatically) block routes which contain the NOPEER Community from
   propagating towards EBGP neighbor marked as 'Lateral Peer' or
   'Provider'. The procedure stops.

4/ If the EBGP neighbor is *not* a 'Lateral Peer' or 'Provider', the
   route MAY be added to the Adj-RIB-Out specific to that EBGP neighbor.
   The NOPEER community is not removed (see step 1).

As Nick Hilliard pointed out earlier in this thread, there might be
business requirements which require the operator to override the
autnomous system's default policy, but as the NOPEER Community happens
to be 'just a BGP community', operators can do as they wish with the
received routing information. A case can be made that operators - by
default - would benefit from accepting the NOPEER community and based on
its presence prevent routes from propagating further towards EBGP
neighbors in the Peer/Provider class.

The above proposal is slightly different than the implementation
requirements stemming from honoring GRACEFUL_SHUTDOWN (where the
intention is for the inter-domain signal to be honored on EBGP-IN), the
NOPEER community essentially is best honored in EBGP-OUT policies.

Promoting inter-domain use of the NOPEER community by outlining how
correctly adding & scoping based on this community one can help mitigate
BGP route leaks. The NOPEER community being readily available in most
deployed BGP speakers for any operator wishing to use the mitigation
mechanism, this might make for a compelling argument.

In short 'Down Only' is equivalent to 'Not towards Peers & Providers:

  - in EBGP-IN set NOPEER on routes received from Peers/Providers
  - in EBGP-OUT block NOPEER routes from being announced to Peers/Providers

The above appears incrementally deployable, and compliant with the
specification of NOPEER, and can be promoted through Network Operator
Groups by converting draft-ietf-idr-route-leak-detection-mitigation to
target Best Current Practise (BCP).

Kind regards,

Job

___
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?

[Job Snijders]

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 more than 'nothing'... :-)

As TCP_FAST_OPEN already is a published RFC, existing BMP clients &
servers are free and able to opportunistically use TCP Fast Open. For
the sake of conversation I'll consider TCP_FAST_OPEN out-of-scope for
BMP and GROW in the rest this email.

BMP - one way protocol on reliable transport: are successive RSTs a signal?
===

In a one-way protocol where the recipient essentially is limited to 'TCP
ACK' and 'TCP RST' as response options, would it perhaps make sense to
outline a BMP protocol where both BMP client and BMP server assume more
delibrate intent from the timing of TCP reconnection events?

If the BMP client includes a 'session_id' message as its first message
towards the BMP server, then when the client loses its connection to the
BMP server, it can continue buffering messages destined for that
specific BMP server linked to the previously sent 'session_id'.

Then, if the BMP client manages to reconnect to the BMP server within 60
seconds, the client will flush all buffered messages associated with the
session_id also communicated in prior BMP sessions.

However if the BMP server closes the TCP session within that 60 seconds
buffer window, a subsequent successful reconnection would result
in the BGP client sending a new session_id followed by all 'Peer Up'
messages, because the previous BMP session (and buffer) were
terminated.

The BMP server can immediately disconnect when it receives a BMP
session_id it does not recognize (by issuing a TCP RST). When a BMP
client receives the 'second' TCP RST within 60 seconds, it can choose to
reconnect following an linear backoff model and for the duration of wait
periods exceeding 1 minute not bother buffering for 'unreachable' BMP
servers.

The heuristic is that the BMP client considers the BMP session
'resumed', iff a BMP server doesn't disconnect within 60 seconds.

The BMP server can use the session_id as input to its decision process
whether to disconnect within 60 seconds or not.

Blink once the BMP session survives... blink twice, game over!

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?

[Robert Raszuk]

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

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

[John Kristoff]

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

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

[Jakob Heitz (jheitz)]

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 be limited. If the window exceeds its maximum, then
it would still be a hard reset.
If we do this, I advocate for a 64 bit serial number.

Regards,
Jakob.

-Original Message-
From: GROW  On Behalf Of Job Snijders
Sent: Tuesday, March 9, 2021 4:26 AM
To: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: [GROW] is TCP the right layer for BMP session resumption?

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 re-transmit
information the client 'already knows'.

I informally polled some people with the question 'thoughts on
TCP_FAST_OPEN? It was brought to my attention a userspace server daemon
is not aware whether a TCP connection was set up with FAST_OPEN or not.

Furthermore, TCP_FAST_OPEN's primary use case appears to be to reduce
the burden of TCP Three-way handshake on 'short-lived' connections, and
was *not* designed for general purpose 'session resumption'.

RFC 7413 appears to suggest TCP_FAST_OPEN can be used to jam a 'small'
message (like a HTTP 302 response to a GET request) into the SYN-ACK,
whereas BMP Session Resumption is not about 'a quick and small reply',
but rather "previously there was lots of data, are you aware of that
previous data? By the way, what will follow next is lots and lots of
more data!".

TCP_FAST_OPEN appears a poor fit for the objective of BMP Seamless
Session Resumption.

If not TCP_FAST_OPEN, then what?


Perhaps inspiration can be taken from RFC 6810's RPKI-To-Router (RTR)
protocol which leverages a "Session ID" and "Serial Number" to allow
efficient (even transport-protocol agnostic!) session resumption.

This same style of session resumption mechanism can also be found in the
RPKI Repository Delta Protocol (RRDP).

Perhaps BMP would benefit from a similar resumption mechanism to reduce
the burden on servers & clients?

I welcome insights and feedback from the working group.

Kind regards,

Job

___
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] route leak solution and IANA large community register

[Job Snijders]

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).

My recommendation would be to let both efforts proceed independently, 
as it probably would be good to continue discussion on whether
draft-ietf-grow-route-leak-detection-mitigation's objective can only be
solved with Large Communities; and separately whether in the large
communities 'space' a segment of the 'spectrum' should be set aside for
future well-known through standards documented signaling.

Kind regards,

Job
GROW Working Group Chair

On Tue, Mar 09, 2021 at 12:30:14PM -0500, Susan Hares wrote:
> 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] 
> Sent: Sunday, March 7, 2021 6:26 PM
> To: Christopher Morrow; Job Snijders
> Cc: grow-cha...@ietf.org; GROW WG; idr-cha...@ietf.org; Susan Hares;
> a.e.azi...@gmail.com
> Subject: route leak solution and IANA large community register
> 
> I have a question for the GROW Chairs and anyone who can help.
> 
> There are these two drafts:
> Methods for Detection and Mitigation of BGP Route Leaks
> https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-
> 04
> 
> BGP Well Known Large Community
> https://tools.ietf.org/html/draft-heitz-idr-wklc-01
> 
> The first is in a mature state in GROW and the second is in a
> pre-adoption-call state in IDR. The first draft requests IANA for an
> allocation in well-known Large Community (WKLC) registry but no such IANA
> registry exists yet. The second draft (in IDR) is making an effort to
> specify and request the creation of an IANA WKLC registry. This work seems
> to be going slow in IDR -- partly the authors are responsible (including
> me).  
> 
> Question: Is the creation of an IANA Large Community registry a prerequisite
> for a WGLC on the first one (in GROW)? Or, it is possible to have WGLC
> requested/completed on the first one and then wait for the creation of the
> IANA LC registry?
> 
> Thanks.
> 
> Sriram  
> 
> 
> 
> ___
> 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] An alternative approach to draft-ietf-grow-route-leak-detection-mitigation

[Job Snijders]

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
Community". Only requiring a single community opens up the path to use
existing well-known RFC 1997 community as signal between BGP nodes.

The section 4.1 leak mitigation algorithm could be revised such that if
a route path present in the Loc-RIB is considered the best path and
eligible for export to EBGP neighbors, an additional verification step
is performed.

The sender could check whether a 'DO community' is present on the route
in the Loc-RIB, and if the to-be-exported-to EBGP neigbhor is configured
as a 'lateral Peer' or as 'Provider', the route is rejected in the PIB
(Policy Information Base) and thus will not be present in Adj-RIB-Out -
thus blocking a leak from happening. This places the route leak
mitigation solution one step earlier in the BGP 'supply chain' process.

There is an existing well-known BGP Community known as 'NOPEER
Community for BGP Route Scope Control', described in RFC 3765.

Similar to how the mitigation does not truly differentiate between
'Providers' and 'Lateral Peers' (if one considers routing policy puzzles
often can be solved through multiple different combinations of policy in
either of EBGP-IN, IBGP-OUT, IBGP-IN, EBGP-OUT.

The recommendation then simplifies to the following three steps:

1/ Recommend network operators to never strip the RFC 3765 Community
   upon receiving a BGP route from either an IBGP or EBGP neighbor.

2/ Recommend network operators to manually configure (or have BGP OPENv2
   speakers automatically) *add* the NOPEER Community (if it wasn't
   already present) to route paths received from a Lateral Peer or
   Provider. Then proceed with whatever Import Policy applies.

3/ Recommend network operators (or have BGP OPENv2 speakers
   automatically) block routes which contain the NOPEER Community from
   propagating towards EBGP neighbor marked as 'Lateral Peer' or
   'Provider'. The procedure stops.

4/ If the EBGP neighbor is *not* a 'Lateral Peer' or 'Provider', the
   route MAY be added to the Adj-RIB-Out specific to that EBGP neighbor.
   The NOPEER community is not removed (see step 1).

As Nick Hilliard pointed out earlier in this thread, there might be
business requirements which require the operator to override the
autnomous system's default policy, but as the NOPEER Community happens
to be 'just a BGP community', operators can do as they wish with the
received routing information. A case can be made that operators - by
default - would benefit from accepting the NOPEER community and based on
its presence prevent routes from propagating further towards EBGP
neighbors in the Peer/Provider class.

The above proposal is slightly different than the implementation
requirements stemming from honoring GRACEFUL_SHUTDOWN (where the
intention is for the inter-domain signal to be honored on EBGP-IN), the
NOPEER community essentially is best honored in EBGP-OUT policies.

Promoting inter-domain use of the NOPEER community by outlining how
correctly adding & scoping based on this community one can help mitigate
BGP route leaks. The NOPEER community being readily available in most
deployed BGP speakers for any operator wishing to use the mitigation
mechanism, this might make for a compelling argument.

In short 'Down Only' is equivalent to 'Not towards Peers & Providers:

  - in EBGP-IN set NOPEER on routes received from Peers/Providers
  - in EBGP-OUT block NOPEER routes from being announced to Peers/Providers

The above appears incrementally deployable, and compliant with the
specification of NOPEER, and can be promoted through Network Operator
Groups by converting draft-ietf-idr-route-leak-detection-mitigation to
target Best Current Practise (BCP).

Kind regards,

Job

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

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

[Nick Hilliard]

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 communities are also array's.

Thomas,

I agree in theory that this would be a nice idea but I'm concerned about 
the performance impact it might have on ipfix / netflow implementations. 
 Normal operating cases would include situations where the as path 
changed during the lifetime of the flow (what do you do here? ignore the 
change?  update the cache and dump the original path? store multiple 
flows?), to lookup performance characteristics (AS path can be very 
long).  It would be advisable to solicit input from equipment 
manufacturers before rushing ahead with something like this, because 
highly performant netflow / ipfix is generally handled in hardware, and 
there may be limited options in terms of flexibility.


Nick

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

Re: [GROW] route leak solution and IANA large community register

[Susan Hares]

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] 
Sent: Sunday, March 7, 2021 6:26 PM
To: Christopher Morrow; Job Snijders
Cc: grow-cha...@ietf.org; GROW WG; idr-cha...@ietf.org; Susan Hares;
a.e.azi...@gmail.com
Subject: route leak solution and IANA large community register

I have a question for the GROW Chairs and anyone who can help.

There are these two drafts:
Methods for Detection and Mitigation of BGP Route Leaks
https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-
04

BGP Well Known Large Community
https://tools.ietf.org/html/draft-heitz-idr-wklc-01

The first is in a mature state in GROW and the second is in a
pre-adoption-call state in IDR. The first draft requests IANA for an
allocation in well-known Large Community (WKLC) registry but no such IANA
registry exists yet. The second draft (in IDR) is making an effort to
specify and request the creation of an IANA WKLC registry. This work seems
to be going slow in IDR -- partly the authors are responsible (including
me).  

Question: Is the creation of an IANA Large Community registry a prerequisite
for a WGLC on the first one (in GROW)? Or, it is possible to have WGLC
requested/completed on the first one and then wait for the creation of the
IANA LC registry?

Thanks.

Sriram  



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

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

[Job Snijders]

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 re-transmit
information the client 'already knows'.

I informally polled some people with the question 'thoughts on
TCP_FAST_OPEN? It was brought to my attention a userspace server daemon
is not aware whether a TCP connection was set up with FAST_OPEN or not.

Furthermore, TCP_FAST_OPEN's primary use case appears to be to reduce
the burden of TCP Three-way handshake on 'short-lived' connections, and
was *not* designed for general purpose 'session resumption'.

RFC 7413 appears to suggest TCP_FAST_OPEN can be used to jam a 'small'
message (like a HTTP 302 response to a GET request) into the SYN-ACK,
whereas BMP Session Resumption is not about 'a quick and small reply',
but rather "previously there was lots of data, are you aware of that
previous data? By the way, what will follow next is lots and lots of
more data!".

TCP_FAST_OPEN appears a poor fit for the objective of BMP Seamless
Session Resumption.

If not TCP_FAST_OPEN, then what?


Perhaps inspiration can be taken from RFC 6810's RPKI-To-Router (RTR)
protocol which leverages a "Session ID" and "Serial Number" to allow
efficient (even transport-protocol agnostic!) session resumption.

This same style of session resumption mechanism can also be found in the
RPKI Repository Delta Protocol (RRDP).

Perhaps BMP would benefit from a similar resumption mechanism to reduce
the burden on servers & clients?

I welcome insights and feedback from the working group.

Kind regards,

Job

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