<?xml version="1.0" encoding="UTF-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1" version="1.1">
  <file original="NoName" source-language="en" datatype="plaintext" target-language="en">
    <body>
      <trans-unit xml:space="preserve" approved="no" id="f0486f65da5c2ee9" weblate-flags="read-only">
        <source>Interdomain routing</source>
        <target state="translated">Interdomain routing</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">5</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c396bb4fa28bc22e" weblate-flags="read-only">
        <source>As explained earlier, the Internet is composed of more than 45,000 different networks [#fasnum]_ called `domains`. Each domain is composed of a group of routers and hosts that are managed by the same organization. Example domains include belnet_, sprint_, level3_, geant_, abilene_, cisco_ or google_ ...</source>
        <target state="translated">As explained earlier, the Internet is composed of more than 45,000 different networks [#fasnum]_ called `domains`. Each domain is composed of a group of routers and hosts that are managed by the same organization. Example domains include belnet_, sprint_, level3_, geant_, abilene_, cisco_ or google_ ...</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">7</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8b7e26fc3f1dc609" weblate-flags="read-only">
        <source>Each domain contains a set of routers. From a routing point of view, these domains can be divided into two classes : the `transit` and the `stub` domains. A `stub` domain sends and receives packets whose source or destination are one of its own hosts. A `transit` domain is a domain that provides a transit service for other domains, i.e. the routers in this domain forward packets whose source and destination do not belong to the transit domain. As of this writing, about 85% of the domains in the Internet are stub domains [#fpotaroo]_. A `stub` domain that is connected to a single transit domain is called a `single-homed stub` (e.g., `S1` in the figure below.). A `multihomed stub` is a `stub` domain connected to two or more transit providers (e.g., `S2`).</source>
        <target state="translated">Each domain contains a set of routers. From a routing point of view, these domains can be divided into two classes : the `transit` and the `stub` domains. A `stub` domain sends and receives packets whose source or destination are one of its own hosts. A `transit` domain is a domain that provides a transit service for other domains, i.e. the routers in this domain forward packets whose source and destination do not belong to the transit domain. As of this writing, about 85% of the domains in the Internet are stub domains [#fpotaroo]_. A `stub` domain that is connected to a single transit domain is called a `single-homed stub` (e.g., `S1` in the figure below.). A `multihomed stub` is a `stub` domain connected to two or more transit providers (e.g., `S2`).</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">11</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f226fd189630877a" weblate-flags="read-only">
        <source>Transit and stub domains</source>
        <target state="translated">Transit and stub domains</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">17</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9f48e8b57a6cb66a" weblate-flags="read-only">
        <source>The stub domains can be further classified by considering whether they mainly send or receive packets. An `access-rich` stub domain is a domain that contains hosts that mainly receive packets. Typical examples include small ADSL- or cable modem-based Internet Service Providers or enterprise networks. On the other hand, a `content-rich` stub domain is a domain that mainly produces packets. Examples of `content-rich` stub domains include google_, yahoo_, microsoft_, facebook_ or content distribution networks such as akamai_ or limelight_. For the last few years, we have seen a rapid growth of these `content-rich` stub domains. Recent measurements [ATLAS2009]_ indicate that a growing fraction of all the packets exchanged on the Internet are produced in the data centers managed by these content providers.</source>
        <target state="translated">The stub domains can be further classified by considering whether they mainly send or receive packets. An `access-rich` stub domain is a domain that contains hosts that mainly receive packets. Typical examples include small ADSL- or cable modem-based Internet Service Providers or enterprise networks. On the other hand, a `content-rich` stub domain is a domain that mainly produces packets. Examples of `content-rich` stub domains include google_, yahoo_, microsoft_, facebook_ or content distribution networks such as akamai_ or limelight_. For the last few years, we have seen a rapid growth of these `content-rich` stub domains. Recent measurements [ATLAS2009]_ indicate that a growing fraction of all the packets exchanged on the Internet are produced in the data centers managed by these content providers.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">19</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7170d59e9de4e972" weblate-flags="read-only">
        <source>Domains need to be interconnected to allow a host inside a domain to exchange IP packets with hosts located in other domains. From a physical perspective, domains can be interconnected in two different ways. The first solution is to directly connect a router belonging to the first domain with a router inside the second domain. Such links between domains are called private interdomain links or `private peering links`. In practice, for redundancy or performance reasons, distinct physical links are usually established between different routers in the two domains that are interconnected.</source>
        <target state="translated">Domains need to be interconnected to allow a host inside a domain to exchange IP packets with hosts located in other domains. From a physical perspective, domains can be interconnected in two different ways. The first solution is to directly connect a router belonging to the first domain with a router inside the second domain. Such links between domains are called private interdomain links or `private peering links`. In practice, for redundancy or performance reasons, distinct physical links are usually established between different routers in the two domains that are interconnected.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">21</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7412c5091b7de553" weblate-flags="read-only">
        <source>Interconnection of two domains via a private peering link</source>
        <target state="translated">Interconnection of two domains via a private peering link</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">27</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4433742b30fc1790" weblate-flags="read-only">
        <source>Such `private peering links` are useful when, for example, an enterprise or university network needs to be connected to its Internet Service Provider. However, some domains are connected to hundreds of other domains [#fasrank]_ . For some of these domains, using only private peering links would be too costly. A better solution to allow many domains to cheaply interconnect are the `Internet eXchange Points` (:term:`IXP`). An :term:`IXP` is usually some space in a data center that hosts routers belonging to different domains. A domain willing to exchange packets with other domains present at the :term:`IXP` installs one of its routers on the :term:`IXP` and connects it to other routers inside its own network. The IXP contains a Local Area Network to which all the participating routers are connected. When two domains that are present at the IXP wish [#fwish]_ to exchange packets, they simply use the Local Area Network. IXPs are very popular in Europe and many Internet Service Providers and Content providers are present in these IXPs.</source>
        <target state="translated">Such `private peering links` are useful when, for example, an enterprise or university network needs to be connected to its Internet Service Provider. However, some domains are connected to hundreds of other domains [#fasrank]_ . For some of these domains, using only private peering links would be too costly. A better solution to allow many domains to cheaply interconnect are the `Internet eXchange Points` (:term:`IXP`). An :term:`IXP` is usually some space in a data center that hosts routers belonging to different domains. A domain willing to exchange packets with other domains present at the :term:`IXP` installs one of its routers on the :term:`IXP` and connects it to other routers inside its own network. The IXP contains a Local Area Network to which all the participating routers are connected. When two domains that are present at the IXP wish [#fwish]_ to exchange packets, they simply use the Local Area Network. IXPs are very popular in Europe and many Internet Service Providers and Content providers are present in these IXPs.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">33</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="dc2f22c1da77b325" weblate-flags="read-only">
        <source>Interconnection of two domains at an Internet eXchange Point</source>
        <target state="translated">Interconnection of two domains at an Internet eXchange Point</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">39</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fc8ee405b62b283c" weblate-flags="read-only">
        <source>In the early days of the Internet, domains would simply exchange all the routes they know to allow a host inside one domain to reach any host in the global Internet. However, in today's highly commercial Internet, this is no longer true as interdomain routing mainly needs to take into account the economical relationships between the domains. Furthermore, while intradomain routing usually prefers some routes over others based on their technical merits (e.g. prefer route with the minimum number of hops, prefer route with the minimum delay, prefer high bandwidth routes over low bandwidth ones, etc) interdomain routing mainly deals with economical issues. For interdomain routing, the cost of using a route is often more important than the quality of the route measured by its delay or bandwidth.</source>
        <target state="translated">In the early days of the Internet, domains would simply exchange all the routes they know to allow a host inside one domain to reach any host in the global Internet. However, in today's highly commercial Internet, this is no longer true as interdomain routing mainly needs to take into account the economical relationships between the domains. Furthermore, while intradomain routing usually prefers some routes over others based on their technical merits (e.g. prefer route with the minimum number of hops, prefer route with the minimum delay, prefer high bandwidth routes over low bandwidth ones, etc) interdomain routing mainly deals with economical issues. For interdomain routing, the cost of using a route is often more important than the quality of the route measured by its delay or bandwidth.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">41</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c1de327065cbc289" weblate-flags="read-only">
        <source>There are different types of economical relationships that can exist between domains. Interdomain routing converts these relationships into peering relationships between domains that are connected via peering links.</source>
        <target state="translated">There are different types of economical relationships that can exist between domains. Interdomain routing converts these relationships into peering relationships between domains that are connected via peering links.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">43</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8c273fb9cbc34391" weblate-flags="read-only">
        <source>The first category of peering relationship is the `customer-&gt;provider` relationship. Such a relationship is used when a customer domain pays an Internet Service Provider to be able to exchange packets with the global Internet over an interdomain link. A similar relationship is used when a small Internet Service Provider pays a larger Internet Service Provider to exchange packets with the global Internet.</source>
        <target state="translated">The first category of peering relationship is the `customer-&gt;provider` relationship. Such a relationship is used when a customer domain pays an Internet Service Provider to be able to exchange packets with the global Internet over an interdomain link. A similar relationship is used when a small Internet Service Provider pays a larger Internet Service Provider to exchange packets with the global Internet.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">47</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="20a2124164d5c1eb" weblate-flags="read-only">
        <source>A simple Internet with peering relationships</source>
        <target state="translated">A simple Internet with peering relationships</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">53</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fa0e71300aae4d6d" weblate-flags="read-only">
        <source>To understand the `customer-&gt;provider` relationship, let us consider the simple internetwork shown in the figure above. In this internetwork, `AS7` is a stub domain that is connected to one provider : `AS4`. The contract between `AS4` and `AS7` allows a host inside `AS7` to exchange packets with any host in the internetwork. To enable this exchange of packets, `AS7` must know a route towards any domain and all the domains of the internetwork must know a route via `AS4` that allows them to reach hosts inside `AS7`. From a routing perspective, the commercial contract between `AS7` and `AS4` leads to the following routes being exchanged :</source>
        <target state="translated">To understand the `customer-&gt;provider` relationship, let us consider the simple internetwork shown in the figure above. In this internetwork, `AS7` is a stub domain that is connected to one provider : `AS4`. The contract between `AS4` and `AS7` allows a host inside `AS7` to exchange packets with any host in the internetwork. To enable this exchange of packets, `AS7` must know a route towards any domain and all the domains of the internetwork must know a route via `AS4` that allows them to reach hosts inside `AS7`. From a routing perspective, the commercial contract between `AS7` and `AS4` leads to the following routes being exchanged :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">55</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0137f052b8c70078" weblate-flags="read-only">
        <source>over a `customer-&gt;provider` relationship, the `customer` domain advertises to its `provider`  its own prefixes and all the routes that it has learned from its own customers.</source>
        <target state="translated">over a `customer-&gt;provider` relationship, the `customer` domain advertises to its `provider`  its own prefixes and all the routes that it has learned from its own customers.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">57</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f307655f20e1086d" weblate-flags="read-only">
        <source>over a `provider-&gt;customer` relationship, the `provider` advertises all the routes that it knows to its `customer`.</source>
        <target state="translated">over a `provider-&gt;customer` relationship, the `provider` advertises all the routes that it knows to its `customer`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">58</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3d3368e47844aa28" weblate-flags="read-only">
        <source>The second rule ensures that the customer domain receives a route towards all destinations that are reachable via its provider. The first rule allows the prefixes of the customer domain to be distributed throughout the Internet.</source>
        <target state="translated">The second rule ensures that the customer domain receives a route towards all destinations that are reachable via its provider. The first rule allows the prefixes of the customer domain to be distributed throughout the Internet.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">60</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b424d89b4fbe4283" weblate-flags="read-only">
        <source>Coming back to the figure above, `AS4` advertises to its two providers `AS1` and `AS2` its own prefixes and the routes learned from its customer, `AS7`. On the other hand, `AS4` advertises to `AS7` all the routes that it knows.</source>
        <target state="translated">Coming back to the figure above, `AS4` advertises to its two providers `AS1` and `AS2` its own prefixes and the routes learned from its customer, `AS7`. On the other hand, `AS4` advertises to `AS7` all the routes that it knows.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">62</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6047d4aae67f39fa" weblate-flags="read-only">
        <source>The second type of peering relationship is the `shared-cost` peering relationship. Such a relationship usually does not involve a payment from one domain to the other in contrast with the `customer-&gt;provider` relationship. A `shared-cost` peering relationship is usually established between domains having a similar size and geographic coverage. For example, consider the figure above. If `AS3` and `AS4` exchange many packets via `AS1`, they both need to pay `AS1`. A cheaper alternative for `AS3` and `AS4` would be to establish a `shared-cost` peering. Such a peering can be established at IXPs where both `AS3` and `AS4` are present or by using private peering links. This `shared-cost` peering should be used to exchange packets between hosts inside `AS3` and hosts inside `AS4`. However, `AS3` does not want to receive on the `AS3-AS4` `shared-cost` peering links packets whose destination belongs to `AS1` as `AS3` would have to pay to send these packets to `AS1`.</source>
        <target state="translated">The second type of peering relationship is the `shared-cost` peering relationship. Such a relationship usually does not involve a payment from one domain to the other in contrast with the `customer-&gt;provider` relationship. A `shared-cost` peering relationship is usually established between domains having a similar size and geographic coverage. For example, consider the figure above. If `AS3` and `AS4` exchange many packets via `AS1`, they both need to pay `AS1`. A cheaper alternative for `AS3` and `AS4` would be to establish a `shared-cost` peering. Such a peering can be established at IXPs where both `AS3` and `AS4` are present or by using private peering links. This `shared-cost` peering should be used to exchange packets between hosts inside `AS3` and hosts inside `AS4`. However, `AS3` does not want to receive on the `AS3-AS4` `shared-cost` peering links packets whose destination belongs to `AS1` as `AS3` would have to pay to send these packets to `AS1`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">66</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bb2c6d4acf90af58" weblate-flags="read-only">
        <source>From a routing perspective, over a `shared-cost` peering relationship a domain only advertises its internal routes/prefixes and the routes that it has learned from its customers. This restriction ensures that only packets destined to the local domain or one of its customers is received over the `shared-cost` peering relationship. This implies that the routes that have been learned from a provider or from another `shared-cost` peer is not advertised over a `shared-cost` peering relationship. This is motivated by economical reasons. If a domain were to advertise the routes that it learned from a provider over a `shared-cost` peering relationship that does not bring revenue, it would have allowed its `shared-cost` peer to use the link with its provider without any payment. If a domain were to advertise the routes it learned over a `shared cost` peering over another `shared-cost` peering relationship, it would have allowed these `shared-cost` peers to use its own network (which may span one or more continents) freely to exchange packets.</source>
        <target state="translated">From a routing perspective, over a `shared-cost` peering relationship a domain only advertises its internal routes/prefixes and the routes that it has learned from its customers. This restriction ensures that only packets destined to the local domain or one of its customers is received over the `shared-cost` peering relationship. This implies that the routes that have been learned from a provider or from another `shared-cost` peer is not advertised over a `shared-cost` peering relationship. This is motivated by economical reasons. If a domain were to advertise the routes that it learned from a provider over a `shared-cost` peering relationship that does not bring revenue, it would have allowed its `shared-cost` peer to use the link with its provider without any payment. If a domain were to advertise the routes it learned over a `shared cost` peering over another `shared-cost` peering relationship, it would have allowed these `shared-cost` peers to use its own network (which may span one or more continents) freely to exchange packets.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">68</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c5795263984e6a18" weblate-flags="read-only">
        <source>Finally, the last type of peering relationship is the `sibling`. Such a relationship is used when two domains exchange all their routes in both directions. In practice, such a relationship is only used between domains that belong to the same company.</source>
        <target state="translated">Finally, the last type of peering relationship is the `sibling`. Such a relationship is used when two domains exchange all their routes in both directions. In practice, such a relationship is only used between domains that belong to the same company.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">72</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e6bc51146de7acfd" weblate-flags="read-only">
        <source>These different types of relationships are implemented in the `interdomain routing policies` defined by each domain. The `interdomain routing policy` of a domain is composed of three main parts :</source>
        <target state="translated">These different types of relationships are implemented in the `interdomain routing policies` defined by each domain. The `interdomain routing policy` of a domain is composed of three main parts :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">76</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d18a0ce36351e7d5" weblate-flags="read-only">
        <source>the `import filter` that specifies, for each peering relationship, the routes that can be accepted from the neighboring domain (the non-acceptable routes are ignored and the domain never uses them to forward packets)</source>
        <target state="translated">the `import filter` that specifies, for each peering relationship, the routes that can be accepted from the neighboring domain (the non-acceptable routes are ignored and the domain never uses them to forward packets)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">78</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bc6443c3f8746a68" weblate-flags="read-only">
        <source>the `export filter` that specifies, for each peering relationship, the routes that can be advertised to the neighboring domain</source>
        <target state="translated">the `export filter` that specifies, for each peering relationship, the routes that can be advertised to the neighboring domain</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">79</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ebde26cee206400e" weblate-flags="read-only">
        <source>the `ranking` algorithm that is used to select the best route among all the routes that the domain has received towards the same destination prefix</source>
        <target state="translated">the `ranking` algorithm that is used to select the best route among all the routes that the domain has received towards the same destination prefix</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">80</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0d21952d092d1119" weblate-flags="read-only">
        <source>A domain's import and export filters can be defined by using the Route Policy Specification Language (RPSL) specified in :rfc:`2622` [GAVE1999]_ . Some Internet Service Providers, notably in Europe, use RPSL to document [#fripedb]_ their import and export policies. Several tools help to easily convert a RPSL policy into router commands.</source>
        <target state="translated">A domain's import and export filters can be defined by using the Route Policy Specification Language (RPSL) specified in :rfc:`2622` [GAVE1999]_ . Some Internet Service Providers, notably in Europe, use RPSL to document [#fripedb]_ their import and export policies. Several tools help to easily convert a RPSL policy into router commands.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">84</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d2b6208025565aa6" weblate-flags="read-only">
        <source>The figure below provides a simple example of import and export filters for two domains in a simple internetwork. In RPSL, the keyword `ANY` is used to replace any route from any domain. It is typically used by a provider to indicate that it announces all its routes to a customer over a `provider-&gt;customer` relationship. This is the case for `AS4`'s export policy. The example below clearly shows the difference between a `provider-&gt;customer` and a `shared-cost` peering relationship. `AS4`'s export filter indicates that it announces only its internal routes (`AS4`) and the routes learned from its clients (`AS7`) over its `shared-cost` peering with `AS3`, while it advertises all the routes that it uses (including the routes learned from `AS3`) to `AS7`.</source>
        <target state="translated">The figure below provides a simple example of import and export filters for two domains in a simple internetwork. In RPSL, the keyword `ANY` is used to replace any route from any domain. It is typically used by a provider to indicate that it announces all its routes to a customer over a `provider-&gt;customer` relationship. This is the case for `AS4`'s export policy. The example below clearly shows the difference between a `provider-&gt;customer` and a `shared-cost` peering relationship. `AS4`'s export filter indicates that it announces only its internal routes (`AS4`) and the routes learned from its clients (`AS7`) over its `shared-cost` peering with `AS3`, while it advertises all the routes that it uses (including the routes learned from `AS3`) to `AS7`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">86</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8235011fd2981ac7" weblate-flags="read-only">
        <source>Import and export policies</source>
        <target state="translated">Import and export policies</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">92</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="df335f30a5048b8f" weblate-flags="read-only">
        <source>The Border Gateway Protocol</source>
        <target state="translated">The Border Gateway Protocol</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">97</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d01b58c52eeba0ca" weblate-flags="read-only">
        <source>The Internet uses a single interdomain routing protocol : the Border Gateway Protocol (BGP). The current version of BGP is defined in :rfc:`4271`. BGP differs from the intradomain routing protocols that we have already discussed in several ways. First, BGP is a `path-vector` protocol. When a BGP router advertises a route towards a prefix, it announces the IP prefix and the interdomain path used to reach this prefix. From BGP's point of view, each domain is identified by a unique `Autonomous System` (AS) number [#fasdomain]_ and the interdomain path contains the AS numbers of the transit domains that are used to reach the associated prefix. This interdomain path is called the `AS Path`. Thanks to these AS-Paths, BGP does not suffer from the count-to-infinity problems that affect distance vector routing protocols. Furthermore, the AS-Path can be used to implement some routing policies. Another difference between BGP and the intradomain routing protocols is that a BGP router does not send the entire contents of its routing table to its neighbors regularly. Given the size of the global Internet, routers would be overloaded by the number of BGP messages that they would need to process. BGP uses incremental updates, i.e. it only announces the routes that have changed to its neighbors.</source>
        <target state="translated">The Internet uses a single interdomain routing protocol : the Border Gateway Protocol (BGP). The current version of BGP is defined in :rfc:`4271`. BGP differs from the intradomain routing protocols that we have already discussed in several ways. First, BGP is a `path-vector` protocol. When a BGP router advertises a route towards a prefix, it announces the IP prefix and the interdomain path used to reach this prefix. From BGP's point of view, each domain is identified by a unique `Autonomous System` (AS) number [#fasdomain]_ and the interdomain path contains the AS numbers of the transit domains that are used to reach the associated prefix. This interdomain path is called the `AS Path`. Thanks to these AS-Paths, BGP does not suffer from the count-to-infinity problems that affect distance vector routing protocols. Furthermore, the AS-Path can be used to implement some routing policies. Another difference between BGP and the intradomain routing protocols is that a BGP router does not send the entire contents of its routing table to its neighbors regularly. Given the size of the global Internet, routers would be overloaded by the number of BGP messages that they would need to process. BGP uses incremental updates, i.e. it only announces the routes that have changed to its neighbors.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">99</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="88149f0e841b0c33" weblate-flags="read-only">
        <source>The figure below shows a simple example of the BGP routes that are exchanged between domains. In this example, prefix `2001:db8:cafe::/48` is announced by `AS1`. `AS1` advertises a BGP route towards this prefix to `AS2`. The AS-Path of this route indicates that `AS1` is the originator of the prefix. When `AS4` receives the BGP route from `AS1`, it re-announces it to `AS2` and adds its AS number to the AS-Path. `AS2` has learned two routes towards prefix `2001:db8:cafe::/48`. It compares the two routes and prefers the route learned from `AS4` based on its own ranking algorithm. `AS2` advertises to `AS5` a route towards `2001:db8:cafe::/48` with its AS-Path set to `AS2:AS4:AS1`. Thanks to the AS-Path, `AS5` knows that if it sends a packet towards `2001:db8:cafe::/48` the packet first passes through `AS2`, then through `AS4` before reaching its destination inside `AS1`.</source>
        <target state="translated">The figure below shows a simple example of the BGP routes that are exchanged between domains. In this example, prefix `2001:db8:cafe::/48` is announced by `AS1`. `AS1` advertises a BGP route towards this prefix to `AS2`. The AS-Path of this route indicates that `AS1` is the originator of the prefix. When `AS4` receives the BGP route from `AS1`, it re-announces it to `AS2` and adds its AS number to the AS-Path. `AS2` has learned two routes towards prefix `2001:db8:cafe::/48`. It compares the two routes and prefers the route learned from `AS4` based on its own ranking algorithm. `AS2` advertises to `AS5` a route towards `2001:db8:cafe::/48` with its AS-Path set to `AS2:AS4:AS1`. Thanks to the AS-Path, `AS5` knows that if it sends a packet towards `2001:db8:cafe::/48` the packet first passes through `AS2`, then through `AS4` before reaching its destination inside `AS1`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">101</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5f64f81111028cfa" weblate-flags="read-only">
        <source>Simple exchange of BGP routes</source>
        <target state="translated">Simple exchange of BGP routes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">106</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="aab4dbf115645eb6" weblate-flags="read-only">
        <source>BGP routers exchange routes over BGP sessions. A BGP session is established between two routers belonging to two different domains that are directly connected. As explained earlier, the physical connection between the two routers can be implemented as a private peering link or over an Internet eXchange Point. A BGP session between two adjacent routers runs above a TCP connection (the default BGP port is 179). In contrast with intradomain routing protocols that exchange IP packets or UDP segments, BGP runs above TCP because TCP ensures a reliable delivery of the BGP messages sent by each router without forcing the routers to implement acknowledgments, checksums, etc. Furthermore, the two routers consider the peering link to be up as long as the BGP session and the underlying TCP connection remain up [#flifetimebgp]_. The two endpoints of a BGP session are called `BGP peers`.</source>
        <target state="translated">BGP routers exchange routes over BGP sessions. A BGP session is established between two routers belonging to two different domains that are directly connected. As explained earlier, the physical connection between the two routers can be implemented as a private peering link or over an Internet eXchange Point. A BGP session between two adjacent routers runs above a TCP connection (the default BGP port is 179). In contrast with intradomain routing protocols that exchange IP packets or UDP segments, BGP runs above TCP because TCP ensures a reliable delivery of the BGP messages sent by each router without forcing the routers to implement acknowledgments, checksums, etc. Furthermore, the two routers consider the peering link to be up as long as the BGP session and the underlying TCP connection remain up [#flifetimebgp]_. The two endpoints of a BGP session are called `BGP peers`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">110</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="478230ea83289317" weblate-flags="read-only">
        <source>A BGP peering session between two directly connected routers</source>
        <target state="translated">A BGP peering session between two directly connected routers</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">116</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="48c7fe964275067b" weblate-flags="read-only">
        <source>In practice, to establish a BGP session between routers `R1` and `R2` in the figure above, the network administrator of `AS3` must first configure on `R1` the IP address of `R2` on the `R1-R2` link and the AS number of `R2`. Router `R1` then regularly tries to establish the BGP session with `R2`. `R2` only agrees to establish the BGP session with `R1` once it has been configured with the IP address of `R1` and its AS number. For security reasons, a router never establishes a BGP session that has not been manually configured on the router.</source>
        <target state="translated">In practice, to establish a BGP session between routers `R1` and `R2` in the figure above, the network administrator of `AS3` must first configure on `R1` the IP address of `R2` on the `R1-R2` link and the AS number of `R2`. Router `R1` then regularly tries to establish the BGP session with `R2`. `R2` only agrees to establish the BGP session with `R1` once it has been configured with the IP address of `R1` and its AS number. For security reasons, a router never establishes a BGP session that has not been manually configured on the router.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">118</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7b49b6657e2c0340" weblate-flags="read-only">
        <source>The BGP protocol :rfc:`4271` defines several types of messages that can be exchanged over a BGP session :</source>
        <target state="translated">The BGP protocol :rfc:`4271` defines several types of messages that can be exchanged over a BGP session :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">122</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a7ddd5c6412fbe48" weblate-flags="read-only">
        <source>`OPEN` : this message is sent as soon as the TCP connection between the two routers has been established. It initializes the BGP session and allows the negotiation of some options. Details about this message may be found in :rfc:`4271`.</source>
        <target state="translated">`OPEN` : this message is sent as soon as the TCP connection between the two routers has been established. It initializes the BGP session and allows the negotiation of some options. Details about this message may be found in :rfc:`4271`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">124</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f901240d61dedd0f" weblate-flags="read-only">
        <source>`NOTIFICATION` : this message is used to terminate a BGP session, usually because an error has been detected by the BGP peer. A router that sends or receives a `NOTIFICATION` message immediately shutdowns the corresponding BGP session.</source>
        <target state="translated">`NOTIFICATION` : this message is used to terminate a BGP session, usually because an error has been detected by the BGP peer. A router that sends or receives a `NOTIFICATION` message immediately shutdowns the corresponding BGP session.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">125</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7e0415bfbbc313d5" weblate-flags="read-only">
        <source>`UPDATE`: this message is used to advertise new or modified routes or to withdraw previously advertised routes.</source>
        <target state="translated">`UPDATE`: this message is used to advertise new or modified routes or to withdraw previously advertised routes.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">126</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="474b23d4ec6e789c" weblate-flags="read-only">
        <source>`KEEPALIVE` : this message is used to ensure a regular exchange of messages on the BGP session, even when no route changes. When a BGP router has not sent an `UPDATE` message during the last 30 seconds, it shall send a `KEEPALIVE` message to confirm to the other peer that it is still up. If a peer does not receive any BGP message during a period of 90 seconds [#fdefaultkeepalive]_, the BGP session is considered to be down and all the routes learned over this session are withdrawn.</source>
        <target state="translated">`KEEPALIVE` : this message is used to ensure a regular exchange of messages on the BGP session, even when no route changes. When a BGP router has not sent an `UPDATE` message during the last 30 seconds, it shall send a `KEEPALIVE` message to confirm to the other peer that it is still up. If a peer does not receive any BGP message during a period of 90 seconds [#fdefaultkeepalive]_, the BGP session is considered to be down and all the routes learned over this session are withdrawn.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">127</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="667b7268f9ce110e" weblate-flags="read-only">
        <source>As explained earlier, BGP relies on incremental updates. This implies that when a BGP session starts, each router first sends BGP `UPDATE` messages to advertise to the other peer all the exportable routes that it knows. Once all these routes have been advertised, the BGP router only sends BGP `UPDATE` messages about a prefix if the route is new, one of its attributes has changed or the route became unreachable and must be withdrawn. The BGP `UPDATE` message allows BGP routers to efficiently exchange such information while minimizing the number of bytes exchanged. Each `UPDATE` message contains :</source>
        <target state="translated">As explained earlier, BGP relies on incremental updates. This implies that when a BGP session starts, each router first sends BGP `UPDATE` messages to advertise to the other peer all the exportable routes that it knows. Once all these routes have been advertised, the BGP router only sends BGP `UPDATE` messages about a prefix if the route is new, one of its attributes has changed or the route became unreachable and must be withdrawn. The BGP `UPDATE` message allows BGP routers to efficiently exchange such information while minimizing the number of bytes exchanged. Each `UPDATE` message contains :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">129</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="416a2d14fec9d180" weblate-flags="read-only">
        <source>a list of IP prefixes that are withdrawn</source>
        <target state="translated">a list of IP prefixes that are withdrawn</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">131</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4271cbcc54ad355f" weblate-flags="read-only">
        <source>a list of IP prefixes that are (re-)advertised</source>
        <target state="translated">a list of IP prefixes that are (re-)advertised</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">132</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4fdc1ae71a28fc13" weblate-flags="read-only">
        <source>the set of attributes (e.g. AS-Path) associated to the advertised prefixes</source>
        <target state="translated">the set of attributes (e.g. AS-Path) associated to the advertised prefixes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">133</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="436d353ef444dbc6" weblate-flags="read-only">
        <source>In the remainder of this chapter, and although all routing information is exchanged using BGP `UPDATE` messages, we assume for simplicity that a BGP message contains only information about one prefix and we use the words :</source>
        <target state="translated">In the remainder of this chapter, and although all routing information is exchanged using BGP `UPDATE` messages, we assume for simplicity that a BGP message contains only information about one prefix and we use the words :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">135</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8f1e4ac95975c91f" weblate-flags="read-only">
        <source>`Withdraw message` to indicate a BGP `UPDATE` message containing one route that is withdrawn</source>
        <target state="translated">`Withdraw message` to indicate a BGP `UPDATE` message containing one route that is withdrawn</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">137</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2a97c8d49a712150" weblate-flags="read-only">
        <source>`Update message` to indicate a BGP `UPDATE` containing a new or updated route towards one destination prefix with its attributes</source>
        <target state="translated">`Update message` to indicate a BGP `UPDATE` containing a new or updated route towards one destination prefix with its attributes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">138</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bebcc40060a26817" weblate-flags="read-only">
        <source>From a conceptual point of view, a BGP router connected to `N` BGP peers, can be described as being composed of four parts as shown in the figure below.</source>
        <target state="translated">From a conceptual point of view, a BGP router connected to `N` BGP peers, can be described as being composed of four parts as shown in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">143</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a0bf5a37f81489a1" weblate-flags="read-only">
        <source>Organization of a BGP router</source>
        <target state="translated">Organization of a BGP router</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">151</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f95a88965a9608e3" weblate-flags="read-only">
        <source>In this figure, the router receives BGP messages on the left part of the figure, processes these messages and possibly sends BGP messages on the right part of the figure. A BGP router contains three important data structures :</source>
        <target state="translated">In this figure, the router receives BGP messages on the left part of the figure, processes these messages and possibly sends BGP messages on the right part of the figure. A BGP router contains three important data structures :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">159</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bece3ff3be0bd5f4" weblate-flags="read-only">
        <source>the `Adj-RIB-In` contains the BGP routes that have been received from each BGP peer. The routes in the `Adj-RIB-In` are filtered by the `import filter` before being placed in the `BGP-Loc-RIB`. There is one `import filter` per BGP peer.</source>
        <target state="translated">the `Adj-RIB-In` contains the BGP routes that have been received from each BGP peer. The routes in the `Adj-RIB-In` are filtered by the `import filter` before being placed in the `BGP-Loc-RIB`. There is one `import filter` per BGP peer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">161</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c904028e3feb9681" weblate-flags="read-only">
        <source>the `Local Routing Information Base` (`Loc-RIB`) contains all the routes that are considered as acceptable by the router. The `Loc-RIB` may contain several routes, learned from different BGP peers, towards the same destination prefix.</source>
        <target state="translated">the `Local Routing Information Base` (`Loc-RIB`) contains all the routes that are considered as acceptable by the router. The `Loc-RIB` may contain several routes, learned from different BGP peers, towards the same destination prefix.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">162</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="05123b3822834469" weblate-flags="read-only">
        <source>the `Forwarding Information Base` (`FIB`) is used by the dataplane to forward packets towards their destination. The `FIB` contains, for each destination, the best route that has been selected by the `BGP decision process`. This decision process is an algorithm that selects, for each destination prefix, the best route according to the router's ranking algorithm that is part of its policy.</source>
        <target state="translated">the `Forwarding Information Base` (`FIB`) is used by the dataplane to forward packets towards their destination. The `FIB` contains, for each destination, the best route that has been selected by the `BGP decision process`. This decision process is an algorithm that selects, for each destination prefix, the best route according to the router's ranking algorithm that is part of its policy.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">163</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="afb85517cea81a87" weblate-flags="read-only">
        <source>the `Adj-RIB-Out` contains the BGP routes that have been advertised to each BGP peer. The `Adj-RIB-Out` for a given peer is built by applying the peer's `export filter` on the routes that have been installed in the `FIB`. There is one `export filter` per BGP peer. For this reason, the Adj-RIB-Out of a peer may contain different routes than the Adj-RIB-Out of another peer.</source>
        <target state="translated">the `Adj-RIB-Out` contains the BGP routes that have been advertised to each BGP peer. The `Adj-RIB-Out` for a given peer is built by applying the peer's `export filter` on the routes that have been installed in the `FIB`. There is one `export filter` per BGP peer. For this reason, the Adj-RIB-Out of a peer may contain different routes than the Adj-RIB-Out of another peer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">164</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c224cea79a6108f2" weblate-flags="read-only">
        <source>When a BGP session starts, the routers first exchange `OPEN` messages to negotiate the options that apply throughout the entire session. Then, each router extracts from its FIB the routes to be advertised to the peer. It is important to note that, for each known destination prefix, a BGP router can only advertise to a peer the route that it has itself installed inside its `FIB`. The routes that are advertised to a peer must pass the peer's `export filter`. The `export filter` is a set of rules that define which routes can be advertised over the corresponding session, possibly after having modified some of its attributes. One `export filter` is associated to each BGP session. For example, on a `shared-cost peering`, the `export filter` only selects the internal routes and the routes that have been learned from a `customer`. The pseudo-code below shows the initialization of a BGP session.</source>
        <target state="translated">When a BGP session starts, the routers first exchange `OPEN` messages to negotiate the options that apply throughout the entire session. Then, each router extracts from its FIB the routes to be advertised to the peer. It is important to note that, for each known destination prefix, a BGP router can only advertise to a peer the route that it has itself installed inside its `FIB`. The routes that are advertised to a peer must pass the peer's `export filter`. The `export filter` is a set of rules that define which routes can be advertised over the corresponding session, possibly after having modified some of its attributes. One `export filter` is associated to each BGP session. For example, on a `shared-cost peering`, the `export filter` only selects the internal routes and the routes that have been learned from a `customer`. The pseudo-code below shows the initialization of a BGP session.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">166</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c8730c89e81b6b64" weblate-flags="read-only">
        <source>In the above pseudo-code, the `build\_BGP\_update(d)` procedure extracts from the `BGP Loc-RIB` the best path towards destination `d` (i.e. the route installed in the FIB) and prepares the corresponding BGP `UPDATE` message. This message is then passed to the `export filter` that returns `None` if the route cannot be advertised to the peer or the (possibly modified) BGP `UPDATE` message to be advertised. BGP routers allow network administrators to specify very complex `export filters`, see e.g. [WMS2004]_. A simple `export filter` that implements the equivalent of `split horizon` is shown below.</source>
        <target state="translated">In the above pseudo-code, the `build\_BGP\_update(d)` procedure extracts from the `BGP Loc-RIB` the best path towards destination `d` (i.e. the route installed in the FIB) and prepares the corresponding BGP `UPDATE` message. This message is then passed to the `export filter` that returns `None` if the route cannot be advertised to the peer or the (possibly modified) BGP `UPDATE` message to be advertised. BGP routers allow network administrators to specify very complex `export filters`, see e.g. [WMS2004]_. A simple `export filter` that implements the equivalent of `split horizon` is shown below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">184</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2f385b01c838c2a2" weblate-flags="read-only">
        <source>At this point, the remote router has received all the exportable BGP routes. After this initial exchange, the router only sends `BGP UPDATE` messages when there is a change (addition of a route, removal of a route or change in the attributes of a route) in one of these exportable routes. Such a change can happen when the router receives a BGP message. The pseudo-code below summarizes the processing of these BGP messages.</source>
        <target state="translated">At this point, the remote router has received all the exportable BGP routes. After this initial exchange, the router only sends `BGP UPDATE` messages when there is a change (addition of a route, removal of a route or change in the attributes of a route) in one of these exportable routes. Such a change can happen when the router receives a BGP message. The pseudo-code below summarizes the processing of these BGP messages.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">197</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c475e20855b7861c" weblate-flags="read-only">
        <source>When a BGP message is received, the router first applies the peer's `import filter` to verify whether the message is acceptable or not. If the message is not acceptable, the processing stops. The pseudo-code below shows a simple `import filter`. This `import filter` accepts all routes, except those that already contain the local AS in their AS-Path. If such a route was used, it would cause a routing loop. Another example of an `import filter` would be a filter used by an Internet Service Provider on a session with a customer to only accept routes towards the IP prefixes assigned to the customer by the provider. On real routers, `import filters` can be much more complex and some `import filters` modify the attributes of the received BGP `UPDATE` [WMS2004]_ .</source>
        <target state="translated">When a BGP message is received, the router first applies the peer's `import filter` to verify whether the message is acceptable or not. If the message is not acceptable, the processing stops. The pseudo-code below shows a simple `import filter`. This `import filter` accepts all routes, except those that already contain the local AS in their AS-Path. If such a route was used, it would cause a routing loop. Another example of an `import filter` would be a filter used by an Internet Service Provider on a session with a customer to only accept routes towards the IP prefixes assigned to the customer by the provider. On real routers, `import filters` can be much more complex and some `import filters` modify the attributes of the received BGP `UPDATE` [WMS2004]_ .</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">237</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6e494f50b8efe93a" weblate-flags="read-only">
        <source>The bogon filters</source>
        <target state="translated">The bogon filters</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">256</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8f0fefa3fe0a7287" weblate-flags="read-only">
        <source>Another example of frequently used `import filters` are the filters that Internet Service Providers use to ignore bogon routes. In the ISP community, a bogon route is a route that should not be advertised on the global Internet. Typical examples include the documentation IPv6 prefix (`2001:db8::/32` used for most examples in this book), the loopback address (`::1/128`) or the IPv6 prefixes that have not yet been allocated by IANA. A well managed BGP router should ensure that it never advertises bogons on the global Internet. Detailed information about these bogons may be found in [IMHM2013]_.</source>
        <target state="translated">Another example of frequently used `import filters` are the filters that Internet Service Providers use to ignore bogon routes. In the ISP community, a bogon route is a route that should not be advertised on the global Internet. Typical examples include the documentation IPv6 prefix (`2001:db8::/32` used for most examples in this book), the loopback address (`::1/128`) or the IPv6 prefixes that have not yet been allocated by IANA. A well managed BGP router should ensure that it never advertises bogons on the global Internet. Detailed information about these bogons may be found in [IMHM2013]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">258</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="eba15c36f41fe65c" weblate-flags="read-only">
        <source>If the import filter accepts the BGP message, the pseudo-code distinguishes two cases. If this is an `Update message` for prefix `p`, this can be a new route for this prefix or a modification of the route's attributes. The router first retrieves from its `RIB` the best route towards prefix `p`. Then, the new route is inserted in the `RIB` and the `BGP decision process` is run to find whether the best route towards destination `p` changes. A BGP message only needs to be sent to the router's peers if the best route has changed. For each peer, the router applies the  `export filter` to verify whether the route can be advertised. If yes, the filtered BGP message is sent. Otherwise, a `Withdraw message` is sent. When the router receives a `Withdraw message`, it also verifies whether the removal of the route from its `RIB` caused its best route towards this prefix to change. It should be noted that, depending on the content of the `RIB` and the `export filters`, a BGP router may need to send a `Withdraw message` to a peer after having received an `Update message` from another peer and conversely.</source>
        <target state="translated">If the import filter accepts the BGP message, the pseudo-code distinguishes two cases. If this is an `Update message` for prefix `p`, this can be a new route for this prefix or a modification of the route's attributes. The router first retrieves from its `RIB` the best route towards prefix `p`. Then, the new route is inserted in the `RIB` and the `BGP decision process` is run to find whether the best route towards destination `p` changes. A BGP message only needs to be sent to the router's peers if the best route has changed. For each peer, the router applies the  `export filter` to verify whether the route can be advertised. If yes, the filtered BGP message is sent. Otherwise, a `Withdraw message` is sent. When the router receives a `Withdraw message`, it also verifies whether the removal of the route from its `RIB` caused its best route towards this prefix to change. It should be noted that, depending on the content of the `RIB` and the `export filters`, a BGP router may need to send a `Withdraw message` to a peer after having received an `Update message` from another peer and conversely.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">263</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="edaaea0a20d77d45" weblate-flags="read-only">
        <source>Let us now discuss in more detail the operation of BGP in an IPv6 network. For this, let us consider the simple network composed of three routers located in three different ASes and shown in the figure below.</source>
        <target state="translated">Let us now discuss in more detail the operation of BGP in an IPv6 network. For this, let us consider the simple network composed of three routers located in three different ASes and shown in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">265</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4ed97f392ffe3651" weblate-flags="read-only">
        <source>Utilization of the BGP nexthop attribute</source>
        <target state="translated">Utilization of the BGP nexthop attribute</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">271</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="705469135b9dc37a" weblate-flags="read-only">
        <source>This network contains three routers : `R1`, `R2` and `R3`. Each router is attached to a local IPv6 subnet that it advertises using BGP. There are two BGP sessions, one between `R1` and `R2` and the second between `R2` and `R3`. A `/127` subnet is used on each interdomain link (`2001:db8::4/127` on `R1-R2` and `2001:db8::0/127` on `R2-R3`) in conformance with the latest recommendation :rfc:`6164`. The BGP sessions run above TCP connections established between the neighboring routers (e.g. `2001:db8::5 - 2001:db8::6` for the `R1-R2` session).</source>
        <target state="translated">This network contains three routers : `R1`, `R2` and `R3`. Each router is attached to a local IPv6 subnet that it advertises using BGP. There are two BGP sessions, one between `R1` and `R2` and the second between `R2` and `R3`. A `/127` subnet is used on each interdomain link (`2001:db8::4/127` on `R1-R2` and `2001:db8::0/127` on `R2-R3`) in conformance with the latest recommendation :rfc:`6164`. The BGP sessions run above TCP connections established between the neighboring routers (e.g. `2001:db8::5 - 2001:db8::6` for the `R1-R2` session).</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">274</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="284877af7c410c21" weblate-flags="read-only">
        <source>Let us assume that the `R1-R2` BGP session is the first to be established. A `BGP Update` message sent on such a session contains three fields :</source>
        <target state="translated">Let us assume that the `R1-R2` BGP session is the first to be established. A `BGP Update` message sent on such a session contains three fields :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">279</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e1d30aba109ae91b" weblate-flags="read-only">
        <source>the advertised prefix</source>
        <target state="translated">the advertised prefix</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">281</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8fff28b36fd2a6ea" weblate-flags="read-only">
        <source>the `BGP nexthop`</source>
        <target state="translated">the `BGP nexthop`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">282</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="307fe7652a298ae6" weblate-flags="read-only">
        <source>the attributes including the AS-Path</source>
        <target state="translated">the attributes including the AS-Path</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">283</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="03afde5d26f20f92" weblate-flags="read-only">
        <source>We use the notation `U(prefix, nexthop, attributes)` to represent such a `BGP Update` message in this section. Similarly, `W(prefix)` represents a `BGP withdraw` for the specified prefix. Once the `R1-R2` session has been established, `R1` sends `U(2001:db8:1234::/48,2001:db8::5,AS10)` to `R2` and `R2` sends `U(2001:db8:5678:/48,2001:db8::6,AS20)`. At this point, `R1` can reach `2001:db8:5678::/48` via `2001:db8::6` and `R2` can reach `2001:db8:1234::/48` via `2001:db8::5`.</source>
        <target state="translated">We use the notation `U(prefix, nexthop, attributes)` to represent such a `BGP Update` message in this section. Similarly, `W(prefix)` represents a `BGP withdraw` for the specified prefix. Once the `R1-R2` session has been established, `R1` sends `U(2001:db8:1234::/48,2001:db8::5,AS10)` to `R2` and `R2` sends `U(2001:db8:5678:/48,2001:db8::6,AS20)`. At this point, `R1` can reach `2001:db8:5678::/48` via `2001:db8::6` and `R2` can reach `2001:db8:1234::/48` via `2001:db8::5`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">285</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="18346b220e9ab6e1" weblate-flags="read-only">
        <source>Once the `R2-R3` has been established, `R3` sends `U(2001:db8:acbd::/48,2001:db8::2,AS30)`. `R2` announces on the `R2-R3` session all the routes inside its RIB. It thus sends to `R3` : `U(2001:db8:1234::/48,2001:db8::1,AS20:AS10)` and `U(2001:db8:5678::/48,2001:db8::1,AS20)`. Note that when `R2` advertises the route that it learned from `R1`, it updates the BGP nexthop and adds its AS number to the AS-Path. `R2` also sends `U(2001:db8:abcd::48,2001:db8::6,AS20:AS30)` to `R1` on the `R1-R3` session. At this point, all BGP routes have been exchanged and all routers can reach `2001:db8::1234/48`, `2001:db8:5678::/48` and `2001:db8:abcd::/48`.</source>
        <target state="translated">Once the `R2-R3` has been established, `R3` sends `U(2001:db8:acbd::/48,2001:db8::2,AS30)`. `R2` announces on the `R2-R3` session all the routes inside its RIB. It thus sends to `R3` : `U(2001:db8:1234::/48,2001:db8::1,AS20:AS10)` and `U(2001:db8:5678::/48,2001:db8::1,AS20)`. Note that when `R2` advertises the route that it learned from `R1`, it updates the BGP nexthop and adds its AS number to the AS-Path. `R2` also sends `U(2001:db8:abcd::48,2001:db8::6,AS20:AS30)` to `R1` on the `R1-R3` session. At this point, all BGP routes have been exchanged and all routers can reach `2001:db8::1234/48`, `2001:db8:5678::/48` and `2001:db8:abcd::/48`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">287</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="92935103b0ff8cb4" weblate-flags="read-only">
        <source>If the link between `R2` and `R3` fails, `R3` detects the failure as it did not receive `KEEPALIVE` messages recently from `R2`. At this time, `R3` removes from its RIB all the routes learned over the `R2-R3` BGP session. `R2` also removes from its RIB the routes learned from `R3`. `R2` also sends  `W(2001:db8:acbd::/48)` to `R1` over the `R1-R3` BGP session since it does not have a route anymore towards this prefix.</source>
        <target state="translated">If the link between `R2` and `R3` fails, `R3` detects the failure as it did not receive `KEEPALIVE` messages recently from `R2`. At this time, `R3` removes from its RIB all the routes learned over the `R2-R3` BGP session. `R2` also removes from its RIB the routes learned from `R3`. `R2` also sends  `W(2001:db8:acbd::/48)` to `R1` over the `R1-R3` BGP session since it does not have a route anymore towards this prefix.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">289</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ace97cb5af4d3f2c" weblate-flags="read-only">
        <source>Origin of the routes advertised by a BGP router</source>
        <target state="translated">Origin of the routes advertised by a BGP router</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">291</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="cbdbdae7b949bfd4" weblate-flags="read-only">
        <source>A frequent practical question about the operation of BGP is how a BGP router decides to originate or advertise a route for the first time. In practice, this occurs in two situations :</source>
        <target state="translated">A frequent practical question about the operation of BGP is how a BGP router decides to originate or advertise a route for the first time. In practice, this occurs in two situations :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">293</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d1223ed84d247207" weblate-flags="read-only">
        <source>the router has been manually configured by the network operator to always advertise one or several routes on a BGP session. For example, on the BGP session between UCLouvain and its provider, belnet_ , UCLouvain's router always advertises the `2001:6a8:3080/48` IPv6 prefix assigned to the campus network</source>
        <target state="translated">the router has been manually configured by the network operator to always advertise one or several routes on a BGP session. For example, on the BGP session between UCLouvain and its provider, belnet_ , UCLouvain's router always advertises the `2001:6a8:3080/48` IPv6 prefix assigned to the campus network</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">295</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="74661b115162e5fa" weblate-flags="read-only">
        <source>the router has been configured by the network operator to advertise over its BGP session some of the routes that it learns with its intradomain routing protocol. For example, an enterprise router may advertise over a BGP session with its provider the routes to remote sites when these routes are reachable and advertised by the intradomain routing protocol</source>
        <target state="translated">the router has been configured by the network operator to advertise over its BGP session some of the routes that it learns with its intradomain routing protocol. For example, an enterprise router may advertise over a BGP session with its provider the routes to remote sites when these routes are reachable and advertised by the intradomain routing protocol</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">296</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7414e6d8be7f213d" weblate-flags="read-only">
        <source>The first solution is the most frequent. Advertising routes learned from an intradomain routing protocol is not recommended, this is because if the route flaps [#fflap]_, this would cause a large number of BGP messages being exchanged in the global Internet.</source>
        <target state="translated">The first solution is the most frequent. Advertising routes learned from an intradomain routing protocol is not recommended, this is because if the route flaps [#fflap]_, this would cause a large number of BGP messages being exchanged in the global Internet.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">298</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="453a4d2f68f2f972" weblate-flags="read-only">
        <source>The BGP decision process</source>
        <target state="translated">The BGP decision process</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">304</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="323086fee812f822" weblate-flags="read-only">
        <source>Besides the import and export filters, a key difference between BGP and the intradomain routing protocols is that each domain can define its own ranking algorithm to determine which route is chosen to forward packets when several routes have been learned towards the same prefix. This ranking depends on several BGP attributes that can be attached to a BGP route.</source>
        <target state="translated">Besides the import and export filters, a key difference between BGP and the intradomain routing protocols is that each domain can define its own ranking algorithm to determine which route is chosen to forward packets when several routes have been learned towards the same prefix. This ranking depends on several BGP attributes that can be attached to a BGP route.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">306</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="523f3319034ff8d0" weblate-flags="read-only">
        <source>The first BGP attribute that is used to rank BGP routes is the `local-preference` (local-pref) attribute. This attribute is an unsigned integer that is attached to each BGP route received over an eBGP session by the associated import filter.</source>
        <target state="translated">The first BGP attribute that is used to rank BGP routes is the `local-preference` (local-pref) attribute. This attribute is an unsigned integer that is attached to each BGP route received over an eBGP session by the associated import filter.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">311</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="581866033d0aa921" weblate-flags="read-only">
        <source>When comparing routes towards the same destination prefix, a BGP router always prefers the routes with the highest `local-pref`. If the BGP router knows several routes with the same `local-pref`, it prefers among the routes having this `local-pref` the ones with the shortest AS-Path.</source>
        <target state="translated">When comparing routes towards the same destination prefix, a BGP router always prefers the routes with the highest `local-pref`. If the BGP router knows several routes with the same `local-pref`, it prefers among the routes having this `local-pref` the ones with the shortest AS-Path.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">313</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f7643dfb2cecaa8c" weblate-flags="read-only">
        <source>The `local-pref` attribute is often used to prefer some routes over others.</source>
        <target state="translated">The `local-pref` attribute is often used to prefer some routes over others.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">315</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1a3b9905b9307641" weblate-flags="read-only">
        <source>A common utilization of `local-pref` is to support backup links. Consider the situation depicted in the figure below. `AS1` would always like to use the high bandwidth link to send and receive packets via `AS2` and only use the backup link upon failure of the primary one.</source>
        <target state="translated">A common utilization of `local-pref` is to support backup links. Consider the situation depicted in the figure below. `AS1` would always like to use the high bandwidth link to send and receive packets via `AS2` and only use the backup link upon failure of the primary one.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">319</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="eb1ca8a8daf7da2c" weblate-flags="read-only">
        <source>How to create a backup link with BGP ?</source>
        <target state="translated">How to create a backup link with BGP ?</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">325</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="108455a7689c99bb" weblate-flags="read-only">
        <source>As BGP routers always prefer the routes with the highest `local-pref` attribute, this policy can be implemented using the following import filter on `R1`</source>
        <target state="translated">As BGP routers always prefer the routes with the highest `local-pref` attribute, this policy can be implemented using the following import filter on `R1`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">327</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8160755e2430dba6" weblate-flags="read-only">
        <source>With this import filter, all the BGP routes learned from `RB` over the high bandwidth links are preferred over the routes learned over the backup link. If the primary link fails, the corresponding routes are removed from `R1`'s RIB and `R1` uses the route learned from `RA`. `R1` reuses the routes via `RB` as soon as they are advertised by `RB` once the `R1-RB` link comes back.</source>
        <target state="translated">With this import filter, all the BGP routes learned from `RB` over the high bandwidth links are preferred over the routes learned over the backup link. If the primary link fails, the corresponding routes are removed from `R1`'s RIB and `R1` uses the route learned from `RA`. `R1` reuses the routes via `RB` as soon as they are advertised by `RB` once the `R1-RB` link comes back.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">335</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bce4715e351487cd" weblate-flags="read-only">
        <source>The import filter above modifies the selection of the BGP routes inside `AS1`. Thus, it influences the route followed by the packets forwarded by `AS1`. In addition to using the primary link to send packets, `AS1` would like to receive its packets via the high bandwidth link. For this, `AS2` also needs to set the `local-pref` attribute in its import filter.</source>
        <target state="translated">The import filter above modifies the selection of the BGP routes inside `AS1`. Thus, it influences the route followed by the packets forwarded by `AS1`. In addition to using the primary link to send packets, `AS1` would like to receive its packets via the high bandwidth link. For this, `AS2` also needs to set the `local-pref` attribute in its import filter.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">337</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="10ac4b6a57befaa2" weblate-flags="read-only">
        <source>Sometimes, the `local-pref` attribute is used to prefer a `cheap` link compared to a more expensive one. For example, in the network below, `AS1` could wish to send and receive packets mainly via its interdomain link with `AS4`.</source>
        <target state="translated">Sometimes, the `local-pref` attribute is used to prefer a `cheap` link compared to a more expensive one. For example, in the network below, `AS1` could wish to send and receive packets mainly via its interdomain link with `AS4`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">346</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="72f1daf4c135b5e6" weblate-flags="read-only">
        <source>How to prefer a cheap link over an more expensive one ?</source>
        <target state="translated">How to prefer a cheap link over an more expensive one ?</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">352</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3a8a840fde016b9f" weblate-flags="read-only">
        <source>`AS1` can install the following import filter on `R1` to ensure that it always sends packets via `R2` when it has learned a route via `AS2` and another via `AS4`.</source>
        <target state="translated">`AS1` can install the following import filter on `R1` to ensure that it always sends packets via `R2` when it has learned a route via `AS2` and another via `AS4`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">354</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="36e2f758d4bf74fa" weblate-flags="read-only">
        <source>However, this import filter does not influence how `AS3` , for example, prefers some routes over others. If the link between `AS3` and `AS2` is less expensive than the link between `AS3` and `AS4`, `AS3` could send all its packets via `AS2` and `AS1` would receive packets over its expensive link. An important point to remember about `local-pref` is that it can be used to prefer some routes over others to send packets, but it has no influence on the routes followed by received packets.</source>
        <target state="translated">However, this import filter does not influence how `AS3` , for example, prefers some routes over others. If the link between `AS3` and `AS2` is less expensive than the link between `AS3` and `AS4`, `AS3` could send all its packets via `AS2` and `AS1` would receive packets over its expensive link. An important point to remember about `local-pref` is that it can be used to prefer some routes over others to send packets, but it has no influence on the routes followed by received packets.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">363</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="060b05e1f1c25ff0" weblate-flags="read-only">
        <source>Another important utilization of the `local-pref` attribute is to support the `customer-&gt;provider` and `shared-cost` peering relationships. From an economic point of view, there is an important difference between these three types of peering relationships. A domain usually earns money when it sends packets over a `provider-&gt;customer` relationship. On the other hand, it must pay its provider when it sends packets over a `customer-&gt;provider` relationship. Using a `shared-cost` peering to send packets is usually neutral from an economic perspective. To take into account these economic issues, domains usually configure the import filters on their routers as follows :</source>
        <target state="translated">Another important utilization of the `local-pref` attribute is to support the `customer-&gt;provider` and `shared-cost` peering relationships. From an economic point of view, there is an important difference between these three types of peering relationships. A domain usually earns money when it sends packets over a `provider-&gt;customer` relationship. On the other hand, it must pay its provider when it sends packets over a `customer-&gt;provider` relationship. Using a `shared-cost` peering to send packets is usually neutral from an economic perspective. To take into account these economic issues, domains usually configure the import filters on their routers as follows :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">365</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c15904281d44896b" weblate-flags="read-only">
        <source>insert a high `local-pref` attribute in the routes learned from a customer</source>
        <target state="translated">insert a high `local-pref` attribute in the routes learned from a customer</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">367</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c08eaf6a712dad95" weblate-flags="read-only">
        <source>insert a medium `local-pref` attribute in the routes learned over a shared-cost peering</source>
        <target state="translated">insert a medium `local-pref` attribute in the routes learned over a shared-cost peering</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">368</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="18019661a13b2d07" weblate-flags="read-only">
        <source>insert a low `local-pref` attribute in the routes learned from a provider</source>
        <target state="translated">insert a low `local-pref` attribute in the routes learned from a provider</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">369</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b0be4d2171d80302" weblate-flags="read-only">
        <source>With such an import filter, the routers of a domain always prefer to reach destinations via their customers whenever such a route exists. Otherwise, they prefer to use `shared-cost` peering relationships and they only send packets via their providers when they do not know any alternate route. A consequence of setting the `local-pref` attribute like this is that Internet paths are often asymmetrical. Consider for example the internetwork shown in the figure below.</source>
        <target state="translated">With such an import filter, the routers of a domain always prefer to reach destinations via their customers whenever such a route exists. Otherwise, they prefer to use `shared-cost` peering relationships and they only send packets via their providers when they do not know any alternate route. A consequence of setting the `local-pref` attribute like this is that Internet paths are often asymmetrical. Consider for example the internetwork shown in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">371</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8894a88d616e087e" weblate-flags="read-only">
        <source>Asymmetry of Internet paths</source>
        <target state="translated">Asymmetry of Internet paths</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">377</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="cdedca74f12e78f5" weblate-flags="read-only">
        <source>Consider in this internetwork the routes available inside `AS1` to reach `AS5`. `AS1` learns the `AS4:AS6:AS7:AS5` path from `AS4`, the `AS3:AS8:AS5` path from `AS3` and the `AS2:AS5` path from `AS2`. The first path is chosen since it was learned from a customer. `AS5` on the other hand receives three paths towards `AS1` via its providers. It may select any of these paths to reach `AS1` , depending on how it prefers one provider over the others.</source>
        <target state="translated">Consider in this internetwork the routes available inside `AS1` to reach `AS5`. `AS1` learns the `AS4:AS6:AS7:AS5` path from `AS4`, the `AS3:AS8:AS5` path from `AS3` and the `AS2:AS5` path from `AS2`. The first path is chosen since it was learned from a customer. `AS5` on the other hand receives three paths towards `AS1` via its providers. It may select any of these paths to reach `AS1` , depending on how it prefers one provider over the others.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">379</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b2faf682997ee957" weblate-flags="read-only">
        <source>BGP convergence</source>
        <target state="translated">BGP convergence</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">384</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="599c238a455400ce" weblate-flags="read-only">
        <source>In the previous sections, we have explained the operation of BGP routers. Compared to intradomain routing protocols, a key feature of BGP is its ability to support interdomain routing policies that are defined by each domain as its import and export filters and ranking process. A domain can define its own routing policies and router vendors have implemented many configuration tweaks to support complex routing policies. However, the routing policy chosen by a domain may interfere with the routing policy chosen by another domain. To understand this issue, let us first consider the simple internetwork shown below.</source>
        <target state="translated">In the previous sections, we have explained the operation of BGP routers. Compared to intradomain routing protocols, a key feature of BGP is its ability to support interdomain routing policies that are defined by each domain as its import and export filters and ranking process. A domain can define its own routing policies and router vendors have implemented many configuration tweaks to support complex routing policies. However, the routing policy chosen by a domain may interfere with the routing policy chosen by another domain. To understand this issue, let us first consider the simple internetwork shown below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">387</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a849af0a67cff36e" weblate-flags="read-only">
        <source>The disagree internetwork</source>
        <target state="translated">The disagree internetwork</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">394</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="04e243aa4d253c76" weblate-flags="read-only">
        <source>In this internetwork, we focus on the route towards `2001:db8::1234/48` which is advertised by `AS1`. Let us also assume that `AS3` (resp. `AS4`) prefers, e.g. for economic reasons, a route learned from `AS4` (`AS3`) over a route learned from `AS1`. When `AS1` sends `U(2001:db8::1234/48,AS1)` to `AS3` and `AS4`, three sequences of exchanges of BGP messages are possible :</source>
        <target state="translated">In this internetwork, we focus on the route towards `2001:db8::1234/48` which is advertised by `AS1`. Let us also assume that `AS3` (resp. `AS4`) prefers, e.g. for economic reasons, a route learned from `AS4` (`AS3`) over a route learned from `AS1`. When `AS1` sends `U(2001:db8::1234/48,AS1)` to `AS3` and `AS4`, three sequences of exchanges of BGP messages are possible :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">396</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a1de154c0310a8cb" weblate-flags="read-only">
        <source>`AS3` sends first `U(2001:db8:1234/48,AS3:AS1)` to `AS4`. `AS4` has learned two routes towards `2001:db8:1234/48`. It runs its BGP decision process and selects the route via `AS3` and does not advertise a route to `AS3`</source>
        <target state="translated">`AS3` sends first `U(2001:db8:1234/48,AS3:AS1)` to `AS4`. `AS4` has learned two routes towards `2001:db8:1234/48`. It runs its BGP decision process and selects the route via `AS3` and does not advertise a route to `AS3`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">398</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a089a18b9e5e6002" weblate-flags="read-only">
        <source>`AS4` first sends `U(2001:db8:1234/48,AS4:AS1)` to `AS3`. `AS3` has learned two routes towards `2001:db8:1234/48`. It runs its BGP decision process and selects the route via `AS4` and does not advertise a route to `AS4`</source>
        <target state="translated">`AS4` first sends `U(2001:db8:1234/48,AS4:AS1)` to `AS3`. `AS3` has learned two routes towards `2001:db8:1234/48`. It runs its BGP decision process and selects the route via `AS4` and does not advertise a route to `AS4`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">399</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="cf98cc67153a1460" weblate-flags="read-only">
        <source>`AS3` sends `U(2001:db8:1234/48,AS3:AS1)` to `AS4` and, at the same time, `AS4` sends `U(2001:db8:1234/48,AS4:AS1)`.  `AS3` prefers the route via `AS4` and thus sends `W(2001:db8:1234/48)` to `AS4`. In the mean time, `AS4` prefers the route via `AS3` and thus sends `W(2001:db8:1234/48)` to `AS3`. Upon reception of the `BGP Withdraws`, `AS3` and `AS4` only know the direct route towards `2001:db8:1234/48`. `AS3` (resp. `AS4`) sends `U(2001:db8:1234/48,AS3:AS1)` (resp. `U(2001:db8:1234/48,AS4:AS1)`) to `AS4` (resp. `AS3`). `AS3` and `AS4` could in theory continue to exchange BGP messages for ever. In practice, one of them sends one message faster than the other and BGP converges.</source>
        <target state="translated">`AS3` sends `U(2001:db8:1234/48,AS3:AS1)` to `AS4` and, at the same time, `AS4` sends `U(2001:db8:1234/48,AS4:AS1)`.  `AS3` prefers the route via `AS4` and thus sends `W(2001:db8:1234/48)` to `AS4`. In the mean time, `AS4` prefers the route via `AS3` and thus sends `W(2001:db8:1234/48)` to `AS3`. Upon reception of the `BGP Withdraws`, `AS3` and `AS4` only know the direct route towards `2001:db8:1234/48`. `AS3` (resp. `AS4`) sends `U(2001:db8:1234/48,AS3:AS1)` (resp. `U(2001:db8:1234/48,AS4:AS1)`) to `AS4` (resp. `AS3`). `AS3` and `AS4` could in theory continue to exchange BGP messages for ever. In practice, one of them sends one message faster than the other and BGP converges.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">400</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ecf4aeb8c9ff4fa1" weblate-flags="read-only">
        <source>The example above has shown that the routes selected by BGP routers may sometimes depend on the ordering of the BGP messages that are exchanged. Other similar scenarios may be found in :rfc:`4264`.</source>
        <target state="translated">The example above has shown that the routes selected by BGP routers may sometimes depend on the ordering of the BGP messages that are exchanged. Other similar scenarios may be found in :rfc:`4264`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">402</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="565ff2287252836b" weblate-flags="read-only">
        <source>From an operational perspective, the above configuration is annoying since the network operators cannot easily predict which paths are chosen. Unfortunately, there are even more annoying BGP configurations. For example, let us consider the configuration below which is often named `Bad Gadget` [GW1999]_</source>
        <target state="translated">From an operational perspective, the above configuration is annoying since the network operators cannot easily predict which paths are chosen. Unfortunately, there are even more annoying BGP configurations. For example, let us consider the configuration below which is often named `Bad Gadget` [GW1999]_</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">404</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9bdb03cdd4a4210d" weblate-flags="read-only">
        <source>The bad gadget internetwork</source>
        <target state="translated">The bad gadget internetwork</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">410</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d229929a4c6e6333" weblate-flags="read-only">
        <source>In this internetwork, there are four ASes. `AS0` advertises one route towards one prefix and we only analyze the routes towards this prefix. The routing preferences of `AS1`, `AS3` and `AS4` are the following :</source>
        <target state="translated">In this internetwork, there are four ASes. `AS0` advertises one route towards one prefix and we only analyze the routes towards this prefix. The routing preferences of `AS1`, `AS3` and `AS4` are the following :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">413</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="891cdbce81149cb4" weblate-flags="read-only">
        <source>`AS1` prefers the path `AS3:AS0` over all other paths</source>
        <target state="translated">`AS1` prefers the path `AS3:AS0` over all other paths</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">415</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bc0c87c43f05758d" weblate-flags="read-only">
        <source>`AS3` prefers the path `AS4:AS0` over all other paths</source>
        <target state="translated">`AS3` prefers the path `AS4:AS0` over all other paths</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">416</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="895521580367c386" weblate-flags="read-only">
        <source>`AS4` prefers the path `AS1:AS0` over all other paths</source>
        <target state="translated">`AS4` prefers the path `AS1:AS0` over all other paths</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">417</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4e752d63cfb5f3b1" weblate-flags="read-only">
        <source>`AS0` sends `U(p,AS0)` to `AS1`, `AS3` and `AS4`. As this is the only route known by `AS1`, `AS3` and `AS4` towards `p`, they all select the direct path. Let us now consider one possible exchange of BGP messages :</source>
        <target state="translated">`AS0` sends `U(p,AS0)` to `AS1`, `AS3` and `AS4`. As this is the only route known by `AS1`, `AS3` and `AS4` towards `p`, they all select the direct path. Let us now consider one possible exchange of BGP messages :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">419</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="859e0fe1330ba846" weblate-flags="read-only">
        <source>`AS1` sends `U(p, AS1:AS0)` to `AS3` and `AS4`. `AS4` selects the path via `AS1` since this is its preferred path. `AS3` still uses the direct path.</source>
        <target state="translated">`AS1` sends `U(p, AS1:AS0)` to `AS3` and `AS4`. `AS4` selects the path via `AS1` since this is its preferred path. `AS3` still uses the direct path.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">421</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="150223d7bd8476f4" weblate-flags="read-only">
        <source>`AS4` advertises `U(p,AS4:AS1:AS0)` to `AS3`.</source>
        <target state="translated">`AS4` advertises `U(p,AS4:AS1:AS0)` to `AS3`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">422</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="aabca6b1962c2674" weblate-flags="read-only">
        <source>`AS3` sends `U(p, AS3:AS0)` to `AS1` and `AS4`. `AS1` selects the path via `AS3` since this is its preferred path. `AS4` still uses the path via `AS1`.</source>
        <target state="translated">`AS3` sends `U(p, AS3:AS0)` to `AS1` and `AS4`. `AS1` selects the path via `AS3` since this is its preferred path. `AS4` still uses the path via `AS1`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">423</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9d57f212b44a1837" weblate-flags="read-only">
        <source>As `AS1` has changed its path, it sends `U(p,AS1:AS3:AS0)` to `AS4` and `W(p)` to `AS3` since its new path is via `AS3`. `AS4` switches back to the direct path.</source>
        <target state="translated">As `AS1` has changed its path, it sends `U(p,AS1:AS3:AS0)` to `AS4` and `W(p)` to `AS3` since its new path is via `AS3`. `AS4` switches back to the direct path.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">424</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="611cf8c51d585f45" weblate-flags="read-only">
        <source>`AS4` sends `U(p,AS4:AS0)` to `AS1` and `AS3`. `AS3` prefers the path via `AS4`.</source>
        <target state="translated">`AS4` sends `U(p,AS4:AS0)` to `AS1` and `AS3`. `AS3` prefers the path via `AS4`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">425</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ed15d56e0e7f2468" weblate-flags="read-only">
        <source>`AS3` sends `U(p,AS3:AS4:AS0)` to `AS1` and `W(p)` to `AS4`. `AS1` switches back to the direct path and we are back at the first step.</source>
        <target state="translated">`AS3` sends `U(p,AS3:AS4:AS0)` to `AS1` and `W(p)` to `AS4`. `AS1` switches back to the direct path and we are back at the first step.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">426</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7ce59bce57f6a558" weblate-flags="read-only">
        <source>This example shows that the convergence of BGP is unfortunately not always guaranteed as some interdomain routing policies may interfere with each other in complex ways. [GW1999]_ have shown that checking for global convergence is either NP-complete or NP-hard. See [GSW2002]_ for a more detailed discussion.</source>
        <target state="translated">This example shows that the convergence of BGP is unfortunately not always guaranteed as some interdomain routing policies may interfere with each other in complex ways. [GW1999]_ have shown that checking for global convergence is either NP-complete or NP-hard. See [GSW2002]_ for a more detailed discussion.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">428</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="550145708e9c3156" weblate-flags="read-only">
        <source>Fortunately, there are some operational guidelines [GR2001]_ [GGR2001]_ that can guarantee BGP convergence in the global Internet. To ensure that BGP will converge, these guidelines consider that there are two types of peering relationships : `customer-&gt;provider` and `shared-cost`. In this case, BGP convergence is guaranteed provided that the following conditions are fulfilled :</source>
        <target state="translated">Fortunately, there are some operational guidelines [GR2001]_ [GGR2001]_ that can guarantee BGP convergence in the global Internet. To ensure that BGP will converge, these guidelines consider that there are two types of peering relationships : `customer-&gt;provider` and `shared-cost`. In this case, BGP convergence is guaranteed provided that the following conditions are fulfilled :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">430</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="794dce2761735d01" weblate-flags="read-only">
        <source>The topology composed of all the directed `customer-&gt;provider` peering links is a graph that does not contain any cycle</source>
        <target state="translated">The topology composed of all the directed `customer-&gt;provider` peering links is a graph that does not contain any cycle</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">432</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="19a117a3750be3fc" weblate-flags="read-only">
        <source>An AS always prefers a route received from a `customer` over a route received from a `shared-cost` peer or a `provider`.</source>
        <target state="translated">An AS always prefers a route received from a `customer` over a route received from a `shared-cost` peer or a `provider`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">433</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0be623d144b41185" weblate-flags="read-only">
        <source>The first guideline implies that the provider of the provider of `ASx` cannot be a customer of `ASx`. Such a relationship would not make sense from an economic perspective as it would imply circular payments. Furthermore, providers are usually larger than customers.</source>
        <target state="translated">The first guideline implies that the provider of the provider of `ASx` cannot be a customer of `ASx`. Such a relationship would not make sense from an economic perspective as it would imply circular payments. Furthermore, providers are usually larger than customers.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">436</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="54083f7718b1ed4c" weblate-flags="read-only">
        <source>The second guideline also corresponds to economic preferences. Since a provider earns money when sending packets to one of its customers, it makes sense to prefer such customer learned routes over routes learned from providers. [GR2001]_ also shows that BGP convergence is guaranteed even if an AS associates the same preference to routes learned from a `shared-cost` peer and routes learned from a customer.</source>
        <target state="translated">The second guideline also corresponds to economic preferences. Since a provider earns money when sending packets to one of its customers, it makes sense to prefer such customer learned routes over routes learned from providers. [GR2001]_ also shows that BGP convergence is guaranteed even if an AS associates the same preference to routes learned from a `shared-cost` peer and routes learned from a customer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">438</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="25dde1aa5231727a" weblate-flags="read-only">
        <source>From a theoretical perspective, these guidelines should be verified automatically to ensure that BGP will always converge in the global Internet. However, such a verification cannot be performed in practice because this would force all domains to disclose their routing policies (and few are willing to do so) and furthermore the problem is known to be NP-hard [GW1999].</source>
        <target state="translated">From a theoretical perspective, these guidelines should be verified automatically to ensure that BGP will always converge in the global Internet. However, such a verification cannot be performed in practice because this would force all domains to disclose their routing policies (and few are willing to do so) and furthermore the problem is known to be NP-hard [GW1999].</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">440</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e0b95c5445d22c4c" weblate-flags="read-only">
        <source>In practice, researchers and operators expect that these guidelines are verified [#fgranularity]_ in most domains. Thanks to the large amount of BGP data that has been collected by operators and researchers [#fbgpdata]_, several studies have analyzed the AS-level topology of the Internet. [SARK2002]_ is one of the first analysis. More recent studies include [COZ2008]_ and [DKF+2007]_</source>
        <target state="translated">In practice, researchers and operators expect that these guidelines are verified [#fgranularity]_ in most domains. Thanks to the large amount of BGP data that has been collected by operators and researchers [#fbgpdata]_, several studies have analyzed the AS-level topology of the Internet. [SARK2002]_ is one of the first analysis. More recent studies include [COZ2008]_ and [DKF+2007]_</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">442</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="19208a0533950f3f" weblate-flags="read-only">
        <source>Based on these studies and [ATLAS2009]_, the AS-level Internet topology can be summarized as shown in the figure below.</source>
        <target state="translated">Based on these studies and [ATLAS2009]_, the AS-level Internet topology can be summarized as shown in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">444</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8575e832221bdbaa" weblate-flags="read-only">
        <source>The layered structure of the global Internet</source>
        <target state="translated">The layered structure of the global Internet</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">450</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6ad1886b19ecfca1" weblate-flags="read-only">
        <source>The domains on the Internet can be divided in about four categories according to their role and their position in the AS-level topology.</source>
        <target state="translated">The domains on the Internet can be divided in about four categories according to their role and their position in the AS-level topology.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">454</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4f8fb9c08660cff8" weblate-flags="read-only">
        <source>Due to this organization of the Internet and due to the BGP decision process, most AS-level paths on the Internet have a length of 3-5 AS hops.</source>
        <target state="translated">Due to this organization of the Internet and due to the BGP decision process, most AS-level paths on the Internet have a length of 3-5 AS hops.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">465</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c463aea6549199a2" weblate-flags="read-only">
        <source>Footnotes</source>
        <target state="translated">Footnotes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">470</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1a8f21f587f696a0" weblate-flags="read-only">
        <source>An analysis of the evolution of the number of domains on the global Internet during the last ten years may be found in http://www.potaroo.net/tools/asn32/.</source>
        <target state="translated">An analysis of the evolution of the number of domains on the global Internet during the last ten years may be found in http://www.potaroo.net/tools/asn32/.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">471</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3ea9c37e2df30165" weblate-flags="read-only">
        <source>Several web sites collect and analyze data about the evolution of BGP in the global Internet. http://bgp.potaroo.net provides lots of statistics and analyzes that are updated daily.</source>
        <target state="translated">Several web sites collect and analyze data about the evolution of BGP in the global Internet. http://bgp.potaroo.net provides lots of statistics and analyzes that are updated daily.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">473</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ea023b09d812a3fe" weblate-flags="read-only">
        <source>See http://as-rank.caida.org/ for an  analysis of the interconnections between domains based on measurements collected in the global Internet.</source>
        <target state="translated">See http://as-rank.caida.org/ for an  analysis of the interconnections between domains based on measurements collected in the global Internet.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">475</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b98e3c931583ad6e" weblate-flags="read-only">
        <source>Two routers that are attached to the same IXP exchange packets only when the owners of their domains have an economical incentive to exchange packets on this IXP. Usually, a router on an IXP is only able to exchange packets with a small fraction of the routers that are present on the same IXP.</source>
        <target state="translated">Two routers that are attached to the same IXP exchange packets only when the owners of their domains have an economical incentive to exchange packets on this IXP. Usually, a router on an IXP is only able to exchange packets with a small fraction of the routers that are present on the same IXP.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">478</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="68866a347a36a894" weblate-flags="read-only">
        <source>See ftp://ftp.ripe.net/ripe/dbase for the RIPE database that contains the import and export policies of many European ISPs.</source>
        <target state="translated">See ftp://ftp.ripe.net/ripe/dbase for the RIPE database that contains the import and export policies of many European ISPs.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">480</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1deabbbc405e8753" weblate-flags="read-only">
        <source>In this text, we consider Autonomous System and domain as synonyms. In practice, a domain may be  divided into several Autonomous Systems, but we ignore this detail.</source>
        <target state="translated">In this text, we consider Autonomous System and domain as synonyms. In practice, a domain may be  divided into several Autonomous Systems, but we ignore this detail.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">482</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="082620889a915a1b" weblate-flags="read-only">
        <source>The BGP sessions and the underlying TCP connection are typically established by the routers when they boot based on information found in their configuration. The BGP sessions are rarely released, except if the corresponding peering link fails or one of the endpoints crashes or needs to be rebooted.</source>
        <target state="translated">The BGP sessions and the underlying TCP connection are typically established by the routers when they boot based on information found in their configuration. The BGP sessions are rarely released, except if the corresponding peering link fails or one of the endpoints crashes or needs to be rebooted.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">484</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f0d41f1ae3afa822" weblate-flags="read-only">
        <source>90 seconds is the default delay recommended by :rfc:`4271`. However, two BGP peers can negotiate a different timer during the establishment of their BGP session. Using a too small interval to detect BGP session failures is not recommended. BFD [KW2009]_ can be used to replace BGP's KEEPALIVE mechanism if fast detection of interdomain link failures is required.</source>
        <target state="translated">90 seconds is the default delay recommended by :rfc:`4271`. However, two BGP peers can negotiate a different timer during the establishment of their BGP session. Using a too small interval to detect BGP session failures is not recommended. BFD [KW2009]_ can be used to replace BGP's KEEPALIVE mechanism if fast detection of interdomain link failures is required.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">486</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7177b9d7463defc0" weblate-flags="read-only">
        <source>A link is said to be flapping if it switches several times between an operational state and a disabled state within a short period of time. A router attached to such a link would need to frequently send routing messages.</source>
        <target state="translated">A link is said to be flapping if it switches several times between an operational state and a disabled state within a short period of time. A router attached to such a link would need to frequently send routing messages.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">488</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4238f0ff6b833d99" weblate-flags="read-only">
        <source>Researchers such as [MUF+2007]_ have shown that modeling the Internet topology at the AS-level requires more than the `shared-cost` and `customer-&gt;provider` peering relationships. However, there is no publicly available model that goes beyond these classical peering relationships.</source>
        <target state="translated">Researchers such as [MUF+2007]_ have shown that modeling the Internet topology at the AS-level requires more than the `shared-cost` and `customer-&gt;provider` peering relationships. However, there is no publicly available model that goes beyond these classical peering relationships.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">490</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="cb31bf53cfc40f35" weblate-flags="read-only">
        <source>BGP data is often collected by establishing BGP sessions between Unix hosts running a BGP daemon and BGP routers in different ASes. The Unix hosts stores all BGP messages received and regular dumps of its BGP routing table. See http://www.routeviews.org, http://www.ripe.net/ris, http://bgp.potaroo.net or http://irl.cs.ucla.edu/topology/.</source>
        <target state="translated">BGP data is often collected by establishing BGP sessions between Unix hosts running a BGP daemon and BGP routers in different ASes. The Unix hosts stores all BGP messages received and regular dumps of its BGP routing table. See http://www.routeviews.org, http://www.ripe.net/ris, http://bgp.potaroo.net or http://irl.cs.ucla.edu/topology/.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/bgp.rst</context>
          <context context-type="linenumber">492</context>
        </context-group>
      </trans-unit>
    </body>
  </file>
</xliff>
