Subject: [Softwires] Charter review and WG creation

From: Mark Townsley <[email-masked]>
Date: Wed, 07 Sep 2005 12:19:11 +0200

Everyone,

Again, apologies for the administrative bumbling getting this list 
together, proposed charter ready, etc. I learned some lessons here, 
sorry you had to be the group to endure that.

Please review the charter on the link that Dave posted and provide 
feedback here. Naturally, I'd like to finalize this and move towards a 
WG before the proposed interim meeting date. Please review the 
presentations from the BoF as well, and if you have any questions now is 
the time to post them (though be sure to look at the Chairs' "obvious 
questions" slide before). Let's hold back on discussing solutions just 
yet, and stay focused on the proposed charter. If you think it is good 
in its present form, please make that known as well.

I understand there was some confusion at the BoF in Paris about what 
"candidate proposals" will be considered for this WG. Please let me 
clarify that, in general, good ideas are always welcome, and any can be 
brought to the WG in whatever form at any time (ID, email, etc). That 
said, this WG will be on a very tight schedule for some of its first 
deliverables, and there will be some important choices for the WG to 
make and not be revisited ad-infinitum. Also, please note that, once the 
WG is formed, the IESG may request that the RFC Editor withhold 
publication of any overlapping or conflicting until the WG concludes its 
work (as described in RFC 3932).

Many thanks,

- Mark

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 07 Sep 2005 17:54:16 +0700

Hi Mark,

Somehow you replied my question regarding the IETF process. I just readed
3932 now so I'm up-to-date on that ;-), but still not clear to me if you're
referring to RFCs or IDs ?

The question is still, regardless of the process, if this is fair w/o making
sure that we have a clear deadline for those documents. Some being cooked my
be inadvertently be left out if a concrete date (a fair one) is not fixed
up-front.

What about the expired I-Ds ? If they are candidate, need to be resubmitted,
even w/o modifications or they will still be considered ?

Regards,
Jordi

> De: Mark Townsley <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Wed, 07 Sep 2005 12:19:11 +0200
> Para: "[email-masked]" <[email-masked]>
> Asunto: [Softwires] Charter review and WG creation
> 
> 
> Everyone,
> 

************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Information available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 07 Sep 2005 14:34:01 +0200

>be inadvertently be left out if a concrete date (a fair one) is not fixed
Again, in principal any idea may be brought to the WG to be considered 
at any time and in any form. But, once the WG exists, I would like all 
energies focused on creating a standard solution (which may include 
making decisions which will not be revisited). After the standard is 
published, other methods may be sent to the RFC Editor, shepherded by 
and AD, etc. I'm not really creating any special policy here, just 
identifying that RFC 3932 exists and not to be surprised if it is used.

I was told that in the past IESG members have said that, since there was 
no WG chartered for creating this protocol, to send any submissions 
directly to the RFC Editor for publication or to find an AD to shepherd 
the work. I don't necessarily want to rehash all the associated history, 
so I am simply pointing out now that this is all well and good up until 
the point the IETF community decides to take this work on as a 
standards-track effort by chartering a WG. It logically follows, then, 
that if you have a protocol that you believe should have an RFC 
published for *regardless* of the outcome of the WG (for example, in 
your opinion it is well-documented, implemented and deployed), you might 
be well served to get these to the RFC Editor as individual submissions 
before the WG exists. Whether you do this or not has no bearing on 
whether the solution will be considered in the WG or not, what is more 
important to the WG is whether the solution actually is well-documented, 
implemented and deployed when judged by consensus.

>even w/o modifications or they will still be considered ?
Expired IDs are never a good thing to bring to a WG. Please update any 
IDs you would like to discuss in the WG with the latest boiler-plates, 
etc. I don't think I am saying anything new here.

All good ideas will be considered. As I believe it states in the 
proposed charter, existing mechanisms will be given more weight than 
those that do not exist. Thus, if an idea is brought forward that is 
brand new, with no implementations or deployments, it carries a 
substantially greater burden of proof than one that does have multiple 
implementations and/or deployments. In other words, the WG prefers 
running code.

- Mark

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 07 Sep 2005 23:30:28 +0700

Ok. Then, when is the date (if fixed) or target one to get the WG chartered,
so everybody that has something in the way make sure to send to the RFC
editor before ?.

Regards,
Jordi

> Responder a: <[email-masked]>
> Fecha: Wed, 07 Sep 2005 14:34:01 +0200
> Para: <[email-masked]>
> CC: "[email-masked]" <[email-masked]>
> Asunto: Re: [Softwires] Charter review and WG creation
> 
>> This electronic message contains information which may be privileged or
>> confidential. The information is intended to be for the use of the
>> individual(s) named above. If you are not the intended recipient be aware
>> that any disclosure, copying, distribution or use of the contents of this
>> information, including attached files, is prohibited.
>> 
>> 
>> 
>>

---

From: Thomas Narten <[email-masked]>
Date: Wed, 07 Sep 2005 16:33:46 -0400

Some comments on the proposed charter.

> Description of Working Group:
> 

> The Softwire Working Group is chartered to specify standardization
> of discovery, control and encapsulation methods for connecting IPvX

Drop the word "discovery", since it's not in the deliverables and the
charter later says its not being done as part of this charter.

> networks across IPvY networks in a way that will encourage multiple,
> inter-operable vendor implementations. Some networks are mandated to
> be IPv4 or IPv6 only (e.g. due to financial or political reasons);
> configured tunnels or ¡Æsoftwires¡Ç are suited for the
> inter-networking job. Currently, a number of deployments have been
> undertaken using the tunnel broker approach, RFC3053. However, as no
> tunneling encapsulation or configuration protocol is specified in
> 3053, interoperability and management of the softwires are a
> significant burden. Other deployments use non-standardized,
> incomplete solutions.

One important point that seems missing from the charter is that (I
thought) the goal here was to have one end of the tunnel be an ISP's
internal aggregating router, the other end would be at a customer end
site. Seems important to me to capture this point, to distinguish this
from intra-ISP tunneling...

> The focus of this WG is to define a softwire setup negotiation
> protocol and encapsualtion. This protocol will be able to provide
> control aspects to negotiate different softwire properties between a
> customer or network edge node and the corresponding softwire
> end-point.

I hope that we are not going to "define" yet another
encapsulation. Can't we use an existing one? The charter is kind of
lose on this point.

> Softwire configuration includes two phases: softwire end point
> discovery and softwire set-up. 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. In the softwire set-up
> phase, the initator and the ISP negotiate the parameters necessary
> to establish the softwire. These two phases are orthogonal and
> independent. The initial milestone for this working group will be
> the set-up phase. After this is completed, the WG will recharter to
> focus on the discovery phase and new technological solutions.

Suggest replacing the last sentence with:

This WG is not chartered to work on the discovery phase and a
recharter will be needed prior to undertaking such work; once the base
work has been completed (or is well under way), WG may consider
rechartering to address discovery.

> Important characteristics of softwires include:

What does "characteristic" mean here? Are these attributes that are to
be negotiated?

> - IPvX-over-IPvY with possible intermediary encapsulation and be
> extensible to cover future encapsulation methods of both unicast and
> multicast traffic.

I don't understand "intermediary encapsulation". What does this mean?
And I'm not sure that "IPvX-over-IPvY" is precise enough. Do you mean
IPv4 over IPv6 tunneling, as defined in RFCXXX, or something else?

> - The IP addresses to use for the softwire end-points

Are these to be negotiated? 

> - A control mechanism for softwire setup, policy, autodetection and
> reconciliation of mismatched parameters (such as MTU, encapsulation,
> authentication, etc..)

what is "autodetection"?

> - Automatic Discovery of softwire endpoints

If this is out of scope for the current charter, I'd suggest remove
this item. It's distracting.

> - Simple encoding to facilitate implementations in hardware

encoding??? Do you mean "encapuslation"? Or something else? Is this
statement oriented at the setup, or the encapsulation, or??

> The WG will reuse existing technologies as much as possible and will
> create additional building blocks when necessary. The initial
> selection of potential solutions will come from a bounded set of
> technologies that are either published as RFCs or in the RFC editor
> queue.

I think I understand what you are trying to do with the last sentence,
but I think the detail of requiring it be an in the RFC editor queue
is not helpful. I assume that what folk are after are "stable" (or
reasonably baked) documents. If so, just define a criteria for
submissions that are to be evaluated. Having it be in the RFC Editor
queue means nothing, since anyone can submit something there, and
right now, the queue is backlogged so submissions are getting reviewed
quickly.

maybe the charter should say the WG will develop an evaluation
criteria for submissions, and have an evaluation date by which
submissions should be formal submitted to the WG for consideration as
candidate proposals. I don't think the details of this have to be in
the charter. Think of what multi6 did, for example.

> 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 encapsulation and submit
> the specification to the IESG for publication as a Proposed
> Standard.

Again, I don't understand what "intermediary" means.

> 3.  Develop the softwire MIB module and submit it to the IESG for
> publication as a Proposed Standard.

> Goals and Milestones:

> Mar 06 Submit a problem statement to the IESG to be considered as an
> Informational RFC

Mar 06, is way too late. IMO, the WG should focus on this document
almost exclusively for the short term, and should send it to the IESG
shortly after the next IETF meeting (i.e., December 2005). ANd if the
WG can't get this document finished (and keep it under, say, 5 pages),
that's a warning sign that the WG doesn't understand  what problem it
is trying to solve.

> Nov 06 Submit softwire encapsulation and control protocol to the
> IESG to be considered as a Proposed Standard

> Nov 06 Submit softwires MIB to the IESG to be considered as Proposed
> Standard.

Finally, I don't at all get the "softwires" name. AFAIK, this is
tunnel setup, pure and simple. Why invent a new name that doesn't make
sense to anyone? (And as paris demonstrated, no one has any idea what
'softwires' is supposed to mean, other than it is yet another cute
name.)

Thomas

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 08 Sep 2005 09:52:55 +0700

See below, in-line.

Regards,
Jordi

> De: Thomas Narten <[email-masked]>
> Fecha: Wed, 07 Sep 2005 16:33:46 -0400
> Para: Mark Townsley <[email-masked]>

Well, as indicated in a previous email, I'm not sure we agree on this.
Probably need to heard much more voices on this list !

> from intra-ISP tunneling...

While I agree that is not required for intra-ISP, if we write it so it's not
a requirement (if we all agree), but an open option (up to the final
solution), could be good.

> encapsulation. Can't we use an existing one? The charter is kind of

I also have the opinion that we should avoid this (and I really think is the
case), but if required, why not ?

> the charter. Think of what multi6 did, for example.

Agree, otherwise, I only see right now possibly one "backed/stable"
solution, and not necessarily is the only/best one which fit the market
needs.

> 'softwires' is supposed to mean, other than it is yet another cute

v6tc was fine ! All this history has been crazy and unnecessary in my
opinion :-(

---

From: Pekka Savola <[email-masked]>
Date: Thu, 8 Sep 2005 09:02:55 +0300 (EEST)

FWIW, I agree on most points Thomas is making, in particular,
  - while I think discovery is highly useful, I agree it's best to
  clearly focus on the basic stuff first (though either way is fine).
  - I'd prefer to not specify new encapsulations but I'm not sure if we 
know yet whether that's the case or not.  For example, is 
IPv6-over-IPv4[UDP] a "new encapsulation"?  It hasn't been specified 
in the generic case anywhere, though it may be trivial.
  - I'm not sure if I see the value in the "softwires" name, but 
anything goes..

I'll make my own comments shortly..

-- 
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: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2005 14:02:47 +0200

=> I support Jordi, even the issue has some simple solutions (mine favorite
is the Microsoft-style one, DNS SRV RR) it is important to specify one.

Regards

Francis,[email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 08 Sep 2005 19:13:00 +0700

And there is a lot of work (documents) done already, so it could be sorted
out in parallel, w/o wasting too much extra time.

Regards,
Jordi

> De: Francis Dupont <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Thu, 08 Sep 2005 14:02:47 +0200

---

From: Thomas Narten <[email-masked]>
Date: Thu, 08 Sep 2005 10:38:07 -0400

> is the Microsoft-style one, DNS SRV RR) it is important to specify one.

Well, here is the crux of the problem. You seem to think there is a
simple solution, because you make assumptions about what the problem
actually is. My sense is that there is not even agreement on the exact
details of what "the discovery problem" is. E.g, the above solution
assumes that the entity creating the tunnel knows the DNS name of its
ISP (so it can construct the SRV name to query). Folk have also
asserted that this is not a reasonable assumption, that this info
isn't always available.

So, before I'd support "solving" this problem or agreeing there are
reasonable solutions, I'd want to see agreement on exactly what the
"discovery problem" is.

Thomas

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2005 23:16:48 +0200

actually is.

=> I agree but I believe it was not the right place to enter into
details... The problem is to discover what server(s) to use for
a service I have subscribed (so not only I know the DNS name but
I have the credentials to go through AAA checks, and to verify
the peer is my ISP).

   My sense is that there is not even agreement on the exact
   
=> the goal is not to solve the issue, it is to put it into the charter.

=> one can consider this is already a part of the problem.

Thanks

[email-masked]