Re: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-01.txt

[KK <[e-mail]>]

Fred,

Thank you for your detailed comments and apologies for a delayed response.

This is very useful feedback! We will work on incorporating these changes
into the next revision.

Regards,
KK




On Thu, Sep 20, 2012 at 7:36 AM, Templin, Fred L
<[e-mail]>wrote:

> Here are my comments on this document:
>
> Fred
> [e-mail]
>
>
> 1) Section 1, s/will be perform better/may perform better
>
> 2) Section 1, "It is thus in the enterprise's interests to
> deploy native IPv6 itself." - This statement is not necessarily
> true for all enterprises, and the fact that the ISP may provide
> native IPv6 services has no bearing on whether the enterprise
> should also provide native IPv6 services. Suggest deleting this
> sentence.
>
> 3)Section 1.3, "Reasons for a Phased Approach", in this
> section there should be a statement to the effect that,
> although some of the RFC1687 reasons for not deploying
> IPv6 are still valid, many of the reasons given in this
> section are new since the publication of RFC1687 and do
> give good reasons for transition.
>
> 4) Section 1.3, the statement: "it can be expected that
> new applications will only support IPv6." Please change
> to: "it can be expected that some new applications will
> only support IPv6."          ^^^^
>
> 5) Section 1.3, "which means that with IPv6 merging networks
> (after two organizations merged) is much easier and faster."
> This statement needs to be backed up with a citation - perhaps
> something from the RENUM working group, or from "Renumbering
> Without a Flag Day".
>
> 6) Section 3.1.2, "...communicates of the network" - should it
> be: "...communicates on the network" ?
>
> 7) Section 3.1.2, second paragraph, somewhere this paragraph
> should cite RFC6724 - "Default Address Selection for Internet
> Protocol Version 6 (IPv6)".
>
> 8) Section 3.3, final sentence: "Either way IPv6 introduces
> the opportunity to rationalize the environment and to architect
> it for growth." - is not true, because IPv6 is an inanimate
> object and cannot "introduce" anything. Maybe you are meaning
> to say (sic) since the network administrators are considering
> an introduction of IPv6 they might also be inclined to review
> their existing architecture for its growth potential while they
> are at it? Plus, this statement and the previous paragraph are
> out of place in a section that is supposed to talk about routing.
>
> 9) Section 3.5, the sentence: "The enterprise administrator will
> want to evaluate whether the enterprise will request address space
> from its ISP (or Local Internet Registry (LIR)), or whether to
> request address space from the local Internet Registry..." - the
> term "local Internet registry" is being used redundantly here in
> a way that may confuse the reader.
>
> 10) Section 3.5, "Each location, no matter how small, should get
> at least a /48." - there has been quite a bit of discussion about
> sites being able to request a smaller size such as /56. Also, the
> size of the minimum site prefix is outside the scope of this
> document. Perhaps change this to something like: "Each location,
> no matter how small, should get the largest practical IPv6 prefix
> delegation.".
>
> 11) Section 4.1, "may need to communist with the outside world",
> "communist" is probably not the correct word here.
>
> 12) Section 4.1, "Add some comment about setting MTU to 1280 to
> avoid tunnel pMTUd black holes?" - This is out of scope for this
> document, and goes against recommendations in some of the tunneling
> documents. Plus, 1280 may not be any safer than something larger
> like 1480 in many cases.
>
> 13) Section 5, the phrase "Dual Stack when you can, tunnel when
> you must" may be inappropriate for some or perhaps even many
> enterprise network use cases. The subsequent sentence also
> contains subjective advice. Suggest rewording the first two
> sentences of this paragraph to something like: "An important
> design paradigm to consider during this phase is to determine
> where Dual Stack and/or tunnel should be used".  Dual stacking
> when possible allows you to build a native IPv6 network
> capability that should be preferred over tunnels."
>
> 14) Section 5.1, "An important design choice to be made is what
> IGP to use inside the network." - Doesn't this text belong back
> in Section 3.3 ("Routing")? Or if not, should Section 3.3 be
> deleted and its text moved here?
>
> 15) Section 5.1, final sentence, "In the long term, DHCPv6 makes
> most sense for use in a managed environment." would almost
> certainly raise prolonged and undesirable debate. The previous
> sentences articulated the SLAAC and DHCPv6 considerations very
> well, so it would be better to just leave this sentence out.
>
> 16) Section 5.2, "It is important to note that most operating
> systems will, by default, prefer to use native IPv6 over IPv4
> when enabled." - this may not be true for OSes that implement
> RFC6724 default address selections. In that case, IPv6 and/or
> IPv4 would be preferred based on the address selection
> algorithm instead of based on some static configuration.
>
> 17) Section 5.2, "Furthermore, some OSes may have tunneling
> mechanisms turned on by default...". Change to: Furthermore,
> some OSes may have unmanaged tunneling mechanisms turned on
> by default..."     ^^^^^^^^^
>
> 18) Sections 6.2 and 7 seem to be preliminary in nature, and
> seem to be in need of substantial editing and/or new text added.
> It is too early to comment on these sections.
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> Of
> > [e-mail]
> > Sent: Saturday, September 15, 2012 11:05 AM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: [v6ops] I-D Action:
> draft-ietf-v6ops-enterprise-incremental-ipv6-
> > 01.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >  This draft is a work item of the IPv6 Operations Working Group of the
> > IETF.
> >
> >       Title           : Enterprise IPv6 Deployment Guidelines
> >       Author(s)       : Kiran K. Chittimaneni
> >                           Tim Chown
> >                           Lee Howard
> >                           Victor Kuarsingh
> >                           Yanick Pouffary
> >                           Eric Vyncke
> >       Filename        : draft-ietf-v6ops-enterprise-incremental-ipv6-
> > 01.txt
> >       Pages           : 28
> >       Date            : 2012-09-15
> >
> > Abstract:
> >    Enterprise network administrators worldwide are in various stages of
> >    preparing for or deploying IPv6 into their networks.  The
> >    administrators face different challenges than operators of Internet
> >    access providers, and have reasons for different priorities.  The
> >    overall problem for many administrators will be to offer Internet-
> >    facing services over IPv6, while continuing to support IPv4, and
> >    while introducing IPv6 access within the enterprise IT network.  The
> >    overall transition will take most networks from an IPv4-only
> >    environment to a dual stack network environment and potentially an
> >    IPv6-only operating mode.  This document helps provide a framework
> >    for enterprise network architects or administrators who may be faced
> >    with many of these challenges as they consider their IPv6 support
> >    strategies.
> >
> >
> > The IETF datatracker status page for this draft is:
> >
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental-
> > ipv6
> >
> > There's also a htmlized version available at:
> >
> http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-01
> >
> > A diff from the previous version is available at:
> >
> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-enterprise-incremental-
> > ipv6-01
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
>