On 3/25/08 10:20 AM, Noel Chiappa allegedly wrote:
> > From: Brian E Carpenter <[EMAIL PROTECTED] >
>
> > That seems to assume that a failure will produce a map change. I expect
> > a failure to produce a change in the routing tables, but why should a
> > (temporary) failure produce any change in the map?
>
> Because it's a lot less overhead to the system (overall) to change a mapping
> entry, and then change it back when the failure has been remedied?
>
> Of couse, if the failure affects *lots* of entries, then it's cheaper overall
> to have the routing deal with it. However, it all depends on the exact nature
> of the failure (which wasn't specified).
>
> Unfortunately, we don't have any way (or tools) that would allow us to decide
> whether it made more sense to handle something in one subsystem (mapping) or
> another (path-selection).
Help me understand. I thought that when Brian said "routing" he was
referring to routing between routed locators, within the topologically
aggregated core, i.e. for example ITRs and ETRs.
I don't see how you can have a choice between fixing failures in mapping
or in routing. They are orthogonal. The mapping system gives you a set
of routed locators that you can send your packet toward in order to get
to a destination that is not routed. Routing gives you paths to
anything that is in fact "routed" (i.e. a path can be discovered via
routing). So how you deal with a failure depends on the failure, but
you don't have a choice.
agree
So clearly I missed what you meant.
> > I would expect this would cause the routing algorithm to be told about
> > the failure and to find an alternative path involving the same or an
> > alternative map entry.
Suppose there is a failure of an intermediate router, between two
domains in the DFZ. They know nothing of mapping/unmapping, and mapping
knows nothing of them. This is handled by BGP right now. Are you
suggesting that changes in BGP paths across the DFZ should be
communicated to the mapping points, or perhaps to the mapping
distribution/discovery system, so that they can change their preferred
mappings?
Or, suppose there is a failure of a de-mapping point (ETR). At least in
LISP, that will very probably not be seen in mainstream BGP -- its RLOC
is just a single address in PA space. Any failure here is not a concern
of mainstream routing, and will be taken care of in the mapping system.
On 3/25/08 5:54 PM, Brian E Carpenter allegedly wrote:
> On 2008-03-26 03:49, Xu Xiaohu wrote:
> > How about having the authoritative ETR to update the status of the EID-
> > >RLOC
> > mapping in the mapping system automatically according to the connectivity
> > between the ETR and the site network, while having the routing system to
> > determine the reachability of the ETR?
>
> However, we want to avoid map flapping by design (you will remember
> that BGP4 route flapping was a big problem).
>
> I would set a quite different timescale for status updates
> in the mapping system - if we followed your suggestion, I would
> suggest that a loss of connectivity should persist for
> a long time, maybe 30 minutes, before the ETR changes the
> map. I'd expect BGP to handle any outages on a shorter timescale.
> If we set the timers in the mapping system to the same order
> of magnitude as those in the routing system, we're likely
> to see some horrible interactions between map flapping
> and route flapping.
The current LISP trick is the "locator reachability" bits piggybacked on
data packets. You can separate operational changes (the kind subject to
flaps) from configuration changes. There is no need for mappings to
change due to operational problems, nor timers etc. I still don't
understand why you think BGP would be involved. Are you presuming that
we are going to run BGP between nodes that are not globally routed? Why
would DFZ BGP even know that an ETR was dead?
Perhaps it would be a good approach to set, for each mapping entry, a timer and
let each end host (or ETRs) send mapping updates to the mapping system?
Hongbin
