Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U)

From: [email-masked] (Noel Chiappa)
Date: Fri, 10 Nov 2006 15:31:18 -0500 (EST)

> From: Brian E Carpenter <[email-masked]>

    > When you have more than 4 billion nodes .. surely you need extra
    > address bits?

Oh, one other thought I had (sorry, had it too late to tack it onto the other
reply email):

If we go the jack-up route (to avoid having to modify hosts), then we have a
big, painful job ahead of us, which is to build, deploy, and populate that
mapping database - the one that maps from old-style "addresses" (aka
identifiers, now) to new-style locators. Getting that done, reliable, getting
the data into it, etc, etc is going to be a major job of work. And I haven't
even talked about the wrapping/unwrapping code in the routers, etc, etc.

It's a scientific (and maybe engineering to) dictum to never change more than
one variable at once in an experiment. I dunno about you, but if we're going
to go the jack-up route, to me that mapping database alone is enough to bite
off in one chew. Let's leave the "running out of 32-bit identifiers" problem,
and the deployment of its solution, until later, yeah?

In fact, I'd be inclined to leave any better routing architecture to phase II
as well, which ought to show you how concerned I am about the magnitude of
the basic jack-up stuff.

But of course we should think about what a follow-on routing architecture
might need, and make sure that both the mapping database, the wrapped header
format (maybe GRE, or something like it?), and the wrapping code in the
routers, all are ready to support a new routing architecture at some later
phase of deployment.

	Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: David Conrad <[email-masked]>
Date: Fri, 10 Nov 2006 15:03:31 -0800

Noel,

> identifiers, now) to new-style locators.

I hesitate to mention this because if you were depressed before, this  
might cause you to slit your wrists, but... (:-))

If the destination DNS has:

# Label                                 Cl RRtype Pref Rdata
0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.id.arpa IN LOCATOR 100 A000::0001
                                            LOCATOR 200 B000::0001

and the source (edge or last hop) router does:

locators = dnslookup(destination_identifier)
if locators exist then
     destination_locator = pick_one(locators)
     encapsulate_and_forward(destination_locator,input_packet)
else
     try_and_forward(input_packet)
endif

No new technology needed, just a small matter of programming.  The  
mapping is done at the edges, distributing both the map database and  
the lookup load.  Caching is built in (although you probably want to  
modify the cache to do a refetch for active flows before the TTL  
expires so you don't have to take the latency hit in the middle of  
the flow).  You get incremental deployment (assuming non-mapped  
prefixes are routable).  And assuming DNSSEC, the mapping is secured.

Like I said, I don't want this to cause you to slit your wrists...

Yes, there are disadvantages to this approach (the first packet  
latency hit, DDoS vulnerability, for example) and there are other  
approaches (some sort of push method, e.g., a BGP attribute), but  
this may be quicker/easier to deploy...

Rgds,
-drc

---

From: John Leslie <[email-masked]>
Date: Fri, 10 Nov 2006 18:45:37 -0500

David Conrad <[email-masked]> wrote:
> To: Noel Chiappa <[email-masked]>
> 
>> If we go the jack-up route (to avoid having to modify hosts), then  
>> we have a big, painful job ahead of us, which is to build, deploy,
>> and populate that mapping database - the one that maps from old-style
>> "addresses" (aka identifiers, now) to new-style locators.

   Whadaya mean "we", kemosabe?

> might cause you to slit your wrists, but... (:-))

   Please! No blood on the carpet! ;^)

>     try_and_forward(input_packet)

   Ignoring details for the moment, the idea looks really promising.
It even passes my "mobility test". (I believe that any "right"
architecture will yield a workable "solution" for mobile computers.)

> the flow).

   Essential for mobility. It even gives a free hint as to how long
the mapping is expected to last.

> You get incremental deployment (assuming non-mapped prefixes are
> routable).

   Yes!!!!

   And that assumption, initially, is perfectly reasonable! Although
both input and output have the form of IPv6 addresses, we know
which is which. And in the "default" (current) state, the input is
_likely_ to serve as a workable output.

> And assuming DNSSEC, the mapping is secured.

   Well, everyone's entitled to a _little_ wishful thinking... ;^)

> latency hit, DDoS vulnerability, for example)

   Engineering details! (I'm sure workarounds can be found.)

> and there are other approaches (some sort of push method, e.g.,
> a BGP attribute), but this may be quicker/easier to deploy...

   I see no reason to limit this to one approach.

   However, we need to discuss "architecture". How, even whether,
DNS supplies the mapping isn't the "architecture" -- rather we
need to agree what we're calling the _input_ and _output_ of this
mapping process.

   May I start the bidding with:

- "endpoint name"              for the input; and
- "network attachment locator" for the output?

--
John Leslie <[email-masked]>