Re: request for agenda items for interim meeting 6 Jun

In addition to the items suggested so far, I think we should also spend some time on
performance considerations and resource sizing requirements for a BGPSEC router.
 
Some of the performance and resource sizing questions are:

Q1: What is an acceptable convergence time after a BGPSEC peering session reset?
(See Wes George's question (in Paris) and some thoughts shared by Geoff with me below.)
 
Q2: What degree of peering is reasonable to assume for various router scenarios
such as Provider Edge (PE), Route Reflector (RR), Route Server (RS), etc.?
(The convergence time and the RIB size would naturally depend on the number
of BGPSEC peering sessions that the PE, RR, or RS needs to handle.)

Q3: Is there any difference in how the RIBs (RIB-in, RIB-out, etc.) are managed at a
RR or RS as compared to how it is done at the PE router?

Q4: Is a large percentage of the clients of an RS consists of stub routers, i.e.,
they do not require signed updates in receive direction?

I did get some inputs on PE and RR peering degrees from a large Tier 1 ISP
and used them in my RIB modeling work earlier. It would be good to revisit this
and try to get a good handle on such measurements for PE, RR, and also RS.
See slide 4 of this study (I did about a year ago) for the measurement
numbers I got from the large Tier 1 ISP.

http://www.nist.gov/itl/antd/upload/BGPSEC_RIB_Estimation.pdf 

They shared the numbers for their typical PE and RR.
(They actually did not share # peerings exactly but simply the measurements
of the # total paths and the # unique prefixes at their PE and their RR.)  

I have the following notes to tease a discussion based on some earlier
questions/conversations at the Paris meeting:

Wes George (question at the Paris SIDR meeting): Are the 30 sec and 70 sec type
of numbers (for convergence after BGPSEC peering reset) small enough?  May not be.
(This question followed my presentation:
http://www.ietf.org/proceedings/83/slides/slides-83-sidr-7.pdf )

As a counter point, Geoff shared the following with me during a coffee break (in Paris):
[Note: I think I am stating the intent of his comments correctly; I request Geoff to
jump in if this does not capture accurately enough what he shared with me.]
The way to think about those delays is that the data packets
would traverse a possibly suboptimal path for the period of T seconds or minutes --
whatever the BGPSEC re-convergence delay number is --
but they are not dropped on the floor. That is a property of BGP.
The data packets may incur a small extra delay due to the suboptimal path
for that (BGPSEC re-convergence) period, and most of the time
users don't even notice that extra data packet delay (if any) at the application layer.

Sriram

_______________________________________________
sidr mailing list
sidr@...
https://www.ietf.org/mailman/listinfo/sidr