Concerning draft-pouffary-v6ops-ent-v6net-04

["Alan E. Beard" <aeb1@aebeard.com>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Folks:

Concerning draft-pouffary-v6ops-ent-v6net-04.txt:

First, some general comments:

The draft in its present form is characterized by a strong, if somewhat
skeletal, basic structure, and there exists the bare minimum of connective
tissue required to hold the structure together.  However, there is
precious little muscle on the structure, a complete absence of fat, and
not even a hint of skin, much less proper clothing for a public
presentation. This draft in its present form does not march, and any
attempt to force movement is likely to give rise to a prodigious
clattering of bones and scraping of joints.

The above, and much of what follows herein, proceeds from a presumption
that the IPv6 Enterprise Network Scenarios document, upon completion, will
bet intended to provide guidance to enterprise network teams (as stated in
paragraph 2 of section 1), and to serve as a basis for the companion
analysis and solutions document.

If the above presumption is even remotely accurate, we will need to
provide information beyond the existing text for the use of the enterprise
network team, which team is likely to be comprised of administrative
managers and, in the case of financial services organizations, auditors in
addition to network engineers.  To be a bit less imprecise, it would be
useful to provide text which might indicate to a reasonable administrative
manager (assuming that at least one instance of this mythical beast
actually exists): what we are talking about (couched in a minimum of
jargon); why the manager should care; and why the IETF is presuming to
give an enterprise advice which may very well be perceived as gratuitous.

Notwithstanding the above, much, in fact almost all, of the existing text
is very good indeed.  In particular, the Base Network Scenarios
definitions are complete and sound, as are the example network
descriptions.  In general, section 3.2, Network Scenarios Characteristics,
is well crafted, although there are few nits involving questions framed "A
or B" which can legitimately be answered "Yes" or "Both".


Now, on to specifics.

Concerning base scenarios:   I can foresee a sequence of events wherein a
single hetwork traverses all three scenarios enumerated in the draft, with
the final state being that represented by scenario 3. The most probable
sequence would be 2;1;3. In fact, one of my clients discussed (and
subsequently abandoned) just this sequence, and several others have
muttered darkly about similar sequences.

Concerning example networks: most of my clients operate networks which
exhibit many of the characteristics of all three enumerated examples.  We
should perhaps not assume that most enterprise networks can be neatly
categorized - the range of services supported in commercial enterprise
networks (particularly in financial services networks, where lies most of
my client base) is more extensive than any one of the enumerated example
networks subsumes. For financial services networks, only single-offering
service providers (for example, ATM operations providers) have the luxury
of a single-application network.  That notwithstanding, the three example
networks, if considered in toto, do cover most of the requirements seen in
networks operated by many of my clients. Perhaps we should add some sort
of statement indicating that real-world networks are likely to exhibit
characteristics which overlap more than one of the enumerated examples.

Concerning network infrastructure requirements, the audience may find it
useful to have additional information concerning which subsets of the
enterprise network team may find specific sections of especial interest,
to wit:

For most of my clients, DNS, routing and autoconfiguration issues are left
to the engineering wallahs: there is a default assumption that these
matters will be resolved by the techies well before any transition is
attempted. Security considerations are likewise left to the techies,
subject to approval of the auditors; in practice, this leaves to the
network engineering team the task of educating the auditors concerning
what security mechanisms carry forward from the IPv4 implementation - a
non-trivial task, as the auditors are by nature and by instruction
paranoid. Considerable guidance (preferably from an authoritative source)
will be required before the auditors will be pacified.

Applications issues, for the most part, fall to network engineering;
applications developers don't know, and emphatically don't care, about v6
support. In practice, applications which support only v4 will force
dual-stack support until all such applications reach the end of their
service life and are retired or replaced with entirely new code.
Recommendations concering applications will be most useful if made
specific to new application development; in almost all cases, existing
applications in commercial environments are unlikely to see re-coding for
support of IPv6. Even new applications are unlikely to support v6 absent
an administrative (as distinguished from engineering) requirement for such
support. Guidance in this area will be most effective if directed to
administrative managment, rather than engineering, staff.

For most networks I see on a regular basis, network management issues are
left for resolution by vendors or by the network operations coding team.
In most cases, dual-stack implementations of NM applications will be
required, but a set of solutions which provides for direct management
(preferably on the native transport protocol) of both v4 and v6 nodes will
be required until all nodes in the network become v6 only.  Guidance from
a source authoritative on these matters will be useful to engineering and
administrative managers of the end-user networks.

Address planning is probably the task which affects vital interests of
every subset of the network team, particularly in view of the current
scheme for allocation of IPv6 address space.  Administrative management
will be involved in an attempt to ensure continuous (non-interruptible)
network operations; auditors will be involved in an attempt to ensure
utter and complete independence from any external entity (including, but
not limited to, any one ISP); and network engineering will be involved
because they have to actually make the bloody thing _work_!

I'm not entirely sure how we draw the distinctions between the several
subsets of the enterprise network team, but I think we need to do at least
some explicit targeting of the text (and tell the audience just _who_ are
the targets) for each section, lest the engineering wallahs be faced with
something like this:

admin: "An RFC?  That's engineering stuff - you handle it."

engr:  "yes, but there is information in here you need..."

admin: "Where does it say THAT?"

engr:  "Um, well, there's no explicit specfication beyond 'enterprise
network team'..."

admin: "Well, you read it, and give us a summary."

[engineer slouches away, muttering darkly.]

Now, the comments herein are admittedly very far from comprehensive or
complete.  However, even this rather sketchy set of notes might stimulate
some discussion.  I'll be traveling for the next three weeks or so,
including 12 days incommunicado in the North Atlantic, but I'll try to
follow this note with some additional mutterings when I get back to the
office about mid-August.

That's my $.02 worth ;-)

Regards,

Alan E. Beard

-- 
Alan E. Beard <aeb1@aebeard.com>
AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809
863.815.2529