> On Mar 20, 2020, at 7:09 AM, Jon Maloy <jma...@redhat.com> wrote:
> 
> Adding cc to int-area@ietf.org <mailto:int-area@ietf.org>, since I forgot 
> that in my original response.
>  
> 
> On 3/19/20 9:18 PM, Joseph Touch wrote:
>> 
>> 
>>> On Mar 19, 2020, at 4:46 PM, Jon Maloy <jma...@redhat.com 
>>> <mailto:jma...@redhat.com>> wrote:
>>> 
>>>>> IP addresses are no good in the *user API*, because they are location 
>>>>> bound. 
>>>>> That is also why DNS was invented, I  believe. 
>>>> 
>>>> 
>>>> DNS names are intended to be a human-rememberable alias to an IP address. 
>>>> They do not indicate a location any more than an IP address does or does 
>>>> not.
>>> Exactly. Read what I wrote again.
>> 
>> IP addresses are no good in the USER API because they are location bound.
>>      
>>      False. DNS names are provided as an alternative for the user API 
>> because they are easier for people to remember and type.
> Then I should probably rephrase this so saying that "IP addresses AND DNS 
> names and are no good in the user API...", although I don't quite agree with 
> that. DNS names are of course much more convenient for a user to deal with 
> than IP addresses. 

Type in www.google.com <http://www.google.com/>

Now type in its IPv6 address.

Now see if you remember google’s website DNS or its IPv6 address. That’s what 
the DNS was originally intended for.

>>      DNS names are no more or less location-independent than IP addresses.
>> 
>> This is also why DNS was invented...
>> 
>>      False. The reason the DNS exists has nothing to do with location. It’s 
>> simply string substitution for convenience, or at least was ONLY that 
>> originally.
> 
> I think you just supported my case for a location independent addressing 
> scheme.

I am - but then I’m baffled why you want to run direct over IP. Ethernet has 
location independent addresses; IP does not* (see next part).

> This was one of the original motivations for developing TIPC in the first 
> place.  A programmer using TIPC can hard code his service addresses if he 
> wants to, ignoring the number of or location of the corresponding endpoints, 
> even as those move around or scale up/down quite fast.

Anycast gives you location independent addresses at the cost of doing discovery 
“inside the network layer”.

However, even if you have those addresses, you still need to identify the 
service types (which is what we use ports for).

——

I’m still stuck at why you want to run direct over IP. If you want Ethernet 
that bridges across routers, GRE does that. If you want loc-independent 
addresses for services, UDP over IP using anycast does that.

What is the specific gain of needing IP but not allowing a transport? AFAICT, 
it’s all down to GSO - which is an implementation. If GSO doesn’t do what you 
want, it would be useful to take your issues there or edit the code yourself 
and submit the patches.

Joe

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to