Subject: Re: [Softwires] comments on softwire problem statement (Tom Pusateri)

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 5 Jan 2006 18:34:14 -0600

I'm working through Tom's comments, but replying to Jordi's reply...

>>
>> 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.
>
> May be you're right is more a combined problem statement + requirements, 
> and
> not just a problem statment.

I'll wait on the chairs to determine whether I'm using 2119 language 
(consistently) or not - this is a related comment.

>>    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?
>
> No, there will not be a specific requirements document, but a solution one
> already.
>
>>
>>    For example, I think the requirement that the concentrator be able
>>    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 ;-)

Honestly, I wish someone would. My recent TRILL experience is that this 
focused the discussion quite a bit. I can make up numbers, but would anyone 
like to suggest real ones?

>>    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.
>
> As said above, the solution/s one.
>
>>
>> 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.
>
> 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.

Keeping the same for now...

>> 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.
>
> I think all this has already being corrected (or is being done now).
>
>>
>>    Section 3.
>> "deserve" should probably be "serve"

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

OK

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

Corrected by previous editor.

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

OK

>>    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.
>
> Any suggestion of concrete text ?
>

Exactly ...

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

The text I'm working with currently says

 <t>As customers networks are typically attached via
 a single link to their ISP, a default route is the only thing that is 
needed for
 each of the address families.</t>

I agree that "the only thing" is too strong a statement. Rephrase as:

 <t>As customer networks are typically attached via
 a single link to their ISP, the minimum routing requirement is a default 
route for
 each of the address families.</t>

Does this work for you?

>>    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.
>
> Yes, it has already been observed, we need a concrete reference here.

OK... I think the point is that we're not inventing anything about 
multicast. Does this work for you?

 <t>Existing multicast solutions can be used over the softwire. Typically,
 such solution would be either proxy MLD/IGMP and PIM.</t>

>>    Section 3.12
>> "assume" should be "assumed"

OK
>>
>> "define" should be "defined"
>>
Corrected by previous editor.

>> The parentheses before "must be encapsulated" is closed
>> after the next bullet point "Path failure detection".
>>
Corrected by previous editor.

>>    Section 4
>> "problem in named" should be "problem is named"
Corrected by previous editor.

>>
>>    Section 4.1
>> "treat" should be "treated"
Corrected by previous editor.

>>
>>    Section 4.6
>> "routers are advertizing routers" needs rewritten

Current text is

 <t>In contrast with the hubs and spokes problem, routers are advertizing 
routers
 for relatively large network islands,
 so authentication of individual users is not necessary.
 However, if running over
 an untrusted network, control or data plane security may be necessary.</t>

If "advertizing routers" is still objectionable, would "border routers" be 
an improvement?

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

OK
>>    Section 4.8
>> should "IPLS" be "VPLS"?

Clues are graciously acknowledged. Are "IP-Only LAN Service", Virtual 
Private LAN Service", or both intended here?

Thanks,

Spencer 

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