Agenda

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 • Requirement • Bruno • Requirements • Pr Li • Problem space • Greg • Comparable problem on multicast • Simon • Comparable problem biscuit • Florent • Comparable problem TSP • Jordi • 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 • 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 • 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