Subject: Re: [arch-d] Whose job is it, anyway?

From: [email-masked]
Date: Tue, 21 Nov 2006 03:49:25 EST

I am also aware of even a product which did routing  location-independently:
It was a military network developed by Siemens whereby a channel was used  
only for sending out search messages all over the (remaining entire) network -  
for each call setup.
That was 35 years ago. Well, it was done in lack of any knowledge  about 
topology determination and may serve now as an example how  NOT to  do. Just the 
opposite: topology determination can and should be improved.
This may start with discussing location identifiers.Can they be improved  ?
User address and router address: How is the binding? Should it stay as it  is 
now ?
Is a single address family enough, or is it more appropriate to cater for  
multiple address families (which requests some AFI) ? VoIP:E164 is done by DNS  
translation.Why not (of course in the future) as one of many families? Is  
there demand for address families by applications which are enabled just by  
futural technologies (sensor technology) ?
And how is the correlation with router addresses ?
Note: On a letter you indicate name and address of the receiver.  Sometimes 
however  a post office resp. P.O.Box number.
 
Heiner Hummel

 
In einer eMail vom 21.11.2006 02:59:35 Westeuropäische Normalzeit schreibt  
[email-masked]:

Dear  Joel,
This looks a good approach. Thx. It might be interesting that you  
detail multi-pathing and multi-homing operations the same. Also  
consider what you think can be end-driven (both ends). Then to  
consider the information needed for each operation, and where can it  
be located.
jfc

At 16:09 20/11/2006, Joel M. Halpern  wrote:

>In watching the discussion of things to be named and how  they are 
>named, I think there are a number of unstated assumptions  people are 
>making.  I think some are agreed.  Some  are subtle enough that I am 
>only going to allude to  them.  But some I think can be usefully 
>surfaced and  discussed on their merits.
>
>For this purpose, I will take  certain things as given.
>1) There ought to be identifiers for certain  objects in the system 
>which are independent of the location of those  objects.  Application 
>instances need to have such  identifiers.
>2) There are (and ought to be) identifiers which are  location 
>dependent.  subnets (and interfaces to subnets)  ought to be 
>identified based on their placement in the network  graph.
>3) It is expected that in most of the net, packet forwarding  will be 
>based on location dependent identifiers  (locators.)
>
>Note, point 3 does not deal with whether that is a  single 
>identifier, a cascade or nested set of identifiers, different  
>locators for local and global use, or any of the many other  
>variations in forwarding paradigms.  It is just saying that  
>forwarding is working in terms of location sensitive  identifiers.  I 
>have seen some research work where that is  not the case.]
>I will use "locator" for an identifier which is location  dependent. 
>(Lots of folks use that, but I don't think we have yet  settled on it.)
>
>If we take that as given, and we assume that  applications normally 
>operate in terms of location, then there are a  couple of interesting 
>tasks for the collective system, and a couple of  operations relating 
>to those tasks.
>
>The tasks  are:
>a) coping with multi-pathing
>b) coping with  multi-homing
>c) coping with mobility
>
>Folks have  sometimes treated various of these as interchangeably 
>solved by the id  / locator split.  While that separation of notions 
>helps us,  it does not "solve" these issues.  It does not even  
>necessitate that these issues be solved in the same  place.
>
>Functionally, one can talk about the functions  of
>i) determining the locator(s) that go with a location independent  identifier
>ii) selecting a locator to use for communication
>iii)  route determination forwarding packets based on that selected  locator
>
>(ii) is sometimes treated as a non-issue, if one  assumes that there 
>is only one such locator.  (ii) is also  sometimes assumed to go in 
>specific places.
>
>Looking at  the tasks above, multi-path is the problem (opportunity) 
>of dealing  with the fact that there are multiple paths to a location 
>across the  network.  We assume (correctly I believe) that coping 
>with  this is the job of the routing / packet forwarding  functions.
>
>On the other end, mobility seems to imply the  changing of the 
>locator(s) associated with a location independent  
>identifier.  Hence, it seems to me that wherever it lives it  is not 
>part of the routing / packet forwarding system.  Yes,  this 
>re-mapping is helped by the separation of  identifiers.  Yes, there 
>can be functions required of packet  handling systems that can help 
>this.  But routing isn't  going to tell you about it, and packet 
>forwarding based on locators  isn't going to cope with it.
>
>The middle task raises, coping  with multi-homing, some interesting 
>questions.  And I think  we have been mixing the answers.  If one 
>assumes that one  can have a singular, meaningful, location dependent 
>identifier for a  (multi-connected) node then one might well expect 
>to use that  identifier in packets, and expect the routing / packet 
>forwarding  system to cope with it.
>If on the other hand, the location dependent  identifiers are 
>associated with subnets / interfaces, then it is hard  to see how 
>locator based forwarding can cope with  this.  Rather, it would seem 
>to be the locator selection  function which has to cope with it.
>
>The question I am wondering  about is, assuming for the moment that 
>it can be made to work either  way, does coping with multi-homing 
>conceptually belong with one or the  other of multi-pathing and 
>mobility?  (We may have to put it  somewhere it does not belong for 
>pragmatic reasons, but it seems  useful to know if that is what we are  
doing.)
>
>Yours,
>Joel M. Halpern
>
>PS: I am  deliberately being vague about where the locator selection 
>function is  being done, and whether it is colocated with the locator  
>determination.  Whether it looks like shim6, GSE, or  something, and 
>whether it is done in the host or in an edge does not,  I think, 
>affect the question  here.
>
>
>_______________________________________________
>Architecture-discuss  mailing list
>[email-masked] (mailto:[email-masked]) 
>_https://www1.ietf.org/mailman/listinfo/architecture-discuss_ 
(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