Re: [rrg] IPv4 & IPv6 routing scaling problems

[[e-mail]]

 
In einer eMail vom 13.02.2010 00:36:52 Westeuropäische Normalzeit schreibt  
[e-mail]:

On Feb  12, 2010, at 12:54 PM, [e-mail] wrote:

> 
> A  corner stone of TARA is the computation of consistent topologies for 
the  various zooms (just by knowing the standardized scale  
ratio).http://www.ietf.org/proceedings/74/slides/grow-6.pdf refers to Route  Reflectors (and 
what they cause). I do observe: IETF- routing experts only  know to deal 
with either full mesh overlay networks or with star-overlay  networks (e.g.RR). 
 But not how to provide properly skimmed  representative overlay networks 
of any scale ratio in-between:-(

That's  because they're constrained by the rules of the routing 
protocol employed,  in this case rules inherent to BGP (path vectors)
for loop avoidance.   If you've some magical way to work around 
this in production networks  we're all ears ;-)

-danny


Brian is wrong by stating "Forget Dijkstra" (first sentence of some  
powerpoint presentation of him)
Just the opposite: Forget DV ! Improve Dijkstra and apply it also  
inter-domain! By disseminating (TARA-)links of a handful different zooms by  means 
of enhanced BGP-UPDATE messages! And do use hereby routable data  
(TARA-locators) rather than just mappable data.
 
And loops? My impression is: People are fond of loops.
I remember a dispute with Joel, about 10 years ago. Scenario: A  triangle 
shaped PNNI-network consisting of the 3 nodes A, B, and C. A and B  belong to 
peer group PG1, C belongs to peer group PG2.
Peer group PG1 partitions, i.e. the link between A and B breaks. My  
solution was to compute a source routing information (DTL stack) to detour via C  
in order to get from A to B. Joel heavily opposed this idea because it 
formed a  loop: from PG1 to PG2 back to PG1. Today I see opposition against TARA 
because  the network inside a geopatch might partition. Yes, this may 
happen. But dealing  with partitions starts with getting from one partition to the 
other. And I can  only offer a loop: out to some neighbor geopatch, from 
there back to the other  partition of the own geopatch.
 
Heiner