[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Some Enterprise Scenarios comments
Hi,
I've quickly read through entnet-scenarios-00. The approach seems
generally OK (remember that ISP and enterprise scenarios are the most
difficult ones, with large variety), but it's a bit early to tell.
More specific comments below. Unfortunately, at this stage, it is
difficult to provide good commentary yet.
Substantial:
------------
==> The approach in section 6 in M1-M6 seems, at places, a bit
solution-specific. In many cases it says "enterprise policy is FOO". My
point is that the document here is trying to grasp IPV4 enterprise systems
as they are, describe them, and perhaps give some view on how to proceed
with a solutions document. The point of subsequent work of v6ops is to
give reasoning why a certain type of enterprise policy is adopted -- not
(yet!) the other way around. The approach seems a bit solutions-centric,
in particular with M2 and M3.
Semi-editorial:
---------------
Abstract
IPv6 will be deployed in Enterprise networks. This scenario has
requirements for the adoption of IPv6.
==> This should be reworded; "this scenario" is ambiguous and sounds bad,
and the scope of the work here is not to set requirements for IPv6
adoption (rather, to describe the current IPv4 enterprise networks).
This document will focus upon
and define: a set of technology scenarios that shall exist for the
enterprise network, the set of transition variables, transition
methods, and tools required by different scenarios. [...]
==> "transition methods" and especially "and tools required by different
scenarios" seem too vague. My first impression was that the document
would be specifying which transition mechanisms (like 6to4, etc.etc.)
would be required. Luckily, this was not the case, but may require some
more verbose text.
Terminology
==> several important wordsmithing fixes in editorial section, below.
Critical issues for each:
PMTUD : Support for discovery vs. traditional ICMP aversion
==> Is PMTUD really a critical approach? Without elaboration, it may be
that some other word might be more appropriate, or this should be
considered a bit..
Trust system between host & network management teams:
Dual-stack vs. IPv6-only
IPv6-only is a restricted capability subset
Routing
Architectural concept of tunneling over foo vs. native service
==> "Trust system ..." ??! I've no idea how these relate to trust, so more
elaboration or rewording is definitely needed!
Scenario #6
A new Enterprise providing location based services for over a wide
geography enables mobile devices for their Account Teams to access
network data and services. Set D.
==> compared to other scenarios, this strikes me as being perhaps a bit
too specific ("account teams", etc.)?
Editorial:
----------
V6ops Working Group Enterprise Network Scenarios Design Team
INTERNET-DRAFT: draft-ietf-v6ops-entnet-scenarios-00.txt
OBSOLETES : draft-pouffary-v6ops-ent-v6net-03.txt
Yanick Pouffary (Chair)
Jim Bound (Editor)
Enterprise Networks Scenarios Design Team
See Acknowledgements Section
February 2003
==> the header is quite unconventional: I'd just make it like:
V6ops Working Group Yanick Pouffary (Chair)
Internet Draft Jim Bound (Editor)
Expiration Date: Aug 2003 Enterprise Networks Scenarios Design Team
February 2003
1. Introduction
IPv6 will be deployed in Enterprise networks. This scenario has
requirements for the adoption of IPv6. This document will focus upon
and define: a set of technology scenarios that shall exist for the
enterprise network, the set of transition variables, transition
methods, and tools required by different scenarios. The document
using these definitions will define the points of transition for an
Enterprise network.
==> same issues as with abstract
The audience for this document is the enterprise network team
==> if you can find, I'd personally prefer another word to "audience".
accomplishing the business goal, IPv6 provides strong motivations to
move.
==> reword or expand "to move" (for a change?)
Enterprise Network - An Enterprise Network is a network
that has multiple links, a router
conection to a Provider, and is activel
managed by a network operations entity.
==> formatting: must not exceed 72 chars (also elsewhere in the document).
==> s/conection/connection/
Provider - A Provider is an entity that provides
services and connectivity to the Internet
or other private external networks for
the Enterprise Network.
==> "Internet or _other_ private external networks" must be reworded;
Internet is not a private external network :-)
Edge - The Edge is the ingress and egress points
connecting to the Internet, Extranet, or
to another private external network.
==> is the assumption so that the egress point = always ingress point?
The plurality of the sentence is ambiguous.
Administrative Domain - An Administrative Domain are the
ingress and egress points connecting
nodes across the Enterprise
Network, behind the Edges.
==> same consideration about points (in "are" applies here). It also
strikes me that the defininion could be simpler (drop out egress/ingress
points completely, Edges covers that already).
Extranet - An Extranet is any Enterprise Network
owned network components at the Edge, but
not part of the Administrative Domain.
==> "any EN owned components" ? I'm having trouble parsing the sentence,
minor rewording.
Border Router - An Enterprise Network Border Router is a
a router that is configured at the Edges.
==> I recommend using another word than "configured" -- typically it has
some other connotations.
Points of Transtion - An Enterprise Network Point of
==> s/Transtion/Transition/
Every node that can be addressed by another node must be in a
registered name service, managing this name service is a
==> s/,/, and/
(multi-Party) require globally consistent addresses for peer-to-
==> s/P/p/
- Routers
- Non Router Nodes
==> why just not say "Hosts" :-)
solutions. A set of suggested solutions will be provided in a follow
on document to this work.
==> s/follow on/follow-up/?
V5: IPv6 software upgrades are not available for existing
routers and nodes.
==> s/available/available or possible/
V6: Source code for applications have been lost or cannot be
==> s/have/has/
V7: New business function being defined and can exist without
==> s/being/is being/, s/can/it can/
This point on the graph will be an transtion strategy. After the
==> s/transtion/transition/
Mobility : Requirements for nodes
==> s/Requirements/Mobility requirements/
Scenario #6 (subset of all scenarios)
==> s/6/7/ ?
The Enterprise network will have varying points of transition that
will require different points of interoperability with IPv6 and IPv4.
==> reword "different points of interoperability"
but an IPv4 Internal Router is between them. These nodes could also
be Mobile nodes too and in a remote location.
==> s/ too and/, or/
1. A Dual Stacked IPv4/IPv6 node wants to communicate to a legacy IPv4
service and is on a Native IPv6 link and Routing Domain. Enterpise
==> "Routing Domain" (upper case) is not defined, I think?
2. A Dual Stacked IPv4/IPv6 node wants to communicate to a legcy IPv4
==> s/node /node /
==> s/legcy/legacy/
This Point of Transition exists for the following conditions:
1. A Dual Stacked IPv4/IPv6 node wants to communicate with a legacy IPv4
==> kill the extra empty line
security, applications, and remove some benefits from the IPv6
protocol.
1. The Design Team highly recommends that network not adopt the
policy
in reference "1" above.
2. IPv6 ONLY nodes should not be deployed in a network until they
will
not require access to any legacy IPv4. This means that
applications
and infrastructure has been ported or moved to IPv6. Until that
time nodes for transition should be Dual Stacked IPv4/IPv6 nodes.
This means networks that want to use IPv6 ONLY nodes will be
required
to move applications and infrastructure to IPv6 first.
==> the 1., 2., list starts out of empty air, so I'm assuming there should
be some kind of text there.
addresses to nodes. Though DHCPv6 can be used to administrate
addresses that are assigned to nodes.
==> s/Though/However,/ (or some other wordsmithing, looks funny that way)
When preforming stateless autoconfiguration, an EUI-64 is generated
==> s/pre/per/
bit IPV6 address. The EUI-64 is derived from the MAC address of the
interface that being autoconfigured. This mechanism proves a large
==> s/IPV6/IPv6/
==> s/that/that's/
==> s/proves/provides/
token should be considered when establishing an address plan."
==> s/"//
This section will identify the tools requirements for an EN
transitioning to IPv6 so the configuration issues for the EN are
==> s/EN/Enterprise Network/
12. Security Section
==> is this Security Section or Security Considerations? :-)
Acknowledgments
==> this section is typically numbered, too.
Design Team' Addresses
Send email to ent-v6net@viagenie.qc.ca to contact the design team and send
comments on the draft to v
Authors contact info will be provided in a future draft.
==> s/Team'/Team's/
==> overlong line
==> s/Authors/Authors'/
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings