
<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title></title>

</head>

<body>

<div name="messageBodySection">I myself am also of two mind on where the flag belongs: on the one hand I strongly recommend everyone to use dedicated ASNs for route server functions (and as such the "net" object is a good place to store it), on the other hand at the "ip level" offers more fine grained control.<br />

<br />

What do others think?<br />

<br />

Kind regards,<br />

<br />

Job</div>

<div name="messageSignatureSection"><br /></div>

<div name="messageReplySection"><br />

On 12 Dec 2016, 20:47 +0100, Arnold Nipper <arnold@nipper.de>, wrote:<br />

<blockquote type="cite">On 12.12.2016 14:25, Job Snijders wrote:<br />

<blockquote type="cite">On Mon, Dec 12, 2016 at 01:58:51PM +0100, Arnold Nipper wrote:<br />

<blockquote type="cite">What does it help when everyone is able to set the flag and you can't<br />

trust that this really is a route server net?<br /></blockquote>

<br />

It helps on the configuration generation side:<br />

<br />

If "route server" == true:<br />

no bgp enforce-first-as<br />

no bgp next-hop peer-address<br />

no as_path_filter "^$peer_asn_"<br />

else:<br />

bgp enforce-first-as<br />

bgp next-hop peer-address<br />

as_path_filter XYZ<br />

<br />

The above pseudo code is assuming people generate config straight from<br />

PDB, in addition to the above, a PDB user can programmatically enforce<br />

their:<br />

<br />

"we peer with every route server"-policy<br />

or "we dont peer with any route servers"-policy<br />

or "we only peer with route servers operated by the IXP themselves"-policy<br />

<br />

So one could argue there is a wide varierty of decisions that can be<br />

assisted if your peers self-report whether they are perform a Route<br />

Server function or not.<br />

<br />

All data retrieved from PDB must be validated against an operators own<br />

policy and procedures. I always consider PDB data to be a raw resources,<br />

this does not have to do with (lack of) trust, but rather with making<br />

assisted choices.<br />

<br />

Hope this clarifies the use case.<br />

<br /></blockquote>

<br />

The use case is quite clear. It's more about where and what to store.<br />

And the more I think about that I come to the conclusion that this<br />

information belongs to the peering IP and not to the network. So far you<br />

can tag the IP that it is an RS Peer. What you would need additionally<br />

is that the IP is an RS itself. Does that make sense?<br />

<br />

<br />

<br />

Arnold<br />

<br /></blockquote>

</div>

</body>

</html>