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 [email protected] https://www.ietf.org/mailman/listinfo/sidr
