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.
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?
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> 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
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
