Re: [RAM] (no subject)

In einer eMail vom 10.06.2007 17:59:30 Westeuropäische Normalzeit schreibt  
rja@extremenetworks.com:

>  Correct me if I am wrong: the IPv6 address space
> does not INCLUDE the  IPv4 address space.

Not correct.  There is a special prefix in  IPv6 that says
the low-order 32 bits are an IPv4 address.   [RFC-4291,
Section 2.5.5.2, Page 10-11]
Thank you Ran

>  One for E.164 (instead of DNS mapping a la enum) ? Etc.  etc.

I believe that it might also be possible to  algorithmically
place an E.164 into an NSAP and then into an IPv6  address
using the special prefix that means an NSAP is in the  low-order
bits of the IPv6 address.  It isn't clear to me  whether
this is explicitly documented at present.

My point here is: By catering multiple address families it becomes more  
obvious that multicast-address range  is the wrong way to indicate "p2mp  
processing". Multicast address range is a bad design principle back from the  early 
beginning.

The discussion on this RAM mailinglist has only Unicast in mind:-( 
The really best solution however will improve the situation for all: p2p  
Unicast, p2p Anycast, p2mp Multicast, mp2p, mp2mp. 

So let's be focused again on routing:

In an email from Lixia on 29.05.2007 05:57:14, _lixia@CS.UCLA.EDU_ 
(mailto:lixia@CS.UCLA.EDU)  it says :

Splitting prefixes is a simple and effective means to achieve  traffic  
engineering goals, and whoever needs to do it will do it. I  believe a  
scalable solution essentially lies on the ability to  effectively (re) 
aggregate prefixes.

my answer was:
...or, just the opposite as I believe, on a design that removes the  pressure 
for doing prefix aggregation totally.

Then silence.

More then ten years ago we worked in the PNNI-WG of the ATM Forum. Georg  
Swallow had already introduced the "UPLINK". A border-to-border node link  
between two peer groups was supposed to be representated by some uplink. That  
uplink was subject to be aggregated to some induced uplink, eventually several  
times in some recursive manner, and finally supposed ´to become part of a  
"higher level horizontal link". The same applied to the neighboring side so that  
from either side the same border-to-border link had to wind up in the same  
higher level horizontal link by either side. 

I was against that link/upling aggregation:
I told the audience,  when we will adjourn the meeting, we  only have to know 
at which city, which hotel and which ballroom the next  meeting will take 
place, and every one is able to get there next time. Based on  this thought the 
Aggregation Token was born, and the horrible topic of  aggregating 
links/uplinks was off the table.

The link/uplink aggregation would have caused, relatively, the same   
scalability problem that this community is about to fight.  So this is just  another 
proof that there is no need to effectively (re) aggregate  prefixes.

Heiner