<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">De-facto standards are as good as people implementing them, however in order to enforce non ambiguous implementations, it has to be de-jure (e.g. a standard track RFC).<div>While I’m sympathetic to the idea, I’m quite skeptical about its viability.</div><div>A well written BCP would be much more valuable, and perhaps when we get to a critical mass, codification would be a natural process, rather than artificially enforcing people doing stuff they don’t see value (ROI) in, discussion here perfectly reflects the state of art.<br><br><div dir="ltr">Cheers,<div>Jeff</div></div><div dir="ltr"><br><blockquote type="cite">On Sep 8, 2020, at 17:57, Douglas Fischer via NANOG <nanog@nanog.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><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><br>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><br></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></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></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></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></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">With that said, now comes some questions:<br><br>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></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></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><font size="2"><span style="font-family:courier new,monospace">Douglas Fernando Fischer</span><br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace">Engº de Controle e Automação</span></font><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;word-wrap:break-word;color:black;text-align:left;line-height:130%;font-family:courier new,monospace"></div></div></div>
</div></blockquote></div></body></html>