Got it. Will follow this.
On 10/6/22 18:06, Templin (US), Fred L wrote:
Thanks Bob, but to pick a commonly-seen nit (and not just from you in
particular)
AERO and OMNI are both always written in all-caps as they are acronyms
the same
as HIP and LISP. “Aero” is not the thing that I work on and has no
meaning in these
discussions; the thing I work on which has meaning here is called:
“AERO”.
*From:*Robert Moskowitz [mailto:rgm-i...@htt-consult.com]
*Sent:* Thursday, October 06, 2022 1:42 PM
*To:* Templin (US), Fred L <fred.l.temp...@boeing.com>; Jens
Finkhaeuser <j...@interpeer.io>; Luigi Iannone <g...@gigix.net>
*Cc:* int-area <int-area@ietf.org>
*Subject:* [EXTERNAL] Re: [Int-area] Rebooting Addressing Discussion
Sorry, Fred, I responded quickly and did not include Aero. But then
my analysis of it is still weak. I need to dig deeper into it.
On 10/6/22 16:20, Templin (US), Fred L wrote:
>Can we actually produce some wider ranging solutions than
HIP/LISP/etal?
There is AERO/OMNI which IMHO are wider ranging solutions. If
folks haven’t
looked at them recently they probably should now (IP parcels too).
*From:*Int-area [mailto:int-area-boun...@ietf.org
<mailto:int-area-boun...@ietf.org>] *On Behalf Of *Robert Moskowitz
*Sent:* Thursday, October 06, 2022 8:37 AM
*To:* Jens Finkhaeuser <j...@interpeer.io>
<mailto:j...@interpeer.io>; Luigi Iannone <g...@gigix.net>
<mailto:g...@gigix.net>
*Cc:* int-area <int-area@ietf.org> <mailto: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.
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> <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
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
