[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Enterprise Analysis DSTM Issue
The DSTM authors will get back to the WG and you on our decision
regarding DSTM in a few weeks.
We have and will continue to take WG input and incorporate consensus and
clearly abide by requirements in the IETF to assure our IETF rules of
engagement are followed strictly. In addition I will respond to Pekka's
excellent technical discussion points as always for some time now.
Regarding your lack of apology that is fine below, I will take that as a
no and note it to my self. No reason to further discuss.
Regarding your individual input, opinion, and analysis it is read.
Regarding your view on IPv6 dominant deployment we can just agree to
disagree as two people. I see no point of rehashing again. Ipv6
dominant networks are a requirement and the WG consenus is that it will
in fact be a reality, as I hear consensus.
Regarding DSTM it does assume a dual stack on all nodes and states that
clearly in the spec and supports IPv6 - in - IPv6 tunneling RFC should
be used. It is only the IPv4 routing within the DSTM domain that will
not be used and this was an idea supported by the market and that is
input at least to those of us that will drive and assist the market to
use DSTM as an IPv6 Transiton mechanism. To state DSTM does not support
a dual-stack method is not valid based on the DSTM spec.
/jim
> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]
> Sent: Tuesday, August 09, 2005 4:50 PM
> To: Bound, Jim
> Cc: v6ops@ops.ietf.org
> Subject: 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
> >
>