Peeringdb: Add 'recommended_routeserver_asn' to ix object

[job]

How about we add a preferred_routeserver attribute to the ix object:

The ix owner sets the value of the attribute, by selecting from a drop-down menu from a list of net objects connected to the ix.

The actual value of the attribute is the ASN of the Preferred Route Server. This way users can do a quick lookup.

Via API we can expose just the ASN integer of the preferred route server, via web interface we can make it a clickable link, example: <a href="/net/6033">AS 53339</a>

[job]

related issues: https://github.com/peeringdb/peeringdb/issues/672 and https://github.com/peeringdb/peeringdb/issues/673

it is clear some in the group have a very strong desire to somehow link the route server to the ixp to make it look and feel more like an actual ISP - I wish the large scale IXPs would actually migrate to a routing based approach instead of extending layer-2 fabrics into larger and larger things. I think years down the road we'll look back at UI changes like this and conclude "this is how the Internet became a single layer-2 domain".

[arnoldnipper]

-1 as it it introduces complexity where it isn't needed

[job]

If this introduces complexity, I have no idea what the other 2 issues are in terms complexity :-)

[arnoldnipper]

I stand corrected to what I said 10 days ago. I made the same proposal already in a
comment to #673

However, instead of preferred_routeserver I would name it recommended_routeserver. And instead of a dropdown make it freely configurable as this would also cover the case that the recommended_routeserver is run by a different org as the one the ix belongs to

[ynbrthr]

And instead of a dropdown make it freely configurable as this would also cover the case that the recommended_routeserver is run by a different org as the one the ix belongs to

what if it's a typo? Shouldn't we notify the user if the ASN he enters is: not a 'Route server' (network type), 2. not a member of the IX; 3. not an existing ASN.

[arnoldnipper]

Actually, I would propose to do it the other way round. The value in recommended_rs has to be

• a net already in PeeringDB

• the net has set info_type to "Route Servers"

If not display an error message.

[ynbrthr]

Actually, I would propose to do it the other way round. The value in recommended_rs has to be

• a net already in PeeringDB

• the net has set info_type to "Route Servers"

If not display an error message.

works for me.

[job]

Actually, I would propose to do it the other way round. The value in recommended_rs has to be

• a net already in PeeringDB
• the net has set info_type to "Route Servers"

If not display an error message.

works for me.

and the net has to be connected to the IXP, i don't think we should allow the system to recommend a route server that is not connected to the fabric :-)

[mcmanuss8]

I'll summarize what I think the proposal should be (seems like we're in agreement, but just summarizing for clarity):

• Add a field called "recommended_route_server" to the ix object. Default it to null for all existing and new records
• Allow an ix owner/admin to select a value for the recommended_route_server field via the UI. Show a dropdown with the list of net objects that are:
  
  
  
  • Members of the IX and
  
  
  • Network Type of Route Server
    
    Consider pushing nets owned by the same org as the ix to the top of the list, followed by others, alphabetically.
  
  
• Display the recommended route server value as a link to the appropriate net object on the /ix/ page, above notes and below Protocols Supported in the main ix info section

+1 to this

[arnoldnipper]

I would like to propose

• removing the limit that the ASN has to be owned by the IX operator (i.e. no drop-down)
• allow multiple values

[mcmanuss8]

removing the limit that the ASN has to be owned by the IX operator (i.e. no drop-down)

I agree. In my summary it was more of a hint (pushing the IX owned ASNs to the top), but not a requirement (you could still pick any Route Server ASN in the list)

allow multiple values

So recommended_routeserver_asns ? How common is it for IX operators to have multiple route servers? I operate no IXes. :)

[arnoldnipper]

So recommended_routeserver_asns ? How common is it for IX operators to have multiple route servers?

Not very, but I can imagine it might be. Otoh, I don't see any harm for allowing more than one. So it is future-proof

[as44980]

So recommended_routeserver_asns ? How common is it for IX operators to have multiple route servers? I operate no IXes. :)

There are certainly use cases where an operator has acquired an existing IXP and deploys new route servers with a different ASN from the 'legacy' RS's, although in that case I would expect both net objects to be associated with the same org as the ix record..

Additionally there are networks which function as a route-server connected to an IXP which is operated by the same org, but also peers at IXP's operated by third parties.. although likely with a policy which does not redistribute prefixes between 'peers' at the third party IXP.

instead of a dropdown make it freely configurable as this would also cover the case that the recommended_routeserver is run by a different org as the one the ix belongs to

Worth considering as there may well be instances where there are multiple route servers connected to the same fabric, each redistributing prefixes between their respective peers but not each other...

However do we know of any cases where the IXP operator would "recommend" its members use a route server operated by a third party? :)

and the net has to be connected to the IXP, i don't think we should allow the system to recommend a route server that is not connected to the fabric :-)

:+1:

[grizz]

• removing the limit that the ASN has to be owned by the IX operator (i.e. no drop-down)

@arnoldnipper
I'm confused by this, there would still need to be a drop down, as it only will allow you to set members of the IX that are type route server. RIght?

[arnoldnipper]

I'm confused by this, there would still need to be a drop down, as it only will allow you to set members of the IX that are type route server. RIght?

The ASN already has to be in PeeringDB and its info_type has to be "Route Servers". I'm not sure what is more user friendly. To present a dropdown or to give the error message 'The ASN has to be in PeeringDB and its Network Type has to be "Route Servers"' if the conditions are not met. I'm very much for the latter.

[netravnen]

I'm confused by this, there would still need to be a drop-down, as it only will allow you to set members of the IX that are type route server. RIght?

The ASN already has to be in PeeringDB and its info_type has to be "Route Servers". I'm not sure what is more user friendly. To present a dropdown or to give the error message 'The ASN has to be in PeeringDB and its Network Type has to be "Route Servers"' if the conditions are not met. I'm very much for the latter.

I am with Arnold on this point, i.e. +1 for the latter.

[grizz]

I'm confused by this, there would still need to be a drop down, as it only will allow you to set members of the IX that are type route server. RIght?

The ASN already has to be in PeeringDB and its info_type has to be "Route Servers". I'm not sure what is more user friendly. To present a dropdown or to give the error message 'The ASN has to be in PeeringDB and its Network Type has to be "Route Servers"' if the conditions are not met. I'm very much for the latter.

@arnoldnipper it also needs to be on that IX.

From a usability standpoint, the former is so much more user friendly. A drop down of IX members that have network type route server is going to be 1 most of the time. In fact, I'd say we could default it to recommended if there is only one network of type route server on the IX.

I feel like we might be having a communication break down here? No one has said the IX needs to own the route server, but the network does need to be a member of the IX, otherwise, to start with, there's no IP address associated with the entry. Since there's such a small subset of networks on the IX of type route server (again, 1 in most cases), it should be a drop down and not a text field.

[arnoldnipper]

You are right, @grizz ... I forgot about the 3rd condition that the ASN has to be a member of the IX. Then a dropdown makes perfect sense. Thank you for clarifying!

[job]

From a usability standpoint, the former is so much more user friendly. A drop down of IX members that have network type route server is going to be 1 most of the time. In fact, I'd say we could default it to recommended if there is only one network of type route server on the IX.

I think the recommended route server ASN can only be considered recommended if the IX operator took an explicit action to recommend it. We should not autogenerate recommendations, if we do we should rename the field to something else maybe?

[arnoldnipper]

I think the _recommended_ route server ASN can only be considered recommended if the IX operator took an explicit action to recommend it. We should not autogenerate recommendations, if we do we should rename the field to something else maybe?

You are absolutely true. However, we only want to support the ix operator in picking this _recommended_ route server ASN. Makes sense?

[job]

I think the _recommended_ route server ASN can only be considered recommended if the IX operator took an explicit action to recommend it. We should not autogenerate recommendations, if we do we should rename the field to something else maybe?

You are absolutely true. However, we only want to support the ix operator in picking this _recommended_ route server ASN. Makes sense?

If PeeringDB automatically makes a recommendation to an IX operator about what potentially could be the recommended_routeserver ... sure! ;-)

[as44980]

I support only permitting the IXP to recommend a route-server which has both a net object with network type route-server, and lists an ip address from the IXP peering lan, as this seems useful to reduce the risk of an incorrect ASN accidentally being populated here..

Regarding the concerns that pre-populated a drop down list implies that the origin of the recommendation is coming from PeeringDB, rather than the IXP, could these be mitigated by making the first and thus default entry in the dropdown a null?

ie the IXP would have to expand the drop down and select one of the (valid) route-server networks connected to that IXP, then explicitly submit the value, in order for this value to be displayed as the 'recommended_routeserver_asn' :)

[vegu]

summary

• add preferred_routeserver field to schema and api of internetexchange object
• can be null or a relationship to a netixlan object that meets the following conditions
  
  
  
  • exists at exchange
  
  
  • is_rs_peer = True
  
  
  • ipaddress specified and within the address space defined on the ixlan
  
  
• defaults to null (not set)
• ui renders this showing ASN, speed and ipaddresses, ASN links to network page
• ui edits this in a dropdown that shows ASN and ipaddress
• api renders this as asn int at depth=0
• api renders this as expanded netixlan object at depth=1 and above

[vegu]

@job @peeringdb/pc please review the summary i posted above and if good move to ready to implement. Otherwise please advise changes and/or post an updated summary

[mcmanuss8]

+1

-Steve

On Jul 17, 2020, at 12:34 PM, Stefan Pratter [e-mail] wrote:


summary

add preferred_routeserver field to schema and api of internetexchange object
can be null or a relationship to a netixlan object that meets the following conditions
exists at exchange
is_rs_peer = True
ipaddress specified and within the address space defined on the ixlan
defaults to null (not set)
ui renders this showing ASN, speed and ipaddresses, ASN links to network page
ui edits this in a dropdown that shows ASN and ipaddress
api renders this as asn int at depth=0
api renders this as expanded netixlan object at depth=1 and above
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

[ynbrthr]

@job @peeringdb/pc please review the summary i posted above and if good move to ready to implement. Otherwise please advise changes and/or post an updated summary

that is a lovely summary :)

All that to say, +1

[arnoldnipper]

summary

• add preferred_routeserver field to schema and api of internetexchange object

Actually ist should only by preferred_routeserver_asn and not preferred_routeserver

• can be null or a relationship to a netixlan object that meets the following conditions

  • exists at exchange
  • is_rs_peer = True
  • ipaddress specified and within the address space defined on the ixlan

this then also does not make sense as it only points to an asn

• defaults to null (not set)
• ui renders this showing ASN, speed and ipaddresses, ASN links to network page

same here

• ui edits this in a dropdown that shows ASN and ipaddress

same here

• api renders this as asn int at depth=0
• api renders this as expanded netixlan object at depth=1 and above

no netixlan at all

[as44980]

Actually ist should only by preferred_routeserver_asn and not preferred_routeserver

+1

  * is_rs_peer = True

From what I can gather the 'is_rs_peer' flag is available to be set by networks who wish to indicate that they peer with the (a?) route-server in that IX, rather than that the network itself is a route-server...

So, should the test for inclusion in the preferred_routeserver_asn dropdown perhaps require net record for that asn has a "Network Type of Route Server" ?

[ynbrthr]

summary

• add preferred_routeserver field to schema and api of internetexchange object

Actually ist should only by preferred_routeserver_asn and not preferred_routeserver

Are we not erring on the pedantic and lengthy side? The latter seems understandable as it is.

[arnoldnipper]

Are we not erring on the pedantic and lengthy side? The latter seems understandable as it is.

No, we aren't ... we always were talking about and the consensus was that the value of the field is an asn and not a netixlan object. I.e. we are pointing to the RS ASN and not the RS themselves.

[ynbrthr]

Are we not erring on the pedantic and lengthy side? The latter seems understandable as it is.

No, we aren't ... we always were talking about and the consensus was that the value of the field is an asn and not a netixlan object. I.e. we are pointing to the RS ASN and not the RS themselves.

that's understood. Even tho, i was arguing that by using "preferred_routeserver", it was clear that we were referring to an actual ASN (metonymy?). But I don't have a strong opinion either way.

[arnoldnipper]

Even tho, i was arguing that by using "preferred_routeserver", it was clear that we were referring to an actual ASN (metonymy?

Actually it was not as @vegu was pointing to RS and not to a net

[grizz]

The field will be stored as a link to the network on the exchange, not just a text ASN. Also, to be clear, it's a set of ASNs, not just a single one. So probably preferred_routeservers or preferred_routeserver_set

ui edits this in a dropdown that shows ASN and ipaddress

This should just be ASN.

[as44980]

The field will be stored as a link to the network on the exchange, not just a text ASN. Also, to be clear, it's a set of ASNs, not just a single one. So probably preferred_routeservers or preferred_routeserver_set

ui edits this in a dropdown that shows ASN and ipaddress

This should just be ASN.

Either way, is this drop down envisaged to allow the selection of multiple ASN's based on the idea to "allow multiple values" despite no mention of any known use cases where an IXP might "recommend" that participants peer with multiple route-servers?

[grizz]

Bumping this to needs implementation details while it's decided.

[arnoldnipper]

Summary

• add recommended_routeserver_asn field to schema and api of ix object
• can be null or a relationship to a net object that meets the following conditions
  
  
  
  • exists at exchange (i.e. ipaddress specified and within the address space defined on the ixlan)
  
  
• defaults to null (not set)
• ui renders this showing ASN, ASN links to network page
• ui edits this in a dropdown that shows ASN
• api renders this as asn int at depth=0

@vegu / @grizz does that make sense?

[grizz]

So, to be clear, this is a single network, not a set?

Shouldn't the net be required to be type "Route Server?"

I don't like adding "shortcut" fields to depth=0, @job what were you envisioning with using asn in the API instead of the net_id?

Since this is adding fields to the API at multiple levels, it should probably be a full vote -- let's discuss on the next call @mcmanuss8?

[grizz]

For the UI, I think it would make sense to add IP addresses on that exchange, and we discussed adding looking glass in #672 -- really this should be a whole new summary section in the web UI.

[arnoldnipper]

For the UI, I think it would make sense to add IP addresses on that exchange

What exactly do you mean by that? Would the UI

• point to the RS ASN (i.e. /net/xxx)

• all of the RS association to that exchange (i.e. a list of netixlan objects, labelled by the IP)

Honestly, I can't see any benefit to add the IP addresses here.

[grizz]

UI would link to /net/$xxx, but display AS, and IP addresses. Display the IP since people use PDB's website to configure sessions by hand.

[arnoldnipper]

UI would link to /net/$xxx, but display AS, and IP addresses. Display the IP since people use PDB's website to configure sessions by hand.

Please provide a mockup for the GUI and how it does look like in the API, @grizz

[as44980]

The field will be stored as a link to the network on the exchange, not just a text ASN. Also, to be clear, it's a set of ASNs, not just a single one. So probably preferred_routeservers or preferred_routeserver_set

ui edits this in a dropdown that shows ASN and ipaddress

This should just be ASN.

Either way, is this drop down envisaged to allow the selection of multiple ASN's based on the idea to "allow multiple values" despite no mention of any known use cases where an IXP might "recommend" that participants peer with multiple route-servers?

Would it be possible to clarify this?