Hi Scott, You wrote, in part:
> I'm not talking about who a source is specifically, but the fact > that inputs to the mapping system need to be controlled. Inputs > might be from "users" (probably site managers), but there will be > policy on them. Who, other than the end-user whose micronet or EID prefix the mapping is for, should control the mapping? With Ivip the restrictions will be not to map it to an address which is any of: Inside a Mapped Address Block - that is, the address is not and RLOC address. Multicast, 10.0.0.0/8 etc. Maybe some other list of prefixes which, for some reason are agreed by all to be where ETRs should never be. If end-user A has two ISPs X and Y, then each ISP gives them an ETR which connects to the end-user's network. Then, its up to the end-user where their micronet / EID prefix is mapped. They can point it to one or the other ETR or they can point it wherever they like. How would the overall map-encap system decide that someone other than the end-user should have a say in where their micronet / EID prefix is mapped? > You can't change the mapping for a prefix, in the > mapping system, instantly. It's the wrong time scale. Ivip aspires to doing it in less than five seconds, globally, from end-user command to all ITRs changing their tunnelling - for a small fee. > . . . >> Ivip control of mapping is on this basis - the end-user >> controls the division of their UAB (User Address Block) in >> terms of splitting it into micronets and mapping those >> micronets to an ETR address, in a system which has nothing to >> do with ETRs. The most obvious way to do it is by a username >> and password over an encrypted link, or a challenge response >> system with a secret key, password etc. This would happen in a >> session with some organisation which directly or indirectly >> controls the mapping for a particular Mapped Address Block >> (MAB) - a BGP advertised prefix which typically contains many >> UABs and therefore typically this many, or probably more, >> micronets. > > If I understand correctly, you are proposing that wandering > devices that want to keep their "addresses" intact will talk to > an agent which will be authorized to make changes to the mapping > system. Yes - or have some other system talk to this "agent". The agent is a UAS - Update Authorisation System - which goes between users and the RUAS (Root Update Authorisation System), of which there are multiple. Each RUAS controls the mapping for one Mapped Address Block. This has been documented since July, but the new ID will take you through it faster, with some updated and simpler terminology: http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-db-fast-push-00.html Also, the 5.5 pages of summary: http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf > That solves the authentication problem (you separate the > wandering device from updating the mapping system) but not the > time scale problem. How many roaming events per second do you > want to support with your mapping system? With IPv4 the raw change data is about 12 bytes. IPv6 is a lot longer. I will write a separate message on this in the next week or two. I look forward to your response to my questions at the end of my message "Future mapping DB size, small micronets/EIDs": Can you write about how LISP-ALT or LISP-NERD could support mobility or not? Also, given the answer to that question, how many EIDs do you think - as an outside but not unrealistic estimate - a LISP scheme would ever have to support, say in 2015, 2020, 2030, 2040 and 2050? > How far are you going to push the changed information? As far as operators feel like pushing it into their networks. Beyond that, they use caching ITRs querying their local query servers. In any event, as long as the full mapping database is pushed to a few hundred sites around the Net, that is going to be much faster and more reliable to have query servers there than to rely on a global network like ALT. I think a worst-case estimate, in terms of how small a distance the full database might be pushed, is something like as far as one or more sites with a bunch of full database query servers in every major ISP. A best case estimate is that it could be pushed further, so there are lots of full database ITRs and query servers all over ISP networks and in many large end-user networks. - Robin -- 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
