Re: [rrg] Constraints due to the need for widespread voluntary adoption

[[e-mail] (Noel Chiappa)]

    > From: Patrick Frejborg <[e-mail]>

    >> (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