Subject: [RRG] some musings on PI v. PA, and assumptions, requirements, and tradeoffs

From: David Meyer <[email-masked]>
Date: Thu, 12 Jul 2007 15:40:05 -0700

I've been thinking about a benefit of PI addressing that
	I have not seen discussed on this list or others (at
	least recently). In particular, PI addressing enables a
	certain kind of "path selection" that might not be easy 
	(or possibly desirable) to retain in any of the the
	LOC/ID split schemes we have been discussing. This is
	contrast with the standard PI stuff (e.g., I don't want
	to renumber, etc). 

	Consider the following scenario: I'm a multihomed stub (I
	don't transit packets between my two upstreams). Further,
	I have PA delegations from each of up upstreams. Now, I'm
	corresponding with a remote site using addressing out of
	one of the PA blocks, call it X. Now, my link to the ISP
	aggregating X breaks. A packet destined for X will then
	travel very close to my site before learning that the
	link is down, possibly too far to be rerouted. And BTW,
	if I advertise X to my other upstream, then my
	advertisement of X has the same cost (to the routing
	system) as a PI advertisement.

	This problem is common to all (I think) of the schemes
	that seek to improve/optimize aggregatability in the
	core. For example:

	(a).    In the 8+8/GSE case, the problem is that the
		packet will follow the RG in the src address all
		the way to the "end" of the path, that is, to the
		ISP that can forward it to the site. You don't
		learn that the site can't receive the packet
		until that point, and there is no way to reroute
		it.  

	(b).    The situation is similar with PA space, since the
		fact that the link at the "end" of the path might
		be down is hidden in the aggregate. You don't
		learn this until you are close to the "end" of
		the path, and there may be no way to reroute the
		packet. 

	(c).    The situation is similar with map/encap, since
		one of its goals to enable better PA-style
		aggregation.   

	OTOH, if I announce PI space, "switching to the new path"
	is controlled by the announcement/withdrawal of the PI
	prefix, and can happen much closer to the source. So in
	this sense aggregation breaks a certain kind of "path
	selection". I think we all realize that there is no free
	lunch, and that this is a property (such as it is) of the
	fact that aggregation throws away information in the
	interest of computability (a standard technique).

	So folks are using PI for reasons other than the standard
	laundry list (i.e., avoiding renumbering, etc). In
	particular, advertising PI space can cause the "switch"
	to a different path during an outage to happen much
	closer to the source (i.e., much further back in the
	network).  

	None of this to say that we shouldn't be moving forward
	with the various solutions we've speced out (quite the
	contrary). Rather, my question is really about revisiting
	assumptions, requirements, and tradeoffs.

	Dave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 13 Jul 2007 11:14:26 +0200

Hi Dave,

> 	system) as a PI advertisement.

basically you are assuming that the failure detection is performed by  
the routing system and that the information about the failures inside  
an aggregate are hidden by aggregation

But it is possible to perform end to end failure detection that is  
likely to be much faster than this (or at least it can be tuned by  
the endpoints to be faster than this and even to detect failure much  
faster than when using PI)

>         I think we all realize that there is no free

exactly and if we want to restore such functionlity without burdening  
the routing system we will need additional mechanisms that will have  
a cost.

a similar considration can be applied to the TE discussion and using  
PA addresses. I mean, when we only use PA addresses and the only one  
that knows that 2 PA prefixes are assigned to a single site is the  
site itself, then the rest of the network cannot perform TE tricks.  
This is a similar trade off: the rest of the network is no longer  
overloaded with additional routing information, but as they no longer  
have the information about all the paths leading to a multihomed  
site, they can not longer play with different paths. If we want to  
restore such functionality, we will need to pay to publish that  
information, either by bigger routing tables, either having a  
parallel database that contains the multiple PA prefixes assigned to  
each multihomed site

Regards, marcelo

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: David Meyer <[email-masked]>
Date: Fri, 13 Jul 2007 07:19:17 -0700

Hey Marcelo,

> an aggregate are hidden by aggregation

	Well, I don't know about "assuming". It definitely
	happens.

> faster than when using PI)

	Sure, but that's not what some people are relying on
	today. 

> the routing system we will need additional mechanisms that will have  

	Yep.

> parallel database that contains the multiple PA prefixes assigned to  

	Those are definitely possibilities. I wonder if there are
	others.

	Dave

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 13 Jul 2007 11:57:26 -0400 (EDT)

> From: David Meyer <[email-masked]>

    > PI addressing enables a certain kind of "path selection" that might not
    > be easy (or possibly desirable) to retain in any of the the LOC/ID
    > split schemes we have been discussing.
    > ...   
    > I advertise X to my other upstream, then my advertisement of X has the
    > same cost (to the routing system) as a PI advertisement.

Sure. As I said back in "Some Thoughts on Multihoming":

  http://ana-3.lcs.mit.edu/~jnc/tech/nsrg/multihoming_points.txt

  "Multihoming is something that is done to provide *benefits*. Those are not
  *free*. There is a *cost* for them, and a multihoming design has to think
  about *where* and how much those costs are."

And if you support multi-homing with the routing, it's the routing that
has the costs.

    > if I announce PI space, "switching to the new path" is controlled by
    > the announcement/withdrawal of the PI prefix, and can happen much
    > closer to the source.

Sure. But go back to what I said next in that note:

  "JTW Principle: - The best design minimizes the overall cost of providing
	those benefits.
  JNC Corollary to the JTW Principle: - It is best if one can allocate the
	costs so that the entities which benefit from the multihoming are
	the ones to bear the cost."

If you have a site which is providing content to a large part of the
Internet, it makes sense (in a system-wide analysis) to have the routing
support multi-homing for that site, because while everyone pays part of the
costs, everyone also benefits. If you have a site that only a few people use,
then, to me at least, it makes sense to use solutions that put more of the
cost on the site and its users.

Yes, the particular routing-based solutions you mentioned (8+8/GSE, PA and
encaps) have the unhappy property that you don't find the problem until the
packets are near the destination, and you may not be able to recover. But
there are other approaches... but they are not without costs of their own.

I'd say that any multi-homing solution which is benefitting only a few people
has to involve the hosts more (which is why, architecturally, Multi6 went
down that path). For your particular issue, hosts would have to e.g. notice
that there's a service interruption, and try a different locator for the
service.

    > So in this sense aggregation breaks a certain kind of "path selection".
    > I think we all realize that there is no free lunch, and that this is a
    > property (such as it is) of the fact that aggregation throws away
    > information in the interest of computability (a standard technique).

There are some similar thoughts in "More Thoughts on Multihoming", here:

  http://ana-3.lcs.mit.edu/~jnc/tech/nsrg/multihoming_more.txt

  "Site multihoming is, fundamentally, a path-selection (routing) issue. That
  is, there are multiple paths through the physical connectivity fabric, and
  we wish to make more than one of them available for use.
  This does not sound hard. Why is it so difficult? The issue turns out to be
  simply one of efficiency - i.e. how high a cost (or overhead) do we want
  the path selection to have/incur. If any infinite cost were acceptable,
  there would be no problem."

I don't have any magical solution to this problem. Indeed, looking at it
the way I laid it out in those two notes, graph theory kind of has you
trapped...

	Noel

---

From: David Meyer <[email-masked]>
Date: Fri, 13 Jul 2007 09:18:52 -0700

> And if you support multi-homing with the routing, it's the routing that

	Most certainly.

> 	the ones to bear the cost."

	This was one of the "principles" that we came away from
	the IAB AMS meeting with, notably, that there is a
	misalignment in the costs and benefits of multihoming
	(core bears the cost, sites gain the benefit, etc).

> cost on the site and its users.

	That makes sense, although in the current regime even in
	the case of a large multihomed content provider, the core
	(network) still bears the burden while the site gains the
	benefit. In some sense everyone benefits (as you say),
	but that cost/benefit tradeoff isn't rationalized (i.e.,
	there's no economy that assigns resources accordingly).
	Today that large site is no different than a small
	multihomed site (with respect to this issue). 

> there are other approaches... but they are not without costs of their own.

	Such as? It might be interesting to explore that space
	just a bit. And BTW, another problem with all of this is
	getting *there* (where ever there might be) from here. If
	the solution isn't incrementally deployable (and those do
	deploy the solution reap the benefits), then we have a
	tough sell.

> that there's a service interruption, and try a different locator for the

	Ah, of course. But then there are the latency issues with
	obtaining the mappings and with locator liveness. Trade
	this for that, I suppose (the mapping latency might not
	be an issue at "switch over time", since you might have
	gotten all the mappings at once during the initial query
	to the mapping system, whatever that may be).

>   there would be no problem."

	Sure, aggreed.

> the way I laid it out in those two notes, graph theory kind of has you

	Me either. But it is something to think about (along with
	the latency issues I mentioned about).

	Dave

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 13 Jul 2007 12:25:47 -0400 (EDT)

> From: marcelo bagnulo braun <[email-masked]>

    > if we want to restore such functionlity without burdening the routing
    > system we will need additional mechanisms that will have a cost.

I'm (obviously :-) mostly in general agreement with this point, but I'm a
little puzzled by the term "restore .. functionality". I'm not sure exactly
what "functionality" you're referring to, but... I always thought of
multi-homing as something new, something extra, which we were doing; creating
more reliability. So, to me, anything that doesn't work is not something that
used to work, but doesn't any more...

    > a similar considration can be applied to the TE discussion and using PA
    > addresses. I mean, when we only use PA addresses and the only one that
    > knows that 2 PA prefixes are assigned to a single site is the site
    > itself, then the rest of the network cannot perform TE tricks. This is
    > a similar trade off: the rest of the network is no longer overloaded
    > with additional routing information, but as they no longer have the
    > information about all the paths leading to a multihomed site, they can
    > not longer play with different paths.

Excellent point.

    > If we want to restore such functionality, we will need to pay to
    > publish that information, either by bigger routing tables, either
    > having a parallel database that contains the multiple PA prefixes
    > assigned to each multihomed site

Two comments.

First, you're right: from a high level, providing these extra services (TE,
in this case) is going to require extra overhead/etc (TANSTAAFL).

Second, at a certain point, I think the existing routing architecture (since
these are all path-selection issues, i.e. routing) is going to prove too big
a problem. At a certain point, you wind up trying to install screws with
a hammer...

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 13 Jul 2007 12:49:09 -0400 (EDT)

>> Internet, it makes sense (in a system-wide analysis) to have the
    >> routing support multi-homing for that site, because while everyone
    >> pays part of the costs, everyone also benefits.

    > benefit.

This doesn't make that much economic sense to me. I reason as follows:

Assume there were no large content providers, just lots of small sites, each
making money. In that case, the network would have to carry as much overall
traffic, but somehow I don't think people would have this reaction 'oh, those
sites are getting something for free, and so the network providers should get
more money from them'.

Yes, a large content provider does use lots of bandwidth - but it has to get
that bandwidth from someone (unless they own their own fiber everywhere).

I tend to view this as a straight economic tussle - like that between a
manufacturer and a union. There's a pie (the income of the content provider),
and the network providers and the content providers are fighting over it.

I might further observe that it's only this way because the network business
has no pie to fight over. If Google/etc were barely breaking even, and the
network providers were raking in money hand over fist, I bet you'd see the
exact reverse of this argument: 'oh, those network guys are only making money
because of our content, so we deserve a share of their pie'.

I am not impressed by either argument.

Last I heard, the telephone companies weren't asking for a share of the
profits of mail-order companies who take their orders over the phone, either.

Right now, network services are not 'properly' valued by the market (in part
because there was overspending on capital investments like fiber). The same
thing happens in other markets too (e.g. commercial buildings). Eventually
things will return to a reasonable mean.

    > In some sense everyone benefits (as you say), but that cost/benefit
    > tradeoff isn't rationalized (i.e., there's no economy that assigns
    > resources accordingly).

I'm not sure I quite understand this? Are you saying that that costs aren't
perfectly assigned, that some people are getting something for free?

    > another problem with all of this is getting *there* (where ever theren
    > might be) from here. If the solution isn't incrementally deployable
    > (and those do deploy the solution reap the benefits), then we have a
    > tough sell.

That is *the* problem in Internet engineering these days. Any old fool (well,
sort of :-) can design a better network, or a jet airplane; but it takes a
real genius to figure out how to turn a fabric biplane into a jet while it's
flying! :-)

    >> hosts would have to e.g. notice that there's a service interruption,
    >> and try a different locator for the service.

    > there are the latency issues with obtaining the mappings and with
    > locator liveness.

I'll bet that pairwise liveness detection, and switching to an alternative,
is a lot quicker than having a giant distributed algorithm notice that
something has changed, and react and stabilize...

    > the mapping latency might not be an issue at "switch over time", since
    > you might have gotten all the mappings at once during the initial query
    > to the mapping system

Well, that's certainly one good option.

	Noel

---

From: Scott Brim <[email-masked]>
Date: Fri, 13 Jul 2007 13:38:21 -0400

Dave, I'm missing what's new here.  Having a PI allocation means news
of available paths to you can be carried further (all over) in BGP
space without being aggregated, so people are aware of you further
away and may take different paths to reach you.  Good but costly.

>   "JTW Principle: - The best design minimizes the overall cost of providing

Just to be sure ... "overall cost" can include lots of things,
including loss of flexibility for the future.

> that there's a service interruption, and try a different locator for the

or pre-announce them to the other end(s) at some higher layer, e.g.
SCTP.  (Aside: think about that and CONS.)

> the way I laid it out in those two notes, graph theory kind of has you

The magical solution is the one we're all talking about -- to
distribute the problem differently, to use push and pull, time and
space. :-)

Scott

---

From: David Meyer <[email-masked]>
Date: Fri, 13 Jul 2007 10:57:54 -0700

> away and may take different paths to reach you.  Good but costly.

	I was just trying to point out that there are folks
	(service providers of a sort) for whom the grail of
	aggregation doesn't seem like an advantage.

	Dave

---

From: David Meyer <[email-masked]>
Date: Fri, 13 Jul 2007 11:00:15 -0700

> perfectly assigned, that some people are getting something for free?

	Basically, its all about routing state. If I'm a
	multihomed site and I inject a PI prefix, then I gain the
	benefit but the core networks bears the cost (state). So
	in that sense the cost/benefit is misaligned.

	Dave

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 13 Jul 2007 14:20:13 -0400 (EDT)

> in the case of a large multihomed content provider, the core (network)
    > still bears the burden while the site gains the benefit.

Ooops, I just realized that your comment is just about the costs and benefits
of the multihoming, not about the costs and benefits of the content provider
in its entirety (which is what I replied to). Sorry!

To that point, I would say that yes, the network providers are providing
routing table entries. However, again, I would say that the providers'
customers, who are the ones using the content provider, are the ones who are
paying the price for those routing table entries, through their payments to
the service provider (or they should be, if the service cost structure was
rational).

And because the site is so widely used, the distribution of the costs (to the
customers) is roughly congruent to the distribution of the benefits (to the
customers).

To come at it another way, think about a small provider in some other
country. At the moment, all other providers (worldwide) have to have a
routing table entry for that provider, even though that provider doesn't
directly pay them for that cost.

Yes, I know there are inter-provider settlements (which cover mostly traffic,
I thought, but could be construed to cover routing overhead as well), and so
perhaps some money is coming through in an indirect way.

But it's really the same basic thing: providers everywhere are bearing a cost
(providing the routing table entry), but 'only' one site is getting a
benefit. In reality, of course, the *users* are also getting a benefit - but
at least in the case of a large content provider with PI-space, users
*everywhere* are getting a benefit, whereas a service clients of small
provider may be only benefitting a small number of users across the network.

I suggested long ago that people ought to have to pay to rent routing table
entries, to encourage people to do aggregation so that they could advertise
their particular piece of the address-space over a minimal scope.  Alas, I
don't think they world is ready for that (at least, yet :-).

(Now that I think about it, though, you'd think the providers would jump on
this idea - they are hurting for income, and this would be a new income
source... :-)

Certainly, if this were done, it would be useful for multi-homing as well (in
addition to other cases, such as small providers with non-connectivity-based
address space), because the costs would be directly visible, and would be
directly factored in to chosing among different engineering options.

To the extent that costs got shifted, though, expect people whose oxen got
gored to complain - even if they would now only be paying for something they
used to get 'for free'...

	Noel

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 13 Jul 2007 18:49:14 -0700

> 	aggregation doesn't seem like an advantage.

This is a really important point. That is, "the sorts" are willing to  
pay for slots in everyone's routing table (read: it costs them  
nothing) because they get better convergence. Having said that, a Loc/ 
ID split solution provides no value in this case of multihoming.

And if their servers are stationary, there isn't a mobility case  
where a Loc/ID split solution would help.

Dino

---

From: Geoff Huston <[email-masked]>
Date: Sat, 14 Jul 2007 16:33:20 +1000

Dino Farinacci wrote:
> pay for slots in everyone's routing table (read: it costs them nothing) 
> because they get better convergence. Having said that, a Loc/ID split 
> solution provides no value in this case of multihoming.
> 
> And if their servers are stationary, there isn't a mobility case where a 
> Loc/ID split solution would help.

Haven't we been round this particular mulberry bush a few times already? 
   Yes, the routing system offers the path of least resistance when 
attempting to solve a number of issues, and thats because routing 
solutions are invariable simple and (today) cheap. And the Loc/ID split 
seems to be a pretty massive solution for something that does not appear 
to be a commonly accepted problem in the first place. So yes, we 
continue to use the routing system for multi-homing, traffic engineering 
and similar. It just works.

The only concern I've heard voiced that seems to me to be a real issue 
in all this is the question "what if we all did that?" Are there numbers 
for "we all" that appear to be beyond the capability of the technology 
curve? Are there numbers for "we all" that might even be beyond the 
capability of the protocol? If so, then we probably need some kind of 
plan B, and it does appear to me that if you want to get out of the 
tyranny of incrementalism then you need to consider something a little 
more fundamental in terms of network architectures when you start to 
look at what would make a Plan B effective. For me this path is where 
the split loc/ID approaches start to gain traction. But to be clear, the 
split loc/ID approach does not appear to me to be a viable tactical 
response to routing inflation in the near term future.

   Geoff

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 14 Jul 2007 00:18:04 -0700

> Haven't we been round this particular mulberry bush a few times  
> already?   Yes, the routing system offers the path of least  
> resistance when attempting to solve a number of issues, and thats  
> because routing solutions are invariable simple and (today) cheap.  
> And the Loc/ID split seems to be a pretty massive solution for  
> something that does not appear to be a commonly accepted problem in  
> the first place. So yes, we continue to use the routing system for  
> multi-homing, traffic engineering and similar. It just works.

To connect to stationary hosts yes. But if they are moving around and  
keep their addresses regardless if those addresses are from PI or PA  
space, then location needs to be topological. Furthermore, moving  
around a lot and injecting and withdrawing more specifics is just  
going to add churn in a major way.

> The only concern I've heard voiced that seems to me to be a real  
> issue in all this is the question "what if we all did that?" Are  
> there numbers for "we all" that appear to be beyond the capability  
> of the technology curve? Are there numbers for "we all" that might  
> even be beyond the capability of the protocol? If so, then we  
> probably need some

All valid questions with no magic answers. But if we are concerned  
with churn and convergence of control-plane tables into forward-plane  
tables and looking at 10^6 sites plus the mobility aspect, the  
numbers are getting large. But this is not scientific but just gut feel.

> kind of plan B, and it does appear to me that if you want to get  
> out of the tyranny of incrementalism then you need to consider  
> something a little more fundamental in terms of network  
> architectures when you start to look at what would make a Plan B  
> effective. For me this path is where the split loc/ID approaches  
> start to gain traction. But to be clear, the split loc/ID approach  
> does not appear to me to be a viable tactical response to routing  
> inflation in the near term future.

As I have said before Geoff, solving the routing table size problem  
is just a side benefit if we first solve the "non-search-site"  
multihoming problem. That is to allow them to use both of their links  
(I believe you said that 80% of all multi-homed sites have exactly 2  
connections) and to be able to tell hosts returning packets to them  
which link to use and how to failover.

A level of indirection can solve this but the big question is it too  
much of a solution. That is, do we have the guts to just brute-force  
and continue to send in PI prefixes.

Dino

---

From: "Medhi, Deep" <[email-masked]>
Date: Sat, 14 Jul 2007 11:59:13 -0500

> To connect to stationary hosts yes. But if they are moving 
> around and keep their addresses regardless if those addresses 
> are from PI or PA space, then location needs to be 
> topological. Furthermore, moving around a lot and injecting 
> and withdrawing more specifics is just going to add churn in 
> a major way.
> 
> > in all this is the question "what if we all did that?" Are there 
> > numbers for "we all" that appear to be beyond the capability of the 
> > technology curve? Are there numbers for "we all" that might even be 
> > beyond the capability of the protocol? If so, then we probably need 
> > some
> 
> All valid questions with no magic answers. But if we are 
> concerned with churn and convergence of control-plane tables 
> into forward-plane tables and looking at 10^6 sites plus the 
> mobility aspect, the numbers are getting large. But this is 
> not scientific but just gut feel.
> 
> > kind of plan B, and it does appear to me that if you want 
> to get out 
> > of the tyranny of incrementalism then you need to consider 
> something a 
> > little more fundamental in terms of network architectures when you 
> > start to look at what would make a Plan B effective. For me 
> this path 
> > is where the split loc/ID approaches start to gain 
> traction. But to be 
> > clear, the split loc/ID approach does not appear to me to 
> be a viable 
> > tactical response to routing inflation in the near term future.
> 
> As I have said before Geoff, solving the routing table size 
> problem is just a side benefit if we first solve the 
> "non-search-site"  
> multihoming problem. That is to allow them to use both of 
> their links (I believe you said that 80% of all multi-homed 
> sites have exactly 2
> connections) and to be able to tell hosts returning packets 
> to them which link to use and how to failover.
> 
> A level of indirection can solve this but the big question is 
> it too much of a solution. That is, do we have the guts to 
> just brute-force and continue to send in PI prefixes.
> 

The above exchange between Geoff and Dino is quite interesting. 

Loc/ID split is an important issue; but, somehow it seems to get grayed
regarding "end" for real end users or PI independent address blocks
(thanks to Lixia, for her nice presentation clarifying the Terminology,
HIP research meeting, March 23, 2007).

I don't believe real end users mostly care what their IP address is
(except, perhaps us 'net-geeks). If they get their service they are
fine. Note that to make TCP-based service work, the end system requires
an IP address (i.e. layer-4 "port" address relates to layer-3
address)--mosty this is accomplished through the end system
implemenation stack. The real question is: should this end IP address
come from the same globally defined addressing mechanism, or should this
end IP address be 'elevated' to make TCP and end services still work,
while a separate addressing is used for the global routing system; for
the time being, I'll call the former "layer-3.5 IP address" for the
purpose of end system service, while I'll call the latter "layer-3 IP
address" for the purpose of global routing system. Whether these two
addressing may look the same or different is something interesting to
think about. 

As a different case, I'll draw the example of local number portability
(LNP), as well as cell phones. Users get their E.164 address (the
telephone number), they can keep it, yet change providers; they are
happy. Although E.164 addressing has its origin in geographic routing,
there has been a clear separation between E.164 for the purpose of
service and how the routing work in PSTN. Partly it was possible to do
so because in the very first place, the end telephone numbering and
nodes numbering (switches) in PSTN didn't come from the same address
space. 

Now when it comes to cell phones, we already know that providers with
newer generation wireless systems assign IP addresses, which may or may
not be locked into the E.164 address. What matters to the end user is
still E.164 address (it's not what is the IP address of the device);
they are happy to get their TV show clips, music download etc etc, and
certainly happy to have a globally unique identifier in the form of
E.164 address so that they can receive/make calls. It doesn't matter to
them if the IP address is different when they are physically in a
different location. Rather, it's the headache of the provider to do such
IP address assignment (which might be different, depending on the
current location); i.e., the provider-independence issue doesn't arise
in this scenario.

Thus, the critical question is: are we willing to have an IP address for
the purpose of the end system service (layer-3.5 address), and another
address for the purpose of routing system (layer-3). If we do so, we'll
need a lookup function much like DNS (perhaps more closer to ARP?),
between layer-3.5 and layer-3 addresses (a level of indirection); this
will then avoid breaking the current global routing system, and in fact,
might allow it to evolve in its own course; similarly, the end system
(and implementation) can evolve separately as well without breaking it.

Whether this is good or bad, remains to be seen and understood. At the
end of the day, this is as much a philosophical question as it is a
system scalability question with potential economic implications. I'll
be the first one to admit that I don't have the far reaching answers.
At this point I'm just pondering the possible issues and implications...

    Thanks.

       -- Deep
          http://www.csee.umkc.edu/~dmedhi

---

From: Bruce Curtis <[email-masked]>
Date: Sat, 14 Jul 2007 21:55:46 -0500

On Jul 13, 2007, at 4:14 AM, marcelo bagnulo braun wrote:

> exactly and if we want to restore such functionlity without  
> burdening the routing system we will need additional mechanisms  
> that will have a cost.
>
> a similar considration can be applied to the TE discussion and  
> using PA addresses. I mean, when we only use PA addresses and the  
> only one that knows that 2 PA prefixes are assigned to a single  
> site is the site itself, then the rest of the network cannot  
> perform TE tricks. This is a similar trade off: the rest of the  
> network is no longer overloaded with additional routing  
> information, but as they no longer have the information about all  
> the paths leading to a multihomed site, they can not longer play  
> with different paths. If we want to restore such functionality, we  
> will need to pay to publish that information, either by bigger  
> routing tables, either having a parallel database that contains the  
> multiple PA prefixes assigned to each multihomed site
>
> Regards, marcelo

   Another possibility to publish the the information is to put the  
multiple destination addresses in each packet.  Of course the cost is  
sending the extra bits. It seems to me that for devices in the core  
of the network the cost of publishing the info this way is mostly  
independent of the total number of routes or paths in the network but  
would instead be dependent on the number of destination addresses  
that would need to be supported per packet.

   As you have pointed out before an architecture based on multiple  
destination addresses has it's own set of problems but it would allow  
for a future where TE could be done in the core while as you mention  
above the ability to do TE beyond the edge with other architectures  
can be quite expensive.

---
Bruce Curtis                         [email-masked]
Certified NetAnalyst II                701-231-8527
North Dakota State University

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Jul 2007 10:44:18 +0200

On 2007-07-15 04:55, Bruce Curtis wrote:
...
> sending the extra bits. It seems to me that for devices in the core of 
> the network the cost of publishing the info this way is mostly 
> would instead be dependent on the number of destination addresses that 
> would need to be supported per packet.

It seems to me that Six/One (and to some extent shim6) is simply
a compressed form of this - a packet contains enough info to
recover the compressed into, which is the set of addresses. The only
question is who's got a copy of the compression state.
> above the ability to do TE beyond the edge with other architectures can 
> be quite expensive.

You could do this neatly in IPv6 with a new form of routing header
which simply lists alternate destination addresses.

     Brian

---

From: Bruce Curtis <[email-masked]>
Date: Mon, 16 Jul 2007 07:50:42 -0500

On Jul 16, 2007, at 3:44 AM, Brian E Carpenter wrote:

>> multiple destination addresses in each packet.  Of course the cost  
>> is sending the extra bits. It seems to me that for devices in the  
>> core of the network the cost of publishing the info this way is  
>> mostly independent of the total number of routes or paths in the  
>> network but would instead be dependent on the number of  
>> destination addresses that would need to be supported per packet.
>

   Yes, but for similar overhead (added bits) to encap/tunneling  
solutions we could put the info in the packet in uncompressed form.

>> destination addresses has it's own set of problems but it would  
>> allow for a future where TE could be done in the core while as you  
>> mention above the ability to do TE beyond the edge with other  
>> architectures can be quite expensive.
>

   Right, something like

http://www.watersprings.org/pub/id/draft-bagnulo-multi6-mhexthdr-00.txt

   This could be implemented on hosts but would also allow middlebox  
solutions that strip or rewrite the header at the edge of the network  
so that between the edge of the network and the host there is only  
one destination address in the packet. (to make ACL management easier  
etc, also a possibility is to have one PI IP number per host that is  
not used for global routing but is one of the addresses in the  
headers plus the  PA addresses etc., another option is to have the PI  
addresses based on location/GPS etc)

   I think the property of easily supporting middlebox solutions but  
not requiring a middlebox (easily implemented on end hosts) is  
attractive.

---

---

From: David Meyer <[email-masked]>
Date: Mon, 16 Jul 2007 07:22:46 -0700

Geoff,

> the split loc/ID approaches start to gain traction. 

	Agreed, but as you know, even that isn't a consensus
	position (that a plan B will be needed, or if it is, that
	loc/ID split would be the solution). 

> But to be clear, the split loc/ID approach does not appear to
> me to be a viable tactical response to routing inflation in the
> near term future. 

	Guess it depends on what "near term" means, but I do
	agree that some of the ideas that have been bouncing
	around to improve various aspects of the current routing
	system (i.e., BGP) seem more near/immediate term.

	However, as I've said on various occasions, if we can
	improve the performance of BGP (again, along all of the
	various dimensions we've been discussing), we should be
	doing that in any event.

	Dave