Re: [rrg] Constraints due to the need for widespread voluntary adoption

[Patrick Frejborg <[e-mail]>]

On Thu, Dec 3, 2009 at 8:13 PM, Noel Chiappa <[e-mail]> 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