Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared

[Dino Farinacci <dino at cisco.com>]

> LISP-01 (02 is the same) has a bunch of stuff about reachability,
> including, for instance:
>
> |  6.3.  Routing Locator Reachability
> |
> |  There are 4 methods for determining when a Locator is either
> |  reachable or has become unreachable:
> |
> |  1.  Locator reachability is determined by an ETR by examining
> |      the Loc-Reach-Bits from a LISP header of a Data Message
> |      which is provided by an ITR when an ITR encapsulates data.
> |
> |  2.  Locator unreachability is determined by an ITR by receiving
> |      ICMP Network or Host Unreachable messages.
> |
> |  3.  ETR unreachability is determined when a host sends an ICMP
> |      Port Unreachable message.
> |
> |  4.  Locator reachability is determined by receiving a Map-Reply
> |      message from a ETR's Locator address in response to a
> |      previously sent Map-Request.
>
> Does any of this apply to LISP-CONS?  Each of these involves an
> ETR or an ITR in doing something much more complex, involving the
> central CPU etc. (and also more open to security problems) then
> simply encapsulating or decapsulating packets.

Locator reachability is done outside of the mapping service. So once  
an ITR gets a mapping, from any database mapping service, it  
determines reachability from either ICMP unreachables or the loc- 
reach-bits from returning packets.

> Does it mean that service restoration when an end-user wants the
> packets to go to an ETR in ISP-B instead of the ETR in ISP-A are
> all controlled by changing the mapping data? (This is the Ivip
> approach.)

No, the mapping data tells you want ETRs are configured for an EID- 
prefix, regardless if they are up or down at the time the mapping  
reply is received by any ITR.

Dino

_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram