Archives

Is is
Cab /PURT consortium.

/KRUP is Casper consortium.

Better better


RANDY BUSH:
Pat pat
/SHREBG /SHREBG

/TPRAPB /TPRAPB

/TKPW?BT
Coverage
/KOFRPBLGS
Coverage /KOFRPBLGDZ ever /KOFRPBLGDZ /*R /KOFRPBLGZ
NaMeX
Within a
/TKAG
Nap tech
Rink
T Nap
/AOERPBT
/STPHAUT /HRUS MED rain yen exchange point.
NaMeX

Owe

ROB BLOKZJIL: Good afternoon everybody. I think it's about time we start. So we will ?? at the back you will either find a seat or keep standing, but stop talking.

Right, this is RIPE 61, the second time we are in Rome, I am Rob blocks I will, I am the Chairman of RIPE, and I extend a very warm welcome to you all in Rome at this RIPE meeting.

As I said, it's the second RIPE meeting in Rome, the first one was in 1995 with about 110 participants. So we have grown, but with we know that. I have a few items I want to communicate with you, but the first one it's something that occurred to me yesterday. In a sense this is a very historical RIPE meeting. It is probably the last RIPE meeting where in the environment of IPv4 address space, we have in the classical environment where the IANA pool is not empty we do business as usual. For those of you who have been following the transfer of address space out offey IANA to the RIRs, you may have notice that had there is not much left, and I think we can all agree that at the next RIPE meeting, we are in a new situation where the source of the free pool of IPv4 address space has run?out, dry, over. So, for those of you who still want to initiate new IPv4 allocation policies, I think you have to do a very, very, very quick job if you think it is still useful.

Right. We have a busy week ahead with an interesting couple of Plenary Sessions,ing withes. We have demonstrationings of various services in the lobby. And we have RIPE BoF, all of that I'll come back to.

There are a couple of practicalities. The meeting area in this hotel is split into two floors. You are now on the ground level and there is one level down where the other meeting room is situated and a couple of other rooms like the terminal room are placed. And I can tell you, if you are looking for a quiet corner to sit and either stair at your screen or have a quiet talk with your friends and colleagues, there are ample quiet corners with cosy chairs downstairs as well. So if you think the lobby is over crowd and you can't find a seat, go downstairs.

Lunch, I think you all found out where we do our lunches. Socials: We have a couple of socials planned this week as usual. The registration information you got your packet has detailed marching orders for all the socials. We have a dinner, as usual, a RIPE dinner on Thursday, if you don't have a ticket, you can still go to the registration desk and buy a ticket.

If you have any problems with your laptop or any other technical support you need, there is the trustworthy RIPE NCC technical team running around and you can recognise them their badge /R?S blue, so blue badges, in case you need technical support.

You have found out probably that on the backside there is a little note in the corner explaining what the password for the wireless network is this time. We do have a password protected wireless that has to do with Italian telecommunications law requirements. Also it's maybe nice to protect networks.

You can also register yourselves at the table next to the registration desk if you are planning to wander around Rome with IP enabled wireless equipment, iPods, iPods and what over pads, pods and stuff including laptops. You can register yourself as a user for all the public Wi?Fi spots in Rome. Again, you have to register because of the same requirements of the /TAL yen telecommunications laws.

RIPE 61, on Saturday afternoon, we had 430 people registered already, and I think we can conclude that a fair slice of them are in the room already today.

So, there are two things left I want to do. In the first place I want to give the floor to I think Brian is going to say a few words to ?? as regards something new in our programme, I have mentioned it already, you will see in your programme you will see there is a RIPE 61 BoF on Thursday and if I can ask Brian to explain, in a few minutes, what that is about. Brian Brian thanks, I shall be brief. There have been a number of discussions over the last year or so, about RIPE meeting evolution and as this slide has been up for the last ten minutes, I should have to say not a word, you have all seen everything that's there. There is a small group of us all Working Group Chairs who got involved in this and are trying to work words to receiving feedback and as you say evolving the meetings. There is myself Brian, there is Andy, injury /OU, by /SKWRAL, christian and Jim, so the six of us are, this is our focus now to try and receive that feedback and improve things for everyone.

The first piece we had on this was the picks security tutorial this morning. If you were at that tutorial and you wish to fill in the survey, the feedback on that, that's the URL for it there. And you are more than welcome to fill that in if you haven't already. We also as /ROP said the BoF session, the boards of a feather session and for those of you who have not encountered these, it's an informal discussion to discuss a topic which is arrived at by CONS suss. We haven't actually made the decision about what will be the main focus of the BoF. It's on Thursday evening so there is a couple of days to decide. If you wish to have input into that, if you go to the meeting pages, RIPE meeting pages and go to the BoF section, that will take you through to the RIPE Labs forum where you can put your input in for what you'd like to have discussed. It's taking place at 17:45 in the main room and the idea is that you'll have a /PWRAOET err after the end of the session that day and /TH*EPB we'll all be done in time to go to the RIPE dinner that evening.

We are, as I say we are? General gathering feedback on the meeting conten and structure. Everyone is welcome to comment. We are going to have a number of ways of doing that to be released over time and there'll be tried to the various RIPE mailings lists. One of them is just to come and talk to /TPHEUF us. I am going to be cruel now. If the /TPAOEF people are in the room. If they'd just like to stand up for a moment. So, these are the people you should talk to. And we'll all be at the newcomers drinks tomorrow evening. So you can grab us then as well. And that's pretty much that. Thank you very much.

Thank you Brian. Those of you who are here not for the first time, you may have noticed an empty spot on the wall there where you might have expected the realtime scribe. It's a pity, but it's not working yet. The scribing is working you but the projection is not because we had some difficulties, a delay of equipment deliveries. So we hope very soon to have the full service there available.

Next, we are meeting here in Rome and we have a lot of help from our local hosts NaMeX and Casper and it is with great pleasure I want to introduce to you mar eats owe /TKPWRETey from NaMeX who wants to say a few words, and though usually we do this on Friday morning after we are sure that everything went well, I think we can already conclude that so far so good and thank you.
(Applause)

SPEAKER: So thank you very much, and welcome to all of you. I'd like to welcome you here in RIPE meeting in Rome especially. I want to first thanks the RIPE meeting, the RIPE staff that give us the opportunity to host this meeting: Just a few words about the host. But first, let me thank those who helped us to host this meeting. First of all, I'd like to thank colt err technology that provided the equipment that we are using for the connection. They provide us 1 /TKPW?BT circuit and a 100 megabit circuit for our connection. And I want to thank also the national research network, GAR, that provide for this meeting the transit, the Internet transit.

Just a few words about Casper. Casper is an inter university consortium that are formed by several /TAL yen universities. Its main goal is to offer a high performance computing services. But he also, from his beginning, offers offered IT service to say university and public administration, starting from 1995 there is a no profit ISP that is very particular ISP for this reason in 1995, together with the other three local ISP, Casper established in this data centre difference the Internet access point that at the time was called Nap Rome a. This project changed and from a volunteer based project now is structured sort a member based, member based consortium and now is one of the most important exchange points in Italy and in south Europe.

We are going to present some new activity during this meeting. First of all, the presentation of NaMeX in some important landing station in the MED /TAEUPB yen area. An agreement we signed together with apples six. Tomorrow evening we organise a social with I M six so err all welcome to come to this social tomorrow night. We are also ?? better also presenting an open source of free wear project to realise Wi?Fi infrastructure we realise that this public Wi?Fi infrastructure in Rome and in the region of Saar deign an is not so far from here, maybe some of you know. We like to enlarge the community of developers and if you want, as somebody just said, I can get your free access for this period of the conference in Rome. And if you are interested in that, you are welcome to meet us to our desk in the main hall.

I hope to ?? this is all from us as a host. We are waiting for you, if you need any help, if you need some help for technical issues or if you need some help for more important things like how to order the right coffee in the Roman bar.

Thank you very much to all of you and enjoy the meeting and enjoy Rome.

(A /PHRAUDZ)

ROB BLOKZJIL: Thank you. Right. This brings me ?? let me do a quick check. I think I have had everything.

Before we start our regular programme, I want to remind you that after the coffee break, we start with the presentation on the new RIPE atlas project by Daniel Karrenberg and this basically is a commercial. Cannot miss that presentation. Because, as will be explained by Daniel, we need your participation in this project.

Okay. Without further ado, I think now we go to the regular programme and the first, the meeting programme for this afternoon is a panel discussion about addition past data for faster /KOFRPBLGS. The leader of the panel is Randy Bush, and I would like to invite my good old friend Randy to get his panel on stage, if that is the format he wants to do it, and the next 50 minutes or so are yours Randy.

RANDY BUSH: Okay. I am Randy Bush. I know many of you. I am /KA*EUR and pee err would you come on up here.

So, I am not going to explain much of the technicalities because I have seen cater's slides and he sets it up very nicely and so does pee err. Cater is one of the leaders of the BGP and IOS side? SISCO. Pee err is a post doc in U C L and they are two different ways of a come publishing a similar thing, which is if you are familiar with pick, prefix independence /KOFRPBLGS, and other fast /KOFRPBLGS techniques, they recoverage on a new set of routes by having received from their peers more than just the best path. They get immediate observing err paths, or almost as good paths. So, there are two different techniques of doing it. One is diverse paths, which will be presented by /KAEU you are. The other will be add path which will be presented by pee err (K E Y U, are) and this is just to try and educate ?? it's not a war, it's not a disagreement. It's trying to provide education on two very similar ways of in fact, I suspect in some ways, they overlap, of reaching the same goals to give you faster /RAOUG /KOFRPBLGS.

SPEAKER: Thank you Randy. Hi, I am /KAEU you are pay tell and I am going to talk about BGP diverse path. This is a global document that I have could he authored with Robert a /SKWRAOUBG and recognises Fernando from SISCO systems. Danny Mac fear son from versus see /AOEUPB.

So, as we all know, BGP protocol defined base ?? provides a mechanism to just announce one part, that's also known as a BGP best part. Announcements of multiple parts within BGP is gradually becoming a requirement primarily due to fast /KOFRPBLGS. At this point, within BGP, we have multiple solutions available to announce multiple paths. They are, you could do full mesh plus best external, you could additional parts. In you could have RD approach and finally could you do diverse paths.

So, a bit about full mesh. Full mesh is explained at length in RFC 4271, that's the BGP RFC, it an insures path diversity in hot potato routing. For cold potato routing you need some kind of best external /PHEBG /TPHEUFPLT. Best external is also an ideaing with document defined if draft best ex /TAOERPBL.text and finally the shortcomings of full mesh are very well known. It results in the TCP stays ex /PHROEUPBGS and BGP can end up storing as many paths as sessions.

So a bit about add paths. Add paths /SEBGS /PHRAEUPBLD at length, the base add baths /PHEBG /TPHEUFPLT is explained at length in draft Walton BGP add paths.text, which is also aing with document. It announced multiple paths over a BGP session. A new ability to needs to be ?? end peers and when you do ad paths, you need to figure out how many paths they would like to announce, what kind of paths they would like to announce and finally if the edge routers can handle for than two parts.

In L 3 VPN, we have something what we call in different, are do it approach. This is an implementation speak, S Ps can configure different RDs for there words into which multihome customers try to plug in. Each unit RD would end up creating unique set of customer prefixes within the provider domain and this works very well in almost all S P environments. This is the mechanism most use today. You don't need to do any kind of a path diversity. You don't need diverse paths or any of those.

So here we come to BGP diverse path. It's an RR based solution that is used to announce diverse paths within /TK?P and by diverse paths, I mean second best, third best, fourth best and so on. It doesn't require any protocol changes in BGP. It's applicable to all BGP ?? since L P 3 ?? has a very solution that is deployed today this is targeted mostly for IP HOP by HOP as well as ex /TEPBL networks.

Diverse paths on using RRs are announced either with RR S P operating only in a shadow RR mode, in which case they would compute diverse part and only announce diverse parts to their peers. Alternatively RRs can tract session types and announce according to what session /R?S configured.

So, a bit about an RR functionality for the diversion path. RRs need to pre?commute diverse path paths as part of its best path prosing and install is in RIB and FIB if it's in the following path. RR can operate in a complete diverse RR mode and can only commute diverse path and announce diverse path. If it were to do that, both the active as well as diverse RRs need to disable IGP metric play in the BGP best part /KPHAOUtation. So that to compute best as well as... on two different nodes.

Alternatively RRs can also track the session types and announce paths accordingly and if they were to do that, would you need to configure additional addresses for each session that you configured. It covers both hard as well as cold potato routing and finally, are, needs to account for additional diverse path /KPHAOUcation, that goes to compute diverse path as well as sessions that RRs need to set up and announce diverse paths. This is the PE functionality. This can practically get away without software upgrades. It needs to configure additional sessions. It can even use its own loop back address to peer with RR for the diverse sessions and any diverse path that is received by, pence

PEs can use this path to compute big computer and install back up parts and use ?? BGP fast re/KOFRPBLGS. Any BGP trying to implement best parts to ensure that it has capacity to establish additional sessions and it has memory to store eye digital paths.

So, here is what we have as a current RR deployment model. You have pair of a, are,s within the cluster. You have edge routers, trying to announce a prefix. RR would commute best part and announce it to PE /AS BR. Notice how path diversity is missing, although you have two parts. Only /#1?RBGS 1 /TPETS to be announced. If you were to do diverse RR in this case, RR 2 would operate purely in a diversion RR mode and it would end up computing second best and announce the second best out of PE /AS BR. That's how you bet the path diversity. As I mentioned earlier, if you were to do this administratively, you need to disable IGP matrix check in your best part /KPHAOUtation /TKPWR*EUPLT so as to back up on two different nodes.

And here is how it would look with a diverse session. RR implements diverse sessions out here. In this case, RR 2 acts adds both active as well as stand by RR and backup RR rather, and it establishes multiple sessions with PE, using multiple different IP addresses, PEs can get away with using just a single IP address and notice how you get path diversity on PE as well as make make the ?? best path. Is if the RR 1 goes town, PE would /STAOUL route on the primary path P /#1?RBGS until P 1 becomes unreachable in which case it will resort to P 2.

Here is an example of an iBGP with /PHRAG IGP and multiple RR clusters. You have B 1, that is an oral best part within a domain and /SRULTS of that, in your current network, B 1 gets to be announced everywhere else. Notice how all the edge routers have P 1 as the best part installed in their favour and they have diversity on RRs, yet you don't get that on the edge routers.

So, here is somehow would look like if you deploy diverse paths, in particular with with with shadow RRs. The red Linx would end up announcing best paths and the yellow Linx would end up announcing diverse paths. As a result, P 2, which is an oral second best in the network gets to be computed and announceed to all the edge routers. This is how would you get a path diversity on all your edge routers from deployment standpoint, once again you don't need any upgrades on PEs /AS BRs. You get the path diversity by configuring additional IGP sessions and in this case you need to insert an additional RR which will purely act as a shadow RR. It works well with flag domain as well as with hierarchial network domain.

Here is how the same network would look like if RRs would run as both active as well as shadow RRs. Basically, you have multiple sessions that you establish between RRs and to the edge routers and again, red would announce best part. Yellow Linx would announce the diverse path and here you don't need any new RRs, shadow, are,s to be inserted. Again no upgrades on the PE /AS BR is required and you need to configure additional sessions.

Hierarchial RRs case. You have multiple cluster domains with RR 1 and RR 2 serving each ?? one POP, one and other POPs and then you have another level of RR hierarchy to which you would establish a diverse session. So two levels of diverse sessions. One between RRs between first and a second level and the other one between RRs within the POP. Again, the path diversity is achieved and you don't need to upgrade any of the edge routers.

A thing to note by diverse path is that with /TKERP usually intracluster routes nay not get announced. This is because diverse paths will not change any BGP route propagation rules. You would still have path diversity within the cluster. However, it is that within intracluster there to be scenarios where you would not exchange all the paths. In order to so of this, you could run best external on to much diverse path and get away with the path diversity that you are looking for. Best external typically helps to you reduce number sessions also if that is what you require between your RR mesh.

So, here is an example where the intracluster routes may not also get announced. It so turns out that the B 3

AXEL PAWLIK: B 3 B turns out to be the oral best and oral back up for the given domain. Since they are originate /TPR?TD cluster that belongs to RR 1, when they go do RR 1 notice how the bath B 1 never against to be announced. This is primarily because the best and the backup both comes from the cluster they're RR 2 belongs. If you were to do best external, best external mandates that every time a best part is selected, which is an inter cluster route, you will have to announce your intracluster route out and it is that rule that will facilitate the diverse path announcement in this case and in so, you will end up announcing B 1 out.

Finally, I have a scenario where (P 1 (in you disable diverse paths between RRs but just enable best external, and if you do that, notice how you have oral backup part as B 3 B, which doesn't guess announced. However, because you have enabled best external, you will end up announcing P 1 from RR 1 as cluster. So this is how we handle best external and diverse paths together. That's about it.

I would like to thank Randy Bush, Robert Raszuk, Chris AS /AR, sat I shall my /TPHAPL and sell may Yilmaz for doing the presentation. Thank you.

(Applause)

RANDY BUSH: /UPBLGS there is a particular clarifying question, I suggest we hold the questions till both /HAOE errand /KAEU you are have presented. Her her I don't mind being interrupted during the talk.

/TPRAPB /TPRAPB so, I am /PE ear /TPRAPB /SOEUS. First RIPE meeting, completely freaking out. So, the first slides might be a bit blurry.

I will talk about BGP add path. BGP add path is not a single proposal. There are a shit load of under proposals being out there and we will try together to figure out what it is about.

So, two main drafts. The main draft, here, who basically describes annen coding to advertise multiple paths over the same BGP session. So we are being to, we will discuss why this draft is being pushed for years now at the IETF. This draft only describes annen coding, so, a BGP implementation of add path can decide which paths are going to be advertised and the number of proposals for implementing add path. As a result, well multiple vendors or even multi will business units within some vendors might be not following the same lines and we have been collaborating with the IOS 6, are team in order to figure out which of the proposals should go through. We did up in the end of ?? with a very short subset of all these proposals to be supported. And I will try to explain to you how we reached these conclusions today.

So, modern /SRAEUGSs for add paths. Well, from an historical point of view, Daniel Walton, worked in SISCO at that time, was trying to phase MED association problem and his idea was that (os /HREUGS) in order to so of that MED oscillation programme we could increase the number of path over the iBGP in order to carry the network down, it have kind of a problem that be well basically, four years now I have never heard any ISP or IETF complaining about it any more. Since then a lot of new idea requirements have popped up. Then we have the typical fast /KOFRPBLGS problem with in the case of the loss of a next up in BGP or the drafts of answer tire AS BR. There has been some pushing for the support of multipath ?? load balancing among multiple BGP next up for the same prefix. There has been some requirements for the France telecom to be able to provide hit list, maintenance operations for iBGP Linx so their ability to shut down any BGP link without losing traffic.

A side gains of the solutions that have been pushed in order to meet these requirements, we can note for example, opt /AL hot potato routing, so prevent route deflecters to do an IGP type break which is not the same as the one /THAZ PE will be doing and as a side again of all of of this, we can see that if you deploy this kind of solutions in your network, you will end up with using the amount of updates that you are going to leak all of the network during a /KOFRPBLGS. I will go through it.

So, basically the source of the problem is the lack of path diversity in iBGP deployments, which stem from implementation of policies and route reflection inside the iBGP topology. So, for example we have two AS BR over which, which receive two paths words to the same prefix P, a blue path and a red path. Policies are configured and let's say that the red path is being tagged with a local previous value of 90. So during the /KOFRPBLGS. The blue path with the local previous of 100 will /PAEUBG it to the AS BR. As a result of the external path of the red AS BR is not going to be picked as best by this AS BR and it will not propagate with within the iBGP topology. As a result all of the other routers in the network are not aware of that path.

Even though ?? even if we have two different paths with the same local preference, as soon as they are advertiseed to route reflecters F these route reflecters make the same decision and select the same path. Here the blue one while the PE out of the cluster will only receive one of them and hence they will not be able to reconverge to the second one when they lose track of of their main BGP next path.

We could basically turn on advertise best external, so according to this proposal, these red paths, even if it is not preferred, will be advertised by the red AS BR words to the route reflector, but this is not sufficient as if the route reflecters made the same decision and picked the blue one with, they are going to advertise the same blue path words to their clients and as a result, even if advertise external path ?? best external paths is turned down, you will see that SA BRses are lack of path diversity too.

What is BGP add path about? The ability to advertise multiple BGP paths over the same N, are L I over the same single iBGP session. As a result in our case here F the route reflect certificate able to propagate both paths, then the PE that receives them will be allowed to inthe prefix in the independent coverage state, to be able to make a /SKWEUBG switch over in the plain upon the loss of the track of one of the two next ups. If these paths are /KWAELey preferred it will be able to load baffle traffic among the two next ups and if maintenance is period of on one of these two, a BGP sessions, even if withdrawals are being propagated in the iBGP topologies, all the routers in the network will never lack of a path and so ends trance /EPBL, they will never drop traffic because they do not know where the route it.

As a side gain, using add paths may allow to do optimal hot potato routing, so the typical issue with route reflecters is that they are doing the iBGP type break for their own clients and these iBGP direct may defer from the one that the PE would do. Depending on which path you advertise with add path, if you let these paths be propagated words to the PE, they will make the IGP their own and hence they will under up BGP next up that is closer than the one that the route reflector would have advertised if it had advertised only a single path.

So churn reduction? ? Another side gain of advertising more paths. This is kind of bizarre as the beginning, because in the beginning, because we advertise more paths in the networks, so if we count the number of stages, it will increase, but as a result, as routers will know their best /KOFRPBLGS path in advance, they will not be an iBGP path hunting so that in the end you will stop sending, use let updates words to your customers, as a result of lack of paths that is presented in the iBGP topology.

So, as an example here, we have three paths, blue,, black, red. The blue path is the primary path which is local previous of 100. If we do not increase the path diversity in the iBGP topology, upon the loss and the PE knows only the blue path initially. Upon the loss of AS BR 1, everything can happen in the iBGP topology. So maybe the PE will trance /KWREPBL find itself with no path. So, it will drop traffic and send the withdrawal over its eBGP sessions until it receives the alternate red path over there and then install that entry in its FIB and send an update over its TE BGP session or trance /KWREPBL, AS BR 3 will think that is only external path is the new best one and advertise it over iBGP. As a result, the PE may think that this is the new best path and advertise an update over its CE BGP session. Then the AS BR 2 will figure here that it owns the new best exit path, and hence it will send an update within the iBGP topology. So that final /HRAOET PE will converge to its best /KOFRPBLGS path and send the final update words to its eBGP client.

If you increase the iBGP path either by path diversity in iBGP, meaning if the PE is already aware in advance of this best /KOFRPBLGS path upon the loss of the primary path, it will directly converge words to the best /KOFRPBLGS path and not send withdrawal and not send transient updates that will be updated a second after. If the attributes actually do not change, it will even be silent and concede all this convergence even to not be chatty about this /KOFRPBLGS even to its customers.

So, what does the add path draft basically do is to instead of advertising a path, it advertises a path and an identifier so that it is allowed to send updates for multiple L, are I, about about path /TWORTSDZ different next ups. So this main draft just defines then coding, so an implementation of add paths has the freedom to select which, among ?? which /PA*PBGS among the one that it knows, it will advertise words to its clients.

There are a lot of ?? as I said in the beginning, there are a lot of applications for add paths and so depending on which of these applications you focus, you will end up with different conclusion on which paths should be advertised by the route reflecters or by the AS BRs. So the goal of this project was to analyse all the proposals that were stemming from the academy, from ISPs, from vendors and try to figure out if there was not one that would rule them all or, and what wouldn't impact on the control plain and on the memory of the routers, of turning each of these modes on?

There are loot of them. It's only a subset here because, well... one can route an entire. The ones I picked for today are old path. Easy, you advertise all the paths, end paths, you you advertise your end preferred path among the ones that you know. We'll explain the other /SWUPBZ as soon as go through them.

So, all paths, basically, a route reflector will receive paths from its clients and it will basically consider that the ones that it needs to reflect to its clients are all the ones that he knows. So, basically, the result of this is that it will be the exact same thing as if you would have an iBGP full mesh and turned advertised best external on. Right. The only difference that if an AS BR knows two different paths, it will with advertise best external, you would advertise only one and with that path you would advertise both. So, all paths is a super set of what an iBGP full press /PHURB external best would provide.

It's ?? if you want to implement that mode, it's kind of easy. You pick your path and you advertise them. I like this mode because if you ever BGP monitor somewhere, you basically set up on that path session with them. You turn your pass on and you have everything there. /WHEFPB we have been discussing with ISP to say try and figure out how would add path work, we have seen how complicated it was to get all the paths available at the border of the network, so if this mode was already there, it would have /?PB much simpler. Of course it's a memory and churn monster. Do you not want to do that if you have a huge network and receive a lot of paths. There are situations where ?? ?? I go quickly. If you have only a few paths for prefix /TES borders and you can turn it on, of course.

N paths will basically let you select the sequence of your preferred paths, usually we consider only next up disjoint path that if you are first path is through say SA BR 1, then you will no longer consider the other paths that have the same next up for advertisement.

So, add N paths provides the most practical use cases F you want a basic prefix independent /KOFRPBLGS report to ensure that you always have an alternate path available at each router, you basically do add N path and configure N to be 2. If you want to do load balancing among multiple next up, then you set N to the number of next up, among which would you like to load balance. And the nice property of this mode is that the number of paths that are advertised is bounded and hence the memory in part is kept under control through the configuration of that value. It doesn't so of ME D oscillations, but we don't carry. From an implementation point of view, the person run N times running the decision process, so depending on the value of N, this can be a little bit tricky. Their optimisations for that that I will not get into.

AS wide best is a proposal where you would basically not let a route reflector perform a local decision on the set of ?? on the set of path that he advertises. So basically this mode will no longer let a route reflector go further than the iBGP. So you basically pick the path that have the IS local preference value. You pick the path that among them the ones that have the shortest AS paths. You respect the MED and once you are there, you are done. You advertise the set of remaining paths.

So, the decision process complexity of this it's easier, ?? is better than the one of not running add path because you basically stop RIR. It provides routing opt /PHALT because you the route reflector doesn't do an ?? hence the PE will be able to do it on its own. It provides MED oscillation avoidance. Watch out it will not ensure the fact that you will a multi?output net paths in the network. For example, if you have one winner' local previous rule so, here my blue path, well, this is the best widened /P*ET. And hence the route reflector is going to advertise that and that only path words to its /KHRAOEUPTS. If you have two paths with the same local previous but one of them is shorter than the other in the AS path Linx. Same thing, you will advertise only the AS one.

Now, there was another proposal called decisive step minus 1. The step was to try to obtain /TKEU /TRERS tee running as few paths as possible. This a spaghetti argument where you would run the usual decision process and once you hit the rule which gives you one best path, you advertise the one that were remaining at the previous step.

The result is that if you have one winner at the local preference rule, well the paths that were remaining at the step before are older paths and so you end up advertising old path. So you got it. If you /AUPB SA path winner you will advertise all the paths with the IS local preference value. The first ever ?? so I will get to the summary after. So the first ever proposal was neighbour AS group best, so you would basically advertise all the per neighbouring AS, one best path. So you split all the paths for a given prefixes based on the neighbouring ASs from which they were received, from each of the subset you pick the best path and you advertise each of these best path from each of these sub sets.

So, as a result, no AS BR running this mode will pick a path with a lower MED value because you will always know about the best pat from each of your neighbouring ASs and hence it's going to be resolved. So it's provides you the best path from each of your neighbouring AS, but you don't know if you have multiple ?? if you have a past words to a given prefixs from different

AXEL PAWLIK: Ss so this mode does not ensure that you will have multiple paths available at the border ?? at each router in the network. And even though you would have them, you are totally not sure if these paths are going to be the best /KOFRPBLGS path so you may receive multiple paths upon the loss of your primary one with. You may switch to a path that was /SAOEFPD from another neighbouring AS but if in the end, you will converge words to a path ?? a secondary path received from the primary neighbouring, a Yours sincerely along which you were sending the traffic, you will switch back again words to this new path. So the churn reduction does not apply on this mode.

So, as a summary, one main thing that except add in path, there is no bound ?? there is no theoretical bound on the number of the paths and hence on the memory stress or churn stress that you will introduce in your network by turning this path on. By turning this mode on. So add all of course is the max.. if all your paths are making it available at the ?? makeing with to the IGP tie break, turning AS wide on will leads to /TAOEUSZ all the paths.
If all your paths are ?? if your best path is based on the local preference value with the main us 1 rule, you will end up advertising all the paths. Group pest, same thing.

MED association avoidance, accept ad N path, all these modes have the feature that they let them be avoided. And some of them are a side again. So, for example, add all, that as a side again, as wide that is a side gain too, but when we focus on the modes that I have been specifically designed to do that, we can figure out that, for example, AS wide best and group west cannot provide, cannot ensure that all the routers will know a net past.

Our conclusion was that as these modes were specifically designed for a problem that the /KWAUSey nonexistent and has all the other modes that are tack cling more concerning problems in service provider networks, we decided to leave to leave them out.

When we were trying to discuss about this is minus 1 step with vendors, we basically figure out that they didn't want to implement this because this was a /SPE gettey. ISPs freak out about the fact this they would advertise all the paths with the IS local preference value because they have basically often case where is they would have a lot of them. And so, as a result, we end up with two options for supporting N paths. First of all all, which max.s out and /KHURPBS stress. We have N, which provides this nice feature that this is bounded. The properties of add N path are kind of great. It doesn't ensure paths opt /PHALT. It of course ensures back up availability as soon as you set N to a larger value than 2. It doesn't ensure that these paths that you receive are your best /KOFRPBLGS ones so it doesn't provide the best churn reduction that you would get. But, by summation you can figure out that this is often the case but it doesn't theoretically ensure this.

The message on process complexity depends on well the laziness or not of the developer that is going to do this or this will have to be taken care of. It doesn't provide MED oscillation avoidance but we don't care and you can figure out that by increasing the value of N, very often you will basically resolve your MED oscillations.

So, currently, in the /RERPLGS draft, the current status is, so it became aing with document last Thursday, is to have add paths implementation must support add in. The default must be 2 but it must be configurable too. We leave an option to have this NB end boweded. We leave the option to implement at all. And all the other ones are basically options.

If you would like to push one of these modes that will basically be ruled out, it's really now is the time to shout, to go and shout at the IETF. If you would like to know whether in your service provider network, how would one of these modes would behave, a researcher in my team implemented the mode in a similar later. So what you can do is to give us your BGP configure, you are iBGP configure, and all your routers, put the priority on your route reflecters. Problem is that if you only provide us the paths that are available at your route reflecters, you will not give us these alternate paths that are not currently advertised. So it would be preferred if you do an all your AS BR 2, this is sometimes be an issue with some big service providers, so there are ways around that. And what we basically output based on this is for each mode, the number of paths you will find in the RIB in of all these routers. The fact these these paths are optimal. We will give you upon the loss of a failure, an /KPRAELGS of the VATTeyness of the route reflecters. And we will also give you the number of transient updates that are going to be sent over eBGP sessions upon the loss of one of your necks hops.

So, from a deployment point of view. As /KAEU you are said, he said network wide update, upgrade is necessary. Well, this is a session wide upgrade that is necessary. So, if you have a route reflector that supports add path and none of your PE as support T well basically this feature, this solution does not bring anything. Do not frequent out if you end up figuring out your vendor of route reflecters support that path and your PE routers only support diverse paths. When you have a net path implementation, turning it into a diverse path implementation is trivial, so basically push the ones that are providing add path to also support diverse path.

As for old solutions, you do not want to increase iBGP path diverse /TAOES. Do you not do in/KRES to re/KRES encapsulation. This is opening up the door to deflexions and if you increase path diversity by advertising paths that are not best paths, watch out for the implementation of prefix independent /KOFRPBGS at your PEs. They are naive implementation that is could lead at that trance /KWREPT loops by adding the router providing the alternate path loop back the traffic words to the primary until it has replaced the prefix independent /KOFRPBLGS behaviour. /*L /*L

Thanks.

(Applause)

RANDY BUSH: Since we don't have a lot of time for discussion, thank you pee err, may I try to ask a couple of questions? First of all, the salient difference ?? a couple of the salient differences seem to me that I am trading spreading out BGP noise flat continuously instead of churn when I want to reconverge. The advantage I get ?? in both cases. The advantage I get for that is fast rereconversion /W?S with pick. The answer is yes or no? In both cases, I am increasing routing noise, the routing chatter that I get but it's going flat instead of happening when there is /KOFRPBLGS.

Okay, number two is the salient difference between the two is diverse path is multiple BGP sessions whereas add path is over a single session. The multiple sessions means that this works best where I have paired route reflecters, or something very similar to that, two border routers getting the same main connectivity could also do this, right. I have the same peer or peers at two border routers, and they could, one could do the diverse, one could do the main path. Pat pat diverse sessions you can get away with the single RR doing both.

RANDY BUSH: Right. And third, I want to ask a question of pee err, the tool you have, the kind of evaluated, will it also price the increased cost in memory on my routers? /TPRAPB /TPRAPB it counts the number of paths and then depending on how attribute sharing is im/PHREPTed on the the router, you will get of course different results.

RANDY BUSH: This is a memory expensive and some routers ?? /TPRAPB /TPRAPB yes.

RANDY BUSH: And even though in carry you are's case in diverse path, that I may be able to do this with no significant software change etc., I may hit a hardware problem. /TPRAPB /TPRAPB if you forget about memory usage and absolutely /AOEUR a peak, either you do diverse path or add path with N set 22. And it's going to be the exact same memory ??

RANDY BUSH: These aren't really that different, the choices of what to announce for the second path actually occur in the diverse path situation as well, except the number of them is the number of sessions. So...

Do other people have questions or comments? Geoff, are you here?

GEOFF HUSTON: Hi. I am Geoff use tonne from APNIC. This strikes knee a little bit bizarre and I keep on wondering why you are trying to ram the round beg down the square hole. What you are trying to do as far as I can see, is do Eanair sat's version of a distributor protocol that's normally Linx state. What you actually want is that the computation is done in parallel all over your net in the iBGP, so when that you have failure, the failure floods quickly and every single switching device goes, a harks, I know what to do to get around the failure, which is a classic property of what happens you do a link state. In other words you fluid the /TPHR?FGS and everyone computes at this moment stain /KWRUL, but you are not going to go there. For some reason, you are trying to jam this distant protocol to behave as if it was link state. That's what you are doing. This whole idea of I don't want best path I want 2 best path. I want 3, and 4 best path. I am like get over T why aren't you doing a straight link state on this kind of information? Why do you still think that you can sort of squeeze the performance of link state out of a distant vector? You want add question Randy?

RANDY BUSH: I think it's a great one, that's why I picked on you. You know, if you don't think this should be done with BGP, how about DNS?

GEOFF HUSTON: I am old enough to remember ??

RANDY BUSH: Everything can be done with one or the other, right?

GEOFF HUSTON: I am hold enough to remember that John my tried ?? and I kind of wonder, to what extent we are blinded by this attitude that oh I have got to use BGP for all these routes? We quite happy walked away from Rick because it /STA*PBG. And the distance nectar really count perform very well. And yet listening for the last hour of these two /TAEPLTS to try and Mick distance vector leap over these enormous boundaries of complexity inside our network you are trying to /SKWAOED performance out this. /WHAEPBGS wrong with using link state. Why do we have this aversion to it?

RANDY BUSH: Because it's a major leap. This stuff is just a minor leap. Pat pat if I could take a stab at it. Both /PROEFPS that we talked about doesn't increase the session scaling. We aren't doing full mesh sessionings and announcing all the paths. Considering the sheer number of paths and prefixes that you have in BGP, both /PROEFPS try to ensure that while you have multiple paths, one of the things in add paths that /HAOE err also explained was to limit number of paths. It's the number of path explosion that is would end up creating spike in the memory, and square sessions that you would end up doing or order of N, number of session that is would you end up doing if you were to peer each one with each other that. Wine crease even more a memory state that you will do. So, in other words, if I would say, if I were to do a full mesh today it won't be any different than a link state.

GEOFF HUSTON: Isn't the end game that's dangerous there, I am essentially flooding the entire external BGP table into my iBGP

GEOFF HUSTON: The /SKWROFB an ISP is to get of theity packet. Get of it. Because keeping pacts is a losing proposition. /TPRAPB /TPRAPB just a clarifying question about the question. Are you talking about link state? Which would be the Linx there, Linx between, a Yours sincerelies.

GEOFF HUSTON: This is the real question that I am getting down into. It's a fast nature architecture that as we make or networks more interconnected and as we try and squeeze for performance and as we try and get them to react more quickly, you kind of wonder if the two decades old routing technology still apply. Realistically, you are not trying to do link state over 350,000 entries. You are trying to do link state over the number of egress points you have got in your network. Which is a vastly smaller issue. And what I suppose I am really getting down into all this, is this sort of tension between thinking about the problem and thinking about how the current tools can be tuned to the problem. And what I am hearing is a whole bunch of how do inopportune iBGP and tweak it a bit? /TPRAPB /TPRAPB let me give you a trial. Link state has the ones that you have described as a pure link state as we usually see them is advertise all. So I advertise the state of my link words to this sub?net on each of my potential exit points words to that subset and then you look at the memory impact and the churn impact and you figure out that it might be a bit freaking you out and then you say oh, I should basically pick advertise within my network only the two Linx words to this sub?net and this is add N with with N set 22 basically. So, I think that we are basically discussing about terminology here and we are discussing about the same kind of solutions. It's just that all these are trying to find the best trade off between advertising being super chatty in iBGP and try to restrict the chattiness to which are the paths that we are really looking at which are basically the ones we are looking at to reconverge on our primary. If you have two or three customer paths, I do not want to advertise in my ?? and I know that upon the failure of one I will recover through the other, do I not want to load all the routers of my network with the paths words to the same /TPRE particulars I receive for my peers and transit providers basically. So we are doing the same thing and we are basically trying to reduce the memory and the churn impact of this.

RANDY BUSH: I am eat going dirty looks from Rob and I suspect it's not about RPKI certificate expiration policies which we usually argue about. You may think it's time to end this. So, thank you very much. And thank you Geoff for /PEUFPG in.

(Applause) Rob /R?B Andy I assume that all these complicated announcements would be covered by digital certificates, but I might be wrong. Okay. Next speaker is luke a Derry, he will talk about 10 /TKPW?BT hardware packet filtering use /KPHODey network /TKAPTers.

Dear Dear good afternoon. My name is luke a Derry and I work for the /TAL yen DNS registry. Basically what I am doing here is a presentation about the latest research we have been carrying on in Pisa about 10 /TKPW?BT monitoring. This work is could he authored with Joseph gas /PRABG kiss of intell. The idea here is to demonstrate that it is now feasible with modern hardware to monitor 10 /TKPW?BT networks without having to purchase a flex and costly /TKAPT errs or solutions.

10 /TKPW?BT is now become /?LG the standard speed in networks so, therefore Yours sincerely important to find a solution to this problem. That can range from you know open manage to monitoring to trouble shooting to security. So, the idea /STO explore what is available it the market today without buying custom /TKAPTers. And what basically is happening here is if we want to analyse traffic, we must use CP, cycles. Using these cycles is very costly especially if you have a big advanced man's where we have a multi?core systems. It is costly because packets as of today are coming from one /AOERPBT /TKAPT errand this /AO*ERPBT /TKAPT err unfortunately is shown in the operating system as an E T H whatever device so is it means that 15 years ago when you had 10 mega bit /AOERPBT, we had ?? even if we have 10 /TKPW?BT /AO*ERPBT.

So the problem is that modern computer architectures are now multi?core so is means that there is no longer a single CPU that is doing the job but there are several independent courses of execution that is in order to be exploited, they must process packets and if every core is fetching packets out of the same /TKAPT err, they will be suspending countless minutes (spending) and multi seconds trying to fight for the same packet. So therefore, the hold /HREBG see architecture of 10 /TKPW?BT /TKAPTers that they still use in every operating system today doesn't work. For the reason because all the multi?core applications have /O to wait and this is bad. Basically there is one core to this handling the traffic and this is not what we want.

Just to outline the situation. You can see that we have modern adopters where we have either 1 or 10 /TKPW?BT feed and on top of it there is a tech not called RX created by mike SKOFT more than five years ago, that is distributing /PAEBGTS across multiple RX Qs. The point is that this RS S, it is passing hardware in every modern /TKPW?BT /TKAPT err, the /PAEBGT header and based on the packet, so IP protocol and VLAN, decide to which Q to send the /PAEBGT to. So this means this is a per flow balancing so it means that every /PAEBGT of a flow will always pass through the same Q. The point is that here we have kind of particle lies /?TD the work but unfortunately as I have said before, the operating system shows you the interface like /SAEUPBG he will /AOERPBT interface so, therefore we are going to merge again all the /PAEBGTS into one place. But in user space, we have several applications or the same multi?fled application that is fighting for the same /PAEBGTS. Because they are all coming from the same /AOERPBT device.

So, as you can see here, you know, we have some kind of merge and split and merge and split so we are wasting a lot of time trying to use the available course, but statement it is pushing all the /PAEBGTing into the same place. Therefore this is very bad and it's not really compliant with the current computing architecture because there is no future to this kind of architectures.

Some people try to bypass this problem purchasing costly F P go,, a /TKAPTers. There are two companies providing these. End days, /THR?PBD another company in Europe in Denmark named cap tech that are making these /TKAPTers. The point is they are able to operate at wire rate but they are expensive. And also the number of filtering rules is very limited. And this is the point. Why do we need filtering rules? Because in order to distribute /PAEBGTS across course, so in order to put certain applications on top of a certain core let's say that we want to analyse the NS traffic, we want to analyse e?mail traffic. We must somehow try to divide this traffic into the operating system or better into the hardware and to send this traffic to the right core. The point is that the 32 /PHEULT erring rules might be enough, but in general, they are not. Because if you combine several rules into one, maybe say IP and protocol, you are going to exhaust the rules pretty quickly. Especially in modern machines. Just to give you an /KWR?FPLTD at the moment /PH*ES mere machines with 12 course, if you put two times 12, so two times 12 course you have 24 course so you see that you have more or less one route per core. That is not really enough.

At the same time, if we try to find a solution that is not somehow inside the computer but outside the computer, something like open flow is doing, we are not going to soft problem. I don't know if you are all familiar with open flow, but basically the idea is that you have a switch that somehow can be modified in behaviour. Creating some kind of access contra lease so, let's say you want to diverge the monitor and probe some kind of traffic. You create one rule using the open control flow which is a PC connected to a special port is sending special /PAEBGTS to the open flow switch and then when the open /SPHROE switch sees a certain /PAEBGT coming from specific port and if parts of this /PAEBGTS is port 25 or port DNS whatever, basically diverting those /PAEBGTS. Somehow you are overriding the standard switch behaviour. Where you have the Mac address and the port association. If there is no rule that is deciding where to send the /PAEBGT to. The standard behaviour can be used.

So an open flow switch can be seen as a way to off load the job of deciding to which /PAEBGT to take into account which /PAEBGT to drop. Unfortunately open flow switches are not very common /TAOES days and they are cost /HRAOEFPLT at the same time you still interest to play with cables. You have to put a lot of cable to add a new component. Of course you must put money into this because they are not cheap. So, maybe you are going to soft problem but you are not going to save money if this is your goal.

So, as I have said, Y is H W filtering important? You want to drop unwanted traffic especially if you are an ISP. If you are on the backbone you want to focus on a certain type of traffic of a certain VLAN or a certain M P L NS, because you have a bug between two end points of you are going to receive loads of /PAEBGTS per second. And you want to focus on a few /PAEBGTS F you want to filtering software, like you are going to waste many PCP /PAEBGTS. You are going to drop /PAEBGTS because in order to drop /PAEBGT in software, if means you have to receive all the /PAEBGT to pass the /PAEBGT to make a decision F the /PAEBGT is good it continues its journey F it is bad, it is dropped. So /TKROFBG /PAEBGT means job drop, something to do, it is not cheap. Therefore as I have said before, /PAEBGT filtering, so the technical, taking a certain /PAEBGT on a certain /POERT is basic activity that is necessary in order to distribute the load across course because if you don't pass the /PAEBGT, if you don't decide based on a filtering rule where to send the /PAEBGT to, you are not going to use cores pretty well. And this is what's happening unfortunately.

This is kind of introduction, but just I want to give you an overview of modern networking architectures in PCs. Basically, what you see is that we have an input stream, so we have the Internet traffic we want to monitor and based on a certain rule, we decide actually the hardware interface decides where to send the /PAEBGT to certain queue and the these are mapped to you CPUs and the card itself and the controller is moving /PAEBGTS to the CPU cache, so there are this path has been optimized very well. Unfortunately the operating system is not using this. But what this picture is saying is that by design today, you have multiple course each receiving a portion of the /PAEBGT so. Problem now is how to filter /PAEBGTS efficiently and decide where to send a certain /PAEBGT to a certain core where a given application is working?

If you think about a few slides back I have shown you the picture of split and merge, okay. This can be solved /KWEURB /EPBL for instance using technology I have developed used PF ring, which is allowing people to use ?? it's possible to map receiving queue with a thread or with an application. A receiving queue is a hardwarend entity, it is living inside your /AOERPBT controller and you have as many queues as the number of course you have, so therefore, if you have a four core machines, you have four queues per port. If you have a 24 core machine, you have 24 queues. So, it is very important to decide to which queue send a certain traffic. And as I told you before, it is now possible with RS S to hardware balance traffic, but RS S is not really going into the /PAEBGT. So cannot say with RS S that it's standards to each Internet working phase I want to send to the queue number 1 the this IP address, I want to said a VLAN. Using this technology that I have developed, the open source at the end of the talk I will show you the download ring. It's now possible to increase the ?? analysis. Let's say you can put to core number 1 etc.. what is not doing, it is the ability to decide in hardware where to send a certain /PAEBGT to a given core and this is the core of this talk.

Earlier this year intell introduced /AOERPBT controller 825 the 99, which is interesting because it allows to filter /PAEBGTS and the number of filtering rules is 32,000. If you compare this to the modern F B J based a /TKAERPT, this is a magnitude more. At the same time, as we can see the cost /PHER port is very little. It's around 350 dollars per port today but it will definitely drop in the future. This is for fibre, copper is much cheaper.

The nice thing about this interface therefore is the ability to filter /PAEBGTS. So the ability to say, I want to send this certain /PAEBGT here to this core. Unfortunately, the operating system as I have said before, continues to see this network inter phase as a standard /AOERPBT, so you can do if configure, if ininterface up and down but cannot do much more than that. It is not possible to programme interface to say I won't apply those filtering rules. And this is the work we have con.

Basically with 82599 you can put some filters but those filters cannot be seen as pass or drop. Of course you can drop /PAEBGT and the trick of dropping /PAEBGT is simply to assign the filter to RX queue that does not exist /TPUFPLT eight queues, this is CP /PAEBGT go to queue number 9 which doesn't exist. You are going to /TKROPT /PAEBGTS. Very easy. The point is that using filters, it is now possible to decide where to send the /PAEBGT to and somehow to load balance the traffic. This is something more important, I think. Because filtering is the basic as I have said before, for balancing the traffic, for reducing the load are for distributing the load across the course.

The 82599 has complicated filtering rule. This is about VLAN filtering. With this you can filter for VLAN, you can fillet are for IP, for port, you can do all the kinds of combinations and there are two types of filtering rules,s were filter. There are 32,000. So basically a certain /PAEBGT must match fact /KHRAOE a search filter. Otherwise you can use hashing filters and these are work like bloom filters. So the more filtering rule you had, the more false positive rate you can have. So, basically the number of rules here is infinite.

So in this case, I am showing just a path of a /PAEBGT. So you have a drop or accept decision and once you have accept decision next to your rule, there is the queue ID where you want to send the /PAEBGT to. So what we have done, me and Joseph is basically the ability to exploit this into Linux. Because PF ring is this kind of module that I have developed and it has been announced for this. What is happening here is that you can have some rules and as you can see at the end of the slide, with a simple eco in a system you can add a /RAOUFPLT let's say the first rule says that, rule number 1, plus means add a rule. Send the /PAEBGT coming from the ?? this is on the screen. Going to host 10600, so it's a network, to any port. Send it to core number 16789 and the second rule says send this traffic port 25 designation, 10600 to any port to the core number 2. You can do something like this. Rules are evaluated in in order. So therefore you can say pass, pass, pass and drop if you want. Dropping /PAEBGTS means that the second parameter means that the queue ID has to be either minus 1 or a queue ID that you don't have. If you have four queues you put 5 and that's T it's going to do the work. As you can see in the top part of the pictures, /PAEBGT are balanced across RX queues and if, as I have shown you before, you can use the visual Internet, you can put /SAEUPBG he will application on top. So therefore you can decide to send a certain /PAEBGT to certain queue to a certain application.

Let me clarify this concept with some examples.

How can we use this technology in real life? When I was /TAEPBG the first RIPE meeting, it was RIPE 51 in Sweden I did a similar presentation, that time it was about 1 /TKPW?BT. Somebody told me Y but I have one bag with a certain IP address and I receive over one million /PAEBGTS per second and I want to pinpoint this problem. So I like to run a white shark or PCP damp and find exactly what kind of /PAEBGTS are exchanged between two host its. So using this technology is very simple. For instance you can sues wire shark, you can set up your rules into your card, let's say this traffic, you know goes to whatever core, pick one core, 0, 0, 0, 0 whatever, goes to one core that does not exist. So basically you are going to drop all this /PAEBGTS.

Of course, it is very fast in terms of rule programming because it's a register based. So you are going to have to reconfigure the card. Like sometime also in router, so whenever you have an extra ?? you are going to stop everything for a few milliseconds. Whereas here everything is working with registers. So you can simply add a rule or remove a rule on the fly. So it means that the /PAEBGTS on the pipeline will not be affected by this new rule but all the new /PAEBGTS will be affected by the rule and everything works as usual. So doing second past based realtime traffic monitoring, something like you receive an ISP traffic and based on signalling you decide whether you want to follow a call or drop call, this is doable with this technology because it is very fast.

Of course you can do traffic classification in balancing, I will come to this later. And for some of you you have to deal with interception of IP traffic it's also very simple, because as you see similar problem to the signalling based problem. Basically you can follow the traffic, or DNS O whatever, or even a /ST*EUBG IP address and as soon as you see the traffic go from your target, you can instrument the rule to say okay send this traffic to the core number 5 and you can combined wire character or PCP damp /O whatever /THO this core and save all the /PAEBGTS.

The last thing of course is 10 /TKPW?BT firewalling that is very appealing especially for those using PC based firewall, you know that whenever you receiver a /PAEBGT, this is going to cause some activity.

I will show you some performance figure. Something that is even more interesting it the ability to do 10 /TKPW?BT /STPHORTing. As you know that is a very possible... but the problem of /STPHORT is that this single threaded, so there is one process that you receive one /PAEBGT after the other and it's processing them. So the first thing to do here is to spread the load cross all the various course so you can reexploit the multi?core machines. This is achieved using virtual /AOUT Internet and using this /TKAPT err.

The second thing here is that with, we cannot do much more. As, you know, /STPHORT uses one in line mode it allows you to make a decision on certain /PAEBGTS whether you want to breach this /PAEBGT or not so you say this /PAEBGT is good, it has to go through. This /PAEBGT is bad I want to drop it. In particular, if /STPHORT sees something bad in terms of connection. So if a certain connection is very nasty, what is possible to do with this is to inject a rule to the hardware and drop this /PAEBGT immediately into the hardware. So, if you go to the enter up website and load up the inside user space there some drivers and one of them is called D, a queue, so it's based on that, there is a new module that allows to you do this. So basically you put /STPHORT on to much of this module on top of your 10 /TKPW?BT card and whenever /STPHORT receives /PAEBGTS that are bad, puts it into hardware. It means you are going to stop all the nasty guys inside the hard way. This is very efficient.

Another thing you can do with this technology of course is divide and concur. So if you have 10 /TKPW?BT ingress traffic and you have too much traffic so instead of having strange and costly hardware architecture, you can have 10 /TKPW?BT /SPHREUPLT or a switch so you can distribute the same traffic to server machines and on each machine you can put this 10 /TKPW?BT card, you put some filtering rules so let's say the first machine takes on portion of the traffic, the second machine another part recollect the last machine all the rest. So, it is a very cheap and efficient, because everything is running at a fast speed balancing machine.

Just to give you some pictures.

As you can see, there is a little difference between filtering in hardware and in software. But the point is that here we have one single filtering rule matching all the traffic. So basically the hardware card is not doing much. In real life you have many more rules. So as you can see, the speed advantage of hardware compared so software is not very much in this.

What is really amazing here and what I think you also expect, is to see a single filtering rule dropping all the /PAEBGTS. So as you can see, the software filter is using the CPU of 20% and the hardware filter is 0. So everything is happening in the hardware. It means that if you receive one fill /TKPW?BT stream of data. If you have your core routers and if you are interested in monitoring a certain traffic and you want to analyse those /PRABG it is wire shark just to make an example. You can put a filtering rule or an if you filtering rules. As I say they are evaluated in order so you can put the last rule, drop everything else. And as you can see, filtering happens totally hardware with a very cheap card. So this means that you can use your available CPU cycles to analyse the traffic and not to drop /PAEBGTS like it happens usually with the standard monitoring. I /TKAPTers.

So, just to wrap?up. I am trying to be as quick as possible. Using this technology, we have shown that it is now possible using commodity hardware to manage 10 /TKPW?BT networks for trouble shooting or more monitoring in Pisa, at the /TAL yen Internet registry, we are using network monitoring tools for monitoring the traffic, for monitoring DNS traffic for instance, and this is one of the advantages of this technology. You have a backbone, you want to find a certain problem and you can somehow monitor it without having to buy a very expensive hardware. It is available at no cost and the ?? this is the URL and for those of you who are interested in reading how the system works, you can also read this paper pelf published recently.

So this is not an advertisement for our technology, but it is a way to tell you that it is now possible to do 10 /TKPW?BT monitoring efficiently using commodity hard wears because most of you are network operators so you are face with this type of problem, you know how hard it is to do 10 /TKPW?B monitoring using a PC and this is I think it's a good technology that is going in the right direction. Thank you very much.

(Applause)

ROB BLOKZJIL: Thank you. Are there any questions? Ruidger.

RUEDIGAR VOLK: One tiny detail. Your example did show filters using IP addresses. This was IPv4.

Also picks, we currently IPv4, because we have implemented IPv4 parsing into the kernel, but it is now possible to do IPv6, yeah.

ROB BLOKZJIL: Are there that many IPv6 /PAEBGTS around? Good. Next question.

I am disgusters Mo del owe from grease, I am /TRE interesting work I'd like to say first of all. I am interested as a system administrator, of an applying some filtering, do I see virtual interfaces on top of ?? in 0 in Linux? For example, if I want to apply a filter and direct all the TCP traffic words to port 25 to a specific interface for example and I want the process to listen on that traffic and and and auto eyes T do a do use a virtual interface?

SPEAKER: What is happening here is that the virtual Internet queues are available at PF ring level so. It means that you can filter /PAEBGTS using PCP damp or wire shark. This is possible. What it is not possible today, but will be possible pretty soon is the ability to expose those interface at the operating system level. So what's happening is you still have, a T H 0, but when you open wire shark, put put, a T H 0 at 0 comma 5. What we are doing at the moment is the follow?up of this, so basically it's the ability to expose those interfaces to the operate /?LGing /S?L. Why this? For two reasons. First of all for virtualalisation. I think it is very important to have this one available at the basic ?? machine, because many people here are trying /O to /SPHO do a different job but using the same /PAEBGTS so. The security manager, the network administrator and so on. You receive one /PAEBGT and this /PAEBGT has to be sent to different applications all at the same time. So, we are thinking to implement this pretty soon and to expose this to a virtual machine. So basically to come back to your question. As of today this is possible only for network monitoring but soon, next year, it will be possible to expose this also to the operating system. Also, we believe that ?? visitalisation is not a good idea because this this case you will be using memory map to read the /PAEBGTS in the other case, if you have a /TK?RBG interface, you will be reading using a system that's maybe not as fish events.

AUDIENCE SPEAKER: This is all specific to the intell version. You have a driver for this specific chip.

SPEAKER: This is ?? if vendors come up with Sim cards, it is also possible, because the infrastructure is the same. We will be adding soon support for /TPHE tier /KWRUPL cards, they don't have the same kind of flexibility of intell but it is also possible, yes.

ROB BLOKZJIL: One more question. Daniel. /KREPB /KREPB luke a, what's missing now? If I want to put two 10 gig cards into that PC and one to use in dos mitigation or something like that, just for dropping a lot of traffic, what is missing to be able to do that? And a short answer I think, Rob, otherwise will kill us?

SPEAKER: If you want to do that mitigation, I think that probably, if mitigation means to drop all the traffic from a certain guy, okay, north is doing its job today because /STPHORT sin /SKWREBGTing the rule. As you know with the 10 /TKPW?BT card you can have two ports. So one card is enough. You can move /PAEBGT from one port to the other into the same card. I don't think that the PC is you know the best for doing these, but it's definitely possible. /KREPB /KREPB I am thinking of more complex rules, not only from the same guy. Let's discuss off line, otherwise he'll really take time away from me. Rob /R?B thank you Daniel for your question. Thank you luke afore a very interesting presentation.

(Applause)

ROB BLOKZJIL: The next speaker is Daniel Karrenberg, but before that we go for a cup of coffee.

Do come back by four o'clock please.

(Coffee break)

LIVE CAPTIONING BY AOIFE DOWNES RPR

DOYLE COURT REPORTERS LTD, DUBLIN IRELAND.

WWW.DCR.IE