<div dir="ltr">Mark,<div><br></div><div>This does not require any more trust for say directly connected peers more then today when you publish communities on the web page. </div><div><br></div><div>It is not about opening up your network. It is about expressing your policy in a common way in the exact say amount as you would open up your network today. </div><div><br></div><div>Notice that in addition to common types there is equal amount of space left for operator's define types. It is just that the structure of community can take number of arguments used during execution - that's all. </div><div><br></div><div>Thx,<br>R.</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 8:10 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"><br>
<br>
On 8/Sep/20 18:41, Robert Raszuk wrote:<br>
<br>
> I don't think this is the ask here. <br>
><br>
> Today NO_EXPORT takes no parameters. I think it would be of benefit to<br>
> all to be able to signal NO_EXPORT TO ASN_X in a common (std) way<br>
> across all of my peers connected to ASN_X. Moreover policy on all<br>
> vendors could understand it too without you worrying to match<br>
> YOUR_STRING and translate into some local policy. <br>
><br>
> That is by no means taking away anything you have at your fingertips<br>
> .. it just adds an option to talk common policy language.<br>
<br>
This already happens today, but mostly in a commercial relationship<br>
(customer and provider).<br>
<br>
While not technically impossible, I struggle to see operators opening up<br>
their networks to peers they hardly personally (or commercially) know<br>
with such a feature, custom or standardized.<br>
<br>
I suppose the bigger question is - can we trust each other, as peers,<br>
with such access to each other's networks?<br>
<br>
Mark.<br>
</blockquote></div>