[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on draft-ietf-v6ops-ent-scenarios-00
Hi Eva,
> First, thanks for this draft, I think it is very useful to
> analyze and understand transition aspects. Im also agree with
> the idea that defining a default transition scenario, will
> not work. However, this draft helps to think about key
> aspects when moving to IPv6.
Thanks we appreciate the comment and support.
>
> Some comments around this draft:
>
> --> In table of contents:
>
> "
> 3. Base Scenarios..............................................6
> 3.1 Base Scenarios Defined.....................................6
> 3.2 Scenarios Characteristics..................................6
> 3.3 Base Scenario Examples.....................................8
> "
>
> I understand point 3.1 and 3.3 are very different, point 3.1
> explains transition scenarios, or IPv6 scenarios, and point
> 3.3 explains existing enterprise scenarios. Maybe, it is more
> clear if the name of these subsections is changed:
>
> 3.1 IPv6 transition base scenarios.
> 3.2 Scenarios Characteristics.
> 3.3 Enterprise specific scenario examples.
Yes this is similar to Tim's input. Agreed.
>
>
>
> Tim Chown wrote:
>
> >>3.1 Base Scenarios Defined
> >>
> >> Scenario 1: Enterprise with an existing IPv4 network
> wants to deploy
> >> IPv6 in parallel with their IPv4 network.
> >>
> >>**Note To V6ops WG: Would a network topology map be useful here?
> >>
> >>
> >
> >I don't think such a map is necessary for any of the base scenarios.
> >
> >However, by "in parallel" do you mean dual-stack infrastructure or
> >separate
> >infrastructure, or is that irrelevant?
> >
> >
>
> --> If it was not dual-stack infrastructure, I think it would be
> scenario 3. If this scenario is related to dual-stack, maybe
> it could be named dual-network.
Hmmm. Might be good idea. Good point. We need to think about that.
>
>
> >> Assumptions: The IPv4 characteristics have an equivalent in
> >> IPv6.
> >>
> >
> >Where might they not do?
> >
> >
> --> Maybe scenario 2, only some specific IPv6 applications
> should work,
> so not all IPv4 services are required in the IPv6 network.
Yes we need to fix this set of statements.
>
>
> >> Scenario 3: Enterprise deploying a new network or
> re-structuring an
> >> existing network, decides IPv6 is the basis
> for network
> >> communication.
> >>
> >>
> >
> >Does this mean IPv6-only network infrastructure? Remember
> you have defined
> >IPv6 above as equal to IPv6-only, so is that what you mean here?
> >
> >
> --> I suppose this scenario is an IPv4 and IPv6 heterogeneous network
> --> which
> will converge to an IPv6 network, where an IPv4 and IPv6
> heterogeneous network is a set of network zones, IPv4-only,
> IPv6-only and dual stack.
Yep. The tricky part here is what does IPv6 only mean and imply and do
we go there in the spec?
>
> >> Assumptions: Required IPv6 network components are available, or
> >> available over some defined timeline.
> >>
> >>
> >
> >Again, do you really mean IPv6-only, or IPv6-capable?
> >
> >
> --> I understand every kind of node, without loosing IPv4/IPv6
> interoperability. Not sure if it is required to emphasize the
> different kind of nodes in this scope.
Thats why if we can leave it as IPv6 capable for the draft it will let
us evolve to the real work.
>
> >> Requirements: Interoperation and Coexistence with IPv4 network
> >> operations and applications are required for
> >> communications.
> >>
> >>
> >
> >So is scenario 3 an IPv6-only network into which IPv6-only or
> >dual-stack hosts may be deployed? If so maybe state that 3
> paragraphs
> >up.
> >
> >
> --> I thought scenario 3 was an IPv4 and IPv6 heterogeneous network,
> --> since
> dual-stack network was scenario 1.
It is but we can make this more clear or I as Editor.
>
> >> Characteristic 1 - Providers for External Network Operation
> >> - IPv4 existing address ownership (Provider based addresses vs.
> >> Provider independent addresses)?
> >>
> >>
> >
> >And number of globally routable IPv4 addresses available?
> >
> --> Very important for some transition mechanisms which require a
> pool of routable IPv4 addresses.
Agreed. This will get added.
>
> >> The Enterprise network will have to support the
> coexistence of IPv6
> >> and IPv4, to support legacy IPv4 applications and nodes. The
> >> Enterprise user has the following choices for that coexistence to
> >> consider today.
> >>
> >>
> >
> >Does this mean "of IPv6-only and IPv4-only"? This is what
> is implied
> >by the definition of terms at the start of the document. Do we
> >actually mean "IPv6-capable and IPv4-capable" or, in the language of
> >the definitions, "IPv6, IPv4 and IPv4/IPv6" applications and nodes?
> >
> --> In my opinion, coexistence means interoperability between
> every kind
> of node and application that enterprise requires. Again, not
> sure if the different kind of nodes and applications should
> be distinguished in this scope.
I hope that differentiation is not required and agree with you.
>
>
> --> Section 4 is named "Support for Legacy IPv4 Nodes and
> Applications"
> however applications are not mentioned in this section. So,
> maybe it should be named "Support for Legacy IPv4 Nodes".
Interesting point. Need to think.
>
>
> --> maybe 4.1 and 4.2 cases could be more general if they are
> considered as:
>
> 4.1. Communicating IPv4 networks through IPv6 zone
> 4.2. Communicating IPv6 networks through IPv4 zone.
Yep.
>
> These two cases include that end-point nodes are dual stack
> or single stack
> and tunnels can be started from end-point nodes (dual stack) or from
> intermediate router (end point nodes are single stack).
> Besides, I think
> it is more coherent with the name of the subsection 4.3, "IPv6
> communication
> with IPv4" which is about connecting networks, not nodes.
Good input and words for us too. Thanks.
Thanks
/jim
>
> Regards,
>
> eva
>
> --
> Eva M. Castro <eva@gsyc.escet.urjc.es>
>
>
>
>
>
>
>