Re: [Softwires] WG Review: Recharter of Softwires (softwire)

[Mark Townsley <[e-mail]>]

On Apr 19, 2011, at 4:36 PM, IESG Secretary wrote:

> A modified charter has been submitted for the Softwires (softwire) working
> group in the Internet Area of the IETF.  The IESG has not made any
> determination as yet.  The modified charter is provided below for
> informational purposes only.  Please send your comments to the IESG
> mailing list ([e-mail]) by Tuesday, April 26, 2011.
> 
> 
> Softwires (softwire)
> **DRAFT 2011-04-14** (v03)
> --------------------
> Current Status: Active
> 
> Chairs:
>     Alain Durand <[e-mail]>
>     Yong Cui <[e-mail]>
> 
> Internet Area Directors:
>     Ralph Droms <[e-mail]>
>     Jari Arkko <[e-mail]>
> 
> Internet Area Advisor:
>     Ralph Droms <[e-mail]>
> 
> Mailing Lists:
>     General Discussion: [e-mail]
>     To Subscribe:       [e-mail]
>     Archive:           
> http://www.ietf.org/mail-archive/web/softwires/current/maillist.html
> 
> Description of Working Group:
> 
>  The Softwires Working Group is specifying the standardization of
>  discovery, control and encapsulation methods for connecting IPv4
>  networks across IPv6 networks and IPv6 networks across IPv4 networks
>  in a way that will encourage multiple, inter-operable
>  implementations.
> 
>  For various reasons, native IPv4 and/or IPv6 transport may not be
>  available in all cases, and there is a need to tunnel IPv4 in IPv6
>  or IPv6 in IPv4 to cross a part of the network which is not IPv4 or
>  IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies
>  two distinct topological scenarios that the WG will provide
>  solutions for: "Hubs and Spokes" and "Mesh." In the former case,
>  hosts or "stub" networks are attached via individual,
>  point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a
>  centralized Softwire Concentrator. In the latter case (Mesh),
>  network islands of one Address Family (IPv4 or IPv6) are connected
>  over a network of another Address Family via point to multi-point
>  softwires among Address family Border Routers (AFBRs).
> 
>  The WG will reuse existing technologies as much as possible and only
>  when necessary, create additional protocol building blocks.
> 
>  For generality, all base Softwires encapsulation mechanisms should
>  support all combinations of IP versions over one other (IPv4 over
>  IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6
>  translation mechanisms (NAT-PT), new addressing schemes, and block
>  address assignments are out of scope. DHCP options developed in this
>  working group will be reviewed jointly with the DHC WG.  RADIUS
>  attributes developed in this working group will be reviewed jointly
>  with the RADEXT WG.  The MIB Doctors directorate will be asked to
>  review any MIB modules developed in the SOFTWIRE working group.  BGP
>  and other routing and signaling protocols developed in this group
>  will be reviewed jointly with the proper working groups and other
>  workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG,
>  etc).
> 
>  The specific work areas for this working group are:
> 
>  1. Developments for Mesh softwires topology; the Mesh topology work
>     will be reviewed in the l3vpn and idr WGs
>     - multicast
>     - MIB module
> 
>  2. Developments for 6rd:
>     - multicast
>     - operational specification
>     - RADIUS option for 6rd server
>     - MIB module
> 

No chance to do a detailed review as I am peeking in while on vacation.... But, I'd like to make two comments

#3 and #4 both seem to be part of the "legacy IPv4 carried over IPv6" problem space.

>  3. Developments for Dual-Stack Lite (DS-Lite):
>     - multicast
>     - operational specification
>     - RADIUS option for AFTR
>     - proxy extensions; GI-DS-Lite; DS-Lite with no NAT or NAT on the
>       B4 element
>     - MIB module
> 
>  4. Developments for stateless legacy IPv4 carried over IPv6
>     - develop a solution motivation document to be published as an
>       RFC

>     - develop a protocol specification response to the solution
> motivation
>       document; this work item will not be taken through WG last call
>       until the solution motivation document has been published

s/published/approved for publication by the IESG. 

- Mark

> 
>  5. Finalize discovery and configuration mechanisms for a gateway to
>     use DS-Lite or 6rd; these discovery and configuration mechanisms
>     must take into a account other operating environments such as
>     dual-stack and tunneling mechanisms not defined by the softwire
>     WG.  Development of new mechanisms will involve the dhc and/or
>     v6ops WGs as appropriate
> 
> Other work items would require WG approval and rechartering.
> 
> Goals and Milestones:
> Apr 2011 Submit DS-lite RADIUS option for Proposed Standard
> Apr 2011 Adopt DS-lite operational document as WG document
> Jul 2011 Submit 6rd RADIUS option for Proposed Standard
> Jul 2011 Submit GI DS-lite for Proposed Standard
> Jul 2011 Adopt B4NAT as WG document
> Aug 2011 Adopt 6rd operational document as WG document
> Aug 2011 Adopt Multicast extensions document as WG document
> Aug 2011 Submit DS-lite operational document for Informational
> Sep 2011 Submit B4NAT for Informational
> Nov 2011 Submit Multicast extensions document for Informational
> Nov 2011 Submit 6rd operational document for Informational
> Nov 2011 Adopt 6rd MIB module as WG document
> Nov 2011 Adopt DS-lite MIB module as WG document
> Nov 2011 Adopt Mesh topology MIB module as WG document
> Nov 2012 Submit 6rd MIB module for Proposed Standard
> Nov 2012 Submit DS-lite MIB module for Proposed Standard
> Nov 2012 Submit Mesh topology MIB module for Proposed Standard
> 
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires