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

RE: Architectural approaches to multi6




I would NOT agree that there are no solutions in routing.
That said, I think that a solution MUST involve having
the transport NOT use the locator as a portion of the
pseudo-header.  So at the very least, there must be host
changes.

I believe that we must solve the failure of non-last-mile
links, including ISP links or even site-internal links.
We cannot do this through signaling our routing and
be scalable, so there must be some way for the 
correspondent host to try multiple locators and figure
out which locators currently work. 

Tony


|    -----Original Message-----
|    From: Dmitri Krioukov [mailto:dima@krioukov.net] 
|    Sent: Thursday, March 27, 2003 2:16 PM
|    To: multi6@ops.ietf.org
|    Subject: RE: Architectural approaches to multi6
|    
|    
|    After browsing through this thread I'd like
|    to ask the following question: how many people
|    on this list would agree that a scalable
|    *engineering* solution to the multihoming
|    problem can be based neither on routing as we
|    know it today nor on any future improved and
|    superior routing architecture (if such an
|    architecture is based on the graph-theoretical
|    network representation)? (I assume that any
|    address binding mechanisms (similar to DNS)
|    are not considered as a part of routing.)
|    
|    Also, a somewhat related question: is handling
|    failures beyond the links between the multihomer
|    and its transit provider (such as failures of links
|    between providers and the rest of the world) a
|    requirement? That it is not is an implicit assumption
|    of my first question. If it is (like it seemingly
|    follows from the requirement ID but not from Christian's
|    experiment), then a solution can only be routing-based,
|    and, hence (how many would agree?), it cannot be
|    scalable.
|    
|    thanks,
|    --
|    dima.
|    
|    
|    
|