Sorry for the delay on this response.
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.
This is really easy to implement. You decide what the reachability is
and then you set the bit-string. Once you have this bit-string it is
stored as part of a MAC re-write string when you decide to
encapsulate. So the forwarding engine, by no means, is figuring out
reachability at packet forwarding time.
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
Right, we have been saying that since we created them. See the Santo
Domingo Nanog slide-set on LISP. The loc-reach-bits handle 3 types of
failures, 1) xTR going down, as discovered by the other xTRs in the
site, 2) CE-PE link goes down attached to an xTR, or 3) the PE box
goes down that is attached to an xTR.
So, let's make this clear, we have always said the loc-reach-bits are
a *hint*. They don't tell you about up reachability, but do tell you
about down reachability. An xTR that receives loc-reach-bit changes
could react to them right-away if it wanted to trust the site. An xTR
could verify the loc-reach-bits to make sure they are in fact valid
and from the right source.
The R-bit per locator entry in the locator-set from a Map-Reply are
authoritative and can be trusted.
The ITR doesn't need per-packet time status of an RLOC. Having it in
the data plane provides the opportunity. And we have found some Data
Center applications that will use this feature but for the capital-I
Internet, cautious use of loc-reach-bits should be considered.
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?
They are not complicated. They are a compressed way to give you
information about many RLOCs in the data-plane. To get the
compression, you need the bit-string to refer to the Map-Reply order
of RLOCs. Those don't change often so this isn't really a problem.
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.
We have outlined that SMRs don't have to be sent often. Removing RLOCs
from a locator-set can be flagged as down and the ITRs using the map-
cache entry for this site can quickly change to new RLOCs. Add RLOCs
are appended to the end so if a site with an old map-cache entry sees
a loc-reach-bit that is set for a locator-set it has as "shorter" it
can ignore it.
The SMR processing needs to only be used when you have to do
"compaction" for the above two cases.
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.
They won't be inconsistent. The xTR that gets the SMR-bit makes sure
that it gets a Map-Reply by rate-limiting the retransmission of the
Map-Request.
Dino
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
