Subject: [Softwires] Notes from Softwires IETF 64

From: David Ward <[email-masked]>
Date: Wed, 09 Nov 2005 11:30:20 -0600

Folks,

Please review and comment for correctness. The deadline for
comments is Nov 18, 2005.

--------------------
 Chairs - Alain Durand and David Ward

 Notes - Spencer Dawkins <[email-masked]>

 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 a 5000-node network diagram from Spain (although there are
other similar networks elsewhere). Has an IPv6 core, but IPv4 access
networks - with data centers that have dual-stack servers.

 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

 Ping Pan - 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!

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 09 Nov 2005 10:19:52 -0800

Just about my presentation, some mistakes and a missing part. I will
summarize it in a slightly different way:

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.

Regards,
Jordi

> De: David Ward <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Wed, 09 Nov 2005 11:30:20 -0600
> Para: <[email-masked]>, "Durand, Alain" <[email-masked]>,
> David Ward <[email-masked]>
> Asunto: [Softwires] Notes from Softwires IETF 64
> 
> Folks,
> 

************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Information available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.