Ran Atkinson wrote: >>> (NAT/NAPT or LocatorRewriting or pick a another name) performed >>> inside a site's border router can enable a site to multi-home >>> effectively without any de-aggregation (i.e. without any impact on >>> the DFZ RIB or DFZ FIB). Existing mechanisms that enable >>> distributed firewalls to share session state would clearly also work >>> to share NAT session state among a set of site border routers, if >>> that were desired.
Scott Brim wrote: >> Multihoming on different providers? If an endpoint appears to have >> two different addresses due to being NATted onto two different >> providers, and routing changes so that packets switch from flowing >> through one provider to flowing through the other one, connections >> break. Brian Carpenter wrote: > Certainly. So if you were product manager for a highly reliable > distributed application, I'm sure you would insist that it was > coded to detect permanent transport failures and try alternative > addresses. That may not be elegant computer science but it's one > way that the Internet routes around damage. Tony Li wrote: > And that again results in trying to fix the routing architecture at > layers 7 and 8. You'll pardon me if I don't find that a > particularly satisfying 'solution'. I agree. Furthermore, it would be in violation of Herrin's Architectural Principle: http://www.irtf.org/pipermail/rrg/2008-December/000620.html Any problem can be solved at the application layer for a single application. Architectural solutions solve the problem at a lower layer so that it stays solved for *all* applications. This is a concise statement of good design principles which have long been known in many fields - including networking, software, building design and urban planning. - Robin _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
