Hi Noel, On Thu, Jun 23, 2011 at 5:46 PM, Noel Chiappa <[email protected]> wrote: > > From: Alia Atlas <[email protected]> > > > I want to see something that has the assumptions written down and > > can be implemented. > > How about 'Anything that can be fed _into_ the mapping system, and get an > answer, is an LEID; anything that can be seen in the _output_ from the > mapping system is an RLOC.' Although even that's probably too precise - it > my mind were fully awake, I could probably come up with some countexamples. > > > At least one case of parts that don't work when the same bit-pattern > > is used as an EID for one host and as an RLOC (or globally routeable > > address) for another is: > > ANYWHERE that a lookup in the mapping database is done to determine > > if an address is an EID or RLOC > > Mu. The assumption in that question (that something is _either_ an RLOC > _or_ an LEID) does not hold 100.00000% - although I wish it did! (Leaving > aside the cases of legacy addresses, which are all both at once, of > course.) If you can look up a bit-pattern in the mapping database, and get > back an answer, that bit-pattern has LEID-nature. But that doesn't mean it > can't also have RLOC-nature.
Yes - but the question is whether the same bitpattern must belong to the same site and end-host. Please see Joel's rephrasing of my concern. I'm fine with the mixed up semantics for interworking and so on. I'm not happy about separate namespaces not being separate (e.g. independently allocatable) without that being clearly written down. What is written down is that they are separate name-spaces. > Yes, having that kind of mixed-up semantics a lot is not good; and for the > simple (and hopefully by far and away the most common) model, it does not > happen. But the Internet is large, and there are more kludges in it than any > of us dream of in our architectures.... Kludges happen - I want documentation of them though. Alia _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
