On Wed, Aug 23, 2017 at 8:00 AM, <nanog-requ...@nanog.org> wrote: > Send NANOG mailing list submissions to > nanog@nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-requ...@nanog.org > > You can reach the person managing the list at > nanog-ow...@nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: Creating a Circuit ID Format (Tassos Chatzithomaoglou) > 2. Re: Creating a Circuit ID Format (Jared Mauch) > 3. 2017 NANOG Elections General Information (Dave Temkin) > 4. Re: Creating a Circuit ID Format (Justin M. Streiner) > 5. Re: Creating a Circuit ID Format (Nick Hilliard) > 6. Spectrum web cache engineer (Andrew Kirch) > 7. RE: Creating a Circuit ID Format (Timothy Creswick) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 22 Aug 2017 19:01:56 +0300 > From: Tassos Chatzithomaoglou <ach...@forthnet.gr> > To: NANOG <nanog@nanog.org> > Subject: Re: Creating a Circuit ID Format > Message-ID: <6b76d308-1a55-af42-c7cd-195d77147...@forthnet.gr> > Content-Type: text/plain; charset=UTF-8 > > I don't know if it has any relation to your issue, but we use Circuit-ID > to uniquely identify the access node plus the customer's access loop > logical port on the access node. > Access node can be either a DSLAM, a switch, an OLT, etc. > > You may have a look at BBF's TR-101 (section 3.9.3) or TR-156 (section > 5.7) for syntax guide . > > -- > Tassos > > Colton Conor wrote on 21/8/17 23:26: > > 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? > > > > What do the larger carriers do? Any advice on creating a circuit ID > format > > for a brand new fiber network? > > > > > > 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. > > > > I am sure anything will work as long as you keep track of it, but any > > advice would be great! > > > > > > ------------------------------ > > Message: 2 > Date: Tue, 22 Aug 2017 12:37:08 -0400 > From: Jared Mauch <ja...@puck.nether.net> > To: Tassos Chatzithomaoglou <ach...@forthnet.gr> > Cc: NANOG <nanog@nanog.org> > Subject: Re: Creating a Circuit ID Format > Message-ID: <2af810ab-e963-4cd4-867c-3d96b73a4...@puck.nether.net> > Content-Type: text/plain; charset=us-ascii > > > > On Aug 22, 2017, at 12:01 PM, Tassos Chatzithomaoglou < > ach...@forthnet.gr> wrote: > > > > I don't know if it has any relation to your issue, but we use Circuit-ID > to uniquely identify the access node plus the customer's access loop > logical port on the access node. > > Access node can be either a DSLAM, a switch, an OLT, etc. > > > > You may have a look at BBF's TR-101 (section 3.9.3) or TR-156 (section > 5.7) for syntax guide . > > > My favorite circuit-ids were those from MFS where it had the service type > (2 chars i think) + a pop-code + z pop-code + service count number. > > We could then tell what pop/facility everything was handed off at easily > enough. I think my house even got a MFS pop code at one time due to the T1 > which was there. > > - Jared > > ------------------------------ > > Message: 3 > Date: Tue, 22 Aug 2017 10:21:32 -0700 > From: Dave Temkin <d...@temk.in> > To: "North American Network Operators' Group" <nanog@nanog.org> > Subject: 2017 NANOG Elections General Information > Message-ID: > <CAFJiuFq5=iAiRBxjbaKmZDvG=04bgdbpnXM1H-7v=dP1vWNZEA@ > mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hello NANOGers! > > We are once again approaching the annual NANOG election > <http://nanog.org/elections/2017/general> and appointment time. Board > candidate nominations open August 7th and the complete Election timeline > can be found here <http://nanog.org/elections/2017/general>. We encourage > those in the community who are not currently NANOG members to consider > becoming members of NANOG and to consider standing for a position in our > leadership. Through membership and voting, you will be an active > participant in directing all NANOG activities. > > Only NANOG members are eligible to nominate, be a candidate, vote, and > serve in the NANOG Board of Directors and Committees. Click here > <https://www.nanog.org/membership> to become a member today! **If you are > not a member and wish to vote in this election, your membership must be > received by 9:00 a.m. Pacific Time on Wednesday, October 4, 2017.** > > Why? > > NANOG is at its strongest and best when there is an engaged group of > members. If you care about NANOG and would like to take a turn at > volunteering your time, please consider becoming part of the team by taking > part in the nomination and election process. If you know someone else that > you believe would be interested in serving on the Board of Directors, > nominate them by completing the Online Process > <https://www.bigpulse.com/138028/signin> beginning August 7, 2017. Any > questions should be submitted to electi...@nanog.org. > > As I spoke about during my opening at NANOG 70, diversity is key to the > viability of the NANOG community. Personally, it concerns me that our only > non-white, non-male elected member of the Board is leaving the board this > year, having served the maximum allowable number of terms. While everyone > is welcome, it is important that we represent our community well at all > levels and so if you or someone you know could help improve that > representation, please consider the nomination process. > > As NANOG continues to evolve, our Board of Directors and Committees will > continue to play an increasingly important role in our success. By joining > now, you can be an integral part of the process. > > For more information about the role of a Board of Director or any Committee > Member, or to find out more about what's involved in serving, please > consult the current NANOG Bylaws > <https://nanog.org/sites/default/files/sites/default/files/NANOG-Bylaws- > October2016.pdf> > or follow the links to the Board and Committee pages from the General 2017 > NANOG Elections Page <https://www.nanog.org/elections/2017/general>. > > > Best regards, > > Dave Temkin > On behalf of the NANOG Board of Directors > > > ------------------------------ > > Message: 4 > Date: Tue, 22 Aug 2017 16:50:40 -0400 (EDT) > From: "Justin M. Streiner" <strein...@gmail.com> > To: James Bensley <jwbens...@gmail.com> > Cc: NANOG <nanog@nanog.org> > Subject: Re: Creating a Circuit ID Format > Message-ID: <pine.lnx.4.64.1708221608470.25...@whammy.cluebyfour.org> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 22 Aug 2017, James Bensley wrote: > > > In my opinion the circuit ID should be an abitrary (but unique) value > > and nothing more. As Nick suggested start at 1 and go up. If your > > company is called ABC Ltd then maybe have your first circuit ID as > > ABC00000001 and count up from there, it's as simple as that. > > > > For me, all the circuit ID should be is a record number/ID of a > > database entry and nothing more (or a search string). Some people like > > to have circuit IDs which include circuit types, or circuit speeds, or > > interface type, but as you asked, do you then change the circuit ID if > > the circuit speed changes, or the interface types changes, or the > > medium etc? > > Agreed. I designed something similar at a previous employer, and it just > used a date-coded ID with sequence number (ex: UOP 20170822.0001), and > then all of the cross-connect details were recorded in a place that was > better suited to capturing that sort of information. That would also > allow us to re-use fiber paths when we upgraded 1G links to 10G, etc. > > This also included IDs that could reference other circuit IDs - including > circuit IDs from other providers - so we could tie non-dark elements > together, such as waves through DWDM gear end up riding on separate dark > fiber paths on either side of the mux. > > The biggest obstacle was getting people to label fiber jumpers in the > field, but that obstacle went away as people get a better understanding of > it and having all of the cross-connects documented saved lots of time and > frustration when having to search through a large patch field at 3 AM... > > jms > > > ------------------------------ > > Message: 5 > Date: Tue, 22 Aug 2017 22:20:20 +0100 > From: Nick Hilliard <n...@foobar.org> > To: James Bensley <jwbens...@gmail.com> > Cc: NANOG <nanog@nanog.org> > Subject: Re: Creating a Circuit ID Format > Message-ID: <599ca014.5020...@foobar.org> > Content-Type: text/plain; charset=UTF-8 > > James Bensley wrote: > > In my opinion the circuit ID should be an abitrary (but unique) value > > and nothing more. As Nick suggested start at 1 and go up. If your > > company is called ABC Ltd then maybe have your first circuit ID as > > ABC00000001 and count up from there, it's as simple as that. > > there are a lot of ways of handling this, which broadly speaking break > down into whether you want to encode data in your circuit ID or whether > you want it to act as nothing more than an index on a database table. > > Regardless of what way you go about things, there are some parallel > issues, including whether you want inline checksumming, whether you want > random value increases or +1 increases, and whether you want an > alphanumeric or strictly numeric ID. Alphanumeric can allow unique > prefixes or suffixes to help identify who owns a circuit ID or what type > it is, at the complexity of adding identifiers which can be > misinterpreted over the phone. > > There are differing opinions on whether other information such as > service type, node location, speed, etc should be encoded in the service > name. > > Things that most people generally agree on include: > > - carefully splitting out service types. E.g. a fibre cable to a > location is one ID; a wavelength on that service is another ID of > another type; an IP transit service on that wave is a third ID, etc. > > - don't reuse IDs, ever. There are plenty of numbers out there. > > - don't change from one ID mechanism to another, if possible. > > Otherwise, for every well-reasoned suggestion to use a specific format, > there are other well-reasoned arguments to do things in a different way. > Choose one and stick with it. > > Nick > > > ------------------------------ > > Message: 6 > Date: Tue, 22 Aug 2017 21:44:24 -0400 > From: Andrew Kirch <trel...@trelane.net> > To: NANOG list <nanog@nanog.org> > Subject: Spectrum web cache engineer > Message-ID: > <CALA5tJLpNQBpE0gJne6VrPy7FPLfQjm5GMYwSj9Zr+=ZgaEHzg@mail. > gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Would a Spectrum engineer please contact me off list? It appears you're > caching an expired certificate for https://www.icei.org. > > The issue is tested/working everywhere else. > > Thanks! > > Andrew > > > ------------------------------ > > Message: 7 > Date: Wed, 23 Aug 2017 08:18:52 +0000 > From: Timothy Creswick <timo...@creswick.eu> > To: NANOG <nanog@nanog.org> > Subject: RE: Creating a Circuit ID Format > Message-ID: > <HE1PR05MB15644799780F432E10AC93ADAF850@HE1PR05MB1564. > eurprd05.prod.outlook.com> > > Content-Type: text/plain; charset="utf-8" > > > Things that most people generally agree on include: > > > > - carefully splitting out service types. E.g. a fibre cable to a > > location is one ID; a wavelength on that service is another ID of > > another type; an IP transit service on that wave is a third ID, etc. > > Definitely. We have one digit in our circuit ID which denotes the type to > aid with quick identification. > > We also use a luhn-10 checksum digit at the end, which is optional on > re-entry. This is really helpful when getting references over the phone. > When written, it's with a hyphen so that it's clear that it's able to be > dropped. > > A few things we also decided on: > > - Circuit references are purely numerical (although we prefix them with > letters when written, those letters are not part of what makes the numbers > unique in our business). The main reason for this is that they can easily > be entered in a variety of *compact* barcode formats. Most label printers > support this, and it saves loads of time in the datacentre when you can > just scan the label on a circuit on a handheld PC. > > - Circuit references are always the same length. This way, if the checksum > digit is being dropped (e.g. because it's coming from a non-human source > like a barcode), we know that the checksum digit is missing. > > - The first digit is never a zero, to avoid silly mistakes if you're > sorting them in Excel etc. > > - The first four digits are a simple date code of YYMM that the ID was > generated. This is surprisingly handy when you're looking for a specific > circuit reference in a list, and it sort of helps to spread the dataset out > a bit. This is what ensures that it's a non-zero first digit for the next > 80 years or so. The date code isn't a *requirement* of our format, however. > Should we need more than 10,000 circuits per month, we'll just abandon the > date coding. > > For those interested, our system looks like this: > > VCI-150600019-7 > > Any non [0-9] characters (including symbols) can be omitted. > > VCI : denotes that this circuit identifier corresponds to our business > 1506 : date code > 0001 : sequence number, incremented per circuit, per month > 9 : circuit type > 7 : checksum (optional) > > T > > > End of NANOG Digest, Vol 115, Issue 21 > ************************************** >
-- -Steve Lerner (m) 212-495-9212
