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

RE: local vs. nonlocal address stability ( was Re: apps people? )



Tony,

simply from these 300+ mails I just read and selected which to respond
to SLs are simply not baked and not good for the market to use them.
Putting on deployment hat and all this discussion from the most
knowledgeable people on this issue here SLs must die and new pheonix is
required.  But to tell a customer to use these is not honorable at this
point. My input now as individual person when asked is DO NOT USE SLs at
ALL.  

/jim

> -----Original Message-----
> From: Tony Hain [mailto:alh-ietf@tndh.net] 
> Sent: Friday, August 08, 2003 7:39 PM
> To: 'Keith Moore'
> Cc: lear@cisco.com; ftemplin@iprg.nokia.com; ipng@sunroof.eng.sun.com
> Subject: RE: local vs. nonlocal address stability ( was Re: 
> apps people? )
> 
> 
> Keith Moore wrote:
> > ...
> > I think the requirement is better stated that apps (not just
> > local apps) continue to operate independent of any normal 
> > address change events, whether or not at the SP edge.
> 
> Nice goal, but requires changes to transport to pull it off. 
> The point is to deliver service long before that will happen.
> 
> > 
> > > I don't understand the point of changing the scenario.
> > 
> > I don't understand the point of stating the scenario in
> > narrow terms in order to argue for a problematic solution 
> > with limited applicability.
> 
> To bound the problem space to something that can be 
> accomplished without changes to transport. Yes it has limited 
> applicability, but that is not a failure, and the problems 
> only arise when the mechanism is used outside the scenario. 
> For those cases, there are other mechanisms.
> 
> > ...
> > > I never said delay working on alternatives.
> > 
> > No, but your insistence on SL is having that effect.
> 
> Clearly you are not reading the documents or the mail 
> carefully. I am not insisting on SL. The Hinden draft is not 
> SL, and meets the requirements that have been raised for 
> limited-range.
> 
> > 
> > > The problems you have
> > > raised in the past stem from multi-homing, so stop claiming that a
> > > limited range prefix causes them.
> > 
> > I've raised lots of problems regarding scoped addresses, only
> > some of which have to do with multi-homing.  Since scoped 
> > addresses are being used to justify forcing hosts and apps to 
> > rely on address selection (with its inherent
> > problems) to a much greater degree than would otherwise be 
> > necessary, it makes sense to focus attention on the dubious 
> > assumptions behind scoped addresses.
> 
> From my recollection, the ones that are not due to 
> multi-homing are simply wishes that filtering in the network 
> would go away. 
> 
> > 
> > > > However if you can identify a significant class of apps that 
> > > > really is inherently local and really has a greater need for 
> > > > address stability than other apps, I can propose a solution to 
> > > > this problem with essentially no impact to apps 
> (especially those 
> > > > that don't need this extra stability), with small 
> impact to hosts 
> > > > and routers, and which doesn't impose the notion of a single 
> > > > "local" scope either.  The reason I haven't proposed 
> this yet is 
> > > > because IMHO it doesn't solve the real problem (we need a 
> > > > reasonable degree of address stability for ALL apps), it adds 
> > > > complexity that would be unnecessary if the real problem were 
> > > > solved, and because it would distract energy from 
> efforts to solve 
> > > > the real problem.
> > > 
> > > Which is the ultimate failure here, there is no single
> > 'real problem'.
> > 
> > True enough - it's just a question on how large you want to
> > draw the circle. 
> > The trick is to draw the circle in such a way that the 
> > solutions are inexpensive and work well.  Usually this 
> > happens somewhere near (though not precisely at) a 
> complexity minimum.
> 
> Again you are looking for a single solution ('the circle'). 
> There are multiple options here and they solve different 
> problem sets. If we really were forced to come up with a 
> single solution, we will be back at nat as the lowest common 
> denominator.
> 
> > 
> > > The
> > > limited-range document describes a set of requirements (read that:
> > > real problems), and there are probably more. In keeping, 
> > there is no
> > > single 'real solution'. Manual configured filtering of PA 
> meets one
> > > set of needs, auto-configuration of limited range prefixes meets 
> > > another set of needs, PI meets yet another set of needs, 
> and these 
> > > sets of needs all overlap in different ways. Rather than 
> > persist with
> > > FUD to prevent one set of problems from being solved, we
> > need to get
> > > on with defining and deploying the mechansims to solve 
> each of them.
> > 
> > No, it doesn't follow.   What you suggest would be reasonable 
> > if the various
> > mechanisms were not too costly, did not conflict with one
> > another, and did not preclude development of better solutions.
> 
> Nothing here conflicts with or prevents other solutions. The 
> fact that a limited range address space exists and is used in 
> some networks does not at all impact an individual network 
> manager from using manual configuration from a different 
> prefix space. If a PI approach existed, it would not preclude 
> use (or meet the need) of another space that is known to be 
> excluded from the global routing tables. The only thing that 
> is preventing development of 'better' solutions is spending 
> time trying to kill ones that are achievable in realistic 
> timeframes. If by some magic a killer solution to all the 
> problems showed up, it would easily push the complexity of 
> multiple solutions out of the market. We can't be sitting 
> around waiting until the magic happens. 
> 
> > 
> > But again, we can solve the local stability problem if there
> > really is a significant use case for it.  
> 
> So solve the requirements and there will not be a need for 
> other approaches. Until then, this filibuster is delaying 
> network managers from deploying IPv6 in a way that will meet 
> their requirements.
> 
> Tony
> 
> 
> --------------------------------------------------------------------
> 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
--------------------------------------------------------------------