1. HSCN Supplier Workshop – 19th May 2016
Peering Discussion
Chair: Kate Gill

2. Today’s Objectives
Agree a mutually favourable technical approach for network interconnects
Review the requirements / principles for HSCN’s preferred approach
Document pros and cons
Timescales required
Agree a set of actions / tasks to take the solution forward with owners
Documentation required
Draw out any commercial issues for discussion this afternoon

3. HSCN requirements for network interconnects
Provide a level playing field for all participating network providers
Support routing “out of the box” across network endpoints and to national applications
No need for major infrastructure changes to connect new suppliers or services
Provide easiest and timely path for Transition
Remove the need for a large core backbone as the bulk of applications and services are moved locally or to the internet
Simple and effective fault diagnosis between supplier networks
To provide centralised connectivity to other networks e.g. SWAN or Janet i.e. permit central interconnects to these services for all HSCN service providers

4. HSCN preferred approach
How should peering work?
As a private peering arrangement not reusing public
Number of locations – 2 and where
Principle of how it works ie fibre under the floor as in same location or connection to this location
Do we put internet into this location as well? Do we try and put filtering/monitoring in here?
N3 connects via two reference connections in the same location – or as they are in the building a “special” bespoke service as it can also be fibre in the building
Do we agree now it connects MPLS DNSP networks and can support PSN as well as ourselves?
Sizing/capacity needed – is it as simple as 10Gb circuits will be plenty for all as a connection  - or do we need to actually think what traffic will be routed over it, for example to the TN which could get above this level (except it might not without internet)?
Layer 2/3 traversal – someone needs to explain difference to me J
Availability target?
Resilience minimum at each exchange?

5. Why We Favour Peering Simple, uncomplicated connectivity
Flexibility (can rapidly deploy increased bandwidth)
Rapid path to connectivity / interconnectivity
Level playing field across suppliers
Simplified end-to-end Service Assurance & fault diagnosis
Best possible performance (traffic doesn’t have to span a core, could use route servers/route reflectors to ensure shortest path etc.)
Use of established Peering Exchanges facilitates simplified Internet connectivity
Allows other networks to connect to the peering e.g. Janet / SWAN

6. Peering - Technical challenges vs Core / Backbone
Open for Discussion:
Point to note – Current sum total of NHS circuits is >500Gb/s
Can hosted services that require national access (e.g. Spine) connect to peering or would be better supported on a backbone providing wider dispersed PoPs. Note we think these could be connected to DLNs
Is the peering option resilient enough for our purposes
What technical challenges do you see with the preferred approach?

7. Other Discussion Points
Availability & Performance – Acceptable targets?
Capacity / Sizing – number of connections
Who should run the peering infrastructure?
Requirement for NSI cross service view
Timescales to deliver – note HSCN needs this prior to April 17 with an ambition to be ready by Dec 16
Anything else?
How should it be set-up and managed?
Who should run the peering infrastructure?
A peering specialist third party
One of the DLN providers?
NSI?
Will there be an NSI cross service view of it
What would we need to do to manage it – capacity/performance??

8. Conclusion
Consensus on approach – review any issues or other proposals
Review action list
Commercial aspects for this afternoon

9. Future Discussions QoS, including IP Addressing
Transition Network Diffserv architecture, Service class mapping and alignment, DSCP codepoints & Transparency.
IP Addressing
Making use of both RIPE and RFC1918
IP Address Management