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

Re: [RRG] map change due to a path failure?

On 3/25/08 10:20 AM, Noel Chiappa allegedly wrote:

    > From: Brian E Carpenter <brian.e.carpenter@gmail.com>

    > 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. 

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? 

Scott


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg