Differences

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

--- peering-toolbox:single_upstream_private_peer [2022/08/01 17:18] – [Letter of Authority] philip
+++ peering-toolbox:single_upstream_private_peer [2022/08/26 19:55] (current) – [ROA and Route Object] philip
@@ Line 10: / Line 10: @@
   - [[single_upstream_private_peer#bgp_with_upstream|Adding the peering, introducing BGP with the upstream]]
-A diagram describing the scenario being discussed is below.
+A diagram showing the typical physical layout of this scenario is shown below:
-{{:peering-toolbox:1-private-peer.png?500| }}
+{{:peering-toolbox:1-private-peer.png?400| }}
 ===== Enabling the Peer =====
@@ Line 65: / Line 65: @@
 The next step is to provide them with a [[single_upstream#letter_of_authority|Letter of Authority]] (if required) which requests their upstreams and peers to allow your address space originated by your ASN.
-LOAs are not usually required as a ROA should be enough to prove the holder of the address space and the origin ASN. But some operators insist on the LOA, still.
+LOAs are not usually required as a ROA is enough to prove the holder of the address space and the origin ASN. But some operators still insist on a LOA.
 ==== ROA and Route Object ====
-Confirm that the ROA (and Route Object) with your ASN as the origin of your address space is still present in your RIR's database. Note that if you are migrating from a static set up, do **NOT** delete the existing ROA (or Route Object) that declares their ASN as the origin - you still need it for now.
+Confirm that the [[peering-toolbox/route_origin_authorisation|ROA]] (and [[peering-toolbox/the_internet_routing_registry#route_object|Route Object]]) with your ASN as the origin of your address space is still present in your RIR's database. Note that if you are migrating from a static set up, do **NOT** delete the existing ROA (or Route Object) that declares their ASN as the origin - you still need it for now.
 ==== BGP Policy Configuration ====