Hi Tony, In your untitled message:
http://psg.com/lists/rrg/2008/msg00964.html you wrote: > I'd like to turn now to the issue of the dynamics of the mapping function. I understand from this that a new topic is being opened with the aim of arriving at some text for which there is rough consensus. I understand that the matter of "mapping granularity" is still under discussion. > In particular, how fast can we allow the mapping entries to be updated? Do > we need to constrain the overall flux of the mapping? > > As always, a clear, succinct articulation of the correct questions is more > valuable than a position statement. ;-) OK. The problem with a single set of questions is that the various map-encap systems have radically different architectures and that therefore the technical constraints, costs etc. are of a different nature in each. In LISP-ALT (and TRRP), the great thing is that the authoritative query server (one or more ETRs for LISP-ALT) can change the mapping for an EID prefix (micronet in Ivip terminology, TRRP too?) every millisecond and there are no costs to the rest of the system. However, since it is a pull-only system, if it is desired that the frequent changes propagate quickly to ITRs which are currently handling traffic addressed to this EID prefix, then the mapping responses must go out with very short caching times. So the question for a pure pull system is something like "How short a caching time will the mapping have?" This will vary with some end-users having a caching time of a few hours or days, and perhaps some having a caching time of a minute or less. With Ivip, the mapping updates go out in real-time and have no caching time - they remain in force for seconds or years, until another mapping change is sent. In Ivip's pull system, where ITRCs (and ITFH ITR functions in sending hosts, but not behind NAT) query local full database query servers (QSDs), perhaps through one or more intermediate QSCs (caching query servers) there is a caching time for the replies. There is also a "Notify" system by which the QSD will send a message to any querier about a mapping change to a micronet for which the QSD recently sent a reply. (This is not a complete description of the system.) It is a local decision by the QSD what the caching time is, which it can decide in various ways. The Ivip spec may have some guidance on these times, but it is likely to be up to the operator so set their own chosen caching time, or to vary it according to the nature of the request, to optimise their trade-offs of having to send out more Notify messages for the longer caching time, vs. reducing the query traffic if they shorten the time. Also, they are trying to optimise how much cache is used on their ITRs. So for Ivip, the cache time is important, but not part of the spec. I will write in a separate message some thoughts about this RRG design process - which in this case struggles to remain meaningful at a higher level than the inevitable low-level differences between the potentially practical map-encap systems. I think the problem with this "dynamics of the mapping system" question is that in order for it to produce meaningful results for each of the current map-encap proposals, it has to be transformed into a series of different questions for each proposal. Therefore, it doesn't enable a single answer or single set of answers to be given which would lead to a meaningful actual design being generated by the RRG. Nor does it enable the different proposals to be compared side-by-side, because each one has answers to different questions. - Robin http://www.firstpr.com.au/ip/ivip/ -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
