<div dir="ltr"><div><br></div>It's not about numbers ... it's about ability to uniformly express policy with chain of arguments. <div><br></div><div>See even with large communities you can define a policy with an unstructured parameter and single action then you need to put it on all of your boxes to act upon. </div><div><br></div><div>Is it possible to perhaps express it there to do what you need today or what you think is possible today. </div><div><br></div><div>Imagine if you would be sending BGP updates between your internal peers and tell each peer how to read the encoding ... Doable - sure. Good idea - not quite. </div><div><br></div><div>R.</div><div><br></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 Wed, Sep 9, 2020 at 5:19 PM Mark Tinka <<a href="mailto:mark.tinka@seacom.com">mark.tinka@seacom.com</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 9/Sep/20 15:25, Robert Raszuk wrote:<br>
      <br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>That's not quite true. </div>
          <div><br>
          </div>
          <div>See the entire idea behind defining a common mechanism
            for signalling policy in communities in a flexible way for
            both intra and inter-domain use is to help you to use the
            same encoding acros policy engines of many vendors. </div>
          <div><br>
          </div>
          <div>I would actually risk to say that it could be even more
            applicable intra-domain then inter-domain. </div>
          <div><br>
          </div>
          <div>See the crux of the thing is that this is not just about
            putting bunch of type-codes into IANA reg. It is much more
            about uniform encoding for your actions with optional
            parameters across vendors. </div>
          <div><br>
          </div>
          <div>In fact the uphill on the implementation side is not
            because signalling new value in BGP is difficult to encode
            ... it is much more about taking those values and
            translating those to the run time policies in a
            flexible way.  <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    But how does that scale for vendors? Let me speak up for them on
    this one :-).<br>
    <br>
    We are now giving them extra work to write code to standardize
    communities for internal purposes. What extra benefit does that
    provide in lieu of the current method where Juniper send 1234:9876
    to Cisco, and Cisco sees 1234:9876?<br>
    <br>
    Should a vendor be concerned about what purpose an internal
    community serves, as long as it does what the Autonomous System
    wants it to do?<br>
    <br>
    Unless I am totally misunderstanding your goal.<br>
    <br>
    Mark.<br>
  </div>

</blockquote></div>