I-D Action:draft-azinger-scalable-addressing-00.txt

Tony Li tony.li at tony.li
Thu Oct 7 18:31:43 CEST 2010


Hi Gert,

> I have not responded for this for a while, because I felt like "no matter
> what I say, it's going to be twisted around and ignored", but there's a
> few things in there that prompt a response...


Actually, I'm just trying to keep the conversation on an apples-to-apples comparison between PA and PI architectures can do.

Given that the draft has been rejected, I'm not sure I see a point to continuing this, but for the sake of completeness...


>>> Let me try to illustrate this with a specific example.  No complex policies
>>> for now, just focusing on "shortest path to destination".
>> 
>> Nope, sorry, you don't get to change the game in the middle.  You asked 
>> for a path equivalent or better than what a single prefix would give you.
> 
> Yes.  So how is this changing the game?


Because the current path is NOT the shortest path.


> True, but not relevant to understanding the problem "we the operators"
> see with the currently existing technology.


Very relevant if you're trying to a direct comparison.  Both PA and PI must be held to the exact same standard.


>> No, BCP 38 requires that the source address MATCH the egress.  If the 
>> egress prefix is applied at the ASBR, that also suffices.
> 
> Since we're talking about *current* technology, the egress prefix has
> to be selected by the sending host.  There is nothing in my ASBRs today
> that could "apply a prefix".


Fair.  I'm getting ahead of myself.  Sorry.


>>> If I have a single S and D prefix, the end host does not *need* to know,
>>> and the network *will know* that the path via ISP 1 to its peer to D is 
>>> shorter than via ISP 2.
>> 
>> No, it will not.  It will simply use the path selected by BGP.  That 
>> could easily be S1 to D2.
> 
> If you mix in policy, you can always construct an example where BGP would
> be configured to pick a bad path.  Yes.  But this is missing the point -
> if you mix in policy, N*M is likely to have more not-working-at-all
> combinations, not just worse-than-best.


We can't untangle routing from policy.  ;-)

Given that reality, yes, it is possible that there are bad paths.  But are they necessarily any worse paths?  It would seem unlikely.


> I'm talking existing technology.  There is no ILNP today.
> 
> Even if it were, how can the destination know what the best prefix order
> is for a given source?  How can the destination know which prefixes are
> *working* prefixes without knowing the network topology in between?


Again, you cannot.  But then you don't get the 'best' path today either.  No known technology is going to give you that, so it's a metric that is pretty much useless.


> So, to summarize again: with existing technology, N*M is not something
> that is fully usable yet - there's a gap.  Future technologies are quite
> likely going to change this approach, but this isn't helping deployment 
> *today* - and last I heard, we're somewhat in a hurry to get IPv6 out.


Hurrying to get IPv6 out and recreate the IPv4 routing table explosion to me seems like you're intentionally working to move us into a position where we have no path forward.  Wouldn't it be better to fix the problems that we have before we move people onto v6?

A PA architecture is fully usable.  It's not perfect, it has some issues, but then the PI architecture has some other huge issues.  If we move to a PA architecture, then future technologies will get us to a better position.  If we stick with PI, we just create a swamp and then have to move to PA later, when we have created a crisis.

Tony



More information about the ipv6-ops mailing list