You missed the point maybe. Common functions should be performed at the waist so applications don’t have to duplicate functionality.
Dino > On Dec 2, 2021, at 2:08 PM, Templin (US), Fred L <fred.l.temp...@boeing.com> > wrote: > > > Your diagram is missing a critical layer – the adaptation layer. > > From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Dino Farinacci > Sent: Thursday, December 02, 2021 1:05 PM > To: Stewart Bryant <stewart.bry...@gmail.com> > Cc: int-area@ietf.org; Dirk Trossen <dirk.trossen=40huawei....@dmarc.ietf.org> > Subject: Re: [Int-area] Side meeting follow-up: What exact features do we > want from the Internet? > > The key question that I would ask Dino is whether these need to be addressed > at the network layer? > > Yes, because of this architectural principle: > > > > > > > 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. > > Its too much complexity for the app. The app is talking to one place and > shouldn't know where it is. Hence the network layer should do this. > > > > > (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? > > Yes, its a network layer problem. The OS is just an implmentation of a > network stack. > > > > > (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. > > I used this example (at the network layer) due to the audience of the list. > What I really want to know is Stewart's crypto wallet address because I want > to send you a donation. That is addressing at a specific app level. > > > “Pinging” Dino’s computer does not have to happen directly at the network > layer to find out that it is alive. To test > > Right but if I want to debug where my crypto transaction is going (I want it > to go from my computer to your computer) then I have to go down a level (to > the network layer), that is as an engineer (not high-level user) to determine > an issue or understand performance. > > > *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. > > There is one network. You are one human being with 2 names. I can call you > Stewart or Mr Bryant. It doesn't matter you will respond but wouldn't it be > better if I called you "my-friend" and packets can go to either Steward or Mr > Bryant? > > I can tell you could react that this is a stretch, but you get what I'm > trying to get across. The physical connection should not matter to the app. > And don't forget the physical connection goes up and down, it gets fast and > slow, it gets address (i.e. locator) changes. That should be damped out from > the app. > > > > > 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. > > You always have to add something to get something. And what you add can be > simple. Just have to make choices very very carefully. > > Dino > > > > 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
