This document discusses tools for automating network interconnection and capacity planning decisions. It describes the complexity of manual processes and how automation can help by providing consistency, speed, ease of support, and compliance. NETCONF is presented as a standard for automating device configuration. Automating common tasks like adding ports and BGP sessions can help provision capacity based on traffic data. Total pluggability of providers is suggested to further streamline automation.

1. Interconnection tools and automation
Andy Davidson <andy.davidson@allegro.net> Allegro Networks / LONAP August 2014 Peer 2.0/SFO

2. Interconnection tools and automation
Andy Davidson <andy.davidson@allegro.net> Allegro Networks / LONAP August 2014 Peer 2.0/SFO

3. Complexity
Time

4. Complexity
Time
“Let’s use our unlimited money and
time to peer at the local IX!”

5. Complexity
Time
“Can you show me that
this is saving us money?”

6. Complexity
Time
“Let’s add Ethernet interconnects
for the cloud”

7. Complexity
Time
“Let’s buy/sell service via L2TP!”

8. Complexity
Time
“Please could you open a
POP in France?”

9. Complexity
Time
“We need the network to generate
higher cost savings”

10. Complexity
Simple
Complex
TOOLS

11. Decision Making:
Tools to manage the big picture

12. I’m not talking about the
YES
or
NO
decision

13. Capacity
Deciding how to deliver traffic

14. How much traffic?
Because I want to provision capacity
Because I want to handle failover/resilience
Because I want to move transit capacity to peering links
Because I want to consider connecting an exchange

15. RT1 RT2
EX2EX1
PP1
PP2
PP3
Transit
6Gbit
5Gbit
2Gbit
4Gbit 4Gbit
AS2 is your largest flow - via PP2 - maybe needs a second private peer backup on RT2?
AS1 via PP1, configure a backup over EX1 or EX2 for deterministic routing?
Can you move larger peers behind EX1 and EX2 onto private peering?
If there is an exchange failure, where will the traffic go? How big a flow should you care about?
If you lose RT2, how will traffic to PP3 and traffic volume via EX2 be delivered?
If you lose RT1, how will traffic volume via PP3 and EX1 be delivered?
4Gbit 4Gbit
AS12345
AS2
AS1
Many peers Many peers
AS3
Questions about your top ‘n’ peers

16. Decision = Data
15/08/2014 BGP Traffic Engineering, Andy Davidson 16
Manuel Kasper - https://neon1.net/as-stats/as-stats-presentation-swinog16.pdf

17. IP Address Time and date Amount of Traffic
For remote asn

18. Automating provisioning

19. Automation has been possible for decades
Tricky part is the business process tie-in
Business or customer need  Network Action
(Why else do an activity?)
Configure the network, not the device
This is the source of complexity
This is also where state anxiety lives

20. Automation is not the product
Automation is the enabler
Consistency
Speed of Delivery
Ease of Support
Speed to integrate
Compliance
Integrated OSS/BSS
Confidence
Commodity
Devolved control

21. What can be touched
• Adding ports (Private peering)
• Adding BGP sessions (Public & Private peering)
• Adding VLANs (Ethernet interconnection)
• Adding access configuration (Wholesale)

22. NETCONF
• API to configure network devices
• Manage configuration and state
• XML RPC using SSH as transport
• Mirrors device configuration, capabilities
Candidate configuration Running configuration

23. <configuration>
<interfaces>
<interface>
<name>ge-1/0/1</name>
<apply-groups>INTERFACE-PARAMETERS-EDGE</apply-groups>
<description>CUST:Manchester Roller Derby (AS789)</description>
<vlan-tagging/>
<encapsulation>flexible-ethernet-services</encapsulation>
<unit>
<name>520</name>
<description>CUST:Manchester Roller Derby (AS789)[SNAP-PEERING:LINX London]{ZRiEKiyK}</description>
<encapsulation>vlan-vpls</encapsulation>
<vlan-id>520</vlan-id>
<family>
<vpls></vpls>
</family>
</unit>
</interface>
</interfaces>
</configuration>

24. <rpc-reply xmlns:junos="http://xml.juniper.net/junos/11.4R7/junos" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0“
message-id="3">
<commit-results>
<ok/>
</comit-results>
</rpc-reply>

25. <rpc-reply xmlns:junos="http://xml.juniper.net/junos/11.4R7/junos" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0“
message-id="3">
<commit-results>
<rpc-error>
<error-severity>error</error-severity>
<source-daemon>
dcd
</source-daemon>
<error-path>
[edit interfaces ge-1/0/4]
</error-path>
<error-info>
<bad-element>
unit 0
</bad-element>
</error-info>
<error-message>
interface needs to be in a VPLS routing instance to support
family VPLS
</error-message>
</rpc-error>
</commit-results>
<ok/>
</rpc-reply>

26. <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.1" message-id="2">
<lock>
<target>
<candidate></candidate>
<target>
</lock>
</rpc>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1" message-id="3">
<ok></ok>
</rpc-reply>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.1" message-id="7">
<commit></commit>
</rpc>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.1" message-id="7">
<ok></ok>
</rpc-reply>

27. State – configure the network, not the device
• Propose business logic
• Lock running config
• Lock candidate config
• Edit candidate config
• (repeat across network)
• Commit check
• Commit
• Copy running config to start
• Unlock configurations
• Confirm business logic

28. Take one single boring process and automate it out of existence
Don’t worry too much about your software today. If this thing catches on, you’re binning your early code anyway
You are exclusively focussed on delivery, saving money, saving effort, removing pain, learning

29. andy ~ $ perl autopeer.pl 12536 LONAP Allegro
terminal monitor
conf t
router bgp xxxxx
neighbor 5.57.81.30 remote-as 12536
neighbor 5.57.81.30 description PEER:: Allegro
neighbor 5.57.81.30 inherit peer-session peer_Lonap
address-family ipv4
neighbor 5.57.81.30 activate
neighbor 5.57.81.30 inherit peer-policy peer_Lonap
end
Take a single, small step to gain skills and confidence

30. Total Plugability
Providers that you can configure automatically
like you can your devices

31. Network provisioning at your…

33. Example use of auto-providers – Private peering

34. Automation & Self Service at the IXP
IXP Manager
(software tool, browser based)
Used at LONAP and IXLeeds
Admin & Customer automation
Open Source
https://github.com/inex/IXP-Manager

35. Hard to find good conversations about automation avoiding:
Those panning for gold in the shape of SDN
Vendors wanting to sell junk network management software
People who just want to nick your leads
“Developers” with empty OSS “projects” on GitHub
Ideally, one day we will have:
Documented wishlist & best practice
Pluggable upstream and downstream services
Reliable standards adherence from vendors
Differentiated, competitive market for automated wholesale services!

36. Andy Davidson
andy.davidson@allegro.net
_______________________
CTO, Allegro Networks
Director, LONAP Ltd.
+44 161 200 1610