[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WGLC ent-analysis-03: DSTM

Jim:

I don't think Pekka was saying that Dual-Stack as described in RFCs 1933 and 2765 is not important to operators. I think that he was saying that extending that to include an Experimental protocol that has specific algorithms attached to it that haven't been agreed to seems an odd recommendation from a working group document.

I think you need to take a little less strident attitude. Your commentary re DSTM sounds a little like "this is my protocol and you don't get to comment on it". If you can't find a way to accept Pekka's commentary, we may need to make this no longer be a working group draft, and advise the IESG to ensure that any RFC Editor path submission of it be published with a note stating that it was not agreed to by the relevant working group.

Lets find common ground here, guys.

Fred


On Aug 8, 2005, at 5:01 AM, Bound, Jim wrote:

We are not removing DSTM from this spec all the authors know for a fact
it is important to operators. If you want further applicability
statements we can do that and there is other work in progress.

Thanks for you input,
/jim


-----Original Message-----
From: owner-v6ops@ops.ietf.org
[mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola
Sent: Friday, August 05, 2005 3:47 PM
To: v6ops@ops.ietf.org
Subject: WGLC ent-analysis-03: DSTM

Hi,

(I'll put two most separable & possibly most discussable items in
separate mails.)

In 8.1:

  Later in the transition process, after the enterprise has
  transitioned to a predominately IPv6 infrastructure, the architect
  should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. Or
  in the case of early deployment of IPv6-dominant networks DSTM can
  be used too.

and in 8.4:

DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in the
enterprise transition or deployment of IPv6-dominant network links
is desired. DSTM is to being submitted as an IETF Experimental RFC.

==> as it is, DSTM is a way too overloaded a mechanism to be
referred to
without more disclaimers or description. As it is, different
people use
"DSTM" to mean at least the following things:
a) v4-in-v6 tunnels
b) automatically set-up v4-in-v6 tunnels
c) automatic set up of v4-in-v6 tunnels when the host
doesn't have v4 address and an app wants to create a v4 socket
d) automatic monitoring and tear-down of said v4-over-v6 tunnel
when the host detects it no longer needs the address/ connectivity
e) plus a number of extensions for even more colorful setups.

a) doesn't require DSTM; b) can be achieved using a tunnel broker; c)
does not require IETF interoperability (a local implementation choice
when/how to launch the v4-in-v6 activation). d) could also
be considered in
the same category (there are no bits in the wire or anything requiring
interoperability AFAICS on when the host removes the tunnel),
though I'm
skeptical whether even providing that would be a good
engineering choice.

My point is that I'm having hard time figuring out:
  1) what the document means when it's recommending DSTM, and
  2) based on my analysis above, I do not believe that DSTM
(in the way that
     I think it's being referred to) is even needed.

Therefore my suggestion is to remove references to DSTM
(preferable) or
greatly clarify the assumptions and the requirements on why it should
be necessary. (On the other hand, if the DSTM spec only described the
algorithms for doing c) and d) above in my list, I would have
a lot fewer
concerns -- but as it is, I believe a reference would confuse
more than
help.)

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