So how do we name internal links in a way that is usefull for all operators, and conforms to the A-Z 0-9 and "-" and can be proposed as an RFC? --Peter
So how do we name internal links in a way that is usefull for all operators, and conforms to the A-Z 0-9 and "-" and can be proposed as an RFC?
--Peter
How about the Sprintlink: sl-pop-router#-port[-speed].sprintlink.net As an example? It's useful for Sprintlink NOC guys (they can see the router and port from DNS) and it's useful because it shows rough or exact link size information to outsiders. But instead of h0/0, use h0-0; s2-6; etc... Just a suggestion... i.e. icm-petersbathroom-2-s2-1-512.icp.net Avi
But instead of h0/0, use h0-0; s2-6; etc...
Just a suggestion...
i.e. icm-petersbathroom-2-s2-1-512.icp.net
You might need to include subinterfaces, and FR DLCIs / VC number as well. We use something very roughly like (I've, urm, simplifed this, i.e. written down what we ought to use) <2 letter POP code> <router number> - <1 let card type> <card no> - <i/f number> [ - <sub i/f number> [ - <DLCI num> ]] [ <2 letter POP code> <router number> ] So TH1-S2-3-4-5-ME6 is The 1st router in Telehouse Serial2/3.4, DLCI 5 which connects to the 6th router in MAE-East. This is readable iff you understand the convention first, which is arguably an advantage in dealing with some customers. Just an idea (not and RFC proposal :-) ) Alex Bligh Xara Networks
Alex.Bligh supposedly said:
But instead of h0/0, use h0-0; s2-6; etc... as well. We use something very roughly like (I've, urm, simplifed this, i.e. written down what we ought to use)
<2 letter POP code> <router number> - <1 let card type> <card no> - <i/f number> [ - <sub i/f number> [ - <DLCI num> ]] [ <2 letter POP code> <router number> ]
So TH1-S2-3-4-5-ME6
Well I think this is the best suggestion I have seen but I have a few comments: 1. I really like the addition of the final pop-router combo so its easy to follow connections. This has been missing in other suggestions so I am curious as to what others think. 2. Using an fixed width format as proposed keeps the maximum length (not including the domain suffix) short. Assuming 2 digit router/interface numbers and a four digit DLCI, the max length is 24 characters. (Even if we allow 3 digits to router numbers we max at 29). I would propose to add a little more information in the form of 1 letter types in from of the numbers (like a 'd' before the DLCI number). Looking at the example above is marginally okay because all field are present but what if there was either no subinterface or no DLCI, how would you tell what the last number is supposed to mean? 3. How do people feel about putting the speed of the link in the DNS name, I have seen one yea and one nay. I am ambivilant, but leaning towards no, not for privacy but for administrative ease. If I upgrade a connection I don't want to have to remember to change my DNS entries. 4. Are people actually interested in pursuing this formally? If a spec was written would you change your DNS names to conform? Would you be willing to set up a formal registration process with the IANA for 2(or 3) letter pop codes to be consistant? ---> Phil
On Tue, 7 Jan 1997, Philip J. Nesser II wrote:
1. I really like the addition of the final pop-router combo so its easy to follow connections. This has been missing in other suggestions so I am curious as to what others think.
I'm puzzled. Connections go from router to router. How does it help to say routerb-x-y-z-routerc.blah.net when routerc will show up as the next hop in the traceroute?
2. Using an fixed width format as proposed keeps the maximum length (not including the domain suffix) short. Assuming 2 digit router/interface numbers and a four digit DLCI, the max length is 24 characters. (Even if we allow 3 digits to router numbers we max at 29). I would propose to add a little more information in the form of 1 letter types in from of the numbers (like a 'd' before the DLCI number). Looking at the example above is marginally okay because all field are present but what if there was either no subinterface or no DLCI, how would you tell what the last number is supposed to mean?
As long as we are going to code router specific things in the DNS, they are going to be a wide variety of thing to indicate. We use the following scheme. <routername> - <interface designation> <slot number> - <card slot number> [<port number> [s <sub-interface number>].<pop>.cic.net. where interface designation is [fddi|hssi|ser|ether|fastether|atm|token|pos] i.e. um1-fastether3-0-0s1.ann-arbor.cic.net is the 1st sub interface of fastethernet in slot 3, card slot 0, port 0 of um1 router at our Ann Arbor POP.
3. How do people feel about putting the speed of the link in the DNS name, I have seen one yea and one nay. I am ambivilant, but leaning towards no,
Speed of the link is not important IMO.
4. Are people actually interested in pursuing this formally? If a spec was written would you change your DNS names to conform? Would you be willing
That depends on what's agreed on. Beauty is in the eye of the beholder, and so are names.
to set up a formal registration process with the IANA for 2(or 3) letter pop codes to be consistant?
If you wanted that, why not take the airport codes as many have already done? -dorian
Dorian R. Kim supposedly said:
On Tue, 7 Jan 1997, Philip J. Nesser II wrote:
1. I really like the addition of the final pop-router combo so its easy to follow connections. This has been missing in other suggestions so I am curious as to what others think.
I'm puzzled. Connections go from router to router. How does it help to say routerb-x-y-z-routerc.blah.net when routerc will show up as the next hop in
the traceroute?
True, but as was pointed out at the last NANOG, sometimes routes change in the middle of traceroute, and seeing where the next hop should be and where it actually goes is more apparent if its encoded on the DNS name. I certainly can live without it if people don't like it, but for me it seems like the right thing to do.
2. Using an fixed width format as proposed keeps the maximum length (not including the domain suffix) short. Assuming 2 digit router/interface numbers and a four digit DLCI, the max length is 24 characters. (Even if we allow 3 digits to router numbers we max at 29). I would propose to add a little more information in the form of 1 letter types in from of the numbers (like a 'd' before the DLCI number). Looking at the example above is marginally okay because all field are present but what if there was either no subinterface or no DLCI, how would you tell what the last number is supposed to mean?
As long as we are going to code router specific things in the DNS, they are going to be a wide variety of thing to indicate.
We use the following scheme.
<routername> - <interface designation> <slot number> - <card slot number> [<port number> [s <sub-interface number>].<pop>.cic.net.
where interface designation is [fddi|hssi|ser|ether|fastether|atm|token|pos] i.e.
um1-fastether3-0-0s1.ann-arbor.cic.net
Could we agree on a fixed width interface designation? fe instead of fastether? tk instead of token? etc..
3. How do people feel about putting the speed of the link in the DNS name, I have seen one yea and one nay. I am ambivilant, but leaning towards no,
Speed of the link is not important IMO.
4. Are people actually interested in pursuing this formally? If a spec was written would you change your DNS names to conform? Would you be willing
That depends on what's agreed on. Beauty is in the eye of the beholder, and so are names.
to set up a formal registration process with the IANA for 2(or 3) letter pop codes to be consistant?
If you wanted that, why not take the airport codes as many have already done?
Agreed, which is why I wanted to increase to 3 letter codes, but we need to make allowances for special places like the NAPS and the MAE's, which deserve their own pop codes.
-dorian
---> Phil
On Tue, 7 Jan 1997, Philip J. Nesser II wrote:
Could we agree on a fixed width interface designation? fe instead of fastether? tk instead of token? etc..
Why fixed width? Given that different gear can accomodate different mix of interfaces, the naming goop on the left side of domain name will be variable length. -dorian
Dorian R. Kim supposedly said:
On Tue, 7 Jan 1997, Philip J. Nesser II wrote:
1. I really like the addition of the final pop-router combo so its easy
to
follow connections. This has been missing in other suggestions so I am curious as to what others think.
I'm puzzled. Connections go from router to router. How does it help to say routerb-x-y-z-routerc.blah.net when routerc will show up as the next hop i n
the traceroute?
True, but as was pointed out at the last NANOG, sometimes routes change in the middle of traceroute, and seeing where the next hop should be and where it actually goes is more apparent if its encoded on the DNS name. I certainly can live without it if people don't like it, but for me it seems like the right thing to do.
2. Using an fixed width format as proposed keeps the maximum length (no
t
including the domain suffix) short. Assuming 2 digit router/interface numbers and a four digit DLCI, the max length is 24 characters. (Even i f we allow 3 digits to router numbers we max at 29). I would propose to a
conventions are fine and it's helpful to users and operators alike for names to contain a fair amount of information but "standardizing" with fixed-width fields, pop codes, next-hop router, etc. doesn't seem that productive when providers are gonna do what they want anyway. better to encourage them to include certain information in their names than specify how to spell DC my US$0.02 /jws p.s. as for recording the next-hop router, what happens on a lan? and what about an atm interface over which many vcs run? dd
a little more information in the form of 1 letter types in from of the numbers (like a 'd' before the DLCI number). Looking at the example abo ve is marginally okay because all field are present but what if there was either no subinterface or no DLCI, how would you tell what the last numb er is supposed to mean?
As long as we are going to code router specific things in the DNS, they ar e going to be a wide variety of thing to indicate.
We use the following scheme.
<routername> - <interface designation> <slot number> - <card slot number>
[<port number> [s <sub-interface number>].<pop>.cic.net.
where interface designation is [fddi|hssi|ser|ether|fastether|atm|token|po s] i.e.
um1-fastether3-0-0s1.ann-arbor.cic.net
Could we agree on a fixed width interface designation? fe instead of fastether? tk instead of token? etc..
3. How do people feel about putting the speed of the link in the DNS na me, I have seen one yea and one nay. I am ambivilant, but leaning towards n o,
Speed of the link is not important IMO.
4. Are people actually interested in pursuing this formally? If a spec was written would you change your DNS names to conform? Would you be willin g
That depends on what's agreed on. Beauty is in the eye of the beholder, an d so are names.
to set up a formal registration process with the IANA for 2(or 3) letter pop codes to be consistant?
If you wanted that, why not take the airport codes as many have already do ne?
Agreed, which is why I wanted to increase to 3 letter codes, but we need to make allowances for special places like the NAPS and the MAE's, which deserve their own pop codes.
-dorian
---> Phil
pjnesser@martigny.ai.mit.edu said:
the traceroute?
True, but as was pointed out at the last NANOG, sometimes routes change in the middle of traceroute, and seeing where the next hop should be and where it actually goes is more apparent if its encoded on the DNS name. I certainly can live without it if people don't like it, but for me it seems like the right thing to do.
I would vote against this. It is too easy for a mistake to lie to you. I've had it abused into my head that things that can lie are the worst thing when debugging a problem. pjnesser@martigny.ai.mit.edu said:
Could we agree on a fixed width interface designation? fe instead of fastether? tk instead of token? etc..
I think we agree fully on this. There are a small enough set of these to reasonably write them down. pjnesser@martigny.ai.mit.edu said:
to set up a formal registration process with the IANA for 2(or 3) letter > pop codes to be consistant? If you wanted that, why not take the airport codes as many have already done?
Agreed, which is why I wanted to increase to 3 letter codes, but we need to make allowances for special places like the NAPS and the MAE's, which deserve their own pop codes.
Been there, done that, won't make that mistake again. It scales badly to a worldwide level. We had multiple sites in malaysia that we couldn't dintinguish because they don't have enough airports. I think what makes more sense (at least to me) is to use any codes that make sense for your ISP, then you put text records in that describe the meaning of that pop abbreviation. It's all in the DNS, but it's not all crammed in the naming scheme. I think this could be done with the iftype abbreviations as well. For the price of a few more DNS queries, you can get dynamic mapping for each ISP in a common form. One other minor suggestion. I would recommend that there be a shelf as well as slot. The time is coming rapidly where routers will be as big as any other type of telco gear, and unit/shelf/slot/if is common throughtot the telco world. Jerry
We use the following scheme.
<routername> - <interface designation> <slot number> - <card slot number> [<port number> [s <sub-interface number>].<pop>.cic.net.
where interface designation is [fddi|hssi|ser|ether|fastether|atm|token|pos] i.e.
um1-fastether3-0-0s1.ann-arbor.cic.net
Could we agree on a fixed width interface designation? fe instead of fastether? tk instead of token? etc..
I agree.. Two letters seems quite sufficient for the time being though whose to say it will be in the future. It also tends to fix the size of the hostname.
"Dorian R. Kim" writes:
On Tue, 7 Jan 1997, Philip J. Nesser II wrote:
1. I really like the addition of the final pop-router combo so its easy to follow connections. This has been missing in other suggestions so I am curious as to what others think.
I'm puzzled. Connections go from router to router. How does it help to say routerb-x-y-z-routerc.blah.net when routerc will show up as the next hop in the traceroute?
I think it will help when routerc fails to show up as the next hop :) Perry
I'm puzzled. Connections go from router to router. How does it help to say routerb-x-y-z-routerc.blah.net when routerc will show up as the next hop in the traceroute?
I think it will help when routerc fails to show up as the next hop :)
No. Traceroute gives you the incoming interface on a router. For a given incoming interface on a router there are multiple next hop routers (and multiple outgoing interfaces). Knowing that the outgoing interface that a packet came from on the previous hop router is not worth adding to the DNS. If this is a point-to-point link, as you seem to be assuming, then it should be subnetted as a /30 and you can thus subtract or add 1 to the IP address as appropriate to find the previous hop's outgoing interface, if that information is important to you. If it is a multiple-access link, then there is no chance of the incoming interface being specific to a particular previous hop anyway, so this scheme falls apart. --jhawk
On Tue, 7 Jan 1997, Philip J. Nesser II wrote:
1. I really like the addition of the final pop-router combo so its easy to follow connections. This has been missing in other suggestions so I am curious as to what others think.
I'm puzzled. Connections go from router to router. How does it help to say routerb-x-y-z-routerc.blah.net when routerc will show up as the next hop in the traceroute?
From experience it helps when routerc *doesn't* show up in the traceroute (i.e. you get * * *) :-)
Actually it doesn't quite work like that as in a traceroute you always see the return i/f, so on a traceroute from A to B to C you see routerb-x-y-z-routera.blah.net routerc-x-y-z-routerb.blah.net It's mainly useful because you immediately know that a link is OK, if you just se serial0 or whatever with equipment that sometimes skips hop reports and sometimes double reports, sometimes is in mid flap, it saves working out whether that was the "right" serial i/f. Alex Bligh Xara Networks
In one message, Paul Vixie wrote:
[<iface>.]<router>.<pop>.<toplev>
In another message, Philip J. Nesser II wrote:
Alex.Bligh supposedly said:
<2 letter POP code> <router number> - <1 let card type> <card no> - <i/f number> [ - <sub i/f number> [ - <DLCI num> ]] [ <2 letter POP code> <router number> ]
TH1-S2-3-4-5-ME6
Well I think this is the best suggestion I have seen but I have a few comments:
1. I really like the addition of the final pop-router combo so its easy to follow connections. This has been missing in other suggestions so I am curious as to what others think.
It doesn't tell you what interface on the upstream router it's talking to, so I don't see an advantage.
2. Using an fixed width format as proposed keeps the maximum length (not including the domain suffix) short. Assuming 2 digit router/interface numbers and a four digit DLCI, the max length is 24 characters. (Even if we allow 3 digits to router numbers we max at 29). I would propose to add a little more information in the form of 1 letter types in from of the numbers (like a 'd' before the DLCI number). Looking at the example above is marginally okay because all field are present but what if there was either no subinterface or no DLCI, how would you tell what the last number is supposed to mean?
Just personal preference here, but I think Paul's example is easier to grok, especially if you don't know the "convention" beforehand. The similarity to DNS subdomain heirarchy lends itself directly to the router, then the slot, then the interface, and then the sub-interface/ DLCI/PVC/what-have-you.
3. How do people feel about putting the speed of the link in the DNS name, I have seen one yea and one nay. I am ambivilant, but leaning towards no, not for privacy but for administrative ease. If I upgrade a connection I don't want to have to remember to change my DNS entries.
4. Are people actually interested in pursuing this formally? If a spec was written would you change your DNS names to conform? Would you be willing to set up a formal registration process with the IANA for 2(or 3) letter pop codes to be consistant?
I like the idea of using the ICAO/IATA identifier of the nearest (major) airport as Paul seems to have done. All the work in defining them has already been done. My question is: who's the audience for this info? -- David Carmean <dlc@avtel.net> Avtel Communications, Santa Barbara, CA +1-805-730-7740 Opinions herein are those of the author only, unless otherwise noted
3. How do people feel about putting the speed of the link in the DNS name, I have seen one yea and one nay. I am ambivilant, but leaning towards no, not for privacy but for administrative ease. If I upgrade a connection I don't want to have to remember to change my DNS entries.
Personally, when I stare at it, all I care about is the loop type (DS0, DS1, DS3, OCx, whatever) and in some cases the transport mechanism (ATM, Frame, SMDS, etc). Since you're going to have different attributes after the interface type and port, there's going to be some level of variation.
4. Are people actually interested in pursuing this formally? If a spec was written would you change your DNS names to conform? Would you be willing to set up a formal registration process with the IANA for 2(or 3) letter pop codes to be consistant?
Well, all I'm really interested in (pending this discussion aging a bit..) is why / can't be a valid DNS character.. I mean, whats really the problem in simply allowing it? -Wayne
_All_ operators? Then let's use something that is given to us as the objective reality - serial and property numbers of boxes and interfaces. This way no operator will be confused by some accidental peculiarities of other operators' internal designs and these numbers are usually composed of alphanumeric characters. An unambiguous location information (USPS-style) should be included in the names too. The only problem will be to fit this all into the constraints of the DNS, but it's not a really big problem, as we can fix RFCs here too. An alternative decision might be to have a global registry of all the boxes and interfaces and use tools like Eric Wassenaar's traceroute that pull up all the needed information from this registry. :-) Dima Merry Christmas to all the Eastern Orthodox believers Peter Lothberg writes:
So how do we name internal links in a way that is usefull for all operators, and conforms to the A-Z 0-9 and "-" and can be proposed as an RFC?
--Peter
On Tue, 7 Jan 1997, Peter Lothberg wrote:
So how do we name internal links in a way that is usefull for all operators, and conforms to the A-Z 0-9 and "-" and can be proposed as an RFC?
Hopefully in a way that doesn't conflict with the use of the dash in this document http://sidhe.memra.com/dash.txt which will shortly be submitted as an Internet draft. Michael Dillon - Internet & ISP Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
So how do we name internal links in a way that is usefull for all operators, and conforms to the A-Z 0-9 and "-" and can be proposed as an RFC?
Well, here's what I suggested to UUNET and Genuity, which they mostly did: To: routing@uu.net Subject: please change your PTR RRs Date: Mon, 24 Jun 1996 06:38:08 -0700 From: Paul A Vixie <vixie@wisdom.home.vix.com> traceroute all over the world will soon show only IP addresses for alternet routers. alternet's router PTR RR names all have slash (/) and/or underbar (_) characters in them. BIND 4.9.4 considers these names "bad", per the CERT announcement earlier this year. please fix your names. what i use on my cisco backbones are names of the form: [<iface>.]<router>.<pop>.<toplev> where <iface> is something like <type><slot>[-<port>], i.e., fddi0 -> f0 (no port number) ethernet2/3 -> e2-3 hssi4.21 -> h4-21 (subinterface 21) note that <iface> is optional since the router's loopback interface address (for IBGP) will just be the router's name. <router> is something like "CR2". <pop> is something like "DCA1". <toplev> is something like "alter.net". thus 106.Hssi4/0.CR2.DCA1.Alter.Net -> h4-106.cr2.dca1.alter.net
So how do we name internal links in a way that is usefull for all operators, and conforms to the A-Z 0-9 and "-" and can be proposed as an RFC?
Well, here's what I suggested to UUNET and Genuity, which they mostly did:
[...]
[<iface>.]<router>.<pop>.<toplev>
where
<iface> is something like <type><slot>[-<port>], i.e., fddi0 -> f0 (no port number) ethernet2/3 -> e2-3 hssi4.21 -> h4-21 (subinterface 21) note that <iface> is optional since the router's loopback interface address (for IBGP) will just be the router's name.
<router> is something like "CR2".
<pop> is something like "DCA1".
<toplev> is something like "alter.net".
I got tired of trying to fix this problem one interface at a time and finally wrote a script that digests a Cisco config file and produces both an error report and the named db files. We use a slightly different convention, but the script is easy to modify. % cat clv1.oar.net | ./ifdns -foar.cfg -e Reverse lookup problem report IP Address Current Hostname Correct Hostname ------------------------------------------------------------------------------ 131.187.68.5 csp-ccf.oar.net clv1-sl9-5.cle.oar.net 199.18.19.5 clv1-lo0.cleveland.oar.net clv1-lo0.cle.oar.net 199.18.21.1 clv1-e0.oar.net clv1-eth0-0.cle.oar.net ... Forward lookup problem report Hostname Current IP Address Correct IP Addrses ------------------------------------------------------------------------------ clv1-sl9-5.cle.oar.net *** 131.187.68.5 clv1-lo0.cle.oar.net *** 199.18.19.5 clv1-eth0-0.cle.oar.net *** 199.18.21.1 .. ftp://ftp.net.ohio-state.edu/users/maf/priv/ifdns and oar.cfg or osu.cfg -- mark
participants (15)
-
Alex.Bligh -
Avi Freedman -
dlc＠avtel.net -
Dorian R. Kim -
dvv＠sprint.net -
Jerry Scharf -
John Hawkinson -
John W. Stewart III -
Mark A. Fullmer -
Michael Dillon -
Paul A Vixie -
Perry E. Metzger -
Peter Lothberg -
Philip J. Nesser II -
Wayne Bouchard