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

Re: Enterprise Analysis DSTM Issue

let's clarify on the conversation.

a) Pekka said that the term "Dual-Stck" was heavily overloaded, and it didn't seem wise for the working group to recommend something that was so unclear.

b) You said that you had no intention of removing DSTM (your experimental work) from the draft regardless of working group (Pekka's) input, because you had customers interested in running DSTM.

c) I said that a working group draft needs to reflect working group input, and that if this could not be accomplished then maybe the document should not be a working group document. That is not a position I plan to apologize for; it is also related to the reason that v6ops doesn't work on transition strategies - the various transition discussions in v6ops did not lead to convergence on a single or small number of recommended strategies.

d) You now have your back up.

Pekka's comments originate from the dual use of the term "dual stack". The IETF has a long-standing recommendation that a network should run both IPv4 and IPv6 (network layer forwarding, routing, and so on) natively, allowing end systems to use either protocol with the expectations one would have of any native deployment. This is described as "dual stack" in RFC 1933 and its successor 2893, in several RFCs describing potential transition mechanisms (2765, 2766, and 2767 come quickly to mind). The term "dual stack" is also used by DSTM. But DSTM doesn't actually run two stacks in the network. It runs an IPv6-only network (at least as far as its customers are concerned) and provides a way for IPv4 systems to rendezvous over it and tunnel through it, allowing end systems to run dual stacks. In your words:

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.

Pekka's observation is that while this is mostly transparent to the end system, it is hardly transparent in the network and (being experimental) is not something the IETF is at this time recommending. This reflects my comment to you of perhaps two months ago. I'm all for your draft discussing dual stack mechanisms - mechanisms that use two stacks, consistent with RFC 2893. But recommending DSTM in a working group recommendation is not consistent with its experimental status. RFC 2026 says, in section 4.2.1:

The "Experimental" designation typically denotes a specification that
is part of some research or development effort. Such a specification
is published for the general information of the Internet technical
community and as an archival record of the work, subject only to
editorial considerations and to verification that there has been
adequate coordination with the standards process (see below). An
Experimental specification may be the output of an organized Internet
research effort (e.g., a Research Group of the IRTF), an IETF Working
Group, or it may be an individual contribution.

and in section 3.3:

(d) Limited Use: The TS is considered to be appropriate for use
only in limited or unique circumstances. For example, the usage
of a protocol with the "Experimental" designation should generally
be limited to those actively involved with the experiment.

In other words, an experimental protocol or procedure may be a perfectly good protocol or procedure and may be a candidate for future standardization. It may have customers using it. However, its general utility has not been shown at the point in time that it has been given that status, and the protocol or procedure is not recommended for general deployment until the experiment has been run.

So, I have two expectations of a working group document: that it reflect the opinions of the working group, and that it reflect the recommendations of the IETF. As you and I discussed in July, the statement

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

fails the latter point, and from the sound of Pekka's comment, fails the former point as well.

I appreciate that you are accepting a number of Pekka's other comments. I'd like you to consider carefully his comment regarding DSTM.

On Aug 9, 2005, at 1:02 PM, Bound, Jim wrote:

WG Members,

For DSTM we are going to discuss as authors what we want to do here per
Fred's mail telling us we could go away if we leave it in the spec, at
least my read of his mail. This will take us a few weeks as some are on
summer vacation.

For your information if your new. DSTM had a minimum of two years IETF
NGTRANS working group discussion, and had discussion before that as the
AIIH proposal. In fact the authors reduced and altered the DSTM
protocol several times per the NGTRANS Chairs input over the years and
the WG.

There will be a series of DSTM specifications sent for Experimental RFC
in the next 6 months. At the same time there will be a new industry
focus on DSTM, that will be quite rigorous, and produce a set of
deployment guidelines including DSTM for the IPv6 Transition.

I realize DSTM is not an Experimental RFC now, but that was because we
were not sure best path to move the work until about 3 weeks ago. But
ISATAP is still awaiting Experimental RFC, was only discussed in NGTRANS
too, not v6ops, and we still need a Tunnel Set Up Protocol. Yet both of
these are fine to reference in the spec? If true, is that "fair".

DSTM is a mechanism that is part of the plan for several enterprises, it
is a valid reference.

No need to respond or support this mail that is not its purpose. But I
want you the WG members to understand our decision or my "individual"
decision when it is made in the next few weeks.

Also it would have been nice if this could have been brought up when I
asked are there other issues in person at the Paris IETF last week. We
could have all met that care in person then at that IETF event.

/jim