I'm a big fan of Let's Encrypt (free, widely trusted SSL certificates) but not a big fan of most of the client software available for requesting and renewing certificates. Unlike a typical certificate authority, Let's Encrypt doesn't have a webui for requesting/renewing certs; everything is driven via an automated process that is run between a Let's Encrypt software client and the Let's Encrypt web service.

Since the protocols that Let's Encrypt uses are standards-based, there are many open source clients available. Being security conscious, I have a few concerns with most of the clients:

• Complication. Many of the clients are hundreds of lines long and unnecessarily complicated. This makes the code really hard to audit and since this code is playing with my crypto key material, I do want to audit it.
• Elevated privilege. At least one of the clients I saw required root permission. That's a non starter.

I got an interesting email from Ying Lu who had read my posts on LSM:

I am curious about the Ethernet DA and codepoint used for multicast MPLS. Previously, I understand that:

• Ethernet DA is unicast MAC of nexthop of each replication leg.
• codepoint is 0x8847

However, looking at RFC5332, I am not so sure... Quote:

"Ethernet is an example of a multipoint-to-multipoint data link. Ethertype 0x8847 is used whenever a unicast ethernet frame carries an MPLS packet. Ethertype 0x8847 is also used whenever a multicast ethernet frame carries an MPLS packet, EXCEPT for the case where the top label of the MPLS packet has been upstream-assigned. Ethertype 0x8848, formerly known as the "MPLS multicast codepoint", is to be used only when an MPLS packet whose top label is upstream assigned is carried in a multicast ethernet frame.

NSF and GR are two features in Layer 3 network elements (NEs) that allows two adjacent elements to work together when one of them undergoes a control plane switchover or control plane restart.

The benefit is that when a control plane switchover/restart occurs, the impact to network traffic is kept to a minimum and in most cases, to zero.

Presenter: Paul Lysander, Technical Marketing Engineer, Cisco

Presented by: Russ White, LinkedIn

Presenter: Fred Niehaus, Technical Marketing Engineer, Cisco Wireless Networking Group

Presented by: David Prall, Communications Architect, Cisco

For reference, David is the "father of IWAN".

This session was not what I was expecting. I was expecting design and architecture, but it was all about features in IOS and IOS-XE (eg, FHRPs, talked about routing protocol timers, PfRv3, BFD). I guess I need to pay more attention to the session code (RST == routing; ARC == architecture).

Presented by Muhammad A Imam, Sr Manager Technical Marketing Engineering

Presenters:

• Lewis Hickman, Consulting Systems Engineer
• Jennifer Valentine, Systems Engineer

Presenter: Steven Heinsius, Product Manager, Enterprise Networking Group

I'm hoping the title of this session could also be "7 Ways to not be a TOTAL Wireless Noob" since that's more my level. 😁