Subject: [Softwires] reworded charter

From: "Durand, Alain" <[email-masked]>
Date: Fri, 16 Sep 2005 15:21:37 -0400

Here is an updated charter based on the feedback we've got so far.

   - Alain.

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 22 Sep 2005 08:25:52 +0300 (EEST)

Hi,

> 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..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Mark Townsley <[email-masked]>
Date: Thu, 22 Sep 2005 13:37:57 +0200

Pekka Savola wrote:

> this is acceptable.

I agree with you that significant protocol details should not be 
introduced before we have nailed down the scope of the problem. As far 
as I can tell, those details have been removed from the charter. Which 
details are you still concerned about?

>   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:
>

As long as the WG is beholden to the problem statement document that it 
produces, I'm not sure why we need an additional step that essentially 
provides a summary of that document within the charter. Given the 
aggressive timelines, I'm afraid of this additional step being a gating 
factor on the output of the WG (put simply, I don't want to get in the 
way of you meeting your aggressive deadlines, and if you are waiting on 
me to push a recharter through in *addition* to a document, there are 
more chances of this happening).

> edge) node and the corresponding softwire end-point."

Are you assuming a "network edge" will always be statically provisioned? 
I think that this may be true for some networks edges, but not others. 
For example, a residential home network with a handful of hosts (set-top 
boxes, a few PCs, game consoles, etc.) may rightfully be considered a 
"network edge" and this should be in scope as much as a single PC.

I think applicability of the output of this WG vs. an existing 
statically provisioned method will boil down to how many and how dynamic 
the tunnel endpoints need to be, not necessarily whether the endpoint is 
a single PC or a network edge. There certainly may be a correlation 
between the dynamic nature demanded by a single node vs. large network 
edge, but it is only a correlation, hard and fast rule.

> challenging as they are already..

Yes, consider yourself challenged. If bumping out the MIB a few months 
provides some relief, I have no problem with that.

- Mark

---

From: Pekka Savola <[email-masked]>
Date: Fri, 23 Sep 2005 09:29:39 +0300 (EEST)

In a different order because the later comment clarifies a point,

On Thu, 22 Sep 2005, Mark Townsley wrote:
> Pekka Savola wrote:
>>  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."
>
> Are you assuming a "network edge" will always be statically provisioned? I 
> think that this may be true for some networks edges, but not others. For 
> example, a residential home network with a handful of hosts (set-top boxes, a 
> few PCs, game consoles, etc.) may rightfully be considered a "network edge" 
> and this should be in scope as much as a single PC.

Ahh! Herein lie the hidden assumptions -- you assume "customer" means 
"customer's PC" but not CPE.  I include "CPE" in the definition of 
"customer" as well.

I think the key point that needs to be emphasized here (and it is 
ambiguous now) is that the tunnel endpoint is at a different 
organization (be it a CPE router, a PC, or whatever).  I haven't yet 
seen a justification for intra-ISP tunnels (e.g., PE routers could be 
considered to be at "network edge").

So I recommend s/a customer (or network edge) node/a customer premises 
node/ below:

"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."

>> 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.
>
> I agree with you that significant protocol details should not be introduced 
> before we have nailed down the scope of the problem. As far as I can tell, 
> those details have been removed from the charter. Which details are you still 
> concerned about?

Upon re-reading, the charter is actually much better in this context 
than before, the only thing that struck me was why there was a need to 
mention MTU at all (either it's communicated explicitly, or calculated 
by deducing the overhead from v4 MTU -- big deal).

>> 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:
>> 
> provides a summary of that document within the charter. Given the aggressive 
> timelines, I'm afraid of this additional step being a gating factor on the 
> output of the WG (put simply, I don't want to get in the way of you meeting 
> your aggressive deadlines, and if you are waiting on me to push a recharter 
> through in *addition* to a document, there are more chances of this 
> happening).

My concern is wider than just the WG.  The problem statement does not 
require IETF-wide review.  I'd be *very* surprised that if this 
charter is proposed to the community, people will ask: "so, you don't 
have a problem statement yet, so you don't understand the problem 
you're trying to solve .. yet you want to get a blanket statement from 
the IETF to charter this activity?  why don't you develop the problem 
statement first and we'll check this out then".

I would certainly ask that kind of question myself if I were not 
participating in the WG.

I would be a lot less concerned if we had an individual problem 
statement draft now and folks could read it and agree that, "yes, this 
is a step in the right direction" (and based on that consensus, a few 
salient attributes of the problem could be put in the charter).

As to the "expense" of explicit re-chartering, yes, that would 
probably be about a month -- if the problem statement is convincing 
enough.  But the same amount of time is going to be used in any case 
by the AD review, IESG review, follow-up discussion, etc.  so the 
matter is IMHO more about the right timing of when the re-chartering 
should be done (e.g., after the document has been submitted to the 
IESG for advancement).

---

From: Mark Townsley <[email-masked]>
Date: Fri, 23 Sep 2005 10:58:40 +0200

Pekka Savola wrote:

>>>  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.
>>>
>> Are you assuming a "network edge" will always be statically 
>> provisioned? I think that this may be true for some networks edges, 
>> but not others. For example, a residential home network with a 
>> handful of hosts (set-top boxes, a few PCs, game consoles, etc.) may 
>> rightfully be considered a "network edge" and this should be in scope 
>> as much as a single PC.
>
>

> the corresponding softwire end-point."

Very good, suggested text change is fine with me.

>>> 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.
>>
>>
>> introduced before we have nailed down the scope of the problem. As 
>> far as I can tell, those details have been removed from the charter. 
>> Which details are you still concerned about?
>
>

Agree, no problem removing MTU from the charter (it will have to be 
dealt with one way or another, but I agree that it is more part of the 
solution space).

>
>>>   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:
>>>
>> As long as the WG is beholden to the problem statement document that 
>> it produces, I'm not sure why we need an additional step that 
>> essentially provides a summary of that document within the charter. 
>> Given the aggressive timelines, I'm afraid of this additional step 
>> being a gating factor on the output of the WG (put simply, I don't 
>> want to get in the way of you meeting your aggressive deadlines, and 
>> if you are waiting on me to push a recharter through in *addition* to 
>> a document, there are more chances of this happening).
>
>

Yes, that may (and probably will) come up. There will be some explaining 
to do. I maintain that every WG is different, this WG does not suffer 
from a lack of problem statements (there are ton of scenerio documents 
to draw from), but a lack of defining its own scope among those 
scenerios. Scoping will be a tough job, so that's what the WG is first 
tasked to do. It would have been nice if the two BoFs provided firm 
scope already, that didn't happen, but it doesn't mean we don't have 
important work to do for the Internet among willing participants.

> salient attributes of the problem could be put in the charter).

Me too, but we don't. That's why as many as you as possible are going to 
lock yourselves in a room in Paris Oct 11 and come up with one to 
present to the community.

> should be done (e.g., after the document has been submitted to the 

The IETF has over 120 WGs. If all had to recharter after every milestone 
achieved, it clearly could not be supported without significant overhead 
withint the IESG and IAB. We've already got one forced recharter for 
this proposed WG, I think moving to two (within the first 6 months of 
the life of the WG no less), on principle alone, is advocating for way 
too much charter-churn.

If the WG fails to deliver a problem statement within 6 months, if it is 
still sitting here arguing over the scope of the effort two years from 
now, micro-managing by the IESG will be in order and a new charter (or 
no charter at all) will be on the table anyway. But if the group is 
successful, I'd rather let it run to completion rather than get in the way.

- Mark