1. Agenda Agreement on the problem statement
Don’t fall into traps of the past
Problems that appear to be similar and how they have been solved in the past
Charter bashing

2. 2 problems? Do we want to solve both problems?
In what order? Sequential/Parallel
The “Chinese/Mesh” problem
The “Japanese/Hub & Spoke” problem

3. The “Mesh” Problem Private or public IPv4 address space (VPN?)
May be Dual stack at the edges
New notion: Address Family Boundary Router
Converse problem: the “Sprint” case
Scale: very large
China: 25 islands, but 100k+ routes per islands
We do not have the case with >10k islands
Characteristics
Multiple persistent attachments
Cut-through (many 2 many traffic matrix)
Routing
Discovery mechanism is not necessarily linked to the routing protocol. It must find the AFBR with the existing encaps types driven by the receiving AFBR

4. The “Hubs & Spokes” Problem
Residential case (leaf network)
One single persistent attachment to a dual stack backbone. The attachment network supports only a single address family natively.
Need to tunnel over the attachment network to get connectivity for the other address family
The attachment CPE may or may not (yet) support the other address family
Cost issue
Difficulty to upgrade
Need to tunnel from another CPE further behind the customer network
Potentially dynamic v4 address on CPE
The softwire “concentrator” MUST be dual stack
Default route from the island to the core
No routing protocol
Scale: many islands (millions)
Discovery is out of scope

5. Ephemerals Do we want to handle ephemeral?
Rapid up/down of reachability
Answer: no
Wants to do shortcuts between many islands
Can’t pre set-up everything, set-up has to be a need to be basis (i.e. per connection)
1s is the goal? 2s seems to be in the realm of what is user acceptable
Is this not a variation of the “Mesh” problem?
somewhere between the two problems
The set-up time of the tunnel needs only be a small fraction of the total set-up time of the CPE.

6. Presentations Florent Requirements & goal Jordi Problem space Simon
Bruno
Requirements
Pr Li
Greg
Comparable problem on multicast
Comparable problem biscuit
Comparable problem TSP
Comparable problems ICMP
Francis
Comparable problem ikev2

7. Bounds on problem statements
Packet switched networks
Critical path:
Hub & Spoke
v4/v6, v6/v4, v6/udp/v4
The initiator of the softwire can be nomadic and be a host or a router
The softwire concentrator is fixed
Mesh
v4/v6, v6/v4, overlapping address space (L3VPN)
Non critical path
v4/v4, v4/udp/v4, v6/udp/v6, v6/v6, v4/udp/v6, L2VPN (IPLS)
Unicast & Multicast must be supported
The set-up time of the tunnel should be a small fraction of the total set-up time of the CPE/AFBR

8. Multicast
Hub & Spoke: use “classic” multicast over the tunnel (proxy MLD or PIM)
Mesh: same as Hub & Spoke if core is not multicast enable, may be optimized if core is multicast enable, deferred for later phase

9. Security Control plane Data plane
Hub & Spoke: the protocol MUST support authentication, but it can be turned off
Mesh: same thing
Data plane
MUST support IPsec
Will define IPsec profile (find Steve Bellovin’s document to point to)

10. Address Stability
No need for address stability for the point to point link
Need address stability for the prefix being delegated (by DHCPv6, minimum /64)

11. OAM requirements Hub & Spoke only Hub & Spoke and Mesh
Must support keep-alive for NAT traversal
Hub & Spoke and Mesh
Usage accounting
End-point failure detection
Must be encapsulated w/in the tunnel in the transmitting direction
Path failure detection
Same control plane of the point to point tunnel set up for Hub & Spoke and Mesh

12. Vancouver Charter Problem statement Presentation of MESH problem
Presentation of HUB & SPOKE problem
Interim meeting after Vancouver to look at the solution space