Minutes routing wg RIPE 45 (barcelona)

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.