<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 8, 2020, at 9:22 AM, Mark Tinka via NANOG <<a href="mailto:nanog@nanog.org" class="">nanog@nanog.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">On 8/Sep/20 17:55, Douglas Fischer via
NANOG wrote:<br class="">
<br class="">
</div>
<blockquote type="cite" cite="mid:CAKEr4RQJAr8nPD65HsUKg8px0O6phRM9av7c+gW92QVyysLFKw@mail.gmail.com" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div dir="ltr" class="">
<div class="gmail_default" style="font-family:courier
new,monospace;font-size:small">Most of us have already used
some BGP community policy to no-export some routes to some
where.<br class="">
<br class="">
On the majority of IXPs, and most of the Transit Providers,
the very common community tell to route-servers and routers
"Please do no-export these routes to that ASN" is:<br class="">
<br class="">
</div>
<div class="gmail_default" style="font-family:courier
new,monospace;font-size:small"> -> 0:<TargetASN></div>
<div class="gmail_default" style="font-family:courier
new,monospace;font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-family:courier
new,monospace;font-size:small">So we could say that this is a
de-facto standard.</div>
<div class="gmail_default" style="font-family:courier
new,monospace;font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-family:courier
new,monospace;font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-family:courier
new,monospace;font-size:small">But the Policy equivalent to
"Please, export these routes only to that ASN" is very varied
on all the IXPs or Transit Providers.</div>
<div class="gmail_default" style="font-family:courier
new,monospace;font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-family:courier
new,monospace;font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-family:courier
new,monospace;font-size:small">With that said, now comes some
questions:<br class="">
<br class="">
1 - Beyond being a de-facto standard, there is any RFC, Public
Policy, or something like that, that would define
0:<TargetASN> as "no-export-to" standard?</div>
<div class="gmail_default" style="font-family:courier
new,monospace;font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-family:courier
new,monospace;font-size:small">2 - What about reserving some
16-bits ASN to use <ExpOnlyTo>:<TargetASN> as
"export-only-to" standard?</div>
<div class="gmail_default" style="font-family:courier
new,monospace;font-size:small">2.1 - Is important to be 16
bits, because with (RT) extended communities, any ASN on the
planet could be the target of that policy.</div>
<div class="gmail_default" style="font-family:courier
new,monospace;font-size:small">2.2 - Would be interesting some
mnemonic number like 1000 / 10000 or so.<br class="">
</div>
</div>
</blockquote>
<br class="">
The standard already exists... "NO_EXPORT". Provided ISP's or
exchange points can publish their own local values to match that
within their network, I believe they can do whatever they want,
since it's locally-significant.<br class="">
<br class="">
I'm not sure we want to go down the trail of standardizing a "de
facto" usage. Just like QoS, it may be doomed as different operators
define what it means for them.<br class="">
<br class="">
Mark.<br class="">
</div>
</div></blockquote><br class=""></div><div>To the extent that communities are standardized, they’re supposed to be ASN:Community, so 0:<TargetASN> seems like a bad convention to begin with.</div><div><br class=""></div><div>Further, many of the things people claim they want from odd-ball techniques trying to cram things into 32-bit communities are actually standardized and easily implemented (without hackery) using either Extended Communities, or Large Communities, with the advantage that you can also accommodate 4-octet ASNs without stupid router tricks.</div><div><br class=""></div><div>Please consider looking at existing standards before making up new ones.</div><div><br class=""></div><div>Thanks,</div><div><br class=""></div><div>Owen</div><div><br class=""></div><br class=""></body></html>