Hi,

Since mapping versioning has been raised for discussion I'd like to comment
some concerns I have about Lisp Reachability Bits. While versioning seems to
solve part of this I think some issues still remain.

1. Reporting local reachability complicates implementation of ITRs: Every
time an ITR encapsulates a package it needs to report local reachability of
the site's ETRs. Not only ITRs must know it (Map Server proposes lighter
ITRs) but there are also ugly failures to take into account i.e. ITRs in the
site getting isolated one from another but both working.

2. Reachability bits don't solve the problem completely: As this bits detect
only some reachability problems ITRs will also use other mechanisms. To be
on the safe side some ITR implementations will probably send Map Requests
after a short period detecting only outbound traffic to some RLOC (and
repeat as often as the standard allows while this condition continues). Is
it worth having this complicated reachability bits mechanism if it doesn't
help us much?

3. Ugly failures appear also here (from LISP draft)

       The ETRs, at the site with the changed mapping, records the fact
       that the site that sent the Map-Request has received the new
       mapping data in the mapping cache entry for the remote site so
       the loc-reach-bits are reflective of the new mapping for packets
       going to the remote site.  The ETR then stops sending packets
       with the SMR-bit set.

ETRs can never be sure if the remote site received or not the Map Replies.
What if they didn't? What if (or while) some ITRs did and some didn't?
Having an old mapping is bad enough, having reachability bits inconsistent
with the mapping gets the problem worse. Versioning looks good to solve this
one.

Regards,
Damian Lezama

_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg

Reply via email to