Subject: Re: [Softwires] Charter review and WG creation

From: "Durand, Alain" <[email-masked]>
Date: Wed, 7 Sep 2005 17:50:25 -0400

Thomas,

Should we explicitely rulled out the intra-isp tunnelibg case now?

A) in Paris, sprint and the chineese ISP were asking for it

B) if we are not talking about highly dynamic tunnels, the intra-isp scenario may not be that different if their network can be mapped with a small number of softwires concentrator.

    - Alain.

-----Original Message-----
From: [email-masked] <[email-masked]>
To: Mark Townsley <[email-masked]>
CC: [email-masked] <[email-masked]>
Sent: Wed Sep 07 16:33:46 2005
Subject: Re: [Softwires] Charter review and WG creation 

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

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

---

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

> A) in Paris, sprint and the chineese ISP were asking for it

It would be useful to have them speak up on the list on why they think 
the solution is needed; in the earlier mail, I wrote my reasons why I 
think it isn't.

Don't get me wrong: softwires protocol _could_ be used used in 
intra-ISP cases as well, but:
  a) The benefits offered by the softwires protocol compared to the
     manual config don't seem significant, and there are significant
     problem.
  b) There is no need to wait for the softwires protocol
     (specification, implementation, deployment, ...), as everything
     can be done easily manually today, from day one.

As such, even b) alone would give the wrong signal that intra-ISP 
cases need to wait for the protocol, which would unduly delay 
deployment.

Thus designing and/or marketing the protocol for intra-ISP case seems 
counterproducive *unless* we get to hear more about the operators' 
requirements why they think it's necessary.

-- 
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: Thomas Narten <[email-masked]>
Date: Thu, 08 Sep 2005 11:01:35 -0400

> Should we explicitely rulled out the intra-isp tunnelibg case now?

I wouldn't rule it out, but I have doubts that it should be a focus
item. If it needs to be, those wanting it should speak up and help
make clear what the requirements are and/or what exact problem they
need solving.

My basic point is that WGs are much more likely to be successful if
they understand the problem they are trying to solve and maintain a
clear focus on that as a bottom line "is this useful to the actual
customer of this work" test. I understood a key problem to be end site
to ISP tunnel set up.

But maybe I'm wrong?

Thomas