Looks like auto-complete in the recipient list meant that my message below went only to the sidr secretary.
Sorry about that. --Sandy Begin forwarded message: > From: Sandra Murphy <sa...@tislabs.com> > Subject: minutes and updated slides uploaded > Date: November 4, 2014 9:00:48 PM EST > To: SIDR Secretary <sidr-secret...@samweiler.com>, "i...@ietf.org wg" > <i...@ietf.org> > Cc: Sandra Murphy <sa...@tislabs.com> > > I uploaded minutes, with thanks to Sue Hares for taking the minutes. > > I made a few name spelling corrections. I added a comment where Sue had > recorded something I said that I did not recognize. Anyone else who > remembers that part of the conversation can clarify. > > There was one participant who introduced himself as Chris from Australia. > Neither Sue nor I were certain of Chris's last name. If anyone knows who > that might have been (I thought the last name might have been Weiren), could > you please let the chairs know? > > I made a few changes to the slides as noted in the meeting. I changed "Ie" > to "I.e.," on slide 11 to help those who thought it read "le", as in "less > than". I added the router keying draft to the list of documents, noted as > missing during the meeting. I deleted two spare slides at the end - more > colorful versions of previous slides. > > The minutes are copied below. > > If anyone has any comments or corrections, please do send them to the list. > > --Sandy > > > > Attendees > > · Susan Hares > · John Scudder > · Chris Morrow > · Sandy Murphy > · Chris from Australia, last name possibly “Weiren” > · William (Bill) Attwood > · Mike Baer > · Jeff Haas > · Jay Borkenhagen > · Alia Atlas > · Doug Montgomery > · Kotikalapudi Sriram > · Oliver Borchert > · Hyojeong Kim (RSVP'd but not certain was in attendance) > · Kambiz Agahian > > SIDR Meeting > > 10:05 Recording attempted but failed. > > Meeting intended to provide a little bit of background for the IDR folks who > will be asked to comment on the SIDR draft. This background provides the > necessary information for IDR participants to review the BGPSEC work. > > Slide presentation > > Questions after slide 10: > > · John: How large will these signatures be? > · Sandy: One of the drafts (algorithms), these certificates use ECDSA. > · Doug: We could send a note regarding how the BGPSEC impacts the normal > common RIB. Size of signatures and how this could related to common RIBs > · John: I’m asking how many bytes per ARC > · Sriram: 64 bytes (P256 curve) per AS > · John: This is contrasted to 4 per AS. > > Slide 11: > > · Sandy: We have done away with the AS Paths, and it is encoded in the > BGPSEC Attributes. Including the AS Path might confuse. We did not tunnel > the ASPath information as the 4 Byte AS does. There is an algorithm to > extract the valid ASPath from the BGP Sec AS Path. An implementation can > remove it from the BGP SecPath attribute upon reception. At the boundaries, > you must strip the BGPSEC Attributes. > > > > > > Slide 12: > > · [Chris W(?)]: Can you tell me how this will impact on global routing > system on carrying the signatures? > · [Sandy]: Rephrasing the question if you send one NLRI per update, how > does this expand the space requirement? Secondly, how much does the > signature add per ASpath. > · Doug M: The RIB modeling dealt with the signature size issues. We’ve > presented these details at a SIDR meeting. > · Sriram: We also looked at how many more updates how many more updates > will you have. When we examined this 4 years ago, there were an average 3.8 > NLRI per attribute path. Therefore you will grow by 4 times. > · Jeff: In the grand scheme of input, I agree that the data flow of > will grow by 4 times per update. However, the major costs will be processing > time and internal space sharing due to the lack of caching of the ASPath > related attributes. > · Sandy: Can you tell us why it is impossible to share the AS Path. > · Jeff: Most attributes tend to share objects as shared objects (AS, > next-hop, etc). The problem is that the AS-Path will not be able to be shared. > · Sandy: I see that the signature is not sharable. > · Jeff: In implementation, these tend to be grouped together. > · Doug: If you are caching at the attribute level. Then the > path-attribute would be unique for each attribute that is signed. > · Sandy: I do understand that the signatures are unique. If your code is > caching attributes, this should not prevent as_path sharing? > · Jeff: You need to store the signature as an attribute of the path > attributes. > · Sandy: It should not hamper > · Jeff: Implementations may need to change our cache. The processing of > the AS path is big part of the caching methodology. Therefore the caching > will be higher than you consider in your estimates of per route estimates. > · Sandy: Should we consider this input? > · Jeff: The point is that this will impact the routes > · John: People should think about what this means for their attribute > list. > > Second question stream: > > · Sandy; Does this impact the route server functions? > · John: There are two document: Route serve ops draft is a grow draft – > it is in or past IETF LC. The Route Server is an IDR draft, and it is not yet > ready for WG LC. > · Sandy: I was not certain if the route-server changes were in-spec or > out-spec for BGP of the information. > A Router-server operates as a collection point for routes at an exchange > point (IXP) from all peers. The route-server removes its own AS, and the > path length does not change. > · John: For BGPSec, the route server is visible as regarding signatures, > but invisible regarding the path length. > · Sandy: The route server sends ASPATH with a key encrypted. (From > Sandy: I am not sure what I said here. The route server sends a BGPSEC > attribute with itself included, but is flagged as a route server, so the > ASPATH path length does not increase and the route server AS would not appear > in the extracted ASPATH) > · John: People who care about Route Server scalability should review > previous slides. > > Slide 13: No additional questions > > Slide 14: 4 byte AS numbers are assumed. > > Slide 18: > > · Kambiz: Will BGPSEC change the decision process? > · Sandy: The results of the BGPSEC process will be available for the > decision process. The BGPSEC process will mark whether this is valid or not. > This is then left to the BGP decision process. These are similar to the > BGP-origin state. One example one operator adds +100 from preferences valid > and subtracts 50 for the invalid state. There has been discussion that under > a heavy load you send all routes. > · Kambiz: Can this be done on a private AS.? > · Sandy: RPKI is for global and public resources. The certificates are > all related via the trust hierarchy. You can set-up a local RPKI to handle > local address space (E.g. RFC1918 space) and then use BGPSEC path attributes. > · Sriram: We do have fairly detailed RIB-size modeling slide for normal > routers and route-reflectors (Quebec Meeting). > · Sandy: I think that your route-reflector mode would be similar to > route-servers. > · John: Sriram did you have the same information for CPU load – Would > you include that? > · Sriram: yes we do. We assumed general purpose processor (Sandy bridge, > KVM process) on how the BGPSEC mode. > · Sandy: Can you bring this up in the joint meeting. > · Jay Borkenhagen: on slide 18, partial deployment two clouds of > BGPSEC do not know of each other. What happens if AS456 is partially > deployed? I think that the only thing that matters is that there is a pathway > through AS456 can be connected. > · Sandy: This is an interesting point. I do not know how operators will > deploy BGPSEC. Do you think it will cause a problem? > · Jeff: This feature will be partial islands of secured information. > You will have an AS will be half secure and half secure. It is likely that > the security aspects of the BGP information will impact deployment. This may > increase tunneling between ISPS. This may impact forwarding. > · Sandy: This forwarding can be done via tunnels or careful next-hop > handling. > · Sandy: I’m not sure what happens when one routing policy is not > contiguous through an AS. > · Chris: Some of this operations process and some of this is > implementation specific. comments. > > > > Final comments: John: We have an open agenda for BGPSEC. Please send in > agenda suggestions to both the IDR and the SIDR chairs. > > Meeting ended at 11:25 am. >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
