Re: [RAM] Re: the separation of ID/RLOC

[Dino Farinacci <dino at cisco.com>]

> Informing a remote mapping function about locator alternatives is just
> one out of three mechanisms that are necessary.  As said in my  
> previous
> email, you also need...
>
> - a provider selection mechanism locally in an edge network that
> monitors provider connections and decides when it is time to  
> switch, and
>
> - a mapping update mechanism that tells remote mapping functions / 
> when/
> to switch to /which/ alternative locator.
>
> These two additional mechanisms are the ones most critical in terms of
> delay and packet loss.  I attended to this more in my previous email.

The LISP-01 draft documents the following design:

o Map-Replies contain locator-sets for an EID-prefix. Along with each  
locator is
  a priority and weight. This is used so either the ETR can force  
the ITR what
  locators to use or the ETR can allow an ITR to select the locators  
it wants within
  the scope of locators the ETR allows.

o The Map-Replies do not convey reachability status of the locators.

o The ITR, when it encapsulates packets sets the loc-reach-bits field  
to indicate
  which locators for its site are currently reachable. The loc-reach- 
bits is a bitfield
  that defines the relative location of a locator record in a Map- 
Reply. Currently the
  bitfield is 12-bits to convey reachability for 12 locators for a  
given EID-prefix.

o The ITR at a site knows reachability of it's own locators based on  
the IGP. And
  typically, the ITRs will be close to the failures, so will be able  
to have this
  info sooner than any other node in the network. As long as packets  
are being sent
  out of the site, any receiving site will get up to date  
reachability of locators.
  Failures that are close the ITR include 1) ITR failure, 2) CE-PE  
link failure, and
  3) PE router failure.

o When an ETR detects a loc-reach-bit setting that changes from 1 to  
0, it will
  not use the locator associated with that bit-setting.

Also, using NERD or CONS as a database mapping service, the mapping  
entries within them also do not provide reachability status.

This allows us to scale the Tony Li rule of "state * rate". Where we  
know the variable 'state' will be very large so we must keep the  
value of 'rate' small. Keeping reachability status out of the mapping  
database allows us to do that.

Dino


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