Subject: [Softwires] comments on softwire problem statement

From: Tom Pusateri <[email-masked]>
Date: Thu, 29 Dec 2005 15:24:11 -0500

1. I'm not sure I understand the process but calling the document a
   problem statement and then saying that "some requirements are also
   identified to better describe the problem definition" is bound
   to introduce some confusion.

   Its not clear what requirements are able to be included in the
   document.  Is there going to be a follow-on requirements document
   as well or are other requirements that don't describe the problem
   definition not going to be mentioned?

   For example, I think the requirement that the concentrator be able
   to be built in hardware is critical to the scaling requirements.

   Also, does anyone want to take a stab at scaling requirements?

   If this is going to be in another document, then great, but if not,
   where does it go? The charter doesn't mention another document.

2. I think the two problems described as "Hub & Spoke" and "Mesh" are
   so different that they probably would do better to be analyzed
   seperately and have potentially different solutions. The users are
   different as well as the termination points in the network.

3. I'll mention the following nits in the current document that haven't
   yet been mentioned by others. Future versions should use a spell
   checker program before submission.

   Section 3.
	"deserve" should probably be "serve"

	"There are three cases refer to Hubs" might read better as
	"Diagram 1 shows three different cases of the Hub and Spokes
	problem."

   Section 3.1 "potentially managed by softwires in a "Mesh" problem
	This is the first use of "Mesh" in the document and it seems
	to assume the reader knows what the authors mean by this but
	they don't necessarily know this yet.

   Section 3.4 "netwroks" should be "networks".

   Section 3.7 "Alternatively, an automated discovery phase..."
	I think this automated discovery phase should be the default
	not an alternative. Manual configuration should be available
	as an override certainly but you want to force this to be
	as automated as possible.

   Section 3.8 "scale the solution to millions"
	I'm glad to see you thinking at this scale. Practicly, this will
	mean concentrators will need to do alot in hardware. This will
	limit the solution space. Maybe this should be spelled out
	more plainly.

   Section 3.9 "a default or static route is the only thing"
	I think this is an incorrect assumption. We cannot tell how people
	will use these. It may be common to have a default route or to
	use static routes but this is definitely not the only thing
	that is needed for both address families. (Especially when you
	consider multicast forwarding and routing.)

   Section 3.10
	I have been highly involved in IP multicast routing for more
	than 15 years and I don't know what "classic" multicast is.
	I don't think this is a good term to use at all.

   Section 3.12
	"assume" should be "assumed"

	"define" should be "defined"

	The parentheses before "must be encapsulated" is closed
	after the next bullet point "Path failure detection".

   Section 4
	"problem in named" should be "problem is named"

   Section 4.1
	"treat" should be "treated"

   Section 4.6
	"routers are advertizing routers" needs rewritten

	A reference to Steve Bellovin's recommendations are badly needed.

   Section 4.8
	should "IPLS" be "VPLS"?

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 30 Dec 2005 10:34:54 +0100

Hi Tom,

See my reply below, in-line.

Regards,
Jordi

> De: Tom Pusateri <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Thu, 29 Dec 2005 15:24:11 -0500
> Para: "[email-masked]" <[email-masked]>
> Asunto: [Softwires] comments on softwire problem statement
> 

May be you're right is more a combined problem statement + requirements, and
not just a problem statment.

>    definition not going to be mentioned?

No, there will not be a specific requirements document, but a solution one
already.

>    to be built in hardware is critical to the scaling requirements.

Agree, but this is implicit in any problem description. The solution may be
implemented in software or hardware or a combination of both. I've no
objection to state that clearly, if appropriate.

>    Also, does anyone want to take a stab at scaling requirements?

Feel free to go ahead ;-)

>    where does it go? The charter doesn't mention another document.

As said above, the solution/s one.

>    different as well as the termination points in the network.

We have already considered this, and clearly the solution may be two
different solutions, but it seems better to keep a single document for the
two problems, just to clarify the differences and the similarities.

>    checker program before submission.

I think all this has already being corrected (or is being done now).

> as automated as possible.

Fully agree. We should reverse the order of this. The charter was designed
to make sure that if the automated discovery is not done, the protocol is
independent on that, but I think reversing the order doesn't "break" the
charter.

> limit the solution space. Maybe this should be spelled out

Any suggestion of concrete text ?

> consider multicast forwarding and routing.)

Well, is the case we are considering, customer->ISP, so a single static or
default router is always there. Not sure if we need/want/can take a
different view on this. May be if you can describe a concrete example of
what you are thinking on ...

> I don't think this is a good term to use at all.

Yes, it has already been observed, we need a concrete reference here.

> A reference to Steve Bellovin's recommendations are badly needed.

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

Barcelona 2005 Global IPv6 Summit
Slides 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.