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

From: [email-masked] (Noel Chiappa)
Date: Thu, 3 Dec 2009 13:13:00 -0500 (EST)

> From: Patrick Frejborg <[email-masked]>

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

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 4 Dec 2009 07:53:26 +0900

> point in time we are talking about, both systems have been well

How about one mapping in the way:

   - DNS names -> ID     (here to me, ID = IP address = node address)

   - ID -> locator; this is not the job of Internet layer. In this context,
the locator here is to me the address of the underlying layer, such as

        - the X.25 address or
        - the ATM address or
        - the LAN MAC address or even
        - the private IP address of an enterprise network

So, my picture is as close as the RANGER proposal in that

        - although I can identify my destination node by 'node address' or
'ID'
        - the local address within each of the enterprise network cascaded
inbetween can all be different, independent.

Assume I'm sending a post mail in Corea to my destination node address (or
you can call it ID, too)

         237 Madison Avenue, New York City, NY, USA
              (happens to be the Morgans where I stayed...)

wherein my home (source) address might be somewhere in Seoul.

Still, the post mail reaches my destination without any problem. In each
county, country on the way from Seoul to New York, through mail boxes,
trucks, trains, ships, airplanes, down back to trains, boxes..., they all
use totally independent local addresses which I (as communicator to my
destination) don't care about, are not known to me, I'm not interested, is
none of my business.

So, all I need is the address (or ID) of my destination, and any locators
local to domains inbetween is none of my business. Locators will be mapped
again and again through the delivery process. In fact, a whole lot of NATs
on the way. NAT is not an evil, rather a norm.

I don't need a artificial concept of domain and interdomain, in fact. There
are only series of concatenated networks (or enterprise networks or whatever
you name it) which are chucked in whatever useful sizes/purposes only local
operators would be concerned about. I don't have to know all that details in
sending out my post mail.

.. network - NAT - network - NAT - network - NAT - .... etc.

So, the terminology 'address' in my use of 'node address' might be confusing
to many of people who used to think that

       address is only for routing whereas
       ID is only for identifying your 'abstract host stack'.

To me, they're one and the same thing. There's no routing without
identifying your partner. There's no identifying your partner without
routing to, i.e., without locating it. The two are one and the same.

The 'locator' which is being used in this community is not something
belonging to the internetworking layer we're talking about. It belongs to
the underlying layer, whatever the latter is. I don't even care how many
sub- and sub-sub- layers my underlying layer might have beneath it. I just
don't know, there's no way I can know, I don't care, not my business.

So, 'locator' is out of scope to our concern. You guys (or enterprise
networks if you like the term better) take whatever locator schemes/sets you
like, but just make sure you work with your neigboring business partners
that my post mail with an exact destination address (ID) be delivered
without fail. If you fail, I'll claim for reimbursement...

This is the model I have.

So.. where am I wrong? Or.. where am I correct or right?

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Patrick Frejborg <[email-masked]>
Date: Fri, 4 Dec 2009 14:01:00 +0200

> ITR to switch to a backup ETR without bothering to get a new mapping. Etc,
Hi Noel,

here I do get headache - I think this is an architectural question. In
order to get this working you need to combine two architectures - the
routing architecture and a mapping database architecture .

You have a mapping database but that database have no information
about an ETR's availability (I'm comparing to current DNS database) -
unless you integrate the current routing architecture with the mapping
database. If the link between the ETR and DFZ is lost the mapping
database need to know that, i.e. the routing protocol must inform the
database. Then the database needs to update all the members of the
mapping database, after that the database members needs to inform
their ITRs so that the ITRs that have ongoing sessions to the affected
ETR will flush their cache and replace the entry to the secondary ETR.
So you will have a redistribution from routing protocol -> mapping
database -> routing protocol, instead of having BGP churn you could
have cache churn instead.

If you prefer to avoid the redistribution you could let the routing
architecture take care to inform the ITR of ETRs availability. But
that will have negative impact on the DFZ. Today the EID in a
multi-homing solution usually creates a /20 prefix - regardless of how
many ISP connections it uses. But by using ETRs each attachment point
will create a /32 entry in the DFZ - unless the ISP are aggregating.
But when the ISP are aggregating the ITRs have no clue if the ETR is
available or not. So it seems that you have to do a redistribution of
routing protocol -> mapping database -> routing protocol to inform the
ITR of the availability of ETRs

And the current DNS system is quite slow to update - what happened in
Sweden was an engineering issue but to get the services restored was
due to the architecture of the system, one hour or longer is really
not what multi-homed enterprises are expecting in failure cases
http://blog.internetnews.com/skerner/2009/10/sweden-se-goes-offline-due-to.html

Or do I miss something ?

-- patte