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: Sat, 11 Nov 2006 12:36:57 -0500 (EST)

> From: [email-masked] (Noel Chiappa)

    >> I don't believe in the "else try_and_forward(input_packet)"
    >> clause, except for local traffic)...

    > I started to think through this whole issue, and discovered a problem.
    > To see it, let's think in a little more detail about how the routing in
    > a "jack-up" system is going to work.

In an attempt to make slightly clearer what I was jabbering on about here, I
have drawn a couple of quick, simplified diagrams which show some of the
things I was talking about.

Remember, I'm talking about the flow of routing data here, *not* packets, and
the mappings you see happening from old-style to new-style are mappings of
routing data, not mappings of packet source/destination addresses.

Again, the basic issue is that we're trying to reduce the amount of routing
information, but my concern is (basically) that until the very last
"old-style" DFZ router goes away, we may have to maintain full old-style
tables anyway in all routers everywhere - depending on how we set things up.

Anyway, the diagrams are here:

  http://ana-3.lcs.mit.edu/~jnc/tech/DisDFZ.jpg

which shows the problems with discontiguous chunks of new-style DFZ (i.e. the
repeated conversion from new-style locators back to old-style addresses), and
here:

  http://ana-3.lcs.mit.edu/~jnc/tech/ContDFZ.jpg

which shows how the same technical issue (the reverse mapping from new-style
addresses back to old-style) occurs with a large, continugous new-style DFZ
on the edge, but how it's more manageable since it's only happening on a
single boundary.

So, try rereading my other message (Fri, 10 Nov 2006 21:18:28 -0500) with
these diagrams, and see if what I'm wondering about makes sense.

For simplicities sake, I have drawn the diagrams as if all networks with
unmapped addresses are attached to the old-style DFZ, and all with mapped
to the new-style, but of course that's not necessary.

Also, I have only drawn the physical topology, not the two separate routing
planes - sorry, didn't have enough patience for a multi-layer drawing!

Anyway, I'd really appreciate it if people could look at this material
(diagrams and text), and see if I've made some obvious blunder in my
understanding, or if there is a real issue here.

	Noel

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

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 12 Nov 2006 04:43:33 -0500

We are going to have to have multiple mail threads and flow aware state
routers are one of them and at that time I will propose the entire
routing based on a flow ID and locator can be done and far more
efficiently than today.  SHIM6 work in progress avoids the end host
problem  as input to this process.  But, the point is there are many
ideas and thoughts but they will not be focused and coordinated until we
organize this effort per what I heard from Leslie as plan forward.  Fine
to brainstorm on this list and hear all persons ideas and thoughts but
this needs a more focused IETF process with working groups, IETF rules
of engagement etc. and to adhere well to Sam Hartmans word of caution at
the Plenary which is working well thus far.

I also suspect per Geof H mail that it is important for us to define
what we want to be an identifier on the Internet and part of the address
space discussion.  I also wonder if the IETF can select such an
identifier without liaison discussions with other SDO and Consortia
stakeholders.  Note IAB message we need to work with all stakeholders.

Best,
/jim

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]] 
> Sent: Saturday, November 11, 2006 12:37 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Ok, so what should we do then? (Was: Re: 
> [arch-d] [Off-topic]Further thoughts: about systems theory 
> and the theory U)
> 
> In an attempt to make slightly clearer what I was jabbering 
> on about here, I have drawn a couple of quick, simplified 
> diagrams which show some of the things I was talking about.
> 
> Remember, I'm talking about the flow of routing data here, 
> *not* packets, and the mappings you see happening from 
> old-style to new-style are mappings of routing data, not 
> mappings of packet source/destination addresses.
> 
> Again, the basic issue is that we're trying to reduce the 
> amount of routing information, but my concern is (basically) 
> that until the very last "old-style" DFZ router goes away, we 
> may have to maintain full old-style tables anyway in all 
> routers everywhere - depending on how we set things up.
> 
> 
> which shows the problems with discontiguous chunks of 
> new-style DFZ (i.e. the repeated conversion from new-style 
> locators back to old-style addresses), and
> here:
> 
> which shows how the same technical issue (the reverse mapping 
> from new-style addresses back to old-style) occurs with a 
> large, continugous new-style DFZ on the edge, but how it's 
> more manageable since it's only happening on a single boundary.
> 
> So, try rereading my other message (Fri, 10 Nov 2006 21:18:28 
> -0500) with these diagrams, and see if what I'm wondering 
> about makes sense.
> 
> 
> For simplicities sake, I have drawn the diagrams as if all 
> networks with unmapped addresses are attached to the 
> old-style DFZ, and all with mapped to the new-style, but of 
> course that's not necessary.
> 
> Also, I have only drawn the physical topology, not the two 
> separate routing planes - sorry, didn't have enough patience 
> for a multi-layer drawing!
> 
> 
> Anyway, I'd really appreciate it if people could look at this 
> material (diagrams and text), and see if I've made some 
> obvious blunder in my understanding, or if there is a real issue here.
> 
> 	Noel
>

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 13 Nov 2006 09:53:10 -0800

I actually think that this discussion is exactly what the doctor ordered
at this stage. I surmise that while the basic facts are agreed upon,
there is still a fair bit of analysis needed to confirm or modify Tony's
observation that "we could reduce the growth due to a) TE, b)
multihoming, and c) fraudulent PI allocations." 

Our understanding of the issues are too fuzzy at this point to move into
an IETF WG. It would be better for a small community to produce a
detailed analysis the current state of the actual domain and then a
larger community to brainstorm possible technical alternatives. Once
we've done that, then we can form an IETF WG to progress the issue.

-----Original Message-----
From: Bound, Jim [mailto:[email-masked]] 
<snip>
Fine to brainstorm on this list and hear all persons ideas and thoughts
but this needs a more focused IETF process with working groups, IETF
rules of engagement etc. and to adhere well to Sam Hartmans word of
caution at the Plenary which is working well thus far.
<snip>

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 13 Nov 2006 13:10:18 -0500

Valid and I think the process will be similar to as you suggest from my
read between the lines from the Plenary (clearly subjective for sure),
but I believe that small community needs to be very diverse in views and
we need to be very careful with that one and it might be better to form
another list based on volunteers rather than selection by a few
randomly.  Always tough to find a balance and make sure all and diverse
views are represented even for a clay model.  But right now we are
hearing things all over the map of what I believe is the problem space
and I am positive my view is skewed so trying not to share it until
later once the staircase of abstraction for analysis is better
identified to move forward.

/jim 

> From: Fleischman, Eric [mailto:[email-masked]] 
> Sent: Monday, November 13, 2006 12:53 PM
> To: Bound, Jim; Noel Chiappa; [email-masked]
> Subject: RE: Ok, so what should we do then? (Was: Re: 
> [arch-d][Off-topic]Further thoughts: about systems theory and 
> the theory U)
> 
> I actually think that this discussion is exactly what the 
> doctor ordered at this stage. I surmise that while the basic 
> facts are agreed upon, there is still a fair bit of analysis 
> needed to confirm or modify Tony's observation that "we could 
> reduce the growth due to a) TE, b) multihoming, and c) 
> fraudulent PI allocations." 
> 
> Our understanding of the issues are too fuzzy at this point 
> to move into an IETF WG. It would be better for a small 
> community to produce a detailed analysis the current state of 
> the actual domain and then a larger community to brainstorm 
> possible technical alternatives. Once we've done that, then 
> we can form an IETF WG to progress the issue.
> 
> From: Bound, Jim [mailto:[email-masked]] <snip> Fine to 
> brainstorm on this list and hear all persons ideas and 
> thoughts but this needs a more focused IETF process with 
> working groups, IETF rules of engagement etc. and to adhere 
> well to Sam Hartmans word of caution at the Plenary which is 
> working well thus far.
> <snip>
>

---

From: <[email-masked]>
Date: Mon, 13 Nov 2006 18:57:06 +0200

How about limiting DFZ only for provider aggregatable addressing and
using some on-demand routing and tunneling over the DFZ for PI prefixes?
Initially this tunneling could be over existing IPv4. This could be
pretty much like some of the tunneling based IPv6 transition methods,
but you keep tunneling even if the DFZ transfers to IPv6.

The border (where the tunneling happens) does on-demand lookups for PI
destination addresses and caches the results. Reverse DNS lookups would
work fine, as long as the PI addresses have prefixes that aggregate on
organizational + some regional structure. Outside of the DFZ the PI
addresses would be routed (internally) and packets with foreign PI
destinations would be default routed towards DFZ.

Some sites having too much peers to cope with number of tunnels would
use just provider based addressing (e.g. content distributors) and cope
with renumbering. That way the tunneling state would distribute to
content servers and could be manageable on the side of the transport
protocol context.

In summary the proposal is to keep DFZ provider based only, and have PI
addressed traffic tunnel over it, forever. This will happen naturally as
an outcome of the IPv6 transition, if we keep the IPv6 DFZ free of PI
addressed routes, as the tunneling mechanism is needed to IPv6
transition over IPv4 anyway.

Regards,

	Jarno

>From: ext Noel Chiappa [mailto:[email-masked]] 
>Sent: 11 November, 2006 19:37
>Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] 
>[Off-topic]Further thoughts: about systems theory and the theory U)
>
>In an attempt to make slightly clearer what I was jabbering on 
>about here, I have drawn a couple of quick, simplified 
>networks with unmapped addresses are attached to the old-style 
>DFZ, and all with mapped to the new-style, but of course 
>that's not necessary.
>

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 13 Nov 2006 22:39:18 -0800 (PST)

> using some on-demand routing and tunneling over the DFZ for PI prefixes?

Actually how about doing on-demand routing in general - i.e. does
each router really need/use all the entries in RIB? Can we do
something similar to DNS where routes are received and cached
but can then expire if not used [note that it would not be
easy since you need route before you can do dns, etc]?

Related research question -
  Has anyone actually done (or wants to do) a study how many routes
from BGP each router actually does use for various size networks & 
organizations?

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Mon, 13 Nov 2006 22:56:57 -0800

let's see. Having the FIB-equivalent-cache built route by route from  
a RIB that was maintained on a neighboring card turned out to be a  
problem, so we decided we needed to have a complete FIB (as in, a  
next hop for every possible destination address) on every forwarding  
card. Now we want to build the FIB-equivalent-cache built route by  
route by querying systems that might be tens to hundreds of  
milliseconds away?

I'll think about that one and let you know what I come up with...

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 14 Nov 2006 08:52:22 +0100

> using some on-demand routing and tunneling over the DFZ for PI  

Something like this has been suggested by several people, including  
myself.

However, there are many details to be worked out. For instance, I'm  
not a fan of doing this on-demand, I'd rather flood the mapping  
information. That makes everything a lot faster and makes debugging  
easier, as you have a full view of the state of the network.

> but you keep tunneling even if the DFZ transfers to IPv6.

The nice thing is that you can offer multiple tunnel options: over  
IPv4 only, over both IPv4 and IPv6, or, in the future, over IPv6  
only. And the payload protocol can be IPv4 or IPv6. Note though that  
tunneling isn't entirely problem-free: it reduces your MTU, and  
having a smaller than 1500 MTU is a problem in IPv4, while a smaller  
than 1280 MTU isn't allowed in IPv6. For IPv6 over IPv6, an  
alternative is address rewriting.

> The border (where the tunneling happens)

I thinkt the tunneling/encapsulation should happen in service  
provider networks, at least at first. This aids transparency and  
deployability, and service providers have a bigger incentive to do  
this than end-users. If end-users want to parFrom [email-masked] Tue Nov 14 02:55:13 2006
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: [arch-d] RE: Ok, so what should we do then?
Date: Tue, 14 Nov 2006 08:52:22 +0100
To: "<[email-masked]>" <[email-masked]>
Cc: [email-masked]

> using some on-demand routing and tunneling over the DFZ for PI  

Something like this has been suggested by several people, including  
myself.

However, there are many details to be worked out. For instance, I'm  
not a fan of doing this on-demand, I'd rather flood the mapping  
information. That makes everything a lot faster and makes debugging  
easier, as you have a full view of the state of the network.

> but you keep tunneling even if the DFZ transfers to IPv6.

The nice thing is that you can offer multiple tunnel options: over  
IPv4 only, over both IPv4 and IPv6, or, in the future, over IPv6  
only. And the payload protocol can be IPv4 or IPv6. Note though that  
tunneling isn't entirely problem-free: it reduces your MTU, and  
having a smaller than 1500 MTU is a problem in IPv4, while a smaller  
than 1280 MTU isn't allowed in IPv6. For IPv6 over IPv6, an  
alternative is address rewriting.

> The border (where the tunneling happens)

I thinkt the tunneling/encapsulation should happen in service  
provider networks, at least at first. This aids transparency and  
deployability, and service providers have a bigger incentive to do  
this than end-users. If end-users want to participate in this, so  
much the better, but we shouldn't make this a requirement for succes.

---

From: Jefsey_Morfin <[email-masked]>
Date: Tue, 14 Nov 2006 10:34:59 +0100

>route by querying systems that might be tens to hundreds of

My proposition was simpler. To have the DNSS (distributed network 
supervisory system) to resolve the domain name/IP address into a 
route from a permanent knowledge of the network helped by a numbering 
plan in symbiosis with topology. The route is put into each packet 
(I  called it the "needle"). The routers obey the needle or return it 
to the origin and alert the DNSS in case of failure. This decreases 
the load on the router and permits all the value added/extended 
(content related) services you want. The big issue is the distributed 
supervisor design. Transition is simple: if there is no needle, 
current solutions apply. The IP dependent users (most probably in 
IPv4 today) can still been served. Tables could transition to some 
local supervisory outputs being cached?

I explained how the PI issue can be addressed.
jfc

---

From: "Schliesser, Benson" <[email-masked]>
Date: Tue, 14 Nov 2006 08:14:46 -0600

Fred Baker [mailto:[email-masked]] wrote:
> > each router really need/use all the entries in RIB?
> 

I have to agree with Fred. Despite my previous comments indicating that
any AS should be able to connect arbitrarily, the fact is that today
there are a relatively small number of networks at the "core" of the
connectivity graph. This on-demand model might not blow up *completely*
for routers that forward to a relatively small number of destinations.
(I.e. the end-network that only talks to Google, Yahoo, and their ISP's
mail server, etc.) But the routing scale problem exists largely in the
"core", where the routers are actually forwarding traffic to a fairly
significant proportion of the allocated address space and currently have
the largest tables. Making routes on-demand for these routers would
initially hinder their ability to forward packets as Fred points out.
And after lookups and tunneling take place their cache state would
probably be on the same scale as today's global routing table, anyway.

Cheers,
-Benson

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Nov 2006 11:15:21 +0100

Or another way to ask the question: how long a startup delay
is acceptable for a new flow, if remote lookup is needed?

In the phone system, the answer seems to be up to several seconds,
but when sending short flows of 1500 byte packets on a 10 Gb link,
it doesn't seem like we can tolerate more than a few tens
of microseconds at most.

     Brian

Fred Baker wrote:
> let's see. Having the FIB-equivalent-cache built route by route from  a 
> RIB that was maintained on a neighboring card turned out to be a  
> problem, so we decided we needed to have a complete FIB (as in, a  next 
> hop for every possible destination address) on every forwarding  card. 
> Now we want to build the FIB-equivalent-cache built route by  route by 
> querying systems that might be tens to hundreds of  milliseconds away?
>

---

From: <[email-masked]>
Date: Tue, 14 Nov 2006 17:02:52 +0200

Schliesser, Benson [mailto:[email-masked]] wrote: 
>I have to agree with Fred. Despite my previous comments 
>indicating that any AS should be able to connect arbitrarily, 
>the fact is that today there are a relatively small number of 
>networks at the "core" of the connectivity graph. This 
>on-demand model might not blow up *completely* for routers 
>that forward to a relatively small number of destinations.
>(I.e. the end-network that only talks to Google, Yahoo, and 
>their ISP's mail server, etc.) But the routing scale problem 
>exists largely in the "core", where the routers are actually 
>forwarding traffic to a fairly significant proportion of the 
>allocated address space and currently have the largest tables. 
>Making routes on-demand for these routers would initially 
>hinder their ability to forward packets as Fred points out.
>And after lookups and tunneling take place their cache state 
>would probably be on the same scale as today's global routing 
>table, anyway.
>

The proposal was to keep routing in the "core" provider based (which
scales well) and do provider independent routing over it, managed by
edge networks themselves. You could tunnel over the core, do mapping on
the locator part of 8+8 etc. So the hypothesis is that on-demand routing
could work on the edges where each network is initiating traffic with
limited number of PI addressed destination networks.

Futher in all likelihood a domain name of the destination is resolved
prior to such communication, and this could be used as a heuristic to
fetch the on-demand routing info to the local domain (e.g. via reverse
mapping the returned PI IP address to find ingress points to the
destination network over the "core").

Also, typically communication with destinations starts with a handshake
protocol, i.e. no need to buffer huge amounts of data. Might even work
w/o buffering: do the look-up as a reaction to "destination unreachable"
being returned from the DFZ. Source will re-transmit the 1st handshake
packet. It would be nice to have the on-demand state in place by the
time the 1st retransmit comes.

Regards,

	Jarno

---

From: "Schliesser, Benson" <[email-masked]>
Date: Tue, 14 Nov 2006 09:40:08 -0600

[email-masked] [mailto:[email-masked]] wrote:
> edge networks themselves.

Ah, I obviously misunderstood. Thanks for the clarification.

> fetch the on-demand routing info to the local domain
> [...]
> no need to buffer huge amounts of data. Might even work

So, if I follow you correctly this time, typical end networks could use
PA space and all traffic should use the path through their "primary"
ISP, but during an outage the originating endpoint would do a lookup to
find the address of the remote endpoint's "secondary" provider
connection(s) and tunnel to it. End networks that use their own PI space
would have to be tunneled for all communications.

Do you envision that the host or the gateway is performing the
tunneling? Is the tunnel endpoint to the remote host or the remote
gateway? Do gateways need to be aware of ICMP unreachable messages
destined for the host endpoint? What about load-balancing etc?

I'm still quite doubtful that this could work well enough to satisfy end
users and applications since it extends connection establishment time
significantly. But it's worth exploring the properties to see what comes
of it.

Cheers,
-Benson

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Nov 2006 16:39:01 +0100

Iljitsch van Beijnum wrote:
> However, there are many details to be worked out. For instance, I'm  not 
> a fan of doing this on-demand, I'd rather flood the mapping  

As I've tried to say a couple of times, i think a key design issue
here is to conceptually and actually separate the way the map is
computed and distributed from the way it is used for forwarding.
That means the choice between (say) mapping on-demand, flooding,
or some other method can be changed later, or even be different
in different parts of the network. The same goes for rewriting
addresses vs encapsulation and the decision whether it's host based
or router based.

We may need to recycle the MIB acronym (M for Mapping), so that
we can conceptually have MIB -> RIB -> FIB.

     Brian

> The nice thing is that you can offer multiple tunnel options: over  IPv4 
> only, over both IPv4 and IPv6, or, in the future, over IPv6  only. And 
> the payload protocol can be IPv4 or IPv6. Note though that  tunneling 
> isn't entirely problem-free: it reduces your MTU, and  having a smaller 
> than 1500 MTU is a problem in IPv4, while a smaller  than 1280 MTU isn't 
> allowed in IPv6. For IPv6 over IPv6, an  alternative is address rewriting.
> 
> I thinkt the tunneling/encapsulation should happen in service  provider 
> networks, at least at first. This aids transparency and  deployability, 
> and service providers have a bigger incentive to do  this than 
> end-users. If end-users want to participate in this, so  much the 
> better, but we shouldn't make this a requirement for succes.
> 
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Nov 2006 16:49:29 +0100

Noel,
...
> these diagrams, and see if what I'm wondering about makes sense.

It confirms my view that we need to focus on the mapping in itself,
without worrying too much exactly how it will be used.

Bizarrely enough, the issue you raise with islands of new-DFZ
needing different mappings is very similar to the issues in 6to4
about why 6to4 can't work if the IPv4 DFZ fragments, because
the trivial mapping that 6to4 relies on is no longer universal.
(End of section 5.5 of RFC 3056).

     Brian

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 14 Nov 2006 11:21:16 -0800 (PST)

To be sure I was not talking about pure on-demand with route received
from far side of the Internet before packet can be sent, but I would
note that most networks do have default transit path and it can be 
immediatly used for packet destined to something not in local RIB.
At the same time when there are regular flows to some network the 
routing path is then learned and is directly available in the local RIB. 
And I agree that it would not really solve the issue for the core
routers - perhaps for core pure DFZ network some sort of DHT-like
approach for BGP routing table (among iBGP speakers on same network) 
maybe of some use.

On Mon, 13 Nov 2006, Fred Baker wrote:

> let's see. Having the FIB-equivalent-cache built route by route from a RIB 
> that was maintained on a neighboring card turned out to be a problem, so we 
> decided we needed to have a complete FIB (as in, a next hop for every 
> possible destination address) on every forwarding card. Now we want to build 
> the FIB-equivalent-cache built route by route by querying systems that might 
> be tens to hundreds of milliseconds away?
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 14 Nov 2006 23:04:36 +0100

On 14-nov-2006, at 16:39, Brian E Carpenter wrote:

>> I'm  not a fan of doing this on-demand, I'd rather flood the  
>> mapping  information.

> in different parts of the network.

Yes, this is a good point. If we keep this at a high level we avoid  
making choices that turn out to be bad later, at least for now.

> The same goes for rewriting addresses vs encapsulation and the  
> decision whether it's host based or router based.

Right.

> we can conceptually have MIB -> RIB -> FIB.

There may even be more levels if we look at the different sources of  
MIB information: static (just portable address space), multihoming- 
related (where the entire network may change connectivity at once and  
TE is an important consideration) and mobility-related (similar to  
multihoming but per host and TE is less important or even unimportant).

---

From: <[email-masked]>
Date: Wed, 15 Nov 2006 12:38:55 +0200

Schliesser, Benson [mailto:[email-masked]] wrote:
>> fetch the on-demand routing info to the local domain [...] 
>no need to 
>> buffer huge amounts of data. Might even work w/o buffering: do the 
>> look-up as a reaction to "destination
>unreachable"
>So, if I follow you correctly this time, typical end networks 
>could use PA space and all traffic should use the path through 
>their "primary"
>ISP, but during an outage the originating endpoint would do a 
>lookup to find the address of the remote endpoint's 
>"secondary" provider
>connection(s) and tunnel to it. End networks that use their 
>own PI space would have to be tunneled for all communications.
>

Rather all networks needing the provider independence would use PI
space. However, it might be beneficial to use PA space for high-volume
publicly accessable servers (e.g. web servers accessible from the
Internet) this applies also to publicly accessible DNS servers etc. but
the intranet would be PI addressed.

Also, preferably multiple routes to the remote PI space would be
discovered at the same time, allowing for TE, load balancing, failover,
etc. Also this kind of explicit on-demand route discovery step would
allow for "controlled transparency", policy-based securing the traffic
in transit etc.

>tunneling? Is the tunnel endpoint to the remote host or the 

It should be at gateways somewhere between the PI-addressed network and
the DFZ "core". Major requirement being allowing edge network to use PI
space and multihome, and having no PI routes in the DFZ.

>remote gateway? Do gateways need to be aware of ICMP 
>unreachable messages destined for the host endpoint? What 
>about load-balancing etc?
>

Load balancing already addressed above. ICMP unreachable was only one
possiblity I have not thought much further. It may also be that it is
not needed, if the tunnel discovery is done on a gateway without any
default routes, as it would notice locally that there is no route to
destination, toss the packet to the slow-path SW processing where the
on-demand routing could be done.

Also, routing could be on-demand only as far as the FIB on the line card
is considered, i.e. the "tunnel route" exists on the slow-path RIB but
is instantiated on the fast-path FIB on-demand. This would be trivial to
do if "destination unreachable" generation already happens on the
slow-path. Is anyone doing this on current routers (e.g. for normal BGP
routes)?

>I'm still quite doubtful that this could work well enough to 
>satisfy end users and applications since it extends connection 
>establishment time significantly. But it's worth exploring the 
>properties to see what comes of it.
>

Well, as Brian wrote, the routing info could be also fully distributed.
But have PI tunnel-routes on-demand delivered to the HW fast-path, and
tunneled (source-routed, wrapped, mapped, etc.) over the DFZ "core", as
otherwise the core FIBs (on fast path) would grow too big, as they would
need all the routes most of the time, I assume.

I still think this kind of a system could be an off-spring of one of the
tunneling based IPv6 transition methods. Run a v6-over-v4
"tunnel-routing-protocol" over the current IPv4 network, and go on from
there.  

Regards,

	Jarno

---

From: Jefsey_Morfin <[email-masked]>
Date: Wed, 15 Nov 2006 12:36:59 +0100

Think of my proposed DNSS needle. The routing information is in the 
packet header: information is already here or a few microseconds away 
(read the header). If the numbering plan is adequately designed 
(topology dependent on the numbering plan) once in a while route 
computation and needle size can be very limited.
jfc

At 11:15 14/11/2006, Brian E Carpenter wrote:

>>let's see. Having the FIB-equivalent-cache built route by route 
>>from  a RIB that was maintained on a neighboring card turned out to be a
>>problem, so we decided we needed to have a complete FIB (as in, 
>>a  next hop for every possible destination address) on every 
>>forwarding  card. Now we want to build the FIB-equivalent-cache 
>>built route by  route by querying systems that might be tens to 
>>hundreds of  milliseconds away?