RE: Aggregation Implies Provider Dependence // Re: [RRG] ALT's strong aggregation often leads to *very* long paths

[<hannu.flinck@nsn.com>]

 Hello Christian and others

You wrote

>The question is whether ALT operators would be willing to 
>engage in such a cooperation with their competitors.  They 
>could do the very same thing already today in order to make 
>renumbering a less frequent event without sacrificing routing 
>scalability.  But they are NOT doing it -- which is why we are 
>looking for alternative solutions here in RRG...


The reason why we do not see such co-operation among the operators/ISPs
is not competition, but rather that there are no sufficient tools.
Currently if you wish to implement address aggregation and address
portability between two adjacent operators (adjacency in terms of
address space), would amount to a lot of manual configuration and
tweaking BGP.  The address aggregation and related address portability
(within the aggregation) would benefit the operators, customers and the
industry as a whole if proper tools just existed. 

As a reference to similar problem, the address portability in the 3G and
GSM networks works fine even between the competitors. This didn't happen
because of the altruism of mobile operators, but because of regulation
that promoted competition. I could even go so far to claim that it was
exactly the hyper competition between the mobile operators that lead to
the implementation of address portability (with the help of regulation).

Regards 
Hannu Flinck   

>-----Original Message-----
>From: owner-rrg@psg.com [mailto:owner-rrg@psg.com] On Behalf 
>Of ext Christian Vogt
>Sent: Friday, February 01, 2008 20:15
>To: Eliot Lear
>Cc: Robin Whittle; Routing Research Group; Dino Farinacci; 
>Scott Brim; Vince Fuller; David Meyer
>Subject: Re: Aggregation Implies Provider Dependence // Re: 
>[RRG] ALT's strong aggregation often leads to *very* long paths
>
>Eliot -
>
>> First of all, I could easily imagine partnerships forming 
>between ALT 
>> providers that share portions of the address space and allow their 
>> customers to renumber from one partner to another.  This isn't pure 
>> independence, but it is something.
>
>The question is whether ALT operators would be willing to 
>engage in such a cooperation with their competitors.  They 
>could do the very same thing already today in order to make 
>renumbering a less frequent event without sacrificing routing 
>scalability.  But they are NOT doing it -- which is why we are 
>looking for alternative solutions here in RRG...
>
>> Second, the degenerate scenario that you describe is that we 
>are fully 
>> disaggregated.  That means that there is a lot of STATE.  It says 
>> nothing about RATE.  This will depend very much on how the LAT is 
>> managed.  If the LAT is extended to the last mile link without any 
>> static announcements, we would have precisely what we have today.
>> However, if LAT announcements are relatively static, then 
>the question 
>> is this: who cares?
>
>I am assuming that you are suggesting the following.  Please 
>clarify if I understood you incorrectly:
>
>- Relax the requirement for aggregation in the LAT.
>
>- The cost of such disaggregation will be a larger LAT routing table.
>   But since the LAT won't be used for traffic engineering purposes (as
>   BGP is in today's single Internet topology), the update rate of the
>   LAT routing table won't necessarily go up.
>
>This is certainly a valid observation.
>
>I believe the important point here is that there is a 
>trade-off between aggregation within the LAT and 
>provider-independence of EID space.  The compromise affected 
>by the ALT specification is in favor of aggregation
>-- and as I have said in my previous email, this makes EID 
>space provider-dependent.  Your suggestion above affects a 
>compromise in favor of provider-independence -- at the cost of 
>larger LAT routing tables.
>
>Both compromises have their pros and cons.  Important is that 
>we are aware that we would have to make this trade-off if we 
>went for ALT.
>
>- Christian
>
>
>
>
>
>--
>to unsubscribe send a message to rrg-request@psg.com 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
>

--
to unsubscribe send a message to rrg-request@psg.com 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