<div dir="ltr">Mark,<div><br></div><div>> The standard already exists... "NO_EXPORT".  <br></div><div><br></div><div>I don't think this is the ask here. </div><div><br></div><div>Today NO_EXPORT takes no parameters. I think it would be of benefit to all to be able to signal NO_EXPORT TO ASN_X in a common (std) way across all of my peers connected to ASN_X. Moreover policy on all vendors could understand it too without you worrying to match YOUR_STRING and translate into some local policy. </div><div><br></div><div>That is by no means taking away anything you have at your fingertips .. it just adds an option to talk common policy language. </div><div><br></div><div>Cheers,</div><div>R.</div><div><br></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 6:23 PM Mark Tinka via NANOG <<a href="mailto:nanog@nanog.org">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>
    <br>
    <br>
    <div>On 8/Sep/20 17:55, Douglas Fischer via
      NANOG wrote:<br>
      <br>
    </div>
    <blockquote type="cite">
      
      <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>
    </blockquote>
    <br>
    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>
    <br>
    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>
    <br>
    Mark.<br>
  </div>

</blockquote></div>