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: Wed, 21 Apr 2010 23:28:23 -0400 (EDT)

> From: John Scudder <[email-masked]>

    > This was covered in Comment 4 of the message Yakov sent to the list:

    >> Suppose a certain EID's mapping entry ... lists the RLOCs of two ETRs,
    >> ETR1 and ETR2. Suppose that later on due to connectivity issues within
    >> the site, ETR1 is able to reach the EID, but ETR2 is not. Is there
    >> some means by which traffic is expected to reliably reach the EID in
    >> this case?

I was trying to get caught up enough in my email to answer this the first
time it was asked, but I guess this time will do... :-)

Those on the LISP design team will recognize this as the issue "EID
reachability as opposed to RLOC reachability" from the LISP 'Outstanding
Issues' list.

(I should explain here that I have a long list of 'Outstanding issues' with
LISP; I have not bothered to mention them to the WG, because they almost all
have the characteristic that the best fix does not require any _protocol_
changes, so the fix can be deployed at leisure - and, more importantly, the
fix can usually be deployed incrementally, with no need to co-ordinate the
deployment of the fix. I.e. we can change the spec, to add algorithms to deal
with the issue, and it can be deployed in each LISP device independently.
Since there are higher-priority things the WG needs to focus on, I have
therefore placed those items in a 'look at later' status.)

Anyway, as some other posts have sort of pointed out, this issue of endpoint
reachability is something that the existing routing/etc architecturs doesn't
really handle, and that's the main reason it has not been addressed.

In general, an external router, RE1, which is advertising an address range
into the core has not verified that all the addresses covered by that block
are _actually reachable_, i.e. that it can successfully exchange packets with
every addresss in that range. (Which is the meaning of "reachable" we are
talking about here, I assume. I should mention here that to many LISP people,
'reachability' has come to mean 'we actually tried it to make sure it
_really_ works', not just 'some table entry somewhere says it _should_
work'.).

Indeed, with a stub AS which has a static config of what to advertize, a
router may be advertizing an address range which it knows, from IGP
information, it cannot reach. Or if it has a static internal route, it may
advertize that externally without knowing if those destinations are
reachable; some intermediate internal router may have failed.

And even if the IGP tells RE1 it can get to a particular address range, that
may still be incorrect. E.g. if an internal router, RI1, is telling RE1 that
RI1 can reach a particular range, but there is some sort of defect which
prevents RI1 from reaching a particular address in that range (perhaps a bad
port on a hub, or something like that), RE1 has no way of knowing that.

Since this limitation seems to already be generally acceptable today, we did
not think it desirable to add the extra complexity/overhead which would be
needed in order to 'solve' a problem that apparently the world is not
clamouring to have solved.

Perhaps you had in mind a weaker version of 'EID reachability'? (Bearing in
mind that the term means different things in different communities.) Did you
simply mean 'an ETR should not advertize an address range in a mapping unless
it has indications, from the IGP, that it can actually reach that address
range'?

I'm not sure that's really a 'LISP protocol' issue, any more than the
analogous BGP behaviour is a BGP issue; yes, it is an issue for how the
interface between BGP and the rest of the router is specified (i.e. does one
even allow static routes to be configured, or does one only allow BGP to
adversize address blocks which it has live internal dynamic routes to)?

Similarly, 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, that's fine, but it's more of a 'LISP
interfacing/usage specification' thing.

If on the other hand you really did mean 'an ETR should not advertize a
mapping for an EID X unless that EID is reachable from the ETR' (using the
strong meaning of "reachable"), that's something I can discuss at some
length. (I have thought that through, in some detail, but examining the
problem at an architectural level - i.e. not specific to LISP, the same
tradeoffs/constraints would apply to any packet-switching system trying to
implement this functionality.)

But I won't launch into that until I'm sure that's what you're really trying
to do.

	Noel

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 22 Apr 2010 13:01:15 -0700

Noel,

> therefore placed those items in a 'look at later' status.)

Do you have detailed solutions to all of the outstanding issues in
your list ? As if not, then your claims about "the best fix does
not require any _protocol_ changes", "can usually be deployed
incrementally", and "with no need to co-ordinate the deployment of
the fix" are nothing more than a collection of (unsubstantiated)
assertions.
  
> interfacing/usage specification' thing.
 
As Dino told us, the mapping information has nothing to do
with the reachability between a given ETR and a given EID.
  
> But I won't launch into that until I'm sure that's what you're really trying
 
We want the LISP spec explicitly spell out the semantics of {RLOG,
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.  

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), and (b) how can one invalidate this information when (at some
later point) the EID is no longer reachable from the RLOC.

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 (in the presence of
multiple RLOCs for the same EID).

Yakov.