Hi Robert,

A couple  of comments inline.

From: Int-area <int-area-boun...@ietf.org> On Behalf Of Robert Moskowitz
Sent: Thursday, 6 October 2022 17:37
To: Jens Finkhaeuser <j...@interpeer.io>; Luigi Iannone <g...@gigix.net>
Cc: int-area <int-area@ietf.org>
Subject: Re: [Int-area] Rebooting Addressing Discussion


On 9/30/22 05:20, Jens Finkhaeuser wrote:
Hi all,

since I found myself contributing to the draft, it should be obvious that I'm 
interested in continuing.

I think the proposed steps make a lot of sense. It should be fairly obvious 
that the distinction between identifiers and locators alone helps distinguish 
between what and how, but there is a large range of "whats" identified already 
in these drafts.

From my work at AnyWi with drones (which ties indirectly to the drip WG), it is 
clear that the "what" most​ often should be the drone (i.e. a multi-homed 
device), but it also should sometimes be the specific link - which is still 
different from the locator of its current network attachment.

DRIP WG is concerned with drone identification, and provides a host identifier 
via an ORCHID - but is not specifically solving the multi-homing problem that 
drones have, nor does it currently care about link specific identifiers. (Some 
of that is considered, but out of scope in RFC7401).

The reason I raise DRIP and RFC7401 here is as an example of ongoing work that 
is already finding partial answers to these questions. In the interest of not 
ending up with too many and too different solutions, it would IMHO be 
beneficial to find a common reference framework.

rfc7401 definitely addresses the multi-homed challenge.  And AXEnterprize has 
demostrated this over 2 years ago of WiFi, to LTE, back to WiFi in test flights 
in the NY UAS test corridor.  Plus there were plenty of uses of 7401 way back 
with multi-homing.  DRIP only adds more refinement to the actual HITs used.

I have looked into various aspects variable length addressing when I was under 
contract with Huawei and their FlexIP work.  So I do have some other 
experiences to draw on.


[LI] You have a long experience that is certainly very useful :-)



The IETF is rich in debates on Location/Identity collisions and separation.  I 
wonder what we can bring to these debates at this time?  Can we actually 
produce some wider ranging solutions than HIP/LISP/etal?

[LI] Yes, debates about location/identity and related arguments have gone on 
for a while in the IETF, and as Jens’s email shows different WG may have 
different ways to use addresses and different semantics given to addresses. So 
having a general way to express such different usage and the additional context 
information may be something really useful that we should look at.

Ciao

L.





I am available to contribute.

Bob




Hope that helps,
Jens
------- Original Message -------
On Friday, September 30th, 2022 at 10:36, Luigi Iannone 
<g...@gigix.net><mailto:g...@gigix.net> wrote:


Hi All,

During the last INTArea meeting the discussion on the two drafts related to 
Internet addressing had three the clear outcomes:
1.       The issue seems to go beyond what the INTArea has been chartered for.
2.       The pain points (aka the problem) have to be scoped in a better way. 
In the current form, the scope is so broad that we risk ending up trying to 
boil the ocean without achieving any relevant result.
3.       Incremental deployability remains a MUST. No revolution. Evolution is 
the only option.

Concerning point 1. The documents have been taken out from INTArea (new 
naming). We still continue the discussion on the INTArea mailing list, at least 
temporarily with the option to have a dedicated mailing list in the future.

I would like to restart discuss on point 2: the scope.

The considerations draft 
(https://datatracker.ietf.org/doc/draft-iannone-internet-addressing-considerations/)
 highlighted three properties, namely:
Property 1: Fixed Address Length
Property 2: Ambiguous Address Semantic
Property 3: Limited Address Semantic Support

But before going to the discussion of which property we should/want change the 
first question the comes up is: what does an address identify exactly?

A simple answer would be: an Interface.

But we all know that reality is far more complex, as pointed out with the many 
existing examples in the considerations draft.
What is even more complex is how to provide a wealth of answers to the above 
question within a framework for evolved addressing that does not rely on the 
continued point-wise approach we see in the Internet today.

In order to start specifying what this evolved addressing framework could be, 
the first steps are:
-          paraphrasing Lixia Zhang’s question from the recent RTG WG interim 
meeting as “What should we identify through an address?”
-          scope the work around those answers we believe are most desirable to 
avoid the boiling the ocean issue

Do you believe this is a reasonable approach to move forward?

Luigi




_______________________________________________

Int-area mailing list

Int-area@ietf.org<mailto:Int-area@ietf.org>

https://www.ietf.org/mailman/listinfo/int-area

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

Reply via email to