Softwire wg

1
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 3979. 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.txtedi
  ted 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
• 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
CPE Router Dual AF Softwire Initiator
9
Usage Case 2
Dual AF
CPE Router Single AF
Dual AF Host Softwire Initiator
10
Usage Case 3
Dual AF
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
• 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
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 dont
  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
• Number of AFBR related to the number of islands
  and exit points from islands (x0-x00 islands)
• We know of no cases of x0000 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 n1 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?