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

From: "Alan E. Beard" <[email-masked]>
Date: Thu, 17 Jul 2003 08:03:41 -0400 (EDT)

[ 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>[email-masked] 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 <[email-masked]>
AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809
863.815.2529

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 18 Jul 2003 12:50:05 -0400

Hi Alan,

Thanks for this input.  We will take it to heart for next release.
Thanks so much.
The team will now add meat to the bones that our colleagues in this WG
made it WG item. 

Two quesitons to you and the working group. 

First one.  We have gone back and forth on this work and other scenario
works if we should put in an IETF doc why a user of this should care.  I
am amoral on this and will go either way.  So I ask should we explain
why this is important to users in this spec and other specs?

Second question is should we target the audience to be the manager,
admin, and engineer or just one of them.  My view is mostly the admin
but enough that the engineer knows to go look at the solutions/analysis
follow on document to the Enterprise scenarios.  

thanks
/jim

> -----Original Message-----
> From: Alan E. Beard [mailto:[email-masked]] 
> Sent: Thursday, July 17, 2003 8:04 AM
> To: [email-masked]
> Subject: Concerning draft-pouffary-v6ops-ent-v6net-04
> 
> 
> 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 
> 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.
> 
> 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 
> 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 
> 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:
> 
> engr:  "Um, well, there's no explicit specfication beyond 
> 'enterprise network team'..."
> 
> 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
> 
> -- 
> AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529
> 
> 
> 
> 
> 
>