> From: Patrick Frejborg <[email protected]>
> The ITR at the residence ... receives a packet from the local network,
> there is no entry in the cache for the destination and thus it consults
> the MS.
Technically (unless by "MS" you meant 'Mapping System', but the acronym MS is
usually expanded to 'Map-Server'), it consults its Map-Resolver ('MR'), and
the MR (through means opaque to the average client, but at the moment its
the ALT) consults the MS on the ITR's behalf.
> The rITR receives a reply from MS, creates the cache entry and adds
> the LISP header to the packet
An ITR _can_ buffer packets until the mapping arrives, but not necessarily:
other options are i) forward them through a PITR, or ii) drop them.
> the packet is routed to the ITR of the content site (cITR), No cache
> entry exists
Unless a mapping has been gleaned (which I personally think ought to be done
at cETRs, otherwise the cITR will have to go through a resolution cycle -
although there are a number of ways this could happen [and I don't recall
what the spec does at the moment],, e.g. when the rITR has to do the lookup,
it can make sure the matching mapping is intalled at the destination).
> a reply is received, a cache entry is created at the cITR and the
> returning packet gets encapsulated
Same comment as above about the rITR.
> For returning packets there is no need to do DNS lookups but if I have
> understood LISP correctly the cITR needs to do MS lookups so that
> returning packets gets routed back to the residences. If the cITR uses
> only one MS server there will be intensive traffic between the cITR and
> the MS server
As mentioned above, I favour some sort of 'piggybacking' (an class of
optimization used in a number of places in LISP) to prevent this by
'pre-loading' the mapping into the cITR's cache, although I'm more concerned
about delay/etc than the server load (although that of course is an issue
too, but only in some circumstances, like the one you outline, whereas delay
is always an issue).
> The major difference with today's architecture is that there is no need
> to do a lookup in DNS for returning traffic
Correct - this is the big architectural difference, hence my desire to get
rid of the mapping lookup in the reverse direction. (I had a great way to do
this in a secured way in CONS, but alas we aren't using CONS.)
> If the cITR cache doesn't scale enough and I would prefer to add a
> second cITR .. How do I ensure that the returning packets are routed to
> the correct cITRs?
This is a great question/engineering issue, and one that has been extensively
discussed in the past. There is no great, easy, solution. Even if one can
provide the 'return' mapping to the ingress cETR (above), what happens if
that's not the same box as the cITR? One either i) has to work out a way to
make sure it is the same box (not trivial), or ii) pass the mapping to the
box that will be the cITR (not trivial), or iii) give up on optimizing out
the lookup cycle in the return direction (not acceptable, IMO). In other
words, the engineering details of large sites remain to be fully worked.
Noel
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
