[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt
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