[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



	Hey Marcelo,

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

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

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

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

> >        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).
> >
> 
> 
> exactly and if we want to restore such functionlity without burdening  
> the routing system we will need additional mechanisms that will have  
> a cost.

	Yep.

> 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

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

	Dave

Attachment: signature.asc
Description: Digital signature