Re: draft-hain-templin-ipv6-localcomm-03.txt

[Fred Templin <[e-mail]>]

Erik,

Erik Nordmark wrote:

>I have some on draft-hain-templin-ipv6-limitedrange-02.txt
>which appear to apply to the new draft even though it has removed
>the explicit reference to the need for a local address format
>from the title and abstract/intro.
>
>The summary is that I think we need a discussion about the needs of
>sites in general and these "active sites" in particular, but this
>draft doesn't seem to do that. Details below.
>
>Comments on draft-hain-templin-ipv6-limitedrange-02.txt
>
>The document seems to make the case that there is a set of
>interested goals and requirements related to "active sites",
>and I agree that this is something that we need to understand
>better.
>
>But the document from the outset, and in every other paragraph,
>assumes that any and all solutions to to making such sites work better
>involve defining some local address space. As a result the document reads
>as an attempt to justify a particular solution to the problem, and not
>as a balanced attempt to understand the issues relating to such sites and
>the goals related to making them work better.
>

We have received this particular comment many times and from
many different sources. The document has undergone significant
modifications based on specific comments in a best effort to eliminate
any perceived links to any specific solution alternative(s).

If you are still seeing the document as advocating a particular solution
alternative, please send specific text change suggestions as that is not
the document's intention.

>Thus I think we instead need goals for "active sites" with local and 
>global communication (taking into account that for different sites the 
>relative importance of global and local communication is likely to be 
>different).
>
>For those that think that there can't exist solutions which don't use
>a local address space I offer 4 different possible approaches where only 1
>use local address space (and another uses local locators which are invisible
>to the applications):
> - unique local addresses plus TBD mechanisms for name resolution (DNS)
>   and application impact; a rather large TBD IMHO. See Keith's recent mail.
> - for sites which are naturally part of some larger site using
>   Nemo (or just tunneling with delegated global addresses from the
>   larger site) just work. This approach doesn't handle
>   all types of active sites, but it doesn't seem to require any additional 
>   standardizion - running DHCPv6 prefix delegation over IPv6-in-IPv6
>   tunnels seems to be sufficient.
> - relying on some multi6 solution (see draft-nordmark-multi6-noid and
>   draft-nordmark-multi6-sim as existance proof that such solutions can be 
>   created, if nothing else [Thus this is not an endorsement that I think
>   those particular approaches are the best.])
>   by using global locators plus standard filtering, renumbering the *locators*
>   on attachment in a new place (keeping the old locator prefix alive while
>   the new locators are propagated). 
> - as above but also using unique local *locators* to make the locator
>   renumbering smoother.  This introduces the need to be able to discover
>   those local locators in addition to discovering the global locators.
>I hope the above list shows that defining some unique local address space
>is not the only approach to making "active sites" work better.
>
>
>Is anybody interested in producing a document about "Issues and goals
>for active sites" without assuming that the solution is some new address
>space?
>

Yes - me. Defining issues and goals for active sites w/o assuming a
solution alternative is exactly what we are striving to accomplish in
the 'hain-templin' document. If you are not seeing this, please send
specific text change suggestions.

Fred
[e-mail]

>FWIW I find it odd that while the multi6 problem statement is related to 
>the overloading of location and identity in the IP address space (which
>made sense 25 years ago) and folks are trying to figure out how
>to add a layer of indirection to solve that problem, the local
>address discussion is about overloading addresses with yet more functionality
>and semantics.
>
>   Erik
>
>
>  
>



--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------