On Thu, Dec 3, 2009 at 8:13 PM, Noel Chiappa <[email protected]> wrote: > > E.g. a particular system might allow inclusion of multiple ETRs directly in > the (identity->location) mapping, such that detection of a dead ETR allows an > ITR to switch to a backup ETR without bothering to get a new mapping. Etc, > etc... > Hi Noel,
here I do get headache - I think this is an architectural question. In order to get this working you need to combine two architectures - the routing architecture and a mapping database architecture . You have a mapping database but that database have no information about an ETR's availability (I'm comparing to current DNS database) - unless you integrate the current routing architecture with the mapping database. If the link between the ETR and DFZ is lost the mapping database need to know that, i.e. the routing protocol must inform the database. Then the database needs to update all the members of the mapping database, after that the database members needs to inform their ITRs so that the ITRs that have ongoing sessions to the affected ETR will flush their cache and replace the entry to the secondary ETR. So you will have a redistribution from routing protocol -> mapping database -> routing protocol, instead of having BGP churn you could have cache churn instead. If you prefer to avoid the redistribution you could let the routing architecture take care to inform the ITR of ETRs availability. But that will have negative impact on the DFZ. Today the EID in a multi-homing solution usually creates a /20 prefix - regardless of how many ISP connections it uses. But by using ETRs each attachment point will create a /32 entry in the DFZ - unless the ISP are aggregating. But when the ISP are aggregating the ITRs have no clue if the ETR is available or not. So it seems that you have to do a redistribution of routing protocol -> mapping database -> routing protocol to inform the ITR of the availability of ETRs And the current DNS system is quite slow to update - what happened in Sweden was an engineering issue but to get the services restored was due to the architecture of the system, one hour or longer is really not what multi-homed enterprises are expecting in failure cases http://blog.internetnews.com/skerner/2009/10/sweden-se-goes-offline-due-to.html Or do I miss something ? -- patte _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
