Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou...

From: [email-masked]
Date: Mon, 27 Nov 2006 12:08:53 EST

"We have had 20 years to get it right..."
 
I am glad that this arch-d list provides the opportunity to openly discuss  
routing & addressing essentials. Some more that breaks with tradition:
Why do we have multicast addresses at all? Since IPv6, we have also Anycast  
addresses.
And what about mp2mp-addresses ? Sorry, I do not speak in favor  of further 
address ranges, but instead in favor of an IP-header  operation-field which 
indicates either Unicast, anycast, multicast(=p2mp), mp2mp  or mp2p. Look, a 
multicast address gives you less information than is given by  the sender's 
unicast address combined with a  Multicast-operation-indication.
We do have multicast address just because we have had them all the time.  
Just like we do have compartments in a train, because the first lok was towing  
coaches:-)
 
Will say that we now have a discussion on what should an address consist of  
and soon we will be backfired by some  problem how shall the  locator for 
multicast look like.
The thing is such simple: There are only addresses. No unicast and no  
other-cast addresses but just simple addresses, which, of course, must not  be 
ambiguous. A particular Multicast-fsm inside the network (still)  needs  to be 
uniquely identified - e.g. with one of the multicast sender's identifiers  
(without the locator) :-)

Heiner

 

  [email-masked]:

We have  had 20 years to get it right and frankly we have avoided 
working on the  problem.  To a large extent we have allowed 
superficial success, i.e.  success in the market and the popular 
press, to be confused as good  science.  They aren't the same thing at 
all.  It is interesting  that most of us would not consider DOS a good 
OS even though it was wildly  successful in the market place, but we 
accept that measure for what we  have created.

This thing can't go on indefinitely as a collection of  band-aids on 
an unfinished demo.  It is far too important for  that.  We have to 
get a good idea what the end state should look like  and then and only 
then begin to consider incremental steps that will take  us there. 
This is arch-d.  Let us do what we know needs to be done  and leave 
the band-aids and kludges to their proper place: on ark  b.

Take care,
John

At 10:18 -0500 2006/11/27, Bound, Jim  wrote:
>Just on this point:
>
>>  If you're going to  go around mucking about with deployed end
>>  point TCP/IP  stacks, then it would probably make more sense
>>  to go back to  the drawing board and come up with IPv7 (IMHO).
>
>I don't  agree.  There can be a transition and it can be done
>transparently  as will any significant change from this effort.  shim6 is
>very  friendly to such a transition as one data point. 
>
>But more  importantly the identifier architecture in shim6 is approaching
>the use  of identifiers far different than for routing.
>
>We need to  define crisply what we want from an identifier for routing
>and how it  works with routing and if it is to be global. 
>
>Also this only  addresses the multihoming problem and the question is if
>that is  addressed in this manner per the IAB Report does this buy us
>more time  to work on the  routing?
>
>/jim
>
>_______________________________________________
>Architecture-discuss  mailing  list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/architecture-discuss

_______________________________________________
Architecture-discuss  mailing  list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: John Day <[email-masked]>
Date: Mon, 27 Nov 2006 16:48:52 -0500

We beat this horse to death several days ago.

At 12:08 -0500 2006/11/27, [email-masked] wrote:
>I am glad that this arch-d list provides the opportunity to openly 
>discuss routing & addressing essentials. Some more that breaks with 
>tradition:
>Why do we have multicast addresses at all? Since IPv6, we have also 
>Anycast addresses.
>And what about mp2mp-addresses ? Sorry, I do not speak in favor 
>of further address ranges, but instead in favor of an IP-header 
>operation-field which indicates either Unicast, anycast, 
>multicast(=p2mp), mp2mp or mp2p. Look, a multicast address gives you 
>less information than is given by the sender's unicast address 
>combined with a Multicast-operation-indication.
>We do have multicast address just because we have had them all the 
>time. Just like we do have compartments in a train, because the 
>first lok was towing coaches:-)
>
>Will say that we now have a discussion on what should an address 
>consist of and soon we will be backfired by some  problem how shall 
>the locator for multicast look like.
>The thing is such simple: There are only addresses. No unicast and 
>no other-cast addresses but just simple addresses, which, of 
>course, must not be ambiguous. A particular Multicast-fsm inside the 
>network (still)  needs to be uniquely identified - e.g. with one of 
>the multicast sender's identifiers (without the locator) :-)
>
>
>
>Heiner
>
>
>
>
>
>
>
>
>   [email-masked]:
>