<!DOCTYPE html>
<html>
<head>
<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;
}
@media print {
body {
background-color: transparent;
color: black;
font-size: 11pt;
}
p, h2, h3 {
orphans: 3;
widows: 3;
}
h2, h3, h4 {
page-break-after: avoid;
}
}
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>
</head>
<body>
<p>Hi André,</p>
<blockquote>
<p>I was considering your “personal speculation” and came to the
conclusion that I agree, this should not be implemented.</p>
<p>For a lot of errors in UPDATE messages, it’s perfectly fine to treat
those as an error and do Treat-as-withdraw (as described in RFC7606).
This includes checking the length of the OTC attribute. I am not asking
to see routes with protocol errors in the routing table.</p>
</blockquote>
<p>Oh there could be many different options … maybe this way? (Still
speculating in my personal capacity, it’s weekend and the next team
meeting is on tuesday.)</p>
<pre><code>allow leaks [off/filtered/on]
allow invalid next hop [off/filtered/on]
allow as sets [off/filtered/on]
allow malformed [off/filtered/on]
...</code></pre>
<p>Here <code>off</code> would reject these altogether (default option),
<code>filtered</code> would pass them to filters but always reject, and
<code>on</code> would allow accepting them to the table?</p>
<blockquote>
<p>As far as I can see RFC9234 does not mandate handling a route leak
with Treat-as-widthdraw. It just refers to leaking routes to be
ineligible (for further use).</p>
</blockquote>
<p>Oh yes, but it’s kinda similar to rejecting AS sets … :wink:</p>
<blockquote>
<p>My understanding: a leaked route should be present in Adj-RIB-In, but
not into Loc-RIB.</p>
</blockquote>
<p>That’s what would actually be possible with that
<code>allow leaks filtered</code>.</p>
<blockquote>
<p>I do understand that Bird does not follow the traditional path of
other BGP speakers and has no Adj-RIB-In/Out. In a multi-table route
server setup Adj-RIB-In/Out is mimicked by the per-peer-table. In a
single-table setup, the leaked route would go into the main table. So
the question is: Could you imagine another way (i.e. different from
Treat-as-withdraw) of handling “ineligible” routes?</p>
</blockquote>
<p>Not with the current implementation, but it’s doable e.g. in the way
shown above.</p>
<blockquote>
<p>How do you treat routes that do not pass next-hop lookup? Shouldn’t
these be ineligible as well? How about doing something similar for
“ineligible by OTC”?</p>
</blockquote>
<p>Well, errmhm … these with unreachable nexthops are usually ineligible
but kept in the table (just not selected). Usually. Some nexthops are
also considered malformed (e.g. a zero nexthop) and rejected without
reaching filters.</p>
<p>Occassionally we open this can of worms in our office, find out that
there are much more worms than we expected, see that some of them are
holding holy hand grenades, and we wisely decide to let the whole thing
sleep for several more years.</p>
<p>Have a nice day!<br />
Maria</p>
<p>–<br />
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.</p>
</body>
</html>