On Mar 23, 2011, at 4:31 PM, Bruno STEVANT wrote: > To Softwire chairs, > Softwire H&S Phase 2 (IPv6 over L2TPv3) is not mentioned in this new charter. > Does the group consider it as a low-priority work to be delayed until next > charter ? I won't be in Prague, but if discussion on the charter is part of > the agenda, I will try to push the question over Jabber.
When we chartered softwires and set it on its path, it's goal was to choose, adapt, or create a limited set of standards track protocols for a limited set of problem spaces that involved connecting various types of IPvX islands over IPvY networks. This was back in 2005, and included a number of parameters for our decision criteria. In what became labeled as the "hub and spoke" case (which looking back is a bit of a misnomer), we were driving towards solving the problem of connecting wireline broadband users with IPv6 over a clearly non-IPv6 last-mile network. One criteria we weighed very heavily was availability of multiple implementations of running code in the various platforms we needed to interconnect, which is one reason why L2TPv2 (RFC 2661) came out on top. The idea to move to L2TPv3 was mostly centered around optimization, and the thought that one day the broadband market might move from L2TPv2 to L2TPv3 on its own accord and that the available implementations would move as well. The latter never really happened (funny how protocol version transitions don't always go as expected!), and L2TPv3 remains relegated to the domain where it started supporting Ethernet, Frame-Relay, ATM, MPLS, etc. rather than PPP for broadband where L2TPv2 remains in wide usage. Around 2008-9, the WG took a turn toward a more mesh-oriented stateless approach for the IPv4-only access network problem in the form of 6rd, while picking up a new stateful hub-and-spoke form for IPv6-only network traversal with dual-stack-lite. Had 6rd been present with running code in the earlier days, it may have supplanted L2TP, or perhaps we would have ended up with a different division of problem spaces and solutions. In any case, it seems we have converged on the point that IP-in-IP tunneling solutions come in stateless and stateful varieties with different tradeoffs for each. Back to the original point of whether we should pursue L2TPv3 for "Phase II" of "Hub and Spoke". No, I don't think so. For IPv6 over IPv4, L2TPv2 continues to work fine for cases where 6rd does not fit and between these two we have a stateless/stateful pair of alternatives. Ds-lite + something like 4rd would give us a stateful and stateless pair for the IPv4 over IPv6 case. Going forward, I think we would be better served making the most sense of this matrix of solutions than optimizing the L2TPv2 case with L2TPv3. - Mark > > Le 21 mars 2011 à 22:29, IESG Secretary a écrit : > >> 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 ([email protected]) by Tuesday, March 29, 2011. >> >> Softwires (softwire) >> --------------------------------------------------- >> Current Status: Active Working Group >> >> Chairs: >> Alain Durand <[email protected]> >> Yong Cui <[email protected]> >> >> Internet Area Directors: >> Ralph Droms <[email protected]> >> Jari Arkko <[email protected]> >> >> Internet Area Advisor: >> Ralph Droms <[email protected]> >> >> Mailing Lists: >> General Discussion: [email protected] >> To Subscribe: [email protected] >> 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 >> >> 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. 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires >> > > -- > Bruno STEVANT - TELECOM Bretagne > > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
