<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hello Maria!</p>
    <p>Thank you for taking the time to read my email.</p>
    <p>Yes, "I have no providers" is a much more accurate description of
      AS 0.  It can be used by tier 1 networks as well as people trying
      to depreciate their old ASN.  It looks like the source of my
      confusion was that I was under the assumption that the transit
      ASPA entries could be used to auto-detect upstream vs downstream
      as opposed to doing the check in the filter script.  Sorry about
      that!</p>
    <p>Thank you for fixing the problem with the static ASPA changes!!</p>
    <p>I noticed in aspa_check() you check for confeds but AS_PATH_SET
      is never checked for.</p>
    <p>The specs say they should return ASPA_INVALID however I noticed
      when I did that I lost about 64 routes which caused some customer
      complaints.  I had to end up slightly changing the code to return
      ASPA_INVALID if upstream and ASPA_UNKNOWN if downstream.<br>
    </p>
    <p>Thank you!<br>
    </p>
    <p>Ralph<br>
    </p>
    <div class="moz-cite-prefix">On 12/26/2024 6:04 AM, Maria Matejka
      via Bird-users wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:Z204Th8mz3_gWQPv@livanecnik.jmq.cz">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <meta charset="utf-8">
      <meta name="generator" content="pandoc">
      <meta name="viewport"
content="width=device-width, initial-scale=1.0, user-scalable=yes">
      <style>html {
  line-height: 1.2;
  font-family: serif;
  font-size: 0.9em;
  color: black; 
  background-color: white;
}body {
  margin: 0;
  margin-right: auto;
  max-width: 36em;
  padding: 1em;
  hyphens: auto;
  overflow-wrap: break-word;
  text-rendering: optimizeLegibility;
  font-kerning: normal;
}p {
  margin: 1em 0;
}a {
  color: black;
}a:visited {
  color: black;
}img {
  max-width: 100%;
}h1, h2, h3, h4, h5, h6 {
  margin-top: 1.4em;
}h5, h6 {
  font-size: 1em;
  font-style: italic;
}h6 {
  font-weight: normal;
}ol, ul {
  padding-left: 1.7em;
  margin-top: 1em;
}li > ol, li > ul {
  margin-top: 0;
}blockquote {
  margin: 0.5em;
  padding-left: 0.5em;
  border-left: 2px solid #e6e6e6;
  color: #444;
}code {
  font-family: 'Lucida Console', monospace;
  font-size: 95%;
  margin: 0;
}pre {
  margin: 1em 0;
  overflow: auto;
  max-width: unset;
  width: fit-content;
}pre code {
  padding: 0;
  overflow: visible;
  overflow-wrap: normal;
  max-width: unset;
  white-space: pre-wrap;
}pre code span {
  white-space: pre;
}.sourceCode {
 background-color: transparent;
 overflow: visible;
}code.diff span.kw,
code.diff span.dt {
  font-weight: bold;
}code.diff span.va {
  background-color: rgba(192, 255, 192, 64);
  color: rgb(0, 64, 0);
}code.diff span.st {
  background-color: rgba(255, 192, 192, 64);
  color: rgb(64, 0, 0);
}pre.diff {
  background-color: rgb(240, 240, 240);
  padding: 0.4em;
  border: 1pt solid grey;
}hr {
  background-color: black;
  border: none;
  height: 1px;
  margin: 1em 0;
}table {
  margin: 1em 0;
  border-collapse: collapse;
  width: 100%;
  overflow-x: auto;
  display: block;
  font-variant-numeric: lining-nums tabular-nums;
}table caption {
  margin-bottom: 0.75em;
}tbody {
  margin-top: 0.5em;
  border-top: 1px solid black;
  border-bottom: 1px solid black;
}th {
  border-top: 1px solid black;
  padding: 0.25em 0.5em 0.25em 0.5em;
}td {
  padding: 0.125em 0.5em 0.25em 0.5em;
}header {
  margin-bottom: 4em;
  text-align: center;
}code{white-space: pre-wrap;}span.smallcaps{font-variant: small-caps;}span.underline{text-decoration: underline;}div.column{display: inline-block; vertical-align: top; width: 50%;}div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}ul.task-list{list-style: none;}q { quotes: "„" "”" "»" "«"; }.display.math{display: block; text-align: center; margin: 0.5rem auto;}</style>
      <p>Hello Ralph,</p>
      <blockquote>
        <p>Issue #1)  There is no way to tell the difference between a
          transit
          entry and an “AS0” entry.</p>
      </blockquote>
      <p>There is no difference between a transit entry and an AS0
        entry. The
        <code>transit</code> keyword is just a syntactic shortcut for
        <code>provider 0</code>.</p>
      <blockquote>
        <p>The treatment of AS0 providers is mentioned in section 5 of
          draft-ietf-sidrops-aspa-verification-19.  It is a mechanism
          for people
          to announce that “no one should announce this AS”.  I’ve
          attached a
          snapshot of the global ASPA table as “bird-aspa-v2.16.conf”. 
          There is
          one AS0 announcement as of today.</p>
      </blockquote>
      <p>No, it isn’t. It’s a mechanism to say “I have no providers”, as
        written in section 5 of the draft:</p>
      <blockquote>
        <p>Registering as AS0 ASPA is a statement by the registering AS
          that it
          has no transit providers (…)</p>
      </blockquote>
      <p>This effectively means that in a valid AS Path, there may be:</p>
      <ul>
        <li>no AS with AS0 ASPA</li>
        <li>a single AS with AS0 ASPA</li>
        <li>two adjacent AS’s with AS0 ASPA</li>
      </ul>
      <p>I fell probably exactly into the same trap when reading the
        drafts
        first time, and the draft authors had to explain the principles
        to me
        several times in person for me to get it right. I tried to fix
        that by
        suggesting a different wording, please check this (long) message
        in
        sidrops:</p>
      <p><a class="moz-txt-link-freetext" href="https://mailarchive.ietf.org/arch/msg/sidrops/LE_nPFL6XFnIKE-25O9WIfZ-YFI/">https://mailarchive.ietf.org/arch/msg/sidrops/LE_nPFL6XFnIKE-25O9WIfZ-YFI/</a></p>
      <blockquote>
        <p>Issue #2)  Changes in static ASPA tables are not reflected
          until
          entries are removed and re-added.</p>
      </blockquote>
      <p>Thanks, fixed:
<a class="moz-txt-link-freetext" href="https://gitlab.nic.cz/labs/bird/-/commit/1e685bbc2a7411c09b6c80404c49a410d6c47a2a">https://gitlab.nic.cz/labs/bird/-/commit/1e685bbc2a7411c09b6c80404c49a410d6c47a2a</a></p>
      <blockquote>
        <p>This problem does not occur when the ASPA elements are
          customer-provider pairs.  I believe this is an overall design
          issue, not
          a simple bug.  I will be bringing this issue up with
          ietf-sidrops.</p>
      </blockquote>
      <p>There were massive data consistency problems in BIRD 3 when the
        ASPA
        elements were customer-provider pairs, and we won’t go back
        there.</p>
      <p>Also, both the configuration and the in-table storage is more
        memory-greedy with the pairs storage.</p>
      <p>Have a nice end-of-the-year! Maria</p>
      <p>–<br>
        Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.</p>
    </blockquote>
  </body>
</html>