<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'>The operators are snowflakes. Are the networks really snowflakes?<br><br><div><span name="x"></span><br><br>-----<br>Mike Hammett<br>Intelligent Computing Solutions<br>http://www.ics-il.com<br><br>Midwest-IX<br>http://www.midwest-ix.com<span name="x"></span><br></div><br><hr id="zwchr"><div style="color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Tom Beecher" <beecher@beecher.cc><br><b>To: </b>"Mike Hammett" <nanog@ics-il.net><br><b>Cc: </b>"NANOG" <nanog@nanog.org>, "Douglas Fischer" <fischerdouglas@gmail.com><br><b>Sent: </b>Tuesday, September 8, 2020 3:36:22 PM<br><b>Subject: </b>Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'<br><br><div dir="ltr">Every network is a snowflake already. Everyone has different needs and operational considerations, which will also change over time. My community structure would not fit your needs, and yours would not fit mine. The current structure of regular and extended allows us to come up with something that works well for each of us, which is good.<div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 8, 2020 at 4:06 PM Mike Hammett <<a href="mailto:nanog@ics-il.net" target="_blank">nanog@ics-il.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">Is there more desire to be flexible because people are snowflakes and their idea is the only way it should be or real, document-able reasons?<br><br><div><span></span><br><br>-----<br>Mike Hammett<br>Intelligent Computing Solutions<br><a href="http://www.ics-il.com" target="_blank">http://www.ics-il.com</a><br><br>Midwest-IX<br><a href="http://www.midwest-ix.com" target="_blank">http://www.midwest-ix.com</a><span></span><br></div><br><hr id="gmail-m_2039002124772486566zwchr"><div style="color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Tom Beecher" <beecher@beecher.cc><br><b>To: </b>"Mike Hammett" <<a href="mailto:nanog@ics-il.net" target="_blank">nanog@ics-il.net</a>><br><b>Cc: </b>"NANOG" <<a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a>>, "Douglas Fischer" <<a href="mailto:fischerdouglas@gmail.com" target="_blank">fischerdouglas@gmail.com</a>><br><b>Sent: </b>Tuesday, September 8, 2020 3:02:37 PM<br><b>Subject: </b>Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'<br><br><div dir="ltr">I also get that intent from the OP. However I disagree that there should be a 'de facto' standard created for such things. All flavors of BGP community specifications are designed to be flexible so that different networks can design a system that is tailored to their needs. <div><br></div><div>Having 'de facto' standards does not simplify in my opinion. I believe it just creates more work for operators trying to navigate around different opinions of what 'de facto' means. </div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett <<a href="mailto:nanog@ics-il.net" target="_blank">nanog@ics-il.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">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><br><div><span></span><br><br>-----<br>Mike Hammett<br>Intelligent Computing Solutions<br><a href="http://www.ics-il.com" target="_blank">http://www.ics-il.com</a><br><br>Midwest-IX<br><a href="http://www.midwest-ix.com" target="_blank">http://www.midwest-ix.com</a><span></span><br></div><br><hr id="gmail-m_2039002124772486566gmail-m_-8133869158136586381zwchr"><div style="color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Tom Beecher via NANOG" <<a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a>><br><b>To: </b>"Douglas Fischer" <<a href="mailto:fischerdouglas@gmail.com" target="_blank">fischerdouglas@gmail.com</a>><br><b>Cc: </b>"NANOG" <<a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a>><br><b>Sent: </b>Tuesday, September 8, 2020 1:30:19 PM<br><b>Subject: </b>Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'<br><br><div dir="ltr">BGP Large Communities ( <a href="https://tools.ietf.org/html/rfc8195" target="_blank">https://tools.ietf.org/html/rfc8195</a> ) already provides for anyone to define the exact handling you wish. <div><br></div><div><br></div></div><br><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">nanog@nanog.org</a>> wrote:<br></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"><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"><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;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div></div>
</blockquote></div>
</div><br></div></div></blockquote></div>
</div><br></div></div></blockquote></div>
</div><br></div></body></html>