Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)]

From: [email-masked] (Noel Chiappa)
Date: Thu, 22 Apr 2010 17:38:42 -0400 (EDT)

>> if you'd simply like the interface between the ETR and the internal
    >> routing to be more dynamic, so that the mappings are less likely to
    >> contain incorrect information

    > the mapping information has nothing to do with the reachability between
    > a given ETR and a given EID.

Your query does raise an interesting architetural question, which is: 'what
channels are available in LISP, architecturally, to convey information about
reachability of EIDs from an ETR'. The thing is that mappings are not
supposed to contain very dynamic information - which may have been your
point?

However... it ETR E1 is up, but temporarily cannot reach some of the address
ranges it is advertizing, it currently has no semantic channel, _other than
issuing an updated mapping_, to propogate that information to its
correspondent ITRs.

That's not necessarily bad, in purely engineering terms: its correspondent
ITRs should quickly (via mapping versioning) find out that a new mapping is
available, and load it. I do concede it's slightly ugly in architectural
terms.

Part of the problem here is that LISP is in this architectural netherworld
between a pure mapping system and a pure routing system; it has some aspects
of both (and the problems of both).

(The routing stuff is in part because of limitations in the current routing
architecture, for which it's trying to compensate, but that's neither here
not there...)

Trust me, this drive me bananas; in fact, the whole LISP architectural
approach causes me a certain amount of grief. Unfortunately, I don't think we
have the luxury of a clean slate, one in which we can produce a nice, clean,
elegant design. We have to work with the lemons that are already globally
deployed, no matter how ugly the result...

    > We want the LISP spec explicitly spell out the semantics of {RLO[C],
    > EID} information carried in Map-Replies, and specifically whether this
    > information carries any indication of whether a particular EID is
    > reachable from a particular RLOC.

Ah, got it. Well, as things stand, if an ETR R1 advertises a mapping from R1
to EID range Ex, it's making an assertion, on which others will rely, that it
can 'reach' Ex.

    > If this information does carry the indication of whether a particular
    > EID is reachable from a particular RLOC, then we want the LISP spec to
    > explicitly spell out (a) how the xTR that sends this acquires it (as
    > the information may be for RLOCs that are different from the xTR)

That may be biting off more than we want to chew right at the moment. E.g. Do
we disallow static configuration? Suppose it's getting it from the IGP - do
we have to list how that works? I'd rather just leave it exactly the way I
put it above ("if an ETR R1 advertises a mapping from R1 to EID range Ex,
it's making an assertion, on which others will rely, that it can 'reach' Ex")
and leave it at that: it makes crystal clear what the responsibility of R1 is
when it advertizes a mapping for an EID range.

    > and (b) how can one invalidate this information when (at some later
    > point) the EID is no longer reachable from the RLOC.

That one doesn't bother me much - as I said, it issues a new mapping, and
people will acquire that quickly because of the versioning.

But you're probably right that this area could use some clarification.

    > If this information does not carry the indication of whether a
    > particular EID is reachable from a particular RLOC, then we want the
    > LISP spec to explicitly spell out the procedures to determine whether
    > the EID is reachable from the RLOC

Why can't we just re-use whatever text BGP currently uses to specify what a
router has to do to ensure that an address range is reachable from it, before
it's allowed to advertize that address range? Do we currently have stringent
standards on what a router has to do before it advertizes reachability?

The thing is that the term "reachability" can have a large range of
'dependability', so what exactly does it mean to say that 'X is reachable
from R' anyway? If R is a router with an explicit route to X, is X
'reachable' from R or not? How about if R is a router which shares a hardware
network with X, but R isn't pinging X to make sure it _really_ can reach X?

I'm not trying to be a PITA here, but the term 'reachable' has historically
been ill-defined in the IETF, except in the bottom line sense (as in,q 'when I
try it, it works'), and I'd like to do better on saying just what it means,
i.e. just how much one can rely on it if some node says 'x is reachable from
me'.

    > (in the presence of multiple RLOCs for the same EID).

Synchronization of mapping information between multiple ETRs (which is what I
gather you are alluding to here), and mechanisms to perform that, are
currently an open area - in part because currently it's all manual.

Any chance you can design something, and write a spec? :-)

	Noel