Skip to main content

You're viewing an archived page. It is no longer being updated.


RIPE Meeting:


Working Group:




Revision Number:


RIPE 45, Barcelona
Routing Working Group Session
13-May-2003 Minutes

Chair: Joachim Schmitz (Joachim395-RIPE)
Scribe: Arife Vural (AC10172-RIPE)
Participants: ??

Joachim Schmitz 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,

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.

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

David: We need feedback eBGP session between router and server and for
certificate exchange and try this before deploy 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: Manage keys, other than that as far as managing the router there
is not much work. It requires certain level of education and it does not
need any hardware upgrade, do not need to encryption, you do not need to
extra CPU load.

Andre: Is there any prototype available?
David: It has been worked done by once.

DFK: What do you do in case of reboot the route?
David: You can delay, first reboot get all certificate.

Henk: Have BGP session but still needs some interaction?
David: Keys should be verified. Get two certificate 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.

Pedro: You do not want to put the sign after you receive comment.
Dave: Split up the certificate, verification and encryption.

C. What S-BBGP means for RIPE and RIPE Members, Steve Kent.


Steve Kent presented S-BGP an extension to make available BGP protocol secure.
This presentation was done through phone line, some parts were not clear.
However, this session was recorded and can be seen from the following URL,

Paul (APNIC): Having practical implementation ASIA Pacific, it would require
extra training. Private web site to manage their AS numbers, also provide to
their assignment certificate. Use the same tool or GUI. Is it interesting
whether any implication about it?

Steve: Hard part of registration in that regard, ISP. I do not agree about
this observation. RIRs help the members to help in the past, help to
out-source signing. However, this would be invisible who should be doing what.
RIRs could take the 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 put the data into repository, it would take 48 hours looks like
the normal BGP.

DFK: I do not have an idea how long does it take just like to provide
feedback, prefixes are announced multiple ASes like to get feedback from

Anonymous: Private address space, does it also get the benefits of sBGP?
Steve: Yes, it requires a work around.

Wilfred: Concentrate on the implication on talk with the group of people.
Steve: It need to be discussed in the community, RIR, or IANA. They rely on
these organizations. How and why do we trust them or try to find another
organization. We should discuss this more consciously and concentrate on

JS suggested to continue the discussion on mailing list.

B. Update on RPSLng Sponsorship, Larry Blunk.


Larry gave an update on RPSLng. Latest update would be sent to the mailing
list and available on IETF page.

Shane: IRRtoolset, rtconfig it has been working. You can get a link from RIPE
Larry: Are you happy about the draft?
Shane: Have not time to look at it, next week I will do.

E. The Peering Game, Bill Norton


Bill Norton gave a presentation about what the motivation for peering
and the possible peering policy, and tactics.

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: A guy from AFNIC liked to discuss for the policy to filter
/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

B. A Day in the Life of a BGP Update in Cisco IOS, Philip Smith.


Philip Smith gave a presentation how a BGP update is processed on a Cisco

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 some would delay to propagate the route especially if you do
a change and like to make known outside.
PS: Flexibility.

C. A Day in the Life of a BGP Update in Juniper JunOS Presentations, Pedro


Pedro presented JunOS implementation of BGP route advertisement interval.

D. Experience with Delaying BGP Updates Registration, Christian Panigl.


Christian Panigl presented the problems he has observed about 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 release 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


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 are the 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: RIPE is not that aggressive.

Randy: Give a presentation, route-dampening algorithm is a disaster, not
time. An hour is not related.

Olaf: Let's talk offline need more raised.