[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: reqs for local addressing OR requirements for SL replacement? [Re: Accept hain/templin draft as wg item?]



Pekka Savola wrote:
> Hi,
> 
> As some others have also commented, I have serious concerns about the 
> hain/templin draft.

Thank you for providing constructive text, rather than simply complaining.

> 
> An observation:
> 
> This document seems to take for granted that local-use addressing is 
> needed.  Moreover, it lists requirements for every possible 
> case where 
> local-use address could be applied to (and, not for example, 
> those cases 
> where the local-use addressing is really necessary).

Necessity is both the perception of the network manager in trying to
implement a local policy, and the availability of alternatives that actually
fit all of the local constraints. 

> 
> Process questions:
> 
>  1. Shouldn't we first see the requirements for site-local 
> replacement (and other issues) and not jump straight to the 
> requirements for local addressing?

I don't understand the question. My original draft started from the premise
that the WG should at least have the requirements for local addressing
before deciding that any given technology is either acceptable or
unacceptable. Site-local is a specific technology that meets many of the
needs of local addressing, but creates other problems through its ambiguity.
Getting rid of ambiguity does not remove the requirements for local
addressing.

> 
>  2. Then if we see that local addressing is required to do X, 
> see that 
> this document covers X adequately?

If the goal is to design specific approaches for every scenario, then this
suggestion would be appropriate. The goal of the requirements document at
the moment is to aggregate multiple needs under a single technical approach.
If the WG decides that multiple approaches make more sense, then there will
need to be multiple requirements documents.

> 
>  3. Not consider those not listed in the sum-of-all-X at all? (or at 
> least, make the separation what scenarios require specific features 
> clearer)?

I am not sure what you are trying to say, but I think this is a continuation
of 2.

> 
> I don't send in more detailed comments on the draft, because 
> I pretty much 
> disagree with everything it says.  

I understand your network does not have these requirements, and if we
required everyone to implement local addresses I could understand some
degree of concern. What I don't understand is why you believe it is
appropriate to tell another network manager that his stated requirements are
invalid.


> If we explicitly make the 
> decision that 
> local-use addressing is needed in some scenarios, I might 
> accept that and 
> review it again with that in mind.

See 2 above.

> 
>  Just two notes:
> 
>  3.1 -- "Network managers have stated, and historical experience has 
> shown, that there is a need for addresses that do not require public 
> registration."  
>  ==> there is no supporting evidence of this expect vague 
> statements.  
> Please be more explicit as I don't see how we can take this for given.

Chasing down quotes is not appropriate. If you want to see more text about
people grabbing random space from documentation or currently using 1./8, I
suspect we can come up with that.

> 
>  3.2 "Applications require addresses that remain stable during 
> intermittent connectivity, site mergers, ..."
>  ==> it is not clear what you mean with stability, i.e. what 
> the _real_ 
> requirement is.  Connection survibability, or something else?

See my note this morning about solving the right problem. Applications
frequently fail if the addresses are changed out from under them. This is
not a requirement, but a fact supported by empirical evidence. The real
requirement is that local applications continue to function even if the
external connectivity is intermittent or changing. I know you have offered
ways to mitigate the problem, but they all come with constraints that, while
appropriate for your network environment, do not meet the needs of other
networks. 

It appears you would rather do targeted engineering for individual
scenarios. We can take that approach, and will likely end up with a variety
of technologies that people then need to figure out which one(s) apply. At
the same time it is very likely that there will be a suppression of many
requirements, because the participants are either not vocal enough, or don't
represent a large enough segment of the community to deserve valuable WG
focus. Forgive me if I consider suppression of requirements to be in direct
conflict with providing solutions.

Tony



> 
> 
> On Fri, 22 Aug 2003, Fred Templin wrote:
> > Folks - do we have consensus to accept this document as an IPv6 wg 
> > item (see below)?
> > 
> > Fred
> > ftemplin@iprg.nokia.com
> > 
> > 
> > Subject:
> > I-D ACTION:draft-hain-templin-ipv6-limitedrange-01.txt
> > From:
> > Internet-Drafts@ietf.org
> > Date:
> > Thu, 14 Aug 2003 10:27:13 -0400
> > 
> > To:
> > IETF-Announce: ;
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > 
> > 
> > 	Title		: Addressing Requirements for Local 
> Communications 
> >                           within Sites
> > 	Author(s)	: T. Hain, F. Templin
> > 	Filename	: draft-hain-templin-ipv6-limitedrange-01.txt
> > 	Pages		: 19
> > 	Date		: 2003-8-14
> > 	
> > The IPv6 addressing architecture specifies global and local-use 
> > unicast addressing schemes, but provides no operational 
> guidelines or 
> > requirements for their use. There is a strong requirement for 
> > addressing to support local communications within sites. Of special 
> > interest are 'active sites', e.g., sites that are 
> > intermittently-connected or disconnected from the global Internet, 
> > sites that frequently change provider points of attachment, 
> sites that 
> > temporarily or permanently merge with other sites, 
> multi-homed sites, 
> > etc. This memo will discuss addressing requirements for local 
> > communications within sites.
> > 
> > A URL for this Internet-Draft is: 
> > 
> http://www.ietf.org/internet-drafts/draft-hain-templin-ipv6-limitedran
> > ge-01.txt
> > 
> > To remove yourself from the IETF Announcement list, send a 
> message to
> > ietf-announce-request with the word unsubscribe in the body 
> of the message.
> > 
> > Internet-Drafts are also available by anonymous FTP. Login with the 
> > username "anonymous" and a password of your e-mail address. After 
> > logging in, type "cd internet-drafts" and then
> > 	"get draft-hain-templin-ipv6-limitedrange-01.txt".
> > 
> > A list of Internet-Drafts directories can be found in 
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	mailserv@ietf.org.
> > In the body type:
> > 	"FILE 
> /internet-drafts/draft-hain-templin-ipv6-limitedrange-01.txt".
> > 	
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> > 		
> > 		
> > Below is the data which will enable a MIME compliant mail reader 
> > implementation to automatically retrieve the ASCII version of the 
> > Internet-Draft.
> > 
> > 
> > 
> > --------------------------------------------------------------------
> > IETF IPng Working Group Mailing List
> > IPng Home Page:                      http://playground.sun.com/ipng
> > FTP archive:                      ftp://playground.sun.com/pub/ipng
> > Direct all administrative requests to majordomo@sunroof.eng.sun.com
> > --------------------------------------------------------------------
> > 
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
> 


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------