Transcript - IRR Tutorial

Champika Wijayatunga: Good morning and welcome to the APNIC Internet Routing Registry tutorial.

First of all, I would like to thank you for coming here this morning and also I would like to thank specially Google for sponsoring this tutorial session.

This session is going to be for one and a half hours, until the morning tea break.

To introduce myself, I'm Champika and I work as training manager at APNIC.

The objective of this training session is basically to discuss about the Internet Routing Registry. And also to provide an understanding about the Internet Routing Registry or what we call IRR. Also, basically, to go through the benefits and also to discuss about RPSL, where we express the policies.

This is what I'm going to do this morning.

Initially, if anyone is new to APNIC Whois Database, I'm going to just do a very brief recap about the APNIC Whois Database and then go on and discuss about IRR or Internet Routing Registry.

Then we will discuss about using these routing policies or the routing registry and then also to express those routing policies using RPSL, which stands for routing policy specification language. Then we will discuss about the benefits of using IRR.

Just to actually recap on the Whois Database. The Whois Database -- of course probably if you are an APNIC member, you may have used the Whois Database to register Internet resources, like IP addresses, numbers, even your contact details and so on. Basically, it's a public network management database and so we register this Internet resource information and also contact details and so on.

Now, how the Internet Routing Registry is related to this, basically we register the routing information as well in the Whois Database. You would have basically the usual IP address related or the allocation, contact details and so on and in addition, you will also have basically the routing information.

APNIC routing registry is actually part of the usual Internet routing registries which are kind of distributed, basically distributed database and mirror with many other Internet routing registries in the world.

Going on to how we represent this data or how we register this information into the Whois Database, it's all based on database objects. You have these database objects and we register this information, such as your IP address information, AS number information, even routing related information and so on all as objects.

Every of these objects, they have attributes and values, and these attributes of course they have values and then there are special syntaxes and so on and of course some are mandatory and some are optional.

Of course, these also can have single-value fields as well as multi-value fields. I will show some examples later on so you can have a look at these objects and templates and so on.

You can use these attributes and query the Whois Database. There are unique or primary keys and also there are lookup keys for queries and also there are inverse keys where we can query the database with reference to other attributes and so on.

You can get the Whois Database templates for any of these objects quite easily. This is an example of a person object -- this is of course an example object.

So you can see on your left side column, you will have all these attributes starting in this case person, address and country and so on, all the way up to the source and then on the right side, you will have person, the value of the person attributes is this case test person, so the person's name and then the address and so on and you go, for example, to the other attributes as well, and this is pretty much what we call a person object. That's an example.

Similarly, we can always have this kind of objects for other various Whois data, for example, like IP addresses, whether it's IPv4 or IPv6 and of course AS numbers and reverse DNS information, all those things.

As I said, they're all registered as objects.

When you want to query these objects in the Whois Database, there are various flags where you can use.

For example, if you want to carry an IP block or an inetnum object, you can use some of these flags which are shown in the slide, because as we know, IP addresses can be represented in a tree hierarchy, so you can basically look for less specific matches, as well as more specific matches or even exact matches and so on.

There are various flags to do that.

Similarly, there are various other flags, for example, if you want to turn off the recursion and so on, otherwise your output can contain quite a lot of objects, so there are various keys and flags where you can do this.

Then we come to the database protection. It's very important when you register all this information like your IP address blocks, AS numbers and as well as even all this routing information, this information is protected. Otherwise, anyone can change this information. That is why the database protection is quite important in this case.

There are some certain mechanisms to introduce the database protection.

In the case of authorisation, we have an attribute called mnt-by shown as in the slides, mnt-by, so that's mnt-by. This is basically a reference to an object called mntner object. This can be found in all the database objects, so whatever information we register in the database, we register using a kind of -- we protect using mntner object.

Then, of course, the authentication part, the authentication, you can use various types of authentications or various mechanisms as well, for example, like a cryptic password or MD5 key and so on.

That's in terms of authentication.

What are the prerequisites of updating an object? Usually when you get the resources from the Internet registry, first thing they will tell you is to create a person object. In other words, if you are the resource holder or if you are managing resources in the Whois Database, you should actually register your contact details in the Whois Database. What you do is you create a person object and this would provide information about that particular person.

Again, in the case of contact details, we do have different types of handles. One is what we call administrative contact where the person is related to the administrator, mostly handling administrative details, whereas the other handle is a technical handle or the technical contact, where, for example, it could be a network engineer and so on, who is more of a technical person. In some cases, of course, one person can be doing both functionalities as well.

That's your person object.

Then, of course, you create a mntner object. Now, mntner object, as I said earlier, that is to protect the object or the information which is contained in that object. That will provide the protection.

These are quite important, especially if you are getting resources, make sure that you have your person object, also make sure that you have created your mntner object.

That's a kind of very quick recap in case you are new to APNIC Whois Database, because why we want to introduce or quickly discuss about the Whois Database is basically the Internet Routing Registry that we are going to discuss is all about, again, it's a part of the Whois Database that we have and that is why you need to have a kind of understanding about the Whois Database as well.

What is IRR or Internet Routing Registry? As the definition says, it's a repository or a database of Internet routing policy information.

When we discuss about internet routing, obviously there are quite a lot of things that we need to consider. For example, there are routing policies, agreements and so on.

Also, if you go into more technicalities or configuration level, obviously we use autonomous system numbers, we use AS numbers to exchange the routing information via BGP. As probably you may know already, if you consider an autonomous system number, obviously you use -- inside the AS number, you use an interior gateway protocol, IGP, as well as to talk between AS numbers or autonomous system numbers, you use an EGP, like BGP in this case.

We use these routing protocols. But the thing is that these routing protocols, there's no proper way to publish this routing information in a repository.

That's why we need to have a repository to publish this routing information in a public place, like a database. That's what the IRR serves for.

Exterior routing decisions are based on policy based rules, but BGP does not provide a mechanism to publish this information and communicate and so on. So routing registry provides this functionality.

That's the main purpose of having this routing registry.

How do you express this? Again, routing policy information is expressed as a kind of series of objects, so we have a number of objects, again, to represent or register this routing information.

Also, the routing registry would give or this routing information will give stability and consistency for kind of routing. All the network operators, network engineers and so on, they can share this routing information.

There are quite a lot of routing registries in the world, APNIC IRR is one of them, but there are more.

The only thing is that they all mirror each other, so if you register in one of those other mirrored routing registries, you do not have to go and again register in another one. So registering in one of those routing registries is enough. There are quite a lot of routing registries in the world.

Then we come to the point, what is a routing policy? What's a routing policy, that's the way you define how you want to get route, in other words, traffic into your network and then how you want to get traffic out of your network basically.

It's a description of routing relationships between, again, autonomous systems, because as I mentioned earlier, we need to communicate in the case of routing, we need to communicate between these autonomous systems, so we need to have routing relationships.

For example, what sort of relationships are we talking about here? Things like who are the BGP peers? It could be your customer, maybe you are peering or you are running BGP with your customers or maybe with your peers or even with your upstream and so on.

Then you share these routes. What are the routes that are being originated by those neighbours that we discussed? Who is importing what? We have these imports and exports. Import is basically inbound and export is outbound.

What are those routes that are being imported from your neighbours? Then what are the routes exported to other neighbours? Then if some multiple routes exist, you might want to select some preferred parts. How do you select that? Then if no route exists, then what are you going to do? What's the situation? Then even things like route aggregation and so on.

These all can be included in the routing policy.

Basically, you need something more expressive to express, a kind of language to express these routing policies, basically.

We have talked about routing policy. Let's see how we can represent this routing policy. In this example, we can see there are two autonomous systems, AS1 and AS2. What we are going to do is, in order for traffic to flow from the network -- let's assume network 2, that's in autonomous system 2 and network 1, that's in autonomous system 1.

In order for traffic to flow from network 2 to network 1, between these two autonomous systems, what are the criteria that should happen? First of all, AS1 has to announce network 1 to AS2 via BGP. Autonomous system 1 has to announce. You can see the word "announce" there, which means AS1 has to announce its network, which is network 1, to the other autonomous system, which is AS2, via BGP.

Then once this announcement comes, then the AS2 can send the packets. If you see now the packet flow is actually opposite to the routes. You announce a route and then the other can send you the packets.

Similarly, the other way around as well. AS2 of course has to accept this information and similarly, in order for traffic to flow towards network 1 to network 2, we are talking the other side, AS2 has to announce network 2 to AS1. Then also AS1 has to of course accept that information and use it. Then of course the resulting packet will flow from network 1 to network 2.

But the only thing here is that in this case AS2 is announcing something and AS1 is accepting something.

But would you want to really accept anything that the other announces? This is a question that we have to think about. Because it may not be legitimate, for example, so if someone is asking you to announce something, it's a question whether you should really accept it or not.

This is why it's very important that we need to check whether this information is registered in a place like a routing registry, so that we can verify the legitimacy of these resources. That's the main purpose.

We define these routing policies. What do we use? We use a language called RPSL. RPSL stands for routing policy specification language. These are defined in RFC, this talks about RFC 2622 describes RPSL. This is based on RIPE-181, which was there before, and you have the structured Whois objects, but we discussed earlier, when I was going through the Whois Database objects, I mentioned to you about the Whois objects and the structure and the templates and so on.

Of course, there are a few more RFCs to talk about some of the security aspects as well as case studies and practical content is there in RFC 2650 as well. It is worthwhile to read these RFCs.

Let's go and discuss about some of the examples, how we can define these routing policies using RPSL. In this case, again, we have two autonomous systems here, one is AS1, you can see that, the other one is AS2. For explanation purposes, we only show here the aut-num object and the import and export attributes but of course an aut-num object will have quite a lot of other attributes as well, but those are not shown for clarity purposes.

Here you can only see the import and export. If you see underneath the AS1, you can see that aut-num is AS1.

That's your aut-num object. We register this information in the Whois Database, so in the case of import, which is actually inbound, it says from AS2, just like what I explained to you earlier, so from AS2, with an action preference, don't worry about this one at this stage. Later on I'll explain to you about this preference.

From a certain preference, then you accept AS2. The routes from AS2. That's your inbound policy.

Similarly, export, which is outbound, to AS2, you announce yourself, because you are AS1. It's a very simple policy here. From AS2, you accept the routes from AS2 and then to AS2, you announce yourself which is AS1. That's the policy for in this case, the AS1.

Similarly, for AS2, very similar. In this case, the other autonomous system is AS1. From AS1, it is accepting AS1, the prefixes from AS1 and then export which is outbound, to AS1 you are announcing yourself, so yourself is AS2.

Here the action preference is actually 100. In the case of if there are some multiple links, for example, where you want to introduce some preference, you prefer something over the other, then you would use this action preference. Lower the preference, highly preferred.

The lower the value, it's highly preferred.

This is kind of an example, how you can represent a routing policy uses RPSL. Let's talk about another example here. A little bit more complicated than the previous case.

In this case, you have four autonomous systems. The first one is of course AS123 and our focus is on AS4, which is highlighted, and then we have AS5 and AS10.

Here the scenario is that AS4 is giving transit to AS5 and AS10. Then AS4 is giving local routes or basically it gives local routes to AS123.

This is the scenario and if you want to actually represent the routing policy using RPSL, you would do something like this. Our focus is AS4 here now. You can see that import or the inbound, so you are accepting these routes, so from AS123, it's pretty much local. So with a certain action preference, you accept AS123.

These are again the key words in RPSL. From AS123, you accept AS123.

Then also from AS5, you also accept AS5, routes from AS5. Remember, you are AS4 here. Also, in the same way, you accept the routes from AS10 as well. But when you announce -- remember, you are giving transit to AS5 and AS10. In this case, when you announce the export attributes, the first one with AS123. So to AS123, you announce yourself, because that's local, so you announce your own, which is AS4. But to AS5 and AS10, it's a bit different, because you are giving transit.

To AS5, then you announce yourself, which is AS4 here and then as well as AS10. In the same way to AS10, you need to announce yourself which is AS4, plus AS5.

Remember, of course, that AS4 and AS5 is not a path, like in BGP, because this is represented in RPSL.

That's another example, how you can use RPSL to represent your routing policy.

Let's take another scenario. In this example, of course, we have three autonomous systems here. The first one is AS123 and then we have AS4 and we have AS6.

AS4 and AS6, that's a private link, in this case, the link 1. AS4 and AS123, that's where the main transit link. The outside is -- outside that AS123 is pretty much the Internet, basically you are receiving the full routing table over there.

Then the situation is in case something happened, let's say to the main link, if the main link is failed, then you want to receive all your back-up, back-up all the traffic over the link 1 and link 3 in the event of link 2 failure.

Let's see how we can represent the routing policy for this scenario.

Routing policy examples: so we are focusing on the AS4 here, which is the highlighted one again. Import and export: import, the first one, from AS123 with action preference of 100, you are accepting any. Here we have this key word "ANY". In RPSL, "ANY" has been used to represent the full routing table.

That's where we receive the full routing table in the usual case, in the default case, through our main link. From AS123, with that action preference, we accept the full routing table, "accept ANY".

If you go to the second line, which is import from AS6, with action preference of 50, you accept AS6. Now this is again the traffic coming from -- basically routes from AS6, AS6 only. So you accept that from AS6 inbound, import. Remember, we are focusing on the AS4.

The third line, which is from AS6, we also have another statement. Action preference 200, in this case, and again we are accepting the full routing table -- "accept ANY".

You can see that of course we are accepting the full routing table, now from AS123 as well as AS6. But we know that our main link, by default we want to receive the traffic from the main link, which is via AS123. If you compare between those two, definitely since we prefer more, with AS123, that's -- I mean, receive the full routing table through that, we will give a lower value for the preference there, action preference 100, comparing to the action preference 200 through AS6.

That's how you represent your inbound policy, which is your import attributes in the aut-num object.

Then export, outbound. Yourself, you are AS4, you have to announce yourself to AS123 as well as to AS6.

The export line, the first one of export line says to AS6, you announce AS4, which is yourself, as well as to AS123, again you announce yourself. That's, in this case, how you define for this sort of scenario your routing policy, using RPSL.

Let's go further now: APNIC database and the Internet Routing Registry. What we discussed so far was using RPSL, how you can represent your routing policy.

APNIC database and the Internet Routing Registry.

First in the beginning, I told you that we have APNIC database, we have our usual registration information, like IP address blocks, contact details and so on. So that's all there.

But in addition, you also have the routing information, in other words, Internet Routing Registry information. In other words, you have two databases in one. It's a kind of public network management database.

So that includes all that information, IP addresses, AS numbers, routing information and so on. This contains routing policy information, like routing policies, just like what we discussed before, routing policies, routes, then you can publish your filters, peers and so on.

This information can be published in this repository.

That's the main purpose, so that this information can be shared among the network engineers basically, whoever works with these routing policies.

APNIC routing registry is part of global Internet Routing Registry.

This is kind of a graphical view of what you see in the Whois Database. You have all these IP addresses, AS number information, maintainers and so on. In addition, you also have Internet Routing Registry information like what we discussed, like route objects or routing information and so on. I'll get to the route objects a bit later.

Next thing, what we need to know, we discussed about number of objects so we have to find the relationships between these objects. What sort of relationships we have between these objects? First of all, we have our inetnum object. Let's go back. We have inetnum object here. So you can see there's a certain IP address range here and also, as I mentioned, it has been administered or we have some responsible person there, a technical person that can be an administrative contact as well and then also it is maintained by, there's a mnt-by attribute, which is what we call a maintainer. So it's protected. This information is protected.

Then below you can see the appropriate person object, which refers to that person, in this case KX17-AP, that's what we call a NIC handle, so that NIC handle is coming from this person object for that particular person.

Then also we have that mnt-by attribute which is MAINT-EX in this example, so that also refers to its own mntner object, which is again listed below, and the mntner object itself has to be protected by the mnt-ID, using a cryptic password or MD5 key and so on. So that's your inetnum object, the person object and the mntner object.

Then you also will have your aut-num object. This is where you register your information about your AS number. In this case, AS1 and again the person who is maintaining this, that is KX17-AP and then also it is being maintained by the same mnt-ID that we discussed, MAINT-EX.

Then let's say you are originating a prefix from this autonomous system. This prefix, which is actually represented in that inetnum object, you can see that range, so that's a /24, for example, so that prefix has been originated from that autonomous system, which is AS1. Then we have to create this object called route object. Why do we need to create this route object? Because that's the prefix that we are announcing or originating from this autonomous system, AS1.

We create this route object and also we have an attribute called origin attribute and we have AS1 there.

Then also when you go further down, you will see mnt-by attribute and our mnt-ID or the mntner object is the value of that attribute.

You can see that there is a proper, good relationship over there. So there is a prefix registered in a route object and also there is an inetnum object for that, you also know who the proper person is, we know the administrator or basically the protection, the mechanism that we can do authentication there and then of course we also know that with the same authentication, we can authenticate AS1, which is actually the mnt-ID of that, which means that particular route object is originating from that autonomous system.

Let's go further. Now we also have other objects, like set objects. In this case, I'm showing you two types of set objects. One is what we call as-set and the other one is what we call route-set.

As-set you can see here in this example, as-set, I'm defining a set of customers, AS-customers. Then I can include some members. So it could be my customers and so on, so I can include them as my members. In this case, I have members, so AS1, I have members like AS10, AS11 and AS2 and so on, so I can include those. Those are all attributes. Members is an attribute.

Then, very similarly, we also have route-sets. The idea of as-set is you can group a set of autonomous systems and call it as an as-set. You group those, it could be your customers and so on, so you group them and call it as an autonomous system, as-set.

Then similarly, we also have route-set in the same way we can define members there, so they're basically the prefixes so you can see in this example, there's a /20 in IPv4 there's another /20 and so on, so these things can be grouped as the route-set or they're kind of members of that route-set.

Also, when you go below, you can see that in the as-set, aut-num AS10 and AS11 and AS2, they are the members because we have defined that as members. In the same way, you will also have members in the route-set at 2/20 prefixes. They should have route objects, what we discussed earlier. There should be route objects originating from that AS2, because these are the prefixes originating from that autonomous system, so you have the originate attribute as AS2. Then of course that refers to the inetnum object, the prefixes, there are two prefixes here, so two inetnum objects with reference which are originating from that AS2.

This is again some more relationships between these objects. In this case, we are using as-set and route-set.

Let's go further. Earlier I mentioned to you about mntner object or mnt-ID. I told you about the attribute mnt-by prefix. In addition to that mnt-by prefix, we can also create more mntner objects based on the hierarchy. For example, if you consider the IP address blocks, IP address blocks are being distributed from the Internet registry to a Internet registry member and so on.

When the Internet registry distributes these IP address blocks, the Internet registry will protect the IP address, for example, allocation.

I use the term "allocation". Allocation means basically a block of IP addresses given to a member for further distribution. A block of IP addresses given to a member for further distribution. That's an allocation, whereas we also have another terminology, what we call assignments.

Assignments are IP addresses that go into operational networks, for example, a block of IP addresses that goes into an operational network or an end site.

Depending on that, of course, let's say an allocation, when APNIC makes an allocation, the Internet registry makes an allocation to its member, it creates an inetnum object and that has mnt-by attribute, usually of course the Internet registry will protect that object or that IP address information, so they would put mnt-by attribute, they will protect it using APNIC's or Internet registry's mnt-by attribute.

After that, when the member further delegates that block, further distributes that block to its downstreams or to its customers and so on, they can further protect that object, it could be a sub-allocation like an allocation, or it could be an assignment, if they are going to assign it to an end site, as an operational network, as I mentioned earlier, they can also protect it using members mntner object. That mntner object is what we call mnt-lower.

Also, I talk about two attributes, two maintain attributes. One is mnt-by and the other is mnt-lower.

In addition, we can also have another attribute called mnt-route, which is shown in the slide here. Mnt-routes can actually, when you create the route objects, remember we discussed the route objects before, those route objects can be protected using the mnt-route attribute.

We talked about three maintain attributes now, which is mnt-by and the other one is mnt-lower and the other one is mnt-routes. They are kind of hierarchically -- the privilege is based on the hierarchy.

These mnt-routes can be used in different types of objects. For example, inetnum objects, remember that is the object that includes IP address information, IP address ranges and so on and for IPv6, we have something called inet6num and aut-num object that register the AS number related information, your autonomous system related information as I showed you before, routing policies and so on, and then of course route object itself is the prefix or the prefixes that are originating from that particular AS number.

All these objects can be protected; in other words, you can use this attribute, main route attributes, in these objects.

This is an example, so this is how you would see an inetnum object. You can see there are three attributes in this, mnt-by, which is protected by APNIC, APNIC-HM and mnt-lower can be an attribute from the member and they can also use mnt-route, it could be a different attribute to protect your route objects and you can also use the same -- in some organizations of course they use the same mnt-ID for both mnt-lower and mnt-routes as well.

Hierarchically, these attributes are protected.

This is the hierarchy. APNIC-HM and then next is mnt-lower and then it's mnt-routes.

Let's now see the route object creation process.

Just to summarise the thing so far, so we have these route objects. Route objects contain the routing information, basically the prefixes that you are originating from a certain autonomous system.

You need to go through multiple authentication checks because there are multiple things for us to authenticate here. That's why you need to go through multiple of these authentication checks.

The first one is originating AS number, originating AS. In this case, the maintainer in the main routes is checked. If not, remember I told you three types of maintainers: mnt-by, mnt-lower and mnt-route.

First thing is it will check for the mnt-routes. If there's no mnt-routes, mnt-lower is checked and if there is no mnt-lower, then the mnt-by is checked. That's how it is.

Not only your originating AS number, but also it checks for the IP address space, because we have to make sure that this IP address space is a legitimate IP address space. That is why it checks for the authentication for that IP address range. In other words, the inetnum object.

Basically when you try to create the route object, you need to pass that. Then of course once it is passed, then it will of course check based on your mnt-ID, the last part is mnt-ID, it will check the mnt-ID, the authentication and if it all matches, if it passes, then you can create the route object.

This is the route object creation process. If you try to sort of put that into a flow or a graphical form, the first step is to create the route object. Let's say you are creating a route object for the given prefix here, which is a /20 in this case and it's originating from this autonomous system, AS1. We also now have to have these two objects in the Whois Database, so we need to have an inetnum object to represent that IP address space, so you can see there is an IP address range over there, in other words, there is an inetnum object in the blue colour and then also there is an aut-num object, that's in the orange colour over there, and also that has got mnt-routes, which is given over there, and then you will also have the mnt-ID, which actually refers to that mntner object that you refer inetnum object and the aut-num object. In other words, it has to match.

The second step is when you start creating the route object, it will check for the AS number and make sure that authentication is okay and then the next step is check the IP address range, make sure the authentication is okay for that range and after that, you can basically create the route object. That's how you can create a route object.

Let's go further on to using the routing registry.

So far, to summarise, we discussed about the Whois Database first. I briefly recapped the Whois Database and the objects and so on. Then we went through the basics of Internet Routing Registry, two databases in one and so on. Then also we discussed about the RPSL routing policies, autonomous systems and also how you can represent the routing policies using RPSL and also we took some case studies so far and then we also went on to discuss about routing information, how we can register the routing information through route objects and then as-sets and route-sets.

Then we will see based on all these things what we learned so far, how we can use this in the routing registry.

The advantage here is that you can use all this information for various purposes. One thing of course as I mentioned to you earlier, this would give us the opportunity to put all this routing information or publish this routing information where, for example, in BGP, we use all the routing information, so IRR gives the way to publish this information.

Also there are other advantages like various tools.

There is this tool set called IRR tool set. This is actually a set of tools developed for using the Internet Routing Registry. But the thing is for you to use these tools, you need to have correct information or correct routing information in the Whois Database.

Then once you have the correct information, correct routing policies and so on, you can use these tools to extract that information and create various, for example, like route configurations and so on.

IRR tool set: of course, IRR tool set, it has tools to do automated router configurations, routing policy analysis and do maintenance and so on. This is maintained by ISC now. Internet Systems Consortium, so you can actually get the IRR tool set. You can download it from ISC website and you can start using it.

Just want to focus one thing here which is there is a tool called RtConfig. That's part of the IRR tool set. You can use this IRR tool set or RtConfig basically to use those routing policies that are in the IRR and generate router configurations.

Usually when you do router configurations, the network engineers, when they configure routers and so on, sometimes you tend to do some typos, maybe mistakes and so on. If you use this kind of tool set, you might not really make many mistakes and so on, because the tool generates you the router configuration and it is more expressive, so you can even use all the filters and so on. So it's quite useful.

You can generate router configurations for various platforms, Cisco and Juniper and so on and you can create route maps and AS path filters and all your ingress and egress filters as well.

The benefits of RtConfig: avoid filter errors, typos and so on and, similarly, it is a way where you can use these consistent policies across, because since everyone registers, everyone publishes this information in a repository, it's much easier to generate the consistent routing policies and consistent router configurations as well. That's one of the main advantages.

Let's go into more some practical scenarios, how we can use RPSL in practice.

We'll take some cases or some case studies in this case to review some of the examples. We discussed about some of the examples earlier using quite simple policies where we define routing policies earlier, when I went through RPSL, and then of course we discussed about complex examples as well, but the only thing is that we did not express those policies too much.

It was not very scalable because we only used particular autonomous systems, we did not consider the case where if we are going to have more and more customers, we only talked about a very specific scenario, but in the case, you might have more customers joining, more autonomous system numbers, you are having, appearing with more autonomous systems and so on, in such cases, your routing policies can get quite complicated.

So your routing policies can get quite complicated and you have to have a proper way of simplifying these routing policies as well as you should be able to actually have those quite scalable as well. This is where we are trying to actually do some more of those simplifications and so on.

To review the RPSL: the purpose of RPSL, we discussed about it, it allows specification of router configurations in the public database to make it all consistent, and it also gives opportunities to consider the policies and configurations to others, we have all those tools and so on, so that's what we were talking about.

When you go through more RPSL into more detail, even if you go and read more about the RFC, you can find there are quite of lot of address prefix range operators, because you can use these operators to express your routing policies. You can use that.

What sort of operators do we have? We have quite a lot of operators, I'm not going to go through all the operators now. For more information, you can definitely refer to the RFC.

These are some examples you can see. If you see the first operator here, you can use that to specify some more exclusive prefix in this case. In this example, if you write that 128.9.0.0/16 and the operator, this contains all those more specific prefixes that include -- sorry, excluding that prefix, because there's a minus there, which is excluding the /16 prefix.

In the same way that if you see the next operator down there, which is actually the plus symbol, if you see that, that's a /8 that contains all the more specifics, plus that /8 itself.

In this way, you can actually be more expressive.

You can exclude certain prefixes, you can include certain prefixes and so on.

Similarly, you can also give some integer. In this case there's an integer called "n" which stands for all the length of the prefix length, "n". In this example, you have the /8 to /16, so we can define all those prefixes which are length of 16, because we have at length 16, we are defining that using that operator.

So you can define or you can express your routing policy in that way. Similarly, the next operator down there, "n-m". This can also get you a certain range.

In this example, 24 to 32 prefixes. So this contains all the more specifics which are length of 24 to 32.

For example, a /28 or a /27 and so on.

These are pretty important, pretty useful, if you have to create some filters. If you want filter some of the routes or some of the prefixes, these are quite useful, these prefix operators.

Then we also have these AS paths, the regular expressions. Because the thing is that when you try to express your routing policies, you also have to consider about our AS path as well. That is why you can also use these regular expressions to match those.

Some examples, some regular expressions here, they are pretty much like those UNIX regular expressions.

You can see that if there's a dot, that can match one character and similarly if you have a star, that can match any number of preceding expressions and so on.

For example, beginning of line, "$" says end of line, so in the same way there are a number of these regular expressions, where you can use these expressions in your routing policies.

Again, more information about these regular expressions is available in the RFC as well. Remember those few RFCs which I mentioned earlier, 2622, 2650 and so on, you can refer to them for more information about these.

These are again how you can use those AS path regular expressions. If you see the first example, which is AS3, that's with the brackets over there, so those are the routes whose AS path contains AS3 and similarly -- you can have many of those.

We will try to actually use this type of regular expressions and try to define routing policies. Earlier we defined routing policies as I said, remember, the few examples I took earlier, we defined routing policies, but we did not use these regular expressions, because it was only kind of very specific cases. We did not consider for a number of customers, number of peers and so on.

But in the real life, you may be having number of customers, number of peers and so on, so you want to make sure that your routing policies are quite scalable and also they are not too complicated, we keep it at simplified level, where we will use these expressions.

I'll take some examples, then you will see some more information.

Some of the common peering policies. In this case, you have five autonomous systems, so you have AS1, so that's actually not connected. That's upstream. There you have the Internet, the full routing table we receive. Then you have AS2, that's an ISP, a transit provider. Then also you have some customers here, so for example, AS3 is a customer, AS4 is a customer.

Peering policies of an AS, in this case, the registered autonomous system, our focus is on AS2, which is what we just highlighted. We are trying now to define the routing policy for this AS2 autonomous system.

If you see the autonomous system here -- remember, we are trying to define for the autonomous system 2, AS2. In the case of AS2, aut-num, the primary key, that is AS2. Then you go all the way down and then you'll see your import and export lines or attributes, inbound and outbound.

Import. If I go back to this scenario, that's the scenario, you are AS2. Your upstream is AS1. Then you have of course customer AS3.

Import. From AS1, remember, AS1 is your upstream.

From AS1, you want to receive the full routing table.

The key word we use is "ANY". So you receive the full routing table. From AS1, you accept "ANY".

Then also you have your customer, which is AS3 and you also accept AS3, but then we have some expressions there. If you go back to those expressions, you'll see the expressions I mentioned to you earlier, so that's the AS path. That's the AS path that starts with AS3 and ends with an AS3. Of course, AS3, the first member of the path and AS3 occurs one or more times in the path and no other AS can be present in the path after AS3.

Because that's what we want.

So that's your scenario. That's your customer which is AS3. That's why we define that using those regular expressions. Earlier, of course, the very first example I had, I just had AS3, just for explanation purposes.

This is kind of much better, more scalable. That's your import.

Then you have export. To AS3, remember, your AS3, that's your customer, you announce the full routing table. To AS3, you announce "ANY". AS3 announce "ANY".

Then also to AS1, that's your upstream ISP, what you do is your announce yourself and your customers -- I mean, the prefixes, routes from the customers. The second export line says to AS1, you announce yourself which is AS2 and then AS3. That's your customer.

The rest are administrative details. Basically now you have defined your routing policy, which is import and export lines using RPSL. Also we have used more expressive way. We have used those regular expressions.

There is also a scenario, remember, if you go to the diagram again, you have another customer which is AS4.

Let's say another customer joins in. Earlier you had AS3. Now you are going to have another customer which is AS4. Then what do we have to do? We have to add another line there. So we will add another line.

Earlier already we had AS3. We'll add another import line from AS4. That's for the new customer. From the AS4 you accept in the same way the prefixes or the routes from AS4.

Then also you are exporting the full routing table, so to AS4, you announce "ANY", that's the full routing table and then also the last one you need to add the AS4 into your -- because you have to announce AS4, that's your new customer, you need to announce that to your upstream provider, so to AS1, you announce AS2, that's yourself. AS3 is the other customer and AS4 is the new customer.

You can see that your routing policy is growing now.

Earlier we had only two import lines, two export lines.

But now we have three import lines and three export lines, so it has grown now.

This is where we can use these as-set objects.

Remember I went through as-set objects earlier? You can put these, you can create an as-set object and include members, so you can put your customer autonomous systems as members of that as-set object.

How do you do it? You create object as-set, so this time as-set, so we are AS2, we create as-set object AS customers. We have AS customers. And then who are the members going to be? AS3 and AS4. They are our customers. That's the as-set object.

Now what do you do? Then we can simplify our routing policy. How can we simplify our routing policy? Because -- remember earlier we had three import lines and three export lines? But we can take out two of those, because two of those are for very specific of those customers, AS3 and AS4, so we can replace those with the new as-set we created.

You would see your aut-num object, AS2, import from AS1, accept "ANY", that's fine, that's the full routing table, then import. Here we say AS2, AS customers. We are not saying one line for AS3. We are not saying another line for AS4. We are putting the as-set, so that we can simplify the whole thing.

Next time if we get an AS6 or AS7 or AS8, the more customers we have, we don't have to again come and add new import lines or new export lines into our policy.

We can always actually add that into the as-set.

They're only one of the members of the as-set, we add into the as-set and then we don't have to modify here of course because the as-set is already included.

Then similarly, the export lines, the export attribute to our customers, we announce the full routing table. We announce "ANY".

Similarly to AS1, you announce ourselves and our customers. You can see that AS3 is not in this policy.

AS4 is not here. Those things, you don't have to come again and again and update with your customer information or the customer AS numbers in this case.

It's a good practice.

Then of course from upstream side, our upstream is AS1, so from AS2, from upstream autonomous system, their policy would be from AS2, you accept AS2 plus AS2 customers.

Go further, now more into expressing the filtering policies as well. As I mentioned to you earlier, RPSL we can use, it is quite expressive, so we can use those operators which I mentioned to you earlier, to actually express more specific filtering policies.

Let's look at this case. Filtering policy. So we have two autonomous system. We have AS2 and AS3, so we have now AS2, the other side is the Internet. We are getting the full routing table. Then AS3, that is a certain prefix which has been allocated by RIR. In this case, it's a /20. That has been allocated to AS3 by the RIR.

The thing is the scenario is AS3 wants to announce part or all of this /20 on the global Internet. AS2 wants to be certain, to make sure that it only accepts -- remember the thing I mentioned earlier. If we are trying to -- if some customer comes to us and says, okay, to announce a certain prefix, we're not going to actually just announce as it is, because we don't know whether it's a legitimate prefix or not.

This is why we have the Internet Routing Registry and we can actually check for the legitimacy of those Internet or those prefixes.

AS2 wants to be certain that it only accepts announcements from AS3 for address space that has been properly allocated to AS3, just to make sure this block has been properly allocated to them and they are the resource holder, they are the proper resource holder for this particular /20.

This is the scenario, so we have to then create some filtering policies, based on this criteria.

How do we do that? Aut-num object with filtering policies. You can see, remember, the operators that we used earlier, you can use those operators, so we are actually in this example we are writing the policy or we are expressing the policy for AS2.

AS2 from import attribute from AS3, that's the other AS, this one, AS3, we want to accept only that particular prefix, but also any prefixes up to a /24.

That's what we want, because otherwise one thing is of course we don't want to get all the small prefixes like /27 and /28 and so on. We can then create a filtering policy based on that requirement.

From AS3, we accept only that /20 and then in the range of 20 to 24. That's your prefix length.

Obviously, for an ISP with a growing or changing customer base, this mechanism will again not scale well.

Remember what we discussed earlier. If we just do only one thing, sometimes if you are going to have more and more customers, it's not going to scale very well.

Just like in the previous case, when we have more customers, our AS numbers, we had to put more and more import lines to define those. What we did was we used those as-set objects.

In this case, similarly, if you're going to do filtering policies, you are going to deal with the route object, so this is where you will use route-set objects.

You can use route-sets here to simplify.

How do you use that? You have route-sets, you create a route-set, so you can see that in this case, you have created a route-set, so who are the members going to be? The members are the prefixes that you want to get. In this case, it's /20, in between /20 to 24, those prefixes, so that will specify all the routes that will be accepted from that given customer.

We have constructed this route-set of course hierarchically, AS2 and AS3, that's the scenario that we have, RS-routes. The first one, the AS2, that indicates whose sets are these. Then AS3 indicates the peer AS.

Then what do you do? Then you would go and apply that to your routing policy. You have your import attributes. First you have, from AS1, you accept "ANY", the full routing table, then you have your customer, which is AS3, you accept the route-set, because now you have certain prefixes that you have defined inside that route-set. They are the members of that route-set.

You do that for your first peer, which is AS3, and then similarly, you can do that for your other peers.

Let's say you are going to have another peer, so you do that for AS4 as well.

Similarly, when you have more and more customers, then you can include these expressions. RPSL allows the peer AS number to be replaced by the key word "PeerAS", also key word "PeerAS". We can see that AS3 and AS4, they are all our peers. If you are going to have more and more, AS5, AS6 and AS7 and so on, there you can replace all that with that key word, what we call "PeerAS", which makes it much simpler, much easier as well.

Finally, you would get your import attributes as from AS2, AS customers, remember, these are our AS customers. We have put all that into the as-set. We are not going to define each one by one.

Then you accept what routes, so that's using your route-set, you are not going to put all the prefixes separately one by one. We have the route-set. Then you also have put your "PeerAS", that's a key word, which can further simplify your policy.

You can even go further and even filter based on the interface level as well. In this scenario, you have your AS1, AS2 and then also you can see that there are certain interfaces. You can also actually define your routing policy based on the boundary router, for example.

In this case, AS1, you are writing the policy for AS1, so the import would be from AS2 at that IP address, if I go back to the slides, so the IP address now in AS1, that's the IP address in this case, 7.7.7.1, so that's where you want to accept. So at AS2 at 7.7.7.1, then you accept the prefixes from AS2, again with those regular expressions.

AS1, in this case, of course there are two interfaces in AS2 here, if you see in the diagram. In AS2, you have two interfaces, one is 7.7.7.2 and the other is 7.7.7.3. If you want to specifically say one of those interfaces, you can still do that.

Let's say you want to accept only those announcements from the router 7.7.7.2. Then you want to discard the 7.7.7.3. So you do it. We add an extra one which is from AS, 7.7.7.2 at that particular IP address which is 7.1 and then accept the AS2.

The last thing: actually, I have gone through a number of cases, in the situation of multi-homing, so in this case, you have AS1 and then you have customers AS2 and AS5. Then also AS3, they are all customers of AS1, AS2 and AS5 and AS3 and if you take AS4 is a customer of AS2 and AS3.

This kind of scenario, you can also, if you want to define the routing policy for AS1, you can go into more -- it's pretty similar -- all based on what we learnt so far, so import from AS2, you accept they are your customers, AS2 and AS4 and all those customers' customers. That's why you have that. From AS3 similarly, you have AS3 or AS4 and the others.

Similarly for AS5, accept AS5 and the others.

You can define these kinds of policies using RPSL.

Finally, just to summarise everything, because we are sort of getting almost to the end of the time that is allocated, what you need to do with all the summary, using the routing registry as a best practice, so define your routing policy properly in the Whois Database or the Internet Routing Registry, as we discussed.

After that, enter the policy into the IRR.

First of all, you have do do a bit of planning, define your routing policies and then enter that routing policy into the IRR and after that, run tools like RtConfig, IR tool set, which I mentioned to you. You can run that and then after that, you can apply those route configs to your routers. This is quite a good way to do it and then obviously when you change your routing policy, when you have different peering relationships and so on, you might want to actually go and change the routing policy and then the IRR as well.

This of course will have some cost and benefits altogether. Basically the costs are you need some initial planning first of all, because you have to write down all your policies, make sure you understand RPSL, make sure you can define all your routing policies and so on. This takes some time and some resources as well.

But then of course you need to again maintain this thing as well, so that also can be considered as a cost in terms of human resources and so on.

The benefits are you have a clear idea of your routing policy, you know what it is and it gives a very good global view of routing, everyone can see the same, consistent configurations over the whole network and then less manual work in the long run. Those are the important things.

I think that's about it. We discussed about the routing registry scope during this training. We discussed all those different types of ways you can define your routing policy, the way we went through RPSL, we went through those regular expressions, the operators, how you can create those, express those routing policies and you can use those in practice. I have taken you through some practical examples. We also talked about registering those in the IRR or the routing registry.

Again, most importantly, finally, this is a free service for APNIC members. If you are an APNIC member, you don't need to again pay and so on separately for this service. It's a free service. Feel free to start registering your routing information in the Whois Database.

All right. I think we are up on time. If you have any questions, I can take it now. Otherwise, you can come separately and offline I can talk to you during tea breaks or so during this week.

Okay. Seems not many questions.

All right. Thank you very much for your participation and hopefully you'll have a good week.

Thank you.

APPLAUSE