1. Alain Durand, Comcast David Ward, Cisco
Softwire wg
Alain Durand, Comcast
David Ward, Cisco

2. Note Well
Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to:
the IETF plenary session,
any IETF working group or portion thereof,
the IESG, or any member thereof on behalf of the IESG,
the IAB or any member thereof on behalf of the IAB,
any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices,
the RFC Editor or the Internet-Drafts function
All IETF Contributions are subject to the rules of RFC 3978 and RFC Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice.
Please consult RFC 3978 for details.

3. Wg status Charter went to internal & external review Comments received
Chairs, AD & IESG members started addressing the comments…
…AD had a baby! (Congratulation!)
As of this morning, we are approved as a wg by the IESG!
Secretariat still needs to make it formal

4. Agenda Overview of meeting in Paris (Chairs)
Hub and Spoke Problem Overview (Durand)
Hub and Spoke Illustration (Miyakawa, Palet, Williams)
Mesh Problem Overview (Ward)
Mesh Illustration (Li)
Status of draft problem statement (Chairs)
Next steps (Chairs, all)

5. Paris Interim Meeting
We held an interim meeting in Paris on October 11th-12th
18 participants, intense discussions, very productive meeting
Focus on problem statement
draft-durand-softwire-problem-statement-00.txt edited in rush just before the cut-off date (excuse typos…)
2 problems identified, topology driven:
Access network, customer initiated, one exit path [Hubs & Spokes]
Core network, ISP initiated, complex routing topology [Mesh]
We will look at both problems independently
Hopefully, they will share enough common technology

6. Hub & Spoke Description

7. Hubs & Spokes Problem Description: Applicability:
Access network problem, customer initiated, one exit path
Applicability:
ISPs with Dual Stack core and a number of dual stack Points of Presence (“Hubs”) where they connect their customers.
3 usage cases have been identified:
the networks between the CPE router and the hub supports only one address family.
the CPE router cannot be easily upgraded to support both address families, a softwire is created from a node behind the CPE router
Same, but initiated from another router behind the CPE router

8. Usage Case 1 Dual AF Single AF Softwire Concentrator
CPE Router Dual AF
Softwire Initiator

9. Usage Case 2 Dual AF Softwire Concentrator CPE Router Single AF
Dual AF Host
Softwire Initiator

10. Usage Case 3 Dual AF Softwire Concentrator CPE Router Single AF
Dual AF Router
Softwire Initiator

11. Hubs & Spokes Assumptions
NAT/PAT (in IPv4) is present
Not always upgradeable CPE router
“Stable” IPv6 prefix desired
Softwires initiated by customer
Customer side: softwire initiator
May be a host or a router
ISP side: softwire concentrator
Routing:
default route from softwire initiator to concentrator
(CPE routers do not generally run a routing protocol, but the softwire solution will work even if it does.)

12. Hubs & Spokes Properties (1)
Scaling:
to the millions of softwire customers
Set-up time (a.k.a. “latency”)
A fraction of the total set-up time of the CPE router
Multicast
Classic multicast solution run over the softwire

13. Hubs & Spokes Properties (2)
Security
Must support secure user authentication
May be turned off.
Must be able to support payload security when desired outside of the softwire mechanism
Operation And Management
Keep alive
Usage accounting
End point failure detection (inner address of the softwire)
Path failure detection (outer address of the softwire)

14. Hubs & Spokes Encapsulations
Critical path
IPv6/IPv4
IPv6/UDP/IPv4
IPv4/IPv6
Other encapsulations to be supported later (e.g. IPv6/IPv6)

15. Hub & Spoke Illustrations
Slides from Shin, Carl & Jordi

16. Mesh Description

17. Mesh Problem Description: Applicability:
Core network problem, ISP initiated, complex routing topology
Applicability:
ISPs (or large enterprise networks acting as ISP for their internal resources) establish connectivity to 'islands' of networks of one address family type across a transit core of a differing address family type.

18. Mesh Diagram IPv6-only Transit Core BGP Dual-Stack AFBR IPv6
Access Island
IPv6
Access Network

19. AFBR
To provide reachability across the transit core dual-stack devices are installed that act as "Address Family Boundary Routers”.
Creates a limited dual-stack edge network
Core can be solely one AF and islands don’t require upgrade
AFBR provide peering across AS or within an AS
Can be used inconjunction w/ route reflectors

20. Full Mesh Overlay for Many2Many connnectivity
V4 island
V6 transit
AFBR
V4 island
AFBR
AFBR
V4 island

21. May have different encaps available
V4 island
V6 transit
core
AFBR
MGRE,L2TPv3
L2TPv3
MGRE
V4 island
AFBR
L2TPv3
MPLS
IPsec
AFBR
MGRE
IPsec
V4 island
Must have solution to allow for negotiation and preference of encap

22. Must support Applications…. L3-VPN using 2547bis
Route Reflector
VPN
V4 island
V6 transit
AFBR
V4 island
AFBR
AFBR
V4 island
VPN
VPN

23. Mesh properties (1) Scaling Services / Encapsulation Security
Number of AFBR related to the number of islands and exit points from islands (x0-x00 islands)
We know of no cases of x islands
Full routing table needs to be supported
Islands can carry x00000 of routes
Services / Encapsulation
v4/v6 or v6/v4
L2VPN
L3VPN (overlapping address spaces)
Multicast a must in all cases
Security
No “user” authentication
Authentication for control plane
may be turned off
Support for IPsec in data plane (outside of softwires)

24. Mesh properties (2) Operation And Management No need for keepalive
Usage accounting
End point failure detection
Path failure detection
Flexible encapsulation possibilities
Interconnection at L2 or L3
Cannot require full mesh of all AFBRs under all circumstances

25. Mesh Illustrations
Slides from Pr Li

26. Problem Statement Draft Status
Problem statement described in draft-durand-softwire-problem-statement-00.txt
Comments received on the ML
Typos
Some minor stuff
n engineer that comes up with n+1 design syndrome
3 issues raised about the Mesh problem:
Scale
Presented today
Should this be solved at layer 2 or layer 3
Crystal ball says both (This belongs to the solution space)
Should the softwires be initiated from the PE or CPE or both?
Crystal ball says most commonly PE (for mesh)

27. Next Steps Mark finish the creation of the wg!
Done, minor nits on charter + secretariat action
Rev problem statement draft
draft-ietf-softwire-problem-statement-00.txt Nov. 14th
draft-ietf-softwire-problem-statement-01.txt Dec. 1st
WG Last Call on problem statement draft
Target: Dec. 8th
Interim meeting on solution space (Jan/Feb 06)
Last was in Europe, Hong Kong?