|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: nanog@nanog.org Date: Tue, 22 Aug 2017 08:36:39 +0100 From: Allan Eising <eising@nordu.net> To: Colton Conor <colton.conor@gmail.com>, nanog@nanog.org In-Reply-To: <CAMDdSzPotYBiYgXH=eTtPGJ1hLcQ8wkpEpFbdskR-zTsNL6fOA@mail.gmail.com> Errors-To: nanog-bounces@nanog.org Excerpts from Colton Conor's message of August 21, 2017 10:26 pm: > We are building a new fiber network, and need help creating a circuit ID > format to for new fiber circuits. Is there a guide or standard for fiber > circuit formats? Does the circuit ID change when say a customer upgrades > for 100Mbps to 1Gbps port? >=20 > What do the larger carriers do? Any advice on creating a circuit ID forma= t > for a brand new fiber network? >=20 >=20 > Originally we ran a CLEC using a LECs copper, and our circuit ID was > historically a telephone number for DSL circuits. The ILEC had a complex > method for assigning circuit IDs. >=20 > I am sure anything will work as long as you keep track of it, but any > advice would be great! >=20 Hi, I see you have already received some very good suggestions. The key for me with circuit IDs are that they have to integrate well in you= r backend systems as well as your products.=20 There is little point in creating a telcordia-like system if you will have trouble filling in all the fields in an automated way, just like it can be troublesome to keep an incrementing number accurate, if you don't have a go= od central database to track it in. Avoid creating a number system where the A-end and B-end is part of the ID if you have (or ever will have) logical multi-point circuits. Also avoid having circuit numbers that take assumptions of your country of operation if you ever have to deliver something cross-border. I happen to like the format of PREFIX-NUMBERS, where the prefix indicates s= ome sort of broad type, and with such a form it is important not to have too restrictive prefix types. For example consider only having Fiber, Copper, a= nd logical as types, or whatever makes sense in your operation. With too many similar types comes the risk of having disparity between what your circuit = ID suggests, and what is actually out there. I would suggest that you keep separate IDs for the actual fiber in the grou= nd, and the service the customer buys. That way you can track the customer subscription, modify the parameters of = it, if the customer upgrades his speed, but separately track your fiber deploym= ent. At a previous employer we had to implement Service IDs on an already existi= ng network where everything previously had been using only the actual fiber ID= s, and that was a painful process, so it's better to get these things right as early as possible. -- Best Regards Allan Eising IP Network Engineer NORDUnet A/S m: eising@nordu.net w: http://www.nordu.net =
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |