Spectrum web cache engineer

[Andrew Kirch]

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

Re: Creating a Circuit ID Format

[Nick Hilliard]

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
> ABC0001 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

Re: Creating a Circuit ID Format

[Justin M. Streiner]

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
ABC0001 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

2017 NANOG Elections General Information

[Dave Temkin]

Hello NANOGers!

We are once again approaching the annual NANOG election
 and appointment time. Board
candidate nominations open August 7th and the complete Election timeline
can be found here . 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
 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
 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

or follow the links to the Board and Committee pages from the General 2017
NANOG Elections Page .


Best regards,

Dave Temkin
On behalf of the NANOG Board of Directors

Re: Creating a Circuit ID Format

[Jared Mauch]

> On Aug 22, 2017, at 12:01 PM, Tassos Chatzithomaoglou  
> 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

Re: Creating a Circuit ID Format

[Tassos Chatzithomaoglou]

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!
>

Re: DevOps workflow for networking

[James Bensley]

On 10 August 2017 at 01:52, Kasper Adel  wrote:
> We are pretty new to those new-age network orchestrators and automation,
>
> I am curious to ask what everyone is the community is doing? sorry for such
> a long and broad question.
>
> What is your workflow? What tools are your teams using? What is working
> what is not? What do you really like and what do you need to improve? How
> mature do you think your process is? etc etc

The wheels here move extremely slowly so it's slowly, slowly catchy
monkey for us. So far we have been using Ansible and GitLab CI and the
current plan is to slowly engulf the existing network device by device
into the process/toolset.

> Wanted to ask and see what approaches the many different teams here are
> taking!
>
> We are going to start working from a GitLab based workflow.
>
> Projects are created, issues entered and developed with a gitflow branching
> strategy.
>
> GitLab CI pipelines run package loadings and run tests inside a lab.

Yes that is the "joy" of GitLab, see below for a more detailed
breakdown but we use docker images to run CI processes, we can branch
and make merge requests which trigger the CI and CD processes. It's
not very complicated and it just works. I didn't compare with stuff
like BitBucket, I must admit I just looked at GitLab and saw that it
worked, tried it, stuck with it, no problems so far.

> Tests are usually python unit tests that are run to do both functional and
> service creation, modification and removal tests.
>
> For unit testing we typically use python libraries to open transactions to
> do the service modifications (along with functional tests) against physical
> lab devices.

Again see below, physical and virtual devices, and also some custom
python scripts for unit tests like checking IPv4/6 addresses are valid
(not 999.1.2.3 or AA:BB:HH::1), AS numbers are valid integeters of the
right size etc.

> For our prod deployment we leverage 'push on green' and gating to push
> package changes to prod devices.
>
> Thanks

Yeah that is pretty much my approach too. Device configs are in YAML
files (actually multiple files). So one git repo stores the
constituent YAML files, when you update a file and push to the repo
the CI process starts which runs syntax checks and semantic checks
against the YAML files (some custom python scripts basically).

As Saku mentioned, we also follow the “replace entire device config”
approach to guarantee the configuration state (or at least “try” when
it comes to crazy old IOS). So this means we have Jinja2 templates
that render YAML files into device specific CLI config files. They
live in a separate repo and again many constituent Jinaj2 files make
one entire device template. So any push to this Jinja2 repo triggers a
separate CI workflow which performs syntax checking and semantic
checking of the Jinja2 templates (again, custom Python scripts).

When one pushes to the YAML repo to update a device config, the syntax
and semantic checks are made against the YAML files; they are then
“glued” together to make the entire device configs in a single file,
the Jinja2 repo is checked out, the entire YAML file is used to feed
the Jinja templates and configs are built and now the vendor specific
config needs to be syntax checked.

This CD part of the process (to a testing area) is a WIP still, for
Junos we can push to a device and use “commit check” for IOS and
others we can’t. So right now I’m working on a mixture of pushing the
config to virtual IOS devices and to physical kit in the lab but this
also causes problems in that interface / line card slot numbers/names
will change so we need to run a few regex statements against the
config to jimmy it into a lab device (so pretty ugly and temporary I
hope).

When the CD to “testing” passes then CD to “production” can be
manually triggered. Another repo stores the running config of all
devices (from the previous push). So we can push the candidate config
to a live device (using Ansible with NAPALM [1]) and get a diff
against the running config, make the “config replace” action, then
download the running config and put that back into the repo. So we
have a local stored copy of device configs so we can see off-line the
diff’s between pushes. It also provides a record that the process of
going form YAML > Jinaj2 > to device produces the config we expected
(although prior to this one will have had to make a branch and then a
merge request, which is peer reviewed, to get the CD part to run and
push to device, so there shouldn’t be any surprises this late in the
process!).

Is it fool proof, no. It is a young system still being design and
developed. Is it better than before, hell yes.

Cheers,
James.

[1] Ansible and NAPALM here might seem like overkill but we use
Ansible for other stuff like x86 box management so this means
configuring a server or a router is abstracted through one single tool
to the operator (i.e. playbooks are use irrelevant of device type,
rather than say p

Re: Virtual or Remote Peering

[James Bensley]

On 15 August 2017 at 15:52, Rod Beck  wrote:
> How well does this service work? I understand it usually involves 
> point-to-multipoint Switched Ethernet with VLANs and resold IX ports. Sounds 
> like a service for ISP that would like to peer, but have relatively small 
> volumes for peering purposes or lopsided volumes.
>
>
> Roderick Beck
>
> Director of Global Sales
>
> United Cable Company
>
> DRG Undersea Consulting
>
> Affiliate Member
>
> www.unitedcablecompany.com
>
> 85 Király utca, 1077 Budapest
>
> rod.b...@unitedcablecompany.com
>
> 36-30-859-5144
>
>
> [1467221477350_image005.png]

I think for very samll providers were cost pretty much governs
everything, it is quite handy.

I know of a small provider who takes/took a 1G pipe to such a remote
connectivity provider, the pipe is split with VLANs and over one VLAN
they have a remote peering session to a IXP, over another VLAN they
receive a blended transit service and over another VLAN L2
connectivity to other PoP the remote peering provider is also.

It is several eggs in one basket but for very small providers this can
provide a much needed money saving opportunity.

Cheers,
James.

Re: Creating a Circuit ID Format

[James Bensley]

On 21 August 2017 at 21:26, Colton Conor  wrote:
> 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!

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
ABC0001 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?

No, it's just a pointer to a database record, KISS.

Cheers,
James.