Re: misleading use of the connect: field in inetnum: object
Hi Daniel,
the real problem with the "connect" attribute is that it still is the badly defined kludge it has been from the start. I can say so because I invented it. Today we have a well defined and agreed way of specifying the information you want: It is called ripe-81 by the document fans and "The Routing Registry" by afficionados.
I had one and only one basic concern: when we put info into the DB, this info should HELP and not CONFUSE. I agree with you that "connect:" is maybe far from optimal.
In my opinion we should put our efforts in getting the RR populated rather than trying to specify how to use an un-specifyable kludge.
So now I've got another concern: populating the RR helps the "afficionados", but probably doesn't help the (end-)user in finding out what he/she can expect. I'd assume people are still thinking in terms of NORDUnet, NSF, RIPE and not in terms of ASxxx and ASyyy. And the basic issue remains - you can just as well put some string into the "as-*:" fields and still have only EARN-E-Mail connectivity...
The original plan was to keep connect alive with the only legal value of LOCAL. Maybe we shouldn't even do this. An item for discussion at the RIPE meeting!
Definitely! And thanks for spending some minutes on it. Cheers, Wilfried.
"Wilfried Woeber, UniVie/ACOnet" <woeber@cc.univie.ac.at> writes: I had one and only one basic concern: when we put info into the DB, this info should HELP and not CONFUSE.
Fully agree. That is hard to do with the current connect field.
So now I've got another concern: populating the RR helps the "afficionados" , but probably doesn't help the (end-)user in finding out what he/she can expect. I'd assume people are still thinking in terms of NORDUnet, NSF, RIP E and not in terms of ASxxx and ASyyy.
Of course you can look up what ASxxx and ASyyy are in the very same database. And find NORDUnet, ACOnet etc. Maybe we should include that info in the recursive lookup information? It can only be one AS per net so it will not be too bad. In the future we will provide tools (PRIDE project) which can actually answer the question "Is there supposed to be connectivity from here to there?" which is the question you are concerned about. The crucial point for these tools to be able to work is a well populated routing registry. That is why I would like to spend efforts on this rather than on fixing old kludges. In the long run (and even in the short run) this will be much more useful.
And the basic issue remains - you can just as well put some string into the "as-*:" fields and still have only EARN-E-Mail connectivity...
No you can't because that is a guarded field and maintained by the service provider represented by that AS. It is not maintained by the people maintaining the network entry. If they have no service provider they will have no information there. VERY different from connect.
Definitely! And thanks for spending some minutes on it.
My pleasure and my job! Daniel
So now I've got another concern: populating the RR helps the "afficionados", but probably doesn't help the (end-)user in finding out what he/she can expect. I'd assume people are still thinking in terms of NORDUnet, NSF, RIPE and not in terms of ASxxx and ASyyy.
Of course you can look up what ASxxx and ASyyy are in the very same database. And find NORDUnet, ACOnet etc. Maybe we should include that info in the recursive lookup information? It can only be one AS per net so it will not be too bad.
But that will not give you the same functionality, and at an increase in both "processing load" and "information load" for the user. I agree that the "connect" field is a kludge not usable for any automated use, but I *do* find it useful as simply a commentary field indicating the intended connectivity. And as long as the NSFnet autonomous system is not in the European routing registry (it isn't, right?), you will not be able to represent the effect of "connect: NSF" with the routing registry. If we were to use the method Daniel hints at to obtain the same (or corresponding) information, you would have to trace the use of an autonomous system number in all the "as-out" and "as-in" fields for the autonomous systems between "here" and "there" to see if there is any intended connectivity. And since you have to have two-way traffic to communicate, you'd have to trace back again (possibly looking at default routes...) I therefore conclude that calculating the equivalent of the "connect" field dynamically on every "whois" lookup for a given network will probably be too expensive (besides, "there" is not well-defined in such a query...:-). I also concur with Wilfried that people still think in terms of NORDUnet, NSFnet, RIPE (?), EBONE, the GIX etc., and personally I see nothing wrong with that. So my personal opinion on the matter at hand is not to delete the "connect" field altogether (or maim it to be essentialy useless by only allowing LOCAL as a legal value (did I mis-quote that?)), but rather redefine it to be "intended region-wise connectivity". This could be done by possibly dropping the RIPE and NORDU attributes (RIPE has no routers and NORDU is more or less equivalent to EBONE these days, connectivity-wise, and besides NORDUnet isn't a large enough region in these matters, IMHO) and instead add EBONE, GIX (and possibly CIX?), and keep EU (?), NSF and of course LOCAL. Please note that this is expression of intent, but it should of course be kept reasonably in sync with reality, eg. by following the routine I do :-) as described in my previous message. Also: please note that I fully support the work behind RIPE-81, the PRIDE project and the population of the routing registry database. However, the "connect" field is hardly a substitute for any of that work (or vice versa). Hope you don't get sick of my nagging :-), - Havard
Havard Eidnes <Havard.Eidnes@runit.sintef.no> writes: * > > So now I've got another concern: populating the RR helps the * > > "afficionados", but probably doesn't help the (end-)user in finding * > > out what he/she can expect. I'd assume people are still thinking in * > > terms of NORDUnet, NSF, RIPE and not in terms of ASxxx and ASyyy. * > * > Of course you can look up what ASxxx and ASyyy are in the very same * > database. And find NORDUnet, ACOnet etc. Maybe we should include that * > info in the recursive lookup information? It can only be one AS per net * > so it will not be too bad. * * But that will not give you the same functionality, and at an increase in * both "processing load" and "information load" for the user. I agree that * the "connect" field is a kludge not usable for any automated use, but I * *do* find it useful as simply a commentary field indicating the intended * connectivity. And as long as the NSFnet autonomous system is not in the * European routing registry (it isn't, right?), you will not be able to * represent the effect of "connect: NSF" with the routing registry. * * If we were to use the method Daniel hints at to obtain the same (or * corresponding) information, you would have to trace the use of an * autonomous system number in all the "as-out" and "as-in" fields for the * autonomous systems between "here" and "there" to see if there is any * intended connectivity. And since you have to have two-way traffic to * communicate, you'd have to trace back again (possibly looking at default * routes...) I therefore conclude that calculating the equivalent of the * "connect" field dynamically on every "whois" lookup for a given network * will probably be too expensive (besides, "there" is not well-defined in * such a query...:-). * * I also concur with Wilfried that people still think in terms of NORDUnet, * NSFnet, RIPE (?), EBONE, the GIX etc., and personally I see nothing wrong * with that. So my personal opinion on the matter at hand is not to delete * the "connect" field altogether (or maim it to be essentialy useless by only * allowing LOCAL as a legal value (did I mis-quote that?)), but rather * redefine it to be "intended region-wise connectivity". This could be done * by possibly dropping the RIPE and NORDU attributes (RIPE has no routers and * NORDU is more or less equivalent to EBONE these days, connectivity-wise, * and besides NORDUnet isn't a large enough region in these matters, IMHO) * and instead add EBONE, GIX (and possibly CIX?), and keep EU (?), NSF and of * course LOCAL. Please note that this is expression of intent, but it should * of course be kept reasonably in sync with reality, eg. by following the * routine I do :-) as described in my previous message. * Well finally you find a comment in here form me ;-). Whilst I agree "to a point" I do not see this really helps as much as you say. First, there is a granularity issue of where you stop with "so-called" regions. Connectivity (intended or otherwise) cannot be defind by anything else other than routing interaction. Adding "name tags" to nets (which are not guarded) is *not* an indication of connectivity (intended or otherwise). To the NSF issue you can of course check (whether you are allowed rather than connected with "-a" flag or whois -h prdb.merit.edu "net". * Also: please note that I fully support the work behind RIPE-81, the PRIDE * project and the population of the routing registry database. However, the * "connect" field is hardly a substitute for any of that work (or vice versa) * . * Well - no it isn't but it is a "proof/result versus intention" issue. PRIDE will give you the ability to extrapolate as you said above. In time to be truly functional the routing registry (as with all registries) must have more coverage than just the RIPE RR whether it be by comman exchange of RIPE-81 style objects or an agreed transfer syntax. As an alternative. Why not just document the "intended connectivity" as remarks and update accordingly. * * Hope you don't get sick of my nagging :-), * Never and it's not nagging. I just remember from before how "undefined" these connect: TAGS were and how difficult it is to use/decide on them but perhaps I'm not seeing it straight either ? * - Havard --Tony
Sorry, but why don't use DNS to propogate RIPE data-base information (such as AS - NET - CUSTOMER information), for example by using some pseudo-domain? We are speaking about internal information system (domains, networks -> customer, rights) system because we are starting of working with additional services and many different servers have to know status of every user throuth it's domain name or network number. Rudnev Aleksey, postmaster@kiae.su, Relcom.
> So now I've got another concern: populating the RR helps the "afficionados" > , > but probably doesn't help the (end-)user in finding out what he/she can > expect. I'd assume people are still thinking in terms of NORDUnet, NSF, RIP > E > and not in terms of ASxxx and ASyyy.
Of course you can look up what ASxxx and ASyyy are in the very same database. And find NORDUnet, ACOnet etc. Maybe we should include that info in the recursive lookup information? It can only be one AS per net so it will not be too bad.
In the future we will provide tools (PRIDE project) which can actually answer the question "Is there supposed to be connectivity from here to there?" which is the question you are concerned about.
The crucial point for these tools to be able to work is a well populated routing registry. That is why I would like to spend efforts on this rather than on fixing old kludges. In the long run (and even in the short run) this will be much more useful.
> And the basic issue remains - you can > just as well put some string into the "as-*:" fields and still have only > EARN-E-Mail connectivity...
No you can't because that is a guarded field and maintained by the service provider represented by that AS. It is not maintained by the people maintaining the network entry. If they have no service provider they will have no information there. VERY different from connect.
> Definitely! > And thanks for spending some minutes on it.
My pleasure and my job!
Daniel
participants (5)
-
alex＠kiae.su -
Daniel Karrenberg -
Havard Eidnes -
Tony Bates -
Wilfried Woeber, UniVie/ACOnet