IntArea WG Agenda IETF 110 - Virtual Friday, March 12, 2021 15:30-16:30 Friday Session II (UTC +1) Chairs: Juan Carlos Zuniga (SIGFOX) Wassim Haddad (Ericsson) Notetakers: Pascal Thubert Shuping Peng # 1. Agenda Bashing, WG & Document Status Updates (Chairs) 5 minutes * Juan Carlos does the usual note-well * No jabber scribe * status update (see slides) * # 2. MADINAS Status Update 5 mins, Juan-Carlos Zúñiga * Juan Carlos describes the problem, lists drafts * expects an interim and then a BoF at IETF 111 * see MADINAS ML # 3. Per-Application Networking Consideration 15 minutes, Tommy Pauly https://tools.ietf.org/html/draft-per-app-networking-considerations-00 * Tommy Pauly presents * Draft discusses the implications of per-app / application-aware networking * Missing an IETF position around the problem space, IETF principles for this case, and requirements * Walking through the draft * examples of app aware networking: LTE APN; walled garden; permission domains; different channel for voice; local resources * the draft discusses network decision (DPI) vs. host decision, pro, cons, mitigations * eg privacy implications if the application declares itself * consideration like broadness of definition of a class / category Q/A: * Dave Thaler: what's the appropriate place? SAAG, DISPATCH, INTAREA? I think INTAREA is the best place for this doc but need reviews from Apps and Security. Happy to help if needed. * Spencer Dawkins: is that engineering or research? people should be crisp on whether this is ready for engineering yet. I recognize that people are engineering solutions in this space now, that's not my question. PANRG (in the IRTF) has been looking at impediments to deployment in the past (in https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/), and trust (whether hosts trusting the network or the network trusting hosts) has been the one consideration that seems intractable. * Tommy: 3 differnet legs: one belongs to IAB for the overall architecture, one is still research in solution space, that's trust between those nodes; and here: what are we doing today? tools we have, ways we think are bad to use those tools * Shuping: thanks for the help on mitigations for Privacy, useful for APN. APN uses groups as suggested here to anonymize. We wish to provide network services, see presentation later. * Tommy: APN has spurred this work but not only; it is a general critique of the space not of APN in particular * Mirja: agree we do not want new IDs. Disagree with using app IDs instead. Lotrs of research there, very hard problem. Need a per case study about what is revealed. easier to say what we should not be doing than what we should be doing * Tommy: appreciate reviews; this is starting place can be refined based on recommendation. * Warren: There is DSCP. My concerns is that it may mitigate the privacy, but when the user only has one choice, it doesnot help them at all. * Toerless: Like to see discusions on ML. NO reply there. A lot of the work we've seen from vendors is not only open internet but for limited domains which can go as far as a home network connected to the ISP with specific contracts and specific security / agreements. Classification of deployment models would be useful. * Tommy: Thank you. * Zhenbin Li: Agree with that we should not indicate individul applicaitons. It is also very difficult for the network to process. When doing the APN work, we also investigate the network scenario, there are entreprise network. They can control their network end-to-end. This is different from the Internet scenario. We would like to get response from the Internet domain people. The limited domain should also be considered. * Tommy: I do think the limited domain fits well. I do believe there is a gap. Something needs to be done. * Juan: Vivid interest - The authors / chairs / AD will check with the charter and coordination with other WGs before doing a adoption call * Spencer notes in Jabber that this would make a smashing topic for an INTAREA interim meeting before IETF 111, if the charter allows it. That would give more time for discussion, and allow participation by everyone in the IETF that needs to participate. # 4. SCHC over PPP 5 minutes, Pascal Thubert https://tools.ietf.org/html/draft-thubert-intarea-schc-over-ppp * Pascal Thubert presents * Co authors? * Add applicability statement? * Possible extensions? * Ask for adoption Q/A: * Juan: Encourage people to discuss in the mailing list. * Pascal: Want to ask for adoption * The chair started the poll on who read this draft. * HOW MANY PEOPLE HAVE READ DRAFT-THUBERT-INTAREA-SCHC-OVER-PPP ? RAISE HAND 6, DO NOT RAISE HAND 21, PARTICIPANTS 107. * Need more discussions to make sure we are going to the right path. # 5. APN: Application-ware Networking 20 minutes, Shuping Peng https://tools.ietf.org/html/draft-peng-apn-scope-gap-analysis * Today's purpose: suggested by IESG to present here, past discussions happened here. Active discussions on the ML. Need to collect feedback to address the concerns. * See slides on what how * Typical domain is a service provider domain. Within that domain the operator can apply his services. When hte packet leaves the domain, the attribute is removed. * what APN is not * The network does not need to know APP or User ID; it's all opaque IDs * APN is not one of listed technologies; it operates at network layer * example of SD WAN. Net operators can provide network SLA to access the cloud * need to steer the traffic at headend over the correct path for this app's SLA * could be TLVs but that's trouble for hardware * 5 tuple non obvious eg when tunneling * how? Place attribute at network edge in network layer. Single field to make decision. Not only for underlay but also overlay. * existing fields are tied to solutions. APN defines a generic attribute. * presented at Dispatch and ART # 6. Challenging Scenarios and Problems in Internet Addressing 10 minutes, Yihao Jia https://datatracker.ietf.org/doc/draft-jia-intarea-scenarios-problems-addressing/ * See slides * authors want to talk about emerging needs for internet addressing beyond IPv6. Adjourning Codimd CHAT INTAREA at IETF 109 Bob Hinden Good morning09:27:27 I can hear you09:27:53 Éric Vyncke No volunteer for minute taking ?09:30:22 Bob Hinden Are there slides? Note well is usually shown.09:32:08 David Black yes, slides coming through ...09:32:33 Alexandre Petrescu I agree, normally there should be a Note Well shown. That is of IETF. It says many interesting things about which we all do agree.09:33:35 Bob Hinden Agenda slide?09:33:45 David Black There are slides being shown note well was shown, agenda slide is up now.09:34:03 Alexandre Petrescu Was the Note Well slide displayed?09:34:15 David Black Yes.09:34:20 Bob Hinden Not seeing anything, am I the only one?09:34:26 Andrew Campling Slides are fine for me09:34:40 David Black I am (obviously) seeing slides ...09:34:43 Alexandre Petrescu Click the upper leftmost rectable showing person and screen?09:34:47 Peter van Dijk Bob, try clicking the first button in the button bar on the top09:34:49 Bob Hinden That was it, I was in the wrong view :-(09:35:18 Need more coffee....09:36:05 David Black I've had many mornings like that ...09:36:21 Mirja Kühlewind too bad that pearg conflicts with this meeting as they talk about ip address privacy09:37:26 BEHCET SARIKAYA Q to JC: April meeting online?09:37:37 Éric Vyncke @Mirja indeed :-(09:38:13 BEHCET SARIKAYA I mean for Madinas09:38:13 Éric Vyncke @Behcet: yes of course ;-)09:38:23 BEHCET SARIKAYA @Eric thanks09:39:48 Alexandre Petrescu It is interesting to talk about ip address privacy, but not interesting to call an IPv6 address a private address like RFC1918 does :-)09:40:16 Andrew Campling DPI doesn't scale so well either09:44:23 Bob Hinden Isn't application aware networking, just the opposite from Network Neutrality?09:44:36 Dave Thaler depends on whether the app is in control or the operator09:44:53 Dirk Kutscher Mostly ;-)09:44:56 Mirja Kühlewind not if there is consent from the client09:44:57 Dave Thaler e.g., is diffserv with DSCP set by the host the opposite of net neutrality or not09:45:19 Éric Vyncke I guess that net neutrality is for the Internet while APN is for private (read enterprise intranet)09:45:20 Andrew Campling @Mirja Probably user rather than client?09:45:41 Dirk Kutscher right09:45:49 "the client" -- app that the user cannot control09:46:07 Alexandre Petrescu In 6GIP it was said also Interface Neutrality - maybe app-aware networking is contrary to Interface Neutrality as well.09:46:33 David Black Definitely hearing use case around interface/network selection per-application09:47:15 Dave Thaler the term "game" is not will defined. charactistics like "latency sensitive" "real-time" are.09:48:22 Bob Hinden This is a good talk!09:48:25 Dave Thaler well09:48:27 Éric Vyncke @Bob +1 (as usual with Tommy)09:48:51 Alexandre Petrescu It's hard to define. Even at the beginning of this presentation, it was said a phone is on multiple networks, like VoLTE, cellular data and WiFi. But Vo_LTE_ and cellular data is the same thing. In the ennd there are just two ifaces about much data in a smartphone, and they are so different that there is no possiility to make them look alike to apps: there are different apps. Apps are more cellular-oriented or more wifi-oriented.09:49:20 Gorry Fairhurst We've seen similar things in tsvwg in the past - the key will be finding what can be claimed about apss/flows and can be used.09:50:02 One of the big questions in the past was "what do you claim you are" versus "what do you claim you want".09:50:52 Transport is interested in QoS also....09:51:09 Bob Hinden +1 to adopt in Internet Area.09:51:27 Dave Thaler TAPS would be another place that this touches on, so transport area review as well09:52:11 Éric Vyncke Hum unsure about TAPS09:52:39 Dave Thaler this shouldn't go in taps, but is relevant to it in some ways09:52:58 Éric Vyncke W/o any hat: it seems either intarea or saag09:53:05 @Dave; ok, it touches indeed many WG ;-)09:53:20 Dave Thaler like the ability to apps to specify what network to go on, and what quality they want is discussed in taps09:53:22 David Black @Dave +1 on Transport Area, but agree w/Eric on appropriate venue likely being somewhere other than TAPS.09:53:28 Dave Thaler yes I think INTAREA is best place, just saying to inform other groups this is where the discussion is09:53:48 Juan-Carlos Zúñiga We are stopping the queue09:54:21 Éric Vyncke @Dave Thaler: we agre09:54:21 Dave Thaler so at least: dispatch, saag, and taps (probably others) should be made aware09:55:21 Dirk Kutscher agree to gap analysis as a first activity on this09:55:23 Erik Kline one of these APN proposals still has app id and use id fields, iirc09:56:37 user*09:56:47 Spencer Dawkins If it helps to include this in the notes, the PANRG draft I was referring to is https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/.09:57:19 Do the right thing, of course ...09:57:30 Dave Thaler the doc in DISPATCH was https://datatracker.ietf.org/doc/draft-peng-apn-scope-gap-analysis09:57:55 David Black Which is also coming up soon in this meeting.09:58:30 Dave Thaler and in SAAG draft-peng-apn-security-privacy-consideration09:58:35 Alexandre Petrescu This makes me think that the use of APN term might be confusing at times. I sometimes work with some operator that routinely puts up app-specific APNs, i.e. an APN for this kind of app or this other APN for that other application, or domain of applications. That's an APN access point name.09:58:35 Dave Thaler to chairs: next steps? call for adoption? need more discussion? (I'm for adopting)10:00:05 Éric Vyncke (after checking with the charter of course)10:00:38 Dirk Kutscher Better not make any recommendation yet. I'd rather like to see a crisp description of the objectives -- and then a discussion about what is missing, and whether better controllable interface selection and a modern QoS system would not suffice.10:00:43 Spencer Dawkins I do note that this would be a SMASHING topic for an INTAREA virtual interim before IETF 111, since we've got several months and we know multiple areas are going to be involved ...10:01:46 Dave Thaler @dirk the draft is about considerations not solutions per se10:02:08 Jim Reid Capturing those considerations will provide the foundations for future work. Got to start somewhere...10:03:18 Dirk Kutscher Yes, that's good.10:03:21 Eduard V It looks like the policy. It is a double-edged sword. Future performance in standards development in exchange for flexibility. Usefulness would depends very much on the quality of the policy itself.10:04:10 Joel Halpern Limited domains for actual applications seem to inevitably stop being limited domain.10:05:23 Dave Thaler for whre: it's actually the style of doc we've done as IAB documents (like Architectectural Considerations of Anycast for example) but IETF stream is stronger than IAB stream so I support INTAREA.10:05:52 Erik Kline I often feel like "limited domain" is a somewhat abused term. A nation-wide incumbent carrier network with a huge market share can be called a "limited domain", but the market power they can exercise goes well outside that domain10:05:54 Éric Vyncke @Joel: s/actual/current/ ?10:06:10 Bob Hinden +1 to Erik.10:06:59 Éric Vyncke @erik: as long it is transparent to the incumbent/monopolistic provider user, then isn't this a 'limited domain ' (e.g., MPLS core)10:07:49 Erik Kline I'm not sure what "transparent" here is implying. The ability for extraordinarily large "limited domains" to effectively force nodes at the edge of that domain to alter their behaviour is what I think escapes the domain10:10:17 Éric Vyncke forcing node outside to change behavior is indeed not a limited domain anymore10:10:56 Joel Halpern @Eric Vynke - history suggests that every time we thought we had an application for a limited domain, it turned out to be used over broader scopes. There may be a few very rare applications that inherently need certain limiting properties. All I know is when we have tried to guess that in the past, we have been wrong.10:11:57 Dirk Kutscher There can be "limited domain networks", but I'd try to avoid using the term "limited domain" for motivating deviations from Internet principles and security best practices, for the reasons that Erik mentioned.10:12:10 Éric Vyncke @Joel fair enough10:12:26 David Black +110:14:39 Alexandre Petrescu But for 'limited domain' term there is an Internet Draft. If other term should replace it, is there an I-D for it?10:18:39 Dave Thaler doesn't say APN is not Diffserv, so presumably it can be diffserv (DSCP)10:19:50 (that came up in dispatch and saag chat)10:20:10 David Black DetNet (Deterministic Networking) may be an example where limited domain app and network scopes mostly line up.10:20:13 Éric Vyncke based on the topology show, indeed10:20:16 of course, how to decide which tag is interesting problem10:20:35 David Black Based on current slide, wonder whether DSCP has enough flexibility.10:21:25 Adrian Farrel Not enough bits?10:21:41 Dave Thaler right one person said "so... DSCP with more bits"? (and I said "IPv6 flowlabel?)10:21:47 frodek IMHO it should be renamed "Network Policy Tokens", not "Application Aware Networking".10:21:51 David Black Too much convention in how values are typically used ...10:21:57 Alexandre Petrescu There is a draft about tokens and QoS in future networks10:22:17 Dirk Kutscher How many equivalence classes are expected here?10:22:35 Adrian Farrel Should the discussion of the purpose and value of the idea be separated from "how we squeeze this into the bit on the wire"?10:22:37 David Black Yes, have seen need for that in another context.10:22:52 Éric Vyncke @Frodek: this will make easier any adoption probably10:22:56 Adrian Farrel @alex that is network tokens, I think10:22:59 Slide said "this is not network tokens"10:23:10 Dave Thaler "1 field in the IP layer" is the part I said "so IPv6 flowlabel?"10:23:47 Adrian Farrel is that consistent with "current" uses of flow label?10:24:15 Dirk Kutscher Ah!10:24:16 Dave Thaler point 210:24:26 this slide is the survey10:24:35 Adrian Farrel oh yes, rtfslides :-(10:24:55 Dave Thaler in saag one discussion (from ekr I think) was about whether user id was, or was not, one of the discriminators. I think one slide said no, and this slide implies yes10:26:10 David Black slide implies "definite maybe" as I read it ...10:26:50 Benjamin Schwartz It seems like each SLA could be encoded as an IPSec tunnel10:27:15 Choose your tunnel to adjust SLA10:27:34 Dave Thaler ekr's (I think it was) is that the ansewr affects lots of other things, so need to know10:27:35 Éric Vyncke IMHO it not so much about HOW to tag but on WHAT the tag selection is based10:27:53 Joel Halpern And this again assumes that things are in limited domains.10:28:04 Erik Kline (8799 was ISE)10:28:17 Ole Trøan Rename intarea to ltdarea?10:28:25 Dave Thaler @Eric right, that was the gist of the saag discussion10:28:29 frodek is this motivated by a wish to preserve "5G slice semantics" outside the 5G domain. I.e. a large number of "slice semantic" and a need to a large number of "policy identifieers"10:28:37 Juan-Carlos Zúñiga @Toerless, point taken about the lack of time - although very hard to manage when requests to present arrive VERY late and once the meeting time has already been planned. We will send a note on the ML on this regard to try to solve the issue for upcoming meetings10:29:29 Erik Kline I think we need a "limited domains considered harmful" alternative to ISE 879910:30:06 Dave Thaler I pointed out in saag that in many use cases you get the user id without it being communicated in any field of the packet, but as a property of the L2 ingress link, as acquired at link authentication time (in 1x, ppp, 5g, etc.)10:30:22 David Black "Send Draft!" (w/credit to Randy Bush) ...10:30:29 Adrian Farrel This work meshes nicely with some routing research work we are looking at (presented in RTGWG yesterday) with early draft at draft-king-irtf-challenges-in-routing-0110:30:44 Dirk Trossen +110:30:54 Tommy Pauly @Erik +1 =)10:30:58 Dave Thaler so could be a discriminator (for good or bad) without DPI per se10:31:02 Joel Halpern I would have liked to see some description of the problems in a presentation that says there are problems. Looking at the draft, I did not understand what problems the authors thought needed to be addressed.10:31:41 Tommy Pauly Indeed, it's not stating any actual problem here.10:32:01 Éric Vyncke and this presentation did not help :-(10:32:08 Alexandre Petrescu There are obviously some problems in some WGs that relate to addressing...10:32:15 Adrian Farrel My fear is the problems are in routing :-)