Subject: Some Enterprise Scenarios comments

From: Pekka Savola <[email-masked]>
Date: Sat, 8 Mar 2003 19:53:29 +0200 (EET)

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 [email-masked] 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

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 9 Mar 2003 22:22:25 -0500

Pekka,

Thanks for the carful review.

>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 

So what your saying is to state the Enterprise need for IPv6?  Each
enterprise will adopt different reasons for IPv6.  I don't think that is
the job of this spec.  The job of this spec is to identify scenarios how
the enterprise will approach the problem.  The M variable defines how
that can be accomplished and the Enterprises are looking at the M
variables before they move to IPv6, and this is only part of the
specifications equation.  Listing them is important for the context of
how the enterprise arrives at their choice, is our thinking model.

M2 and M3 are no different than the other M values.  These are simply
choices in strategy and if anything we are missing some values.  

>==> 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 

This wording has changed 4 times on the team.  

But this is a good point.

We on the team have never believed the mission here is to describe IPv4
enterprise networks.  So we may not agree on a very basic premise.  The
job is to describe how IPv4 Enterprises will approach moving to IPv6.

>would be required.  Luckily, this was not the case, but may 

I for one agree. 

Not going to respond to other comments till I feel we agree on the scope
of the work.  I am sure you can understand that because it affects all
other responses.

Regards,
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 10 Mar 2003 11:19:00 -0500

Hi Pekka,

We will fix all edits below.  Thank you for this extensive review of our
spec.
All your input below is valid.

Thank You,
/jim

> that some other word might be more appropriate, or this should be 

The operational issue the user has to consider for IPv6 packets in their
network is they are now only fragmented e2e, if at all, and this can
affect an enterprise like a discrete engineering operation that sends
MBs of data modeling across the network or a financial institution bulk
wire transfer updates, etc etc.  PMTUD is important to be used.  I think
PMTUD is the correct word and later needs more discussion in the follow
on text.  What other word would be better, to point out this in a
listing of bullets?

> elaboration or rewording is definitely needed!

Agreed.  WHen I keyed this in as editor I knew someone would ding us on
this one for sure.  The idea is to get some crisp bullets of where the
core trust beliefs can be shattered in the minds of the users defining
how to adopt IPv6.  Some of the ones I hear, as a note, are fallacy and
not reality, and some are completely missing.  But yes this needs major
wordsmithing.  

> too specific ("account teams", etc.)?

We can fix that yes.

>                                                  Yanick
> Pouffary (Chair)

I will look at this as editor.  I followed templates/current-wisdom the
IETF points me to as a note though.

> ==> same issues as with abstract

We hear you.

> ==> if you can find, I'd personally prefer another word to "audience".

We will review ok.  

> ==> reword or expand "to move" (for a change?)

We will review ok.

> ==> formatting: must not exceed 72 chars (also elsewhere in

Hmmmm.  NROFF did it correct it got munged by peoples mailers on the
team. Will fix.

> ==> s/conection/connection/

Thanks.

> Internet is not a private external network :-)

ACK.

> The plurality of the sentence is ambiguous.

Not necessarily esp. multi-site enterprise.  Will reword.

> points completely, Edges covers that already).

That fixes the issue above too.  Thanks.

> ==> "any EN owned components" ?  I'm having trouble parsing

ACK.

> ==> I recommend using another word than "configured" --
> typically it has some other connotations.

ACK.

>       registered name service, managing this name service is a

Thanks.

> 	(multi-Party) require globally consistent addresses for peer-to-

Thanks

> ==> why just not say "Hosts" :-)

I agree. I think we were practicing valuing differences :--)

> ==> s/follow on/follow-up/?

Thanks

> ==> s/available/available or possible/

Thanks

> 	V6:  Source code for applications have been lost or cannot be

Thanks

> ==> s/being/is being/, s/can/it can/

Thanks

> ==> s/transtion/transition/

Thanks

> ==> s/Requirements/Mobility requirements/

Thanks

>    Scenario #6 (subset of all scenarios)

Thanks

> ==> reword "different points of interoperability"

ACK.

> 	  be Mobile nodes too and in a remote location.

THanks