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

["Bound, Jim" <jim.bound@hp.com>]

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:aeb1@aebeard.com] 
> Sent: Thursday, July 17, 2003 8:04 AM
> To: v6ops@ops.ietf.org
> Subject: Concerning draft-pouffary-v6ops-ent-v6net-04
> 
> 
> [ 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
> 
> 
> 
> 
> 
>