
<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="">Yes, but with large communities, that’s called RFC-8092 and in general, RFC-8642 has some good data.<div class=""><br class=""></div><div class="">There’s also BGP extended communities (RFC-7153 and the IANA registry it creates).<br class=""><div class=""><br class=""></div><div class=""><div>Creating an ad hoc BCP vs. using the existing RFC process seems ill-advised.</div><div><br class=""></div><div>Owen</div><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 8, 2020, at 11:35 AM, Mike Hammett via NANOG <<a href="mailto:nanog@nanog.org" class="">nanog@nanog.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><style type="text/css" class="">p { margin: 0; }</style><div class=""><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt;" class="">How I see the OP's intent is to create a BCP of what defined communities have what effect instead of everyone just making up whatever they draw out of a hat, simplifying this process for everyone.<br class=""><br class=""><div class=""><span name="x" class=""></span><br class=""><br class="">-----<br class="">Mike Hammett<br class="">Intelligent Computing Solutions<br class=""><a href="http://www.ics-il.com" class="">http://www.ics-il.com</a><br class=""><br class="">Midwest-IX<br class="">http://www.midwest-ix.com<span name="x" class=""></span><br class=""></div><br class=""><hr id="zwchr" class=""><div style="font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica, Arial, sans-serif; font-size: 12pt;" class=""><b class="">From: </b>"Tom Beecher via NANOG" <<a href="mailto:nanog@nanog.org" class="">nanog@nanog.org</a>><br class=""><b class="">To: </b>"Douglas Fischer" <<a href="mailto:fischerdouglas@gmail.com" class="">fischerdouglas@gmail.com</a>><br class=""><b class="">Cc: </b>"NANOG" <<a href="mailto:nanog@nanog.org" class="">nanog@nanog.org</a>><br class=""><b class="">Sent: </b>Tuesday, September 8, 2020 1:30:19 PM<br class=""><b class="">Subject: </b>Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'<br class=""><br class=""><div dir="ltr" class="">BGP Large Communities ( <a href="https://tools.ietf.org/html/rfc8195" target="_blank" class="">https://tools.ietf.org/html/rfc8195</a> ) already provides for anyone to define the exact handling you wish. <div class=""><br class=""></div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG <<a href="mailto:nanog@nanog.org" target="_blank" class="">nanog@nanog.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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 class=""><br class=""></div>-- <br class=""><div dir="ltr" class=""><font size="2" class=""><span style="font-family:"courier new",monospace" class="">Douglas Fernando Fischer</span><br style="font-family:"courier new",monospace" class=""><span style="font-family:"courier new",monospace" class="">Engº de Controle e Automação</span></font><div style="padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden; text-align: left; line-height: 130%; font-family: "courier new", monospace;" class=""></div></div></div>

</blockquote></div>

</div><br class=""></div></div></div></blockquote></div><br class=""></div></div></body></html>