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

["Hongbin Luo" <hbluo@bjtu.edu.cn>]

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

 

          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