Re: Enterprise Analysis DSTM Issue

[Pekka Savola <pekkas@netcore.fi>]

On Wed, 10 Aug 2005, Fred Baker wrote:
> On Aug 10, 2005, at 6:34 AM, Pekka Savola wrote:
> > We need to separate "use of v4-in-v6 tunnels as a concept" from "DSTM the 
> > protocol".  Fleshing it out or removing it seem the only choices.
>
> So what I hear you arguing for, which I think is consistent with Tim's 
> comments, is that this section should say that we require a tunneling 
> solution which might use a variety of tunnel approaches including virtual 
> circuit networks including MPLS, IP/IP, IP/GRE, IPSEC Tunnel Mode, and so on, 
> and that in addition a common rendezvous mechanism is required. DSTM is an 
> example of a rendezvous mechanism, as are the DNS-ALG in NATPT, the mechanism 
> in Silkroad, and so on, and v6tc-or-whatever is chartered to come up with 
> that mechanism.
>
> Am I correct?

Yes, but I think this still misses the point.  I don't have strong 
objections to v4-in-v6 tunneling (whatever the encapsulation), BUT the 
main point is that referring to DSTM as an example of either v4-in-v6 
or v4-in-v6 rendezvous function is misleading.

If we want to refer to a protocol or a rendezvous function for 
v4-in-v6 tunnels, we can just refer to RFC2473 and TSP (they're 
already referred to in the document)?  The first describes the 
encapsulation ("configured v4-in-v6 tunneling"), the second also more 
of the rendezvous (+address assignment) function.  Both are pretty 
straightforward protocol specifications, easy to implement 
interoperably if you need to, and the scope of the specs is well 
understood.

Referring to DSTM is misleading because its specification seems like a 
mix between a paper describing a relatively straightforward v4-in-v6 
concept (though this might or might not have been obvious 5 years ago) 
and a protocol specification.  And:

 a) I have not seen a justification for a concept document (we should 
consider including the appropriate discussion in this doc, if the 
concept needs more discussion)

 b) The spec is not useful as a protocol specification; while it can 
probably be used to create an implementation, it doesn't seem 
sufficient to create interoperable implementations, and it's not clear 
what's actually required for the implementations and what's not.

As rewriting an external spec (the area of which would be under 
discussion for softwires BOF/WG) is out of scope for this WG (though I 
might be willing to help off-list in the interest of clearing up the 
confusion)..

My question is now: is there something missing in ent-analysis with 
regards to the description of the v4-in-v6 tunnel concept?

If we could find appropriate description, maybe we wouldn't need the 
references to DSTM and all would be clearer to the reader.

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