Dear working group, Please find attached the draft minutes for the wg meeting during RIPE 45. There are certain areas that would benefit from commentary, particularly by the people involved in the conversations. Comments are appreciated. Regards, Joao Damas, ISC Routing-wg co-chair RIPE 45, Barcelona Routing Working Group Session 13-May-2003 Minutes Chair: Joachim Schmitz (Joachim395-RIPE) Scribe: Arife Vural (AC10172-RIPE) Participants: ?? Joachim Schmitz (JS) welcomed us all to the meeting and declared it open. The participant's list was then handed out by the chair and Arife Vural from RIPE-NCC volunteered to take the minutes. JS reminded this session was recorded and kindly asked everyone who involved the discussion to step up to microphone and tell his/her name and the company name they work for. Web-cast URL, http://www.ripe.net/ripe/meetings/ripe-45/webcast.html Previous meeting notes were approved. This time Routing-WG was split up into two sessions. There was no comment on agenda. It was accepted. D. soBGP Deployment Considerations, Dave Cook. http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-routing- sobgp-ripe/ David Cook gave a presentation how to deploy soBGP with examples. DFK: What process needs to be in place to deploy this tool? Is the software available? David: We need backgorund eBGP session between router and server for certificate exchange and need to try this before deploying all over the network. It should be tried at least by using two ASes. DFK: It is more about process you put in your NOC even if you have peer ASes, additional operation work or work load. David: For managing keys there is extra work. Other than that, for managing the router there is not much extra work. It requires certain level of education and it does not need any hardware upgrade, as the router does not do encryption, you do not get extra CPU load. Andre: Is there any prototype available? David: No. DFK: What do you do if the router reboots? David: You can delay verification, first reboot then get all certificates. Henk: If you have a BGP session, does it still needs some interaction? David: Keys should be verified. Get certificates to be signed. Henk: 1 half of this room like to implement soBGP others like to implement BGP. What would be the solution? David: Single solution. C. What S-BBGP means for RIPE and RIPE Members, Steve Kent. URL, http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-routing- sbgp/ Steve Kent presented S-BGP, an extension to make available BGP protocol secure. This presentation was done remotely, through phone line, some parts were not clear. However, this session was recorded and can be re-played from the following URL, http://www.ripe.net/ripe/meetings/ripe-45/webcast.html Paul (APNIC): For having a practical implementation in Asia Pacific, this would require extra training. APNIC has a private web site to allow members to manage their AS numbers, also provide to their assignment certificate. Use the same tool or GUI. Is it interesting? Is there any implication derived from this? Steve: Some people say the hard part is the registration, for the ISP. I do not agree with this observation. RIRs have helped the members in the past. It may help to out-source signing. However, who is signing should be invisible. RIRs could take some of the responsibility. DFK: Time for a prefix to be routed, when you use sBGP, download from repository. 48 hours to turn-up a new prefix. Steve: After putting the data into repository, it would take 48 hours. Other than that it looks like normal BGP. DFK: I do not have an idea how long does it take just to provide feedback. When prefixes are announced from multiple ASes how to get feedback from operators. Anonymous: Private address space, does it also get the benefits of sBGP? Steve: Yes, it requires a work around. Wilfried: Concentrate on the implications on talks with this group of people. Steve: It needs to be discussed in the community, RIR, or IANA. They rely on these organisations. How and why do we trust them or try to find another organization. We should discuss this more consciously and concentrate on implications. JS suggested to continue the discussion on mailing list. B. Update on RPSLng Sponsorship, Larry Blunk. URL, http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-routing- rpslng-update/ Larry gave an update on RPSLng. Latest update would be sent to the mailing list and available on IETF page. Shane: Working on IRRtoolset. rtconfig is working. You can get a link from the RIPE site. Larry: Are you happy about the draft? Shane: Had no time to look at it, next week I will do. E. The Peering Game, Bill Norton URL, http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-routing- art-peering/ Bill Norton gave a presentation about what the motivation for peering and the possible peering policy, and tactics. Second slot =========== RIPE 45, Barcelona Routing Working Group Session 14-May-2003 Minutes Chair: Joachim Schmitz (Joachim395-RIPE) Scribe: Arife Vural (AC10172-RIPE) Participants: ?? Matthew reminded myAS tutorial, it would be in TTM session. Comment: Someone from AFNIC would like to discuss the policy for filtering /48. He asked whether there is any operational document about it. JS: You are free to offer a draft and state the problem on mailing list. B. A Day in the Life of a BGP Update in Cisco IOS, Philip Smith URL, http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-routing- bgp-update.pdf Philip Smith (PS) gave a presentation on how a BGP update is processed on a Cisco router. Question part, JS: Any idea about the convergence algorithm? PS: I'm not a programmer, I teach how BGP works, do not have any idea about the algorithm. Anonymous: Why would you delay the propagation of the route especially if you do a change and would like to make it known to outside. PS: Flexibility. C. A Day in the Life of a BGP Update in Juniper JunOS Presentations, Pedro Marques URL, http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-routing- pedro/ Pedro presented the JunOS implementation of BGP route advertisement interval. D. Experience with Delaying BGP Updates Registration, Christian Panigl. URL, http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-routing- bgpexp/ Christian Panigl (CP) presented the problems he has observed regarding BGP delays and convergence. Pedro: There was a bug in JunOS which could not recognize the duplicate updates. It was fixed release on R6. Randy: It is a known problem for specific releases of Cisco. 100 of duplicate announcements and if you put them together, it would be more interesting. E. Observed properties of BGP convergence, Olaf Maennel URL, http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-routing- bgp-convergence/ Olaf presented his and his colleagues' work about BGP convergence. Pedro: Excessive updates are the same or not? Olaf: Usually the same but sometimes community is different. JS: Did you look at the different RRC boxes? Olaf: All of the same. CP: Aggressive dampening, you mean algorithm or the parameters? Especially, about the attribute change is the related about the algorithm? Olaf: Did config on the box, in additional slides, it says the algorithm and time. CP: Which dampening parameters did you use? Olaf: Cisco defaults. CP: The ones in the RIPE document are not that aggressive. Randy: Gave a presentation (RIPE 43), route-dampening algorithm is a disaster, not time. An hour is not related. Olaf: Let's talk offline need more raised.