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 problems? Do we want to solve both problems? In what order? Sequential/Parallel The “Chinese/Mesh” problem The “Japanese/Hub & Spoke” problem

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

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

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.

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

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

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

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)

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)

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

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