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

Moving backward [Re: Fourth alternative [was Re: Moving forward ....]]



Michael,

Sorry, but I think you are dead wrong, and you are moving us backward
and risking another year or two of wasted time.

There is nothing new in this whole argument. As I pointed out
in the IAB architecture session in Vienna, these issues have been
around for 6 years at least. We know what we can do with today's
routing mechanisms, today's renumbering mechanisms, and today's
security mechanisms, and that leads *directly* to the requirements
in the Hain/Templin draft, and IMHO *directly* to the solution in
the Hinden/Haberman draft.

I think we are way past the point in history where it is fruitful to
make the sort of free-space wish-the-world-was-different analysis
you are advocating. Hinden/Haberman leads to simple, straightforward
changes to shipping code and that's all we can afford now.

   Brian

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <brc@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK

Michael Thomas wrote:
> 
> Fred.Templin@nokia.com writes:
>  > If you think the document has a scoping issue (no pun intended),
>  > then let's discuss that with a measured tone.
> 
> Yes, I think it has scoping issues. A name change,
> for starters. It should first lay out requirements
> of network operators, etc in terms of what they
> need to accomplish not how they can accomplish it.
> Take as a very large for example, address
> stability. That's not the requirement, per
> se. What they want is for topology tweaking to not
> adversely affect running applications. However
> protocols such as TCP are incapable of sustaining
> sessions across address changes which is typically
> needed when you want to move topology around.
> That's the reason I say that "stability" is a
> solution, not a requirement. Keeping addresses the
> same is *a* way of keeping applications from
> breaking, but not the only one. Mobile IP
> obviously comes to mind, and there are other ways
> we could envision like Fred's attempt at
> operational renumbering.
> 
> Another example is your "well known prefix". I'd
> think that the requirement is that certain
> services and/or classes of devices need to be
> isolated and/or invisible from the other parts of
> the net. A well known prefix is a way to do that,
> but it doesn't necessitate local scope and again
> isn't the only way to wall stuff off.
> 
> I really don't want to drag this into a meta
> argument about the merits of various solutions,
> but only to point out that the entire document is
> structured in a way that the answer is foregone.
> That's not what we need right now. We need
> something that tries to be unbiased about the
> ultimate compromises we're going to have to make
> by saying what we want (requirements), what the
> possible frameworks are for addressing the
> requirements, and most especially what their
> possible downsides are. We don't need boosterism
> which tries to paper over the warts; all possible
> solutions have problems, what we need is an honest
> evaluation so that we can decide which path is the
> least objectionable.
> 
>                 Mike
> --------------------------------------------------------------------
> 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
--------------------------------------------------------------------