Differences

This shows you the differences between two versions of the page.

--- peering-toolbox:the_internet_routing_registry [2022/05/06 15:35] – [Background] philip
+++ peering-toolbox:the_internet_routing_registry [2023/04/30 15:39] (current) – [Route Object] philip
@@ Line 13: / Line 13: @@
 Our advice is as follows:
   * Network Operators holding IP address distributed by an RIR should only use their RIR's instance of the Internet Routing Registry
-  * Network Operators holding IP address distributed by InterNIC (pre-existing the RIRs) means the Network Operator has to use RADB unless their RIR has a policy permiting them to use the RIR's intance of the IRR.
+  * Network Operators holding IP address distributed by InterNIC (pre-existing the RIRs) means the Network Operator has to use RADB unless their RIR has a policy permitting them to use the RIR's instance of the IRR.
 It is beyond the scope of the Peering Toolbox to provide a detailed tutorial about the operation of the Internet Routing Registry. However, we have to highlight the three key objects that all network operators need to be aware of, and one that is more or less mandatory in today's Internet. The following sections describe:
@@ Line 23: / Line 23: @@
 ===== Route Object =====
-The Route Object documents which Autonomous System is originating the route listed. It is required by many major transit providers because they build their customer and peer filter based on the route-
+The Route Object documents which Autonomous System is originating the route listed. It is required by many major transit providers because they build their customer and peer filter based on the route-objects listed in the IRR. Operators will refer to at least the 5 RIR routing registries and the RADB to check for route-objects. Those who run their own IRR instance will generally check there first before consulting with the IRR instances run elsewhere.
-objects listed in the IRR. Operators will refer to at least the 5 RIR routing registries and the RADB to check for route-objects. Those who run their own IRR instance will generally check there first before consulting with the IRR instances run elsewhere.
 A typical IPv4 route object may look like this:
@@ Line 35: / Line 34: @@
 The key ingredients of a route-object are:
-  * route/route6: identifying the IP address block
+  * **route/route6**: identifying the IP address block
-  * descr: describing what the block is about (useful but not essential)
+  * **descr**: describing what the block is about (useful but not essential)
-  * country: which country it is used in (can help with geolocation)
+  * **country**: which country it is used in (can help with geolocation)
-  * notify: who to notify if anything with the object changes
+  * **notify**: who to notify if anything with the object changes
-  * maint-by: who the maintainer of the object is
+  * **maint-by**: who the maintainer of the object is
-  * origin: the ASN which is originating this address block
+  * **origin**: the ASN which is originating this address block
-  * last-modified: when the object was last changed
+  * **last-modified**: when the object was last changed
-  * source: which instance of the IRR provided the data
+  * **source**: which instance of the IRR provided the data
 Operators who build their BGP filters based on the contents of the IRR will search all route-objects for their peer ASNs, and only accepte BGP announcements from peers (and customers) which have matching and correct route-objects. No route-object or an incorrect route-object, and the BGP announcement will not be accepted.
@@ Line 80: / Line 79: @@
 Then when the Network Operator needs to refer to outbound policy for its customers, rather than an entry for each customer ASN (and its own), it simply refers to its AS-set instead.
-[[:peering-toolbox/how-to-peer| Back to "What I need to Peer" page]]
+[[:peering-toolbox/how-to-peer| Back to "What is required for Peering" page]]