Softwires WG NotesChairs - Alain Durand and David Ward

Notes - Spencer Dawkins 

Agenda bashing: none noted.

The IESG approved Softwire as a working group this morning... Some editorial 
nits, but we are a working group.

Congrats to Mark Townsley, now a father... (applause)

A) Overview of meeting in Paris

Held in Paris on Oct 11-12, with 18 participants and intense discussion.

Focused exclusively on the problem statement for Softwires. Draft problem 
statement submitted "just in time" for draft cut-off, needs cleanup.

Identified two problems, based on topology ("hubs and spokes", "mesh"). Will 
look at problems independently, but HOPE they will share "enough" common 
technology - not independent.

Goals - NOT to do new encapsulation, tunneling, or routing technologies.

B) Durand: Hub and Spoke Problem Overview

Not a new problem, has been discussed, Paris work was to describe it formally.

Access network, customer initiated, one exit path (no routing)

Dual stack core and points of presence, may be connected by 
single-address-family path elements.

Two components, Softwire Initiator and Softwire Concentrator are dual-stack. 
Initiator may be directly connected to the Internet, or via router that is NOT 
dual-stack.

Some use cases do IPv4-over-IPv6, others do the reverse.

Assumtions - NAT/PAT in IPv4, CPE router may not be upgraded, want stable IPv6 
address/prefix ...

Scaling to millions, setup latency is "fraction of the setup time of the CPE 
router". multicast uses classic solution over softwire

Must support secure user authentication, but may be turned off. Must support 
payload security when desired.

Operation and Management - keep-alive, usage accounting, endpoint failure 
detection, path failure detection

Targeting v6/v4, v6/udp/v4, v4/v6

Is the model datagrams over datagrams, or datagrams over connections, or? 
datagrams over datagrams

B1) Shin, Carl, Jordi:Hub and Spoke Illustration

Shin showed same IPv6 over IPv4 illustration as Paris (IETF and Interim 
meeting).

Would do native IPv6, but don't want to require CPE replacement in this 
solution.

Jordi showed two example cases which he often finds when dealing with
customers:

1) A 5000-sites network diagram from Spain (although there are other similar
networks elsewhere). Has an IPv6 core and access, but dual stack in the
sites. Most of the traffic is tending to be IPv6-only, either among the
sites or to the data center, which remains dual stack in order to support
also Internet (IPv4) applications (in/out initiated).

2) An ISP network with has an IPv4 only core and access network. The core
could be also dual stack, and actually more often is this way. The end sites
are dual stack, being the CPE NAT (most typically) or not, IPv4-only or dual
stack.
 

Carl showed KDDI's home deployment network diagram - based on ISP backbone 
that's IPv6, but has IPv4 access networks and NAT boxes. Very similar network 
diagram for hotspots supporting IMS services. Mutual authentication is needed 
for these applications.

C) Ward: Mesh Problem Overview

Mesh problem is for core networks with complex routing topologies. Difference is 
that softwires are ISP-provided and initiated

"Address Family Boundary Router" - new component terminology

Core can be exclusively one address family, islands don't need to be upgraded.

AFBR peering can be intra-AS or inter-AS

Connectivity is many-to-many - not a single uplink routing situation

Must support multiple encapsulation mechanisms

Must support 2547bis L3VPNs (cannot break these with our solution)

Number of AFBRs is related to number islands/exit points from an island. We 
think the range is for 10s-100s of islands - not thousands, or higher, but 
islands can use a full routing table

Must support L2VPN, L3VPN-overlapping addresses, multicast

Don't think we need keepalives, but do need accounting, failure detection, 
flexible encapsulation

C1) Prof Li: Mesh Illustration

Professor Li showed the Chinese Next-Generation Internet project CERNET2 network 
diagram. IPv6 is being used for political reasons.

25 POPs, 20 cities connected by transport network, about 100 access networks

Not easy to port applications from IPv4 to IPv6 - need high-performance IPv4 
connectivity - want to support IPv4 access networks and applications

Using edge routers that correspond to AFBRs in softwire description with IPv6 
core network

Can use same architecture in reverse if there are IPv4-only core networks

Concerns about scalability and broadcast storms if they use level two solution

Initial requirement is within an AS, but multi-AS support is desirable

Pekka Savola - not really an IPv6 core if you have 100 PE routers that are 
dual-stack

??? - this is similar to what is done in North America using level two solutions

D) Presentation of draft problem statement

Next version will not be edited by Alain...

Are there other designs that could be used? Almost certainly - probably 
infinitely so.

Mesh network questions - scale (answered today), L2 versus L3 (probably need 
both), initiated from PE or CPE, or both (most likely PE, for mesh)

Greg Shepards - Don't see any of this coming from a technical driver, only from 
a business driver

E) Next steps

Well, celebrate, and then ...

Need to rev nits on charter, rev problem statement draft (immediately), WG last 
call ends December 8th, Interim meeting on solution space in January/February

Will not work on solutions until problem statement goes to IESG

F) Questions and comments

Pekka - supportive of hubs and spokes, see it a lot and it's been discussed 
extensively. More sceptical about mesh networks, have only heard this 
requirement from one or two operators and need to get operator feedback for a 
generic solution

Jim - good job, do you need help offline? I'm seeing the same thing in North 
America, and now in South America as well. Operators will send relayed e-mail, 
but don't want to join the mailing list and see the other discussions

Mark - having two problems in the same document limits the hub from trying to 
solve the mesh problem - we actually need this in order to make progress

Mark - we have a good turnout on readers for the problem statement - working 
group last call of 01 by December 1, so we go into the working group interim 
meeting? Sense of the room is "don't wait for six months"...

Dino - do you think these are new problems or old problems that have never been 
solved?
Dave - hubs and spoke has almost come and gone with non-standard solutions, and 
mesh is similar to comparable problems - we don't need more solutions, we just 
need to choose some of the solutions we've already got

Shin - will this be rough consensus and running code, or more theorectical?
Alain - running code is not an absolute requirement until draft standard, but 
we'd love to make few/no changes. We will not be here for five years

Tom - can we start documenting existing solutions?
David - we can do this in parallel.

Pekka - would like to see mesh network deployers send description to the mailing 
list, because we don't want solutions based on one or two inputs.
David - we can't force people to send stuff to the mailing list, but we'd love 
to see them do this

Jim - we know the mesh problem exists. We're not the Gardner group, we're 
engineers. We would love to have operator inputs but we can't wait on this, or 
we would never do anything. I can wait for customer requirements at work.

Pekka - we can define a problem statement around CERNET's presentation, but what 
if it's not a typical mesh network?
Alain - please encourage operators who are deploying different mesh solutions to 
tell us about them!