Hi Fred, I see AERO and OMNI as examples of technologies trying to fill a gap (or a few gaps), falling exactly in what has been done in the Gap Analysis draft: surveying technologies that are filling gap in the addressing model.
Ìt would be wonderful if you could formulate the gap(s) that AERO and OMNI fill so that this can be added to the analysis in the GA draft. What do you think? Ciao L. > On 2 Dec 2021, at 15:45, Templin (US), Fred L <fred.l.temp...@boeing.com> > wrote: > >> Yes, I agree but I am not convinced we need to solve this by adding the >> complexity in L3 and hence through out the whole of the Internet >> rather than further up the protocol stack. > > AERO and OMNI do not solve this at L3; they solve it in the adaptation layer > (i.e., > lower down the protocol stack). > > Fred > >> -----Original Message----- >> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Stewart Bryant >> Sent: Thursday, December 02, 2021 3:45 AM >> To: Dino Farinacci <farina...@gmail.com> >> Cc: int-area@ietf.org; Dirk Trossen >> <dirk.trossen=40huawei....@dmarc.ietf.org> >> Subject: [EXTERNAL] Re: [Int-area] Side meeting follow-up: What exact >> features do we want from the Internet? >> >> EXT email: be mindful of links/attachments. >> >> >> >> The key question that I would ask Dino is whether these need to be addressed >> at the network layer? >> >>> On 1 Dec 2021, at 22:18, Dino Farinacci <farina...@gmail.com> wrote: >>> >>> Here's my single feature request the network layer should provide: >>> >>> (1) I want to be connected ALL THE TIME, I want my computer to use all its >>> links, either cabled or radio, ALL THE TIME. >> >> It can do this by treating these as independent links with different >> addresses and bind them in the application or through some OS service. >> >>> >>> (2) I do not want to turn on and off wifi to get my device/computer to >>> connect when it is currently not connected. The network layer >> should do all this for me. >> >> Is that a network layer problem or an OS problem? >> >>> >>> (3) I want it easy for people to find me (my IP address), so I don't want >>> multiple addresses from the user level. I want one device ID, EID, >> host address, whatever you want to call it. I want you to "ping >> <dino's-computer>". >> >> It is important that people can find you/your device, but I am not convinced >> they need to find you by historic IP address. >> >> “Pinging” Dino’s computer does not have to happen directly at the network >> layer to find out that it is alive. To test *a* path to Dino’s >> computer sure you need the address that that path responds to, but I am not >> convinced that it is simpler if the address on that network is >> the same as the address on all of the other networks to which it is attached. >> >>> >>> Yes, I want host multi-homing and mobility. And I want it to work >>> seamlessly. >>> >> >> Yes, I agree but I am not convinced we need to solve this by adding the >> complexity in L3 and hence through out the whole of the Internet >> rather than further up the protocol stack. >> >> Stewart >> >> >> >>> Speaking as a user, >>> Dino >>> >>>> On Dec 1, 2021, at 12:52 AM, Dirk Trossen >>>> <dirk.trossen=40huawei....@dmarc.ietf.org> wrote: >>>> >>>> Dear all, >>>> >>>> Many thanks for those participating in the side meeting on Internet >>>> addressing during the IETF 112 week. As suggested during the >> meeting, we want to take various points of discussion during the meeting >> onto the mailing list to continue discussion here on possible ways >> forward. >>>> >>>> Specifically, we wanted to come back on the issue that a larger >>>> architectural discussion may be needed, a point that we make towards >> the end of the GA draft >> (https://datatracker.ietf.org/doc/draft-jia-intarea-internet-addressing-gap-analysis/), >> but which was also core to >> Dirk K’s main point that only such architecture discussion may lead to >> possibly needed changes to addressing. We will be looking into such >> possibly larger discussion along different possible avenues. >>>> >>>> For our discussion here on the INT area list, we found Dino’s related >>>> suggestion particularly useful in that we may need a discussion on >> what we (as users) may want from a network. We feel that our current GA >> draft may contribute to this question by observing that the many >> extensions to Internet addressing that we have gathered so far may be seen >> as an expression of a desired feature that those proposing the >> extension may want to see from the network. Hence, in addition to >> positioning those extensions as identified gaps to Internet addressing, >> we may want to formulate those extensions as desired features towards an >> extended Internet system, not just addressing; this can be done >> through suitably extending the GA draft with another section. >>>> >>>> Why is this useful? We think that such view provides an observational >>>> input into the question that Dino suggests to answer, which in turn >> links to the larger architectural discussion that Dirk K suggests to have. >> While the overall architectural discussion may (and likely will) touch >> on more than ‘just’ addressing, we as a community may contribute to the >> discussion by rationalizing the work that has been done in this >> space. >>>> >>>> We would like to solicit thoughts on this proposed way forward as concrete >>>> steps for the community here on the list. Also, anybody >> wanting to provide concrete input and contribution to this proposed revision >> of the draft is more than welcome. >>>> >>>> Best, >>>> >>>> Dirk >>>> (on behalf of the co-authors) >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
