Subject: Re: [Softwires] reworded charter

From: "Durand, Alain" <[email-masked]>
Date: Thu, 22 Sep 2005 20:17:06 -0400

Pekka,

Due to the fairly agressive schedule we are trying to meet (schedule that translates time to market requerements),  I find that asking this charter to explicitely mandate a re-chartering event is a very expensive proposition.

I also agree with Mark that the network edge is a non issue, I hope that in Paris we could get a better understanding that the key factor here is the rate of changes in tunnel set-up (I.e. Once a while vs a. Tunnel per TCP session).

That said, I agree with your point on MIBs, the schedule is a bit optimistic here and should be pushed out.

    - Alain.

-----Original Message-----
From: Pekka Savola <[email-masked]>
To: Durand, Alain <[email-masked]>
CC: [email-masked] <[email-masked]>
Sent: Thu Sep 22 01:25:52 2005
Subject: Re: [Softwires] reworded charter

Hi,

On Fri, 16 Sep 2005, Durand, Alain wrote:
> Here is an updated charter based on the feedback we've got so far.

This is a significant improvement, thanks.

I still have two issues with it:

  1) the lack of a problem statement prior to chartering.  This is 
troubling; we don't yet know which scenarios are to be addressed, and 
still we are deciding on the details of the protocol.  I don't think 
this is acceptable.  As I argued before, I think we need to add an 
explicit re-chartering event after we're sufficiently far with the 
problem statement / scenarios draft.  Suggest adding a new paragraph 
after the first -- the wording is not good but gives an idea:

   The first task is getting consensus on the problem
   statement (scenarios being addressed).  Re-chartering will be
   needed prior to adopting work on the protocol, as the attributes of
   the protocol (initial description below) are subject to change.

[[ and and explicit recharter milestone after the PS ]]

  2) the "(or network edge)" seems troubling to me, because I don't see 
the requirement for this protocol in such case.  I'd remove it now, 
and maybe re-evaluate after finishing the problem statement if needed.

"The focus of this WG is to define a softwire setup negotiation 
protocol and encapsulation to be use between a customer (or network 
edge) node and the corresponding softwire end-point."

Another minor suggestion: realistically, the MIB could probably have a 
delivery date a bit further in the future.. the dates are very 
challenging as they are already..

> Softwires (softwires)
>
>
>
> Chairs (tentative):
>
> David Ward <[email-masked]>
> Alain Durand <[email-masked]>
>
>
>
> Internet Area Directors:
>
> Mark Townsley
> Margaret Wasserman
>
>
>
> Internet Area Advisor:
>
> Mark Townsley
>
>
>
> Technical Advisors:
>
> Prof Li Tsinghua University
> Thomas Narten IBM
>
>
> Mailing Lists:
>
> General Discussion: [email-masked]
>
> Send mail to: [email-masked]
>
> With a subject line: subscribe
>
> Archive: ftp://ftp.ietf.org/ietf-mail-archive/softwires-wg
>
>
> Description of Working Group:
>
> The Softwire Working Group is specifying the standardization of
> discovery, control and encapsulation methods for connecting IPvX
> networks across IPvY networks in a way that will encourage multiple,
> inter-operable vendor implementations. For various reasons (financial or
> political), native IPv4 and/or IPv6 transport may not be available in
> all cases, and there is need to tunnel IPvX in IPvY to cross a part of
> the network which is not IPvX -capable. Configured tunnels or softwires
> are suited for the inter-networking job. Non-interoperable tunneling
> mechanisms have been developed based on the RFC3053 tunnel broker
> concept, and in addition, standardized mechanisms like RFC2893, RFC2473,
> GRE, L2TP, etc. have been used in some scenarios. Other deployments use
> non-standardized, incomplete solutions. The lack of interoperable and/or
> standardized solution in that space has been noted in the v6ops WG
> scenario analysis.
>
> The focus of this WG is to define a softwire setup negotiation protocol
> and encapsulation to be use between a customer (or network edge) node
> and the corresponding softwire end-point. Softwire configuration
> includes two phases: softwire end point discovery and softwire set-up.
>
> In the softwire set-up phase, the initator and the ISP negotiate the
> parameters necessary to establish the softwire. Those include:
>
> - The encapsulation type: IPvX-over-IPvY with a possible intermediary
> layer (e.g. UDP). This encapsulation negotiation should be extensible to
> cover future methods of both unicast and multicast traffic.
>
> - How to obtain the IP addresses to use for the softwire end-points.
> This could be done with an out-of-band mechanism or directly negotiated
> at set-up phase.
>
> - The MTU to be used by the softwire or an out-of-band mechanism to
> compute it
>
>
> In the softwire end point discovery phase, the initiator gets a name or
> an IP address for the ISP-side end point of the softwire to establish.
> This phase is orthogonal to the set-up one.
>
> The initial milestone for this working group will be the set-up phase.
> This WG is not chartered to work on the discovery phase and a re-charter
> will be needed prior to undertaking such work; once the base work has
> been completed (or is well under way), WG may consider re-chartering to
> address discovery.
>
> The WG will reuse existing technologies as much as possible and will
> create additional building blocks when necessary.
>
> The WG is chartered to complete the following work items:
>
> 1. Document problem statement and submit to IESG as Informational.
>
> 2. Document softwire encapsulation and control protocol usage for
> IPvX-over-IPvY with possible intermediary layer and submit the
> specification to the IESG for publication as a Proposed Standard.
>
> 3. Develop the softwire MIB module and submit it to the IESG for
> publication as a Proposed Standard.
>
>
>
> Goals and Milestones:
>
> Jan 06    Submit a problem statement to the IESG to be considered
>          as an Informational RFC
>
> Jul 06    Submit softwire encapsulation and control protocol to the
>          IESG to be considered as a Proposed Standard
>
> Jul 06   Submit softwires MIB to the IESG to be considered as Proposed
> Standard
>
>
>
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/softwires
>

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires