Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt

[Tim Chown <tjc@ecs.soton.ac.uk>]

I agree with Yanick's points in line (the ones that aren't just "OK" :)

Tim

On Mon, May 24, 2004 at 11:56:10PM +0200, Pouffary, Yanick wrote:
> Hi 
> 
> Thanks for the review. Comments in-line.
> 
> Yanick
> 
> 
> > -----Original Message-----
> > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On 
> > Behalf Of Pekka Savola
> > Sent: Monday, May 24, 2004 2:23 PM
> > To: v6ops@ops.ietf.org
> > Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt
> > 
> > On 12 May 2004, Jonne Soininen wrote:
> > > Hi everybody,
> > >
> > > this is a WG Last Call for comments on sending 
> > > draft-ietf-v6ops-ent-scenarios-02.txt, "IPv6 Enterprise Network 
> > > Scenarios" to the IESG for consideration as Informational:
> > >
> > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-
> > 02.txt
> > 
> > Personal comments below.
> > 
> > Seems to be ready after a revision for clarifications etc.  -- in any 
> > case, the most important thing is the _next_ document..
> > 
> > I think Example network C, a security defense network, is not 
> > mainstream enough to be applicable to be investigated in the 
> > scenarios.  There are probably 1, 5 or 10 such networks in the world. 
> > We should be focusing on more common scenarios (even addressing 
> > "80/20" would be good).  [I have a few specific comments for 
> > clarification within this example, but I'll send them if this example 
> > is not replaced by something else.]
> > 
> 
> [YP] I agree with Richard Graveman to keep this example. Please send
> you're your comments. 
> 
> > I also thought that section 4 could possibly be removed at this point.
> 
> > If it wouldn't be, there are a few clarifications I have scribbed up, 
> > omitting them now..
> > 
> 
> [YP] We all agree
> 
> > substantial:
> > ------------
> > 
> > [Network Infrastructure Component 1, sect 3.2]
> >     Enterprise Provider Requirements
> >        - One site vs. multiple sites?
> > 
> > ==> do you refer to _geographical_ sites here, or something else 
> > (e.g., in the multi6 WG sense)?  Maybe add 'geographical' here?
> > 
> 
> [YP] ok
> 
> >        - Leased lines or VPN?
> > 
> > ==> spell out, e.g. to:
> > 
> >        - If multiple sites, how is the traffic exchanged securely
> between
> >          them?
> > ...
> >        - What is the IPv6 address assignment plan available
> >          from the provider?
> > 
> > ==> this should possibly be spelled out a bit, like:
> > 
> >        - Do the provider(s) delegate a stable /48 prefix?
> >          Does the enterprise need more?
> > 
> 
> [YP] ok
> 
> > ...
> >        - Will clients be Multihomed?
> > 
> > ==> 'clients'?  Spell out a bit, maybe like:
> > 
> >        - Is the enterprise multihomed?  Which multihoming techniques
> are
> >          supported by the Service provider?
> > 
> 
> [YP] ok
> 
> > ...
> > 
> >        - Is there an external data-center?
> > 
> > ==> I think this needs to be spelled out a bit.  Did you mean like:
> > 
> >        - Would some enterprise server(s) be housed in the service
> >          providers' data centers?
> > 
> 
> [YP] ok
> 
> > ...
> > 
> > ==> add an additional requirement, like:
> > 
> >        - Is IPv6 available using the same access links as IPv4,
> >          or differently?
> > 
> 
> [YP] ok
> 
> > ...
> > 
> >    [Network Infrastructure Component 2]
> > 
> > ==> add a couple of requirements, like:
> > 
> >        - Are applications only run in the internal networks?
> 
> [YP] ok
> 
> >        - Are ALGs or proxies being used for some applications?
> >          Would using such be feasible?
> >        - Are there applications which cannot be proxied or
> >          upgraded to support IPv6?
> 
> [YP] I think we have this already covered.
> 
> > 
> >    [Network Infrastructure Component 3]
> > 
> >       - Is a Tele-commuter work force supported?
> > 
> > ==> reword to be more generic, maybe like:
> > 
> >       - Is working remotely (e.g., through VPNs) supported?
> > 
> 
> [YP] ok
> 
> > ...
> > 
> >        - Is inter-site communications required?
> > 
> > ==> I don't quite understand this requirement, because I fail to see
> _any_
> > scenario where you wouldn't need to communicate between sites?  Could
> you
> > clarify?
> > 
> 
> [YP] The enterprise may want to deploy IPv6 within a single site.
> 
> >        - Is network mobility used or required for IPv6?
> > 
> > ==> This requirement seems to need a bit more spelling out, as it
> isn't
> > 100%
> > obvious what you're referring to (MIPv6 vs NEMO?), what's the usage
> case?
> > 
> >        - What are the requirements of the IPv6 address plan?
> > 
> > ==> maybe add a couple of clarifying points here:
> > 
> >        - Is there a detailed asset management database, including
> hosts,
> >          IP/MAC addresses, etc.?
> >        - What is the enterprise' approach to numbering geographically
> >          separate sites which have their own Service Providers?
> > 
> 
> [YP] ok - may be
> 
> > ...
> > 
> >       - What will be the IPv6 Security policy/procedure?
> > 
> > ==> there should probably be a bit more on this..? maybe at least
> like:
> > 
> >       - Are separate or same firewalls, IDS systems, etc. used for
> IPv6?
> >         Which part of the traffic is encrypted using IPsec and how?
> > 
> 
> [YP] your clarifications are useful but do we need to be that specific?
> 
> >   Network Infrastructure Component 4
> >     Enterprise Network Management System
> >        - Performance Management Required?
> >        - Network Management Applications Required?
> >        - Configuration Management Required?
> >        - Policy Management and Enforcement Required?
> >        - Security Management Required?
> >        - Management of Transition Tools and Mechanisms?
> > 
> > ==> these should probably be spelled out a bit more, because at least
> I
> > didn't have much idea what all of these included?
> > 
> > [Example Network A, sect 3.3]
> > 
> >      - ISP does not offer IPv6 service.
> >      - Private Leased Lines no Service Provider Used
> > 
> > ==> is the first really often the case?  If you're a suffiently big
> > enterprise, I think at least in Europe there are already quite a few
> ISPs
> > willing to give you service. (note: s/ISP does/ISPs do/ .. as it has
> > multiple ISPs?)
> > 
> 
> [YP] yes it is the case. We have a lot of enterprises out there which
> are far behind with regard to internet revolution.
> 
> > ==> I don't quite understand the second bullet point?  do you mean
> that
> > the
> > site has just one ISP, and the rest are connected using leased lines
> to
> > the
> > "primary" ISP, and they don't have a direct connectivity at all?
> > 
> > I'm not sure if this is any longer the "mainstream" scenario, because
> the
> > net traffic is probably so high that the enterprises don't want to pay
> > $$$$
> > for transporting all their traffic to their HQ using leased lines, but
> to
> > throw it out to their ISP immediately (and tunnel internal traffic
> with
> > VPNs, or leased lines).
> > 
> 
> [YP] I don't agree. Yes this is a cost issue hence why they are looking
> at deploying IPv6 as a replacement solution.
> 
> >      - All routers and switches are upgradeable to IPv6.
> >      - Existing firewalls can be upgraded to support IPv6 rules.
> > 
> > ==> are these mainstream scenarios?  What does a switch's IPv6 upgrade
> > mean
> > (is it L3 switch? or management functions?)
> > 
> >      - IPv4 Private address space is used within the enterprise.
> > 
> > ==> the enterprise already had PI space (from the above), but still
> uses
> > private address space internally -- any particular reason why?
> > 
> 
> >   DNS will now have to support both IPv4 and IPv6 DNS records and the
> >    enterprise will need to determine how the DNS is to be managed and
> >    accessed, and secured.  The range of DNS operational issues are out
> >    of scope for this work. [...]
> > 
> > ==> here, it would be good to refer to
> > draft-ietf-dnsop-ipv6-dns-issues-07.txt, and possibly add at the end
> > something like:
> > 
> 
> [YP] ok
> 
> >   These operations include at least:
> >     - configuring IPv6 DNS servers as resolvers on IPv6(-only) hosts,
> >     - selecting a method to insert AAAA/PTR records in the DNS,
> >     - managing the DDNS reverse/forward updates processes, if used,
> >     - providing IPv6 transport capability in the recursive internal
> >       DNS servers, and
> >     - managing the IPv6 capability in the authoritative servers, and
> >       configuring the AAAA records at the delegator of the DNS zones.
> > 
> > ....
> > 
> >    The choice of interior routing protocols have an impact on how the
> >    routing tables will be handled: some such as OSPF will have the
> >    ships-in-the-night paradigm, others such as ISIS are integrated.
> This
> >    has an impact on the topology and the management of the network.
> > 
> > ==> I don't really understand what you mean with the sentence about
> OSPF
> > vs
> > ISIS.  Do you mean that w/ OSPF you'd use separately OSPFv2 and
> OSPFv3,
> > and with IS-IS just one process?
> > 
> > Note that this discussion could probably be just a summary of
> > draft-ietf-v6ops-isp-scenarios-analysis-02.txt section 4.3.1 and the
> > Appendix A. (We should refer to that document here at least.)
> > 
> >    IPv6 capable routers should be monitored to ensure the router has
> >    sufficient storage for both IPv6 and IPv4 route tables.  Existing
> >    network design principles to limit the number of routes in the
> >    network, such as prefix aggregation, become more critical with the
> >    addition of IPv6 to an existing IPv4 network.
> > 
> > ==> I do not think monitoring the routers for sufficient v4/v6 route
> > table storage is an operationally important issue, clearly not more
> son
> > than
> > monitoring v4 route tables today, at least.  Maybe just remove this
> first
> > sentence or even the whole paragraph.
> > 
> 
> [YP] Exactly the point is you need to do the same. I think we should
> keep the paragraph as is.
> 
> > ==> maybe add at the end add something like:
> > 
> >   Decisions wrt. routing include at least:
> >    - whether IPv4 and IPv6 routing topologies will be different,
> >      affecting the decision on which routing protocols to use,
> >    - how redundancy is ensured if tunneling is used, and
> >    - which tools are to be used to monitor the IPv6 infrastructure.
> > 
> 
> [YP] ok
> 
> > 5.3  Autoconfiguration
> > 
> >    IPv6 introduces the concept of stateless autoconfiguration in
> >    addition to stateful autoconfiguration.  The enterprise will have
> to
> >    determine the best method of autoconfiguration, for their network.
> >    The enterprise will need to determine if they are to use stateless
> or
> >    stateful autoconfiguration, and how autoconfiguration is to operate
> >    for DNS updates.  The enterprise will need to determine how prefix
> >    delegation is done from their upstream provider and how those
> >    prefixes are cascaded down to the enterprise IPv6 network.  The
> >    policy for DNS or choice of autoconfiguration is out of scope for
> >    this document.
> > 
> > ==> this section should probably be generalized to be something like
> > 'Configuration of Hosts [or: .. of Infrastructure and Hosts]'
> > (and generalize the autoconfiguration a bit more
> > in the rest of the paragraph as well)
> 
> 
> [YP] ok
> 
> > ==> remove ", for their network", as everything is done for their
> network
> > in
> > any case.
> > ==> dynamic prefix delegation inside the enterprise may not be a
> really
> > feasible option, but in any case,  I'd probably add something like:
> > "; the choices are to do this manually, or using a dynamic protocol"
> > to better spell it out.
> > ==> One might consider adding at the end something on whether an asset
> > management database is being used, and the choices for configuring
> other
> > information on the hosts (e.g., DNS servers, proxy servers, etc.etc.).
> > 
> 
> [YP] We will try to rework this
> 
> 
> > 5.4  Security
> > 
> >    Current existing mechanisms used for IPv4 to provide security need
> to
> >    be supported for IPv6 within the enterprise.  IPv6 should create no
> > *  new security concerns for IPv4.  The entire security infrastructure
> > *  currently used in the enterprise needs to be analyzed against IPv6
> > *  deployment effect and determine what is supported in IPv6.  Users
> >    should review other security IPv6 network infrastructure work in
> the
> > *  IETF and within the industry on going at this time.  Users will
> have
> > *  to work with their platform and software providers to determine
> what
> > *  IPv6 security network infrastructure components are supported. The
> >    security filters and firewall requirments for IPv6 need to be
> >    determined by the enterprise. The policy choice of users for
> security
> >    is out of scope for this document.
> > 
> > ==> there is considerable overlap with two sentences above, marked
> with
> > '*'.
> > I suggest removing one of them and expanding the other slightly.
> > 
> > ==> you should probably refer to some security documents here, e.g.,
> > draft-savola-v6ops-security-overview-02.txt
> > 
> > ==> add at the end maybe something like:
> > 
> >    At the very least, one has to consider for example:
> >      - whether the same access control/IDS policies are to be used for
> >        IPv6 as with IPv4, and whether these are to be handled by the
> >        same or different equipment/software,
> >      - how keying and/or certificates are managed,
> >      - how VPNs are controlled,
> >      - whether RFC3041 temporary addresses are to be used and to
> >        what extent if so,
> >      - whether there are to be internal access control points, and
> >      - if tunneling techniques are used, how this affects the site
> >        security, and how site must be secured to make tunneling
> secure.
> > 
> 
> [YP] ok
> 
> > 5.6  Network Management
> > 
> > 
> >    The addition of IPv6 network infrastructure components will need to
> >    be managed by the enterprise network operations center.  Users will
> >    need to work with their network management platform providers to
> >    determine what for IPv6 is supported during their planning for IPv6
> >    adoption, and what tools are available in the market to monitor the
> >    network.
> > 
> > ==> remove 'in the market' -- appears redundant here?
> > ==> maybe add something like:
> > 
> >    At least, one should consider:
> >     - whether IPv6-capable devices can be managed or monitored using
> >       IPv4, and what must be done if that is not possible, and
> >     - how IPv6 infrastructures are being monitored?
> > 
> > 
> > 5.7  Address Planning
> > 
> >    The address space within the enterprise will need to be defined and
> >    coordinated with the routing topology of the enterprise network.
> It
> >    is also important to identify the pool of IPv4 address space
> >    available to the enterprise to assist with IPv6 transition methods.
> > 
> > ==> I don't think the "pool of IPv4 address space" is all that
> > relevant consideration here, as it hints at the use of IPv6-only
> > infrastructures, NAT-PT, and the like.
> 
> [YP] don't agree. The availability of IPv4 address space will trigger
> the choice of deployment techniques. It is very relevant.
> 
> > ==> in any case, I think there is one thing that should be explicitly
> > called
> > out: Whether the site wants to consider whether this new kind of local
> > addressing is used for v6 or not.
> > 
> 
> [YP] ok
> 
> >    For inter-domain use, sites may choose to migrate IPv4 multicast
> >    applications to SSM, for which no reverse path discovery method is
> >    required.
> > 
> > ==> ", for ..." part is incorrect and out of context, replace with
> > something
> > like: ", which simplifies the multicast architecture, but requires
> that
> > the
> > applications specify the multicast transmission source(s).
> > 
> > ==> Maybe add a new paragraph:
> > 
> >    The enterprises also need to consider whether IGMP/MLD snooping or
> >    similar solutions to reduce the multicast flooding is
> >    required: this may be especially important if the subnets are
> large,
> >    or multicast is used extensively.
> > 
> > 5.9 Multihoming
> > 
> > 
> >    At this time, current IPv6 allocation policies are mandating the
> >    allocation of IPv6 address space from the upstream provider. If an
> >    enterprise is multihomed, the enterprise will have to determine how
> >    they wish to support multihoming.  This also is an area of study
> >    within the IETF and work in progress.
> > 
> > ==> I think it would be appropriate to describe RFC3178 model of
> > multihoming
> > very briefly, e.g., like in section 5.6 in
> > draft-ietf-v6ops-isp-scenarios-analysis-02.txt
> > 
> 
> [YP] ok
> 
> > 7.  References
> > 7.1  Normative References
> > 
> >    None at this time.
> > [...]
> > 
> > ==> please add a lot more explicit informative / normative references
> to
> > the
> > subject which were discussed.
> > 
> 
> [YP] ok
> > 
> > 
> > semi-editorial
> > --------------
> > 
> > [Scenario 2 in sect 3.1]
> >     Scenario 2: Enterprise with an existing IPv4 network wants to
> deploy a
> >                 set of particular IPv6 "applications" (application is
> >                 voluntarily loosely defined here, e.g. peer to peer).
> >                 The IPv6 deployment is limited to the minimum required
> to
> >                 operate this set of applications.
> > 
> > ==> I don't think it's good to say "minimum" here, because there is no
> > reason to restrict it to the absolute minimum required.  The point
> here is
> > just that v6 deployment doesn't need to be _larger_ than required to
> > operate
> > the set of applications.
> > 
> > Maybe reword: s/is limited to/does not need to be more extensive than/
> > 
> 
> [YP] ok
> 
> > editorial
> > ---------
> > 
> > IPv6 Enterprise Network Scenarios
> > 
> > ==> maybe rename to something like 'Enterprise Networks IPv6
> Transition
> > Scenarios' to be more in line with the rest of the document?
> > 
> >    Enterprise Network    - A network that has multiple internal links,
> >                            one or more router connections, to one or
> > more
> >                            Providers and is actively managed by a
> > network
> >                            operations entity.
> > 
> > ==> align the text for those lines which were broken to multiple lines
> > by originally too many chars/line? (same also later)
> > 
> >    Provider              - An entity that provides services and
> >                            connectivity to the Internet or
> >                            other private external networks for the
> >                            enterprise network.
> > 
> > ==> isn't 'Provider' a slightly too terse (and ambiguous) term?
> > Maybe 'Service Provider' or abbreviated SP if necessary, instead?
> > 
> >    IPv6 only             - A node or network capable of supporting
> only
> >                            IPv6.  This does not imply an IPv6 only
> >                            stack, in this document.
> > 
> > ==> the last sentence should probably be reworded to be clearer.  Did
> you
> > mean something like:
> >                                   In the context of this document, a
> >                            dual-stack node which has disabled IPv4 is
> >                            considered IPv6 only.
> > 
> > 3.2  Scenarios Network Infrastructure Components
> > 
> > ==> reword to: 'Network Infrastructure Components for Scenarios' ?
> > 
> >           - Are the nodes moving within the enterprise network?
> >            - Are the nodes moving outside and inside the enterprise
> >              network?
> > 
> > ==> these should probably be shifted left about 3-4 spaces?
> > 
> >      - The DHCP server to update naming records for dynamic desktops
> > uses
> > 
> > ==> reword maybe to:
> > 
> >      - The DHCP server updates the DNS records for dynamic desktops
> >        with DDNS.
> > 
> > Document Acknowledgments
> > 
> > ==> s/Document //
> > 
> > Authors-Design Team Contact Information
> > 
> > ==> maybe reword to "Authors' Addresses" as it's the regular format?
> > 
> > ==> this is pretty long.  Two possibilities to summarize this a bit:
> >  a) add an "Editor's Address" section, with just Jim's contact info,
> in
> > full; Keep "Authors' Addresses" section for the rest, but mention only
> > names, affiliations and the email addresses.
> >  b) just take out other info for the non-editors as names,
> affiliations
> > and
> > email addresses.
> > 
> > 
> > --
> > Pekka Savola                 "You each name yourselves king, yet the
> > Netcore Oy                    kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> > 
> > 
> 
> Thanks
> Yanick
>