> From: Patrick Frejborg <pfrejb...@gmail.com>
>> (Note that this is an architectural discussion, not an engineering
>> one, so I am assuming that at the future point in time we are talking
>> about, both systems have been well engineered, i.e. they have 'good'
>> security
> I think I got the message - you are designing a new mapping database,
> using experience and lessons learned from the DNS world and making the
> new a more robust and secured one. Architecturally analyzing the
> approach, it would be more secure than the current distribution of
> routing information.
Ah, no, that would mostly be engineering (doing a better detailed design,
e.g. closing vulnerabilities). Architecture means (among other things - the
definition of 'architecture' is a complex topic) things that are fundamental
- i.e. basic and unavoidable.
So, to give brief examples ('we may not have the definition, but we have the
example', as The Master was wont to say :-), saying something like 'path
selection requires some information about what is connected to what' is
architecture. Saying '16-bit nonces are too short, they can be broken by
exhaustive attack, 64-bit nonces are better' is engineering.
Yes, a re-resign can also involve improving the architecture (and not just
engineering) - e.g. adding a new namespace to allow separation of location and
identitity is an architectural improvement.
My original message was trying to understand the fundamental and unavoidable
problems/weaknesses caused by having _two_ mapping systems ('DNS names' ->
identifiers, and identifiers -> locators) as opposed to one - i.e. things no
mere engineering changes could improve (hence my "assuming that at the future
point in time we are talking about, both systems have been well engineered").
> A question, if I loose my primary ETR how fast is the mapping database
> updated to switch the connections to the secondary ETR? Is the mapping
> database based upon Dynamic DNS?
These are engineering questions that will depend on the detailed design of
the particular system; in particular, use of the term ETR seems to imply a
certain design approach (i.e. encapsulation).
E.g. a particular system might allow inclusion of multiple ETRs directly in
the (identity->location) mapping, such that detection of a dead ETR allows an
ITR to switch to a backup ETR without bothering to get a new mapping. Etc,
etc...
Noel
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
