IETF
APN
apn@jabber.ietf.org
Friday, July 30, 2021< ^ >
Room Configuration
Room Occupants

GMT+0
[18:31:32] Meetecho joins the room
[18:36:18] mcr joins the room
[18:45:07] Dan Voyer_web_901 joins the room
[18:45:07] Lorenzo Miniero_web_404 joins the room
[18:45:07] Bob Hinden_web_410 joins the room
[18:45:07] Dhruv Dhody_web_740 joins the room
[18:45:07] Adrian Farrel_web_934 joins the room
[18:45:07] Dirk Hugo_web_914 joins the room
[18:45:07] Shuping Peng_web_302 joins the room
[18:46:33] Bob Hinden_web_410 leaves the room
[18:46:47] dhruvdhody joins the room
[18:47:02] meetecho-alexamirante joins the room
[18:47:16] Jim Guichard_web_804 joins the room
[18:47:40] Bob Hinden_web_187 joins the room
[18:49:27] Kazuaki Ueda_web_615 joins the room
[18:50:06] Ron Bonica_web_687 joins the room
[18:50:30] Bruno Decraene_web_217 joins the room
[18:51:15] Gang Yan_web_392 joins the room
[18:51:58] Luigi Iannone_web_372 joins the room
[18:52:00] David Millman_web_293 joins the room
[18:52:03] Hirochika Asai_web_459 joins the room
[18:52:10] <Bob Hinden_web_187> Hello
[18:52:19] <Dan Voyer_web_901> yes
[18:52:29] Xiao Min_web_772 joins the room
[18:52:32] dhruvdhody has set the subject to: IETF 111 APN BOF
[18:52:38] Erik Kline_web_730 joins the room
[18:52:44] Loa Andersson_web_368 joins the room
[18:52:47] <dhruvdhody> Me!
[18:52:53] Daniel King_web_174 joins the room
[18:53:11] <Adrian Farrel_web_934> Dhruv proves his usefulness yet again
[18:53:13] Frode Kileng_web_428 joins the room
[18:53:27] Nalini Elkins_web_833 joins the room
[18:53:28] <dhruvdhody> :-D
[18:53:38] Watson Ladd_web_701 joins the room
[18:53:39] Huaimo Chen_web_590 joins the room
[18:53:39] Zhenbin Li_web_980 joins the room
[18:53:39] Liu Yao_web_262 joins the room
[18:53:42] Stewart Bryant_web_274 joins the room
[18:53:46] Ketan Talaulikar_web_700 joins the room
[18:54:08] Olaf Kolkman_web_121 joins the room
[18:54:24] sheng fang_web_191 joins the room
[18:54:27] Stefano Previdi_web_646 joins the room
[18:54:48] Hongwei Yang_web_546 joins the room
[18:54:54] <Bob Hinden_web_187> Thanks
[18:55:01] Joel Halpern_web_736 joins the room
[18:55:02] Ted Hardie_web_764 joins the room
[18:55:13] Olaf Kolkman_web_121 leaves the room
[18:55:14] Gang Yan_web_392 leaves the room
[18:55:16] Philip Eardley_web_494 joins the room
[18:55:18] Olaf Kolkman_web_932 joins the room
[18:55:19] Scott Mansfield_web_137 joins the room
[18:55:26] Yingzhen Qu_web_646 joins the room
[18:55:27] Mazen Khaddam_web_167 joins the room
[18:55:53] Michael Richardson_web_958 joins the room
[18:56:07] Hongwei Yang_web_546 leaves the room
[18:56:11] Ted Hardie_web_764 leaves the room
[18:56:21] Russ White_web_329 joins the room
[18:56:23] Peng Liu_web_158 joins the room
[18:56:36] Ted Hardie_web_575 joins the room
[18:56:45] Wim Henderickx_web_410 joins the room
[18:56:53] Yoshifumi Atarashi_web_650 joins the room
[18:56:58] Carsten Bormann_web_132 joins the room
[18:57:00] Jen Linkova_web_744 joins the room
[18:57:01] Chongfeng Xie_web_787 joins the room
[18:57:02] John Drake_web_368 joins the room
[18:57:11] Srihari Sangli_web_131 joins the room
[18:57:16] Martin Vigoureux_web_135 joins the room
[18:57:18] Ike Kunze_web_708 joins the room
[18:57:20] Jie Dong_web_139 joins the room
[18:57:24] John Drake_web_368 leaves the room
[18:57:24] Mark McFadden_web_265 joins the room
[18:57:26] Tadahiko Ito_web_316 joins the room
[18:57:28] John Drake_web_482 joins the room
[18:57:36] Ville Hallivuori_web_757 joins the room
[18:57:38] Justin Iurman_web_849 joins the room
[18:57:39] Y. Richard Yang_web_225 joins the room
[18:57:41] John Kaippallimalil_web_664 joins the room
[18:57:45] Wesley Eddy_web_858 joins the room
[18:57:45] Cullen Jennings_web_768 joins the room
[18:57:59] Luis Contreras_web_441 joins the room
[18:58:04] Giuseppe Fioccola_web_327 joins the room
[18:58:05] Alvaro Retana_web_722 joins the room
[18:58:23] Haibo Wang_web_115 joins the room
[18:58:25] <mcr> do a mic test!
[18:58:32] John Scudder_web_779 joins the room
[18:58:44] Jeffrey Haas_web_126 joins the room
[18:58:45] Feng Yang_web_394 joins the room
[18:58:52] Jingrong Xie_web_938 joins the room
[18:58:52] Linda Dunbar_web_489 joins the room
[18:58:52] Eckard Bogenfeld_web_496 joins the room
[18:58:53] Boris Khasanov_web_722 joins the room
[18:58:53] Takuya Miyasaka_web_704 joins the room
[18:58:57] Daniel Bernier_web_884 joins the room
[18:58:58] Shu-Fang Hsu_web_808 joins the room
[18:59:08] Chonggang Wang_web_328 joins the room
[18:59:08] Gyan Mishra_web_159 joins the room
[18:59:14] <mcr> Adrian, I am more interesting in the general decor.
[18:59:17] Aihua Guo_web_687 joins the room
[18:59:21] John Scudder_web_779 leaves the room
[18:59:24] Rick Taylor_web_700 joins the room
[18:59:26] Gang Yan_web_172 joins the room
[18:59:27] <Jeffrey Haas_web_126> Adrian, just means you're not spending enough time authoring books.
[18:59:28] <mcr> Like , look at the interesting colours of your books.
[18:59:31] Zongpeng Du_web_361 joins the room
[18:59:31] cabo joins the room
[18:59:32] Tianji Jiang_web_508 joins the room
[18:59:34] Tarek Saad_web_966 joins the room
[18:59:35] Shuai Zhang_web_941 joins the room
[18:59:42] Benjamin Kaduk_web_615 joins the room
[18:59:44] <mcr> @jeffrey, or maybe he wants to know how many of us have his book?
[18:59:48] Xiao Cui_web_842 joins the room
[18:59:48] <Jen Linkova_web_744> Yeah, my reading reduced dramatically too - no more 14hrs flights..;(
[18:59:50] Antoine Fressancourt_web_388 joins the room
[18:59:52] Richard Li_web_959 joins the room
[18:59:52] Donald Eastlake_web_106 joins the room
[18:59:55] Eric Kinnear_web_641 joins the room
[18:59:58] Antoine Fressancourt_web_388 leaves the room
[18:59:58] John Scudder_web_873 joins the room
[18:59:59] Renan Krishna_web_694 joins the room
[18:59:59] Tony Przygienda_web_515 joins the room
[19:00:02] Antoine Fressancourt_web_108 joins the room
[19:00:04] <Olaf Kolkman_web_932> Aha it is a trick... When I zoom into your bookshelf Adrian I see books you authored...  you want us to buy your books !
[19:00:10] Alexander Clemm_web_354 joins the room
[19:00:15] Robert Wilton_web_169 joins the room
[19:00:15] Lin Han_web_866 joins the room
[19:00:18] Andrew Stone_web_320 joins the room
[19:00:20] Tom Hill_web_186 joins the room
[19:00:21] Zhaohui Zhang_web_834 joins the room
[19:00:21] Greg White_web_341 joins the room
[19:00:23] Greg Wood_web_642 joins the room
[19:00:28] Balazs Varga_web_940 joins the room
[19:00:35] John Border_web_857 joins the room
[19:00:40] Srihari Sangli_web_131 leaves the room
[19:00:46] Srihari Sangli_web_710 joins the room
[19:00:48] Yuji Tochio_web_972 joins the room
[19:00:51] Andrew Stone_web_320 leaves the room
[19:00:53] Frode Sorensen_web_708 joins the room
[19:00:54] Eduard V_web_805 joins the room
[19:00:55] Andrew Stone_web_209 joins the room
[19:00:59] Peter Campbell_web_172 joins the room
[19:01:03] Hermin Anggawijaya_web_197 joins the room
[19:01:10] János Farkas_web_859 joins the room
[19:01:18] Daniel Huang_web_612 joins the room
[19:01:20] Charles Eckel_web_741 joins the room
[19:01:21] Greg Wood_web_642 leaves the room
[19:01:23] Jim Uttaro_web_649 joins the room
[19:01:33] Martin Horneffer_web_889 joins the room
[19:01:33] Greg Wood_web_561 joins the room
[19:01:34] Yang Guo_web_718 joins the room
[19:01:36] Zhibo Hu_web_638 joins the room
[19:01:36] Kireeti Kompella_web_499 joins the room
[19:01:37] Lou Berger_web_111 joins the room
[19:01:40] Xiao Cui_web_842 leaves the room
[19:01:41] Mike McBride_web_873 joins the room
[19:01:42] Deborah Brungard_web_195 joins the room
[19:01:42] David Black_web_656 joins the room
[19:01:49] Eve Schooler_web_533 joins the room
[19:01:51] Julien Maisonneuve_web_989 joins the room
[19:01:58] Eric Voit_web_966 joins the room
[19:02:02] Hannu Flinck_web_445 joins the room
[19:02:04] Greg Mirsky_web_877 joins the room
[19:02:06] Chris Bowers_web_241 joins the room
[19:02:10] Haoyu Song_web_176 joins the room
[19:02:11] frodek joins the room
[19:02:18] James Galvin_web_259 joins the room
[19:02:21] Jari Arkko_web_150 joins the room
[19:02:23] Scott Mansfield_web_137 leaves the room
[19:02:23] Gorry Fairhurst_web_252 joins the room
[19:02:25] Kentaro Ebisawa_web_403 joins the room
[19:02:31] Scott Mansfield_web_836 joins the room
[19:02:39] Sergey Fomin_web_937 joins the room
[19:02:42] János Farkas_web_859 leaves the room
[19:02:43] Kiran Makhijani_web_850 joins the room
[19:02:51] János Farkas_web_454 joins the room
[19:02:57] Kiran Makhijani_web_850 leaves the room
[19:03:01] Kiran Makhijani_web_245 joins the room
[19:03:05] Bhavit Shah_web_144 joins the room
[19:03:09] Bhavit Shah_web_144 leaves the room
[19:03:11] Diego Lopez_web_692 joins the room
[19:03:11] Bhavit Shah_web_165 joins the room
[19:03:13] Spencer Dawkins_web_685 joins the room
[19:03:22] Ruixue Wang_web_825 joins the room
[19:03:24] Anna Blasiak_web_675 joins the room
[19:03:28] kaduk@jabber.org/barnowl joins the room
[19:03:36] <Kireeti Kompella_web_499> is "mute you all" a mutual sentiment?
[19:03:39] Francois Clad_web_717 joins the room
[19:03:44] Cong Li_web_541 joins the room
[19:03:46] Lars Eggert_web_364 joins the room
[19:03:47] Yuefeng Qiu_web_196 joins the room
[19:03:47] Enke Chen_web_811 joins the room
[19:03:48] Roland Bless_web_943 joins the room
[19:03:58] Chenhao Ma_web_595 joins the room
[19:04:06] Jiao Kang_web_938 joins the room
[19:04:10] Jiao Kang_web_938 leaves the room
[19:04:11] Jiao Kang_web_787 joins the room
[19:04:12] Shraddha Hegde_web_654 joins the room
[19:04:14] <Watson Ladd_web_701> i'm skeptical about this plan
[19:04:22] Zhe Lou_web_621 joins the room
[19:04:24] Cengiz Alaettinoglu_web_967 joins the room
[19:04:25] km joins the room
[19:04:46] Wen Lin_web_190 joins the room
[19:05:03] Carlos Bernardos_web_961 joins the room
[19:05:08] Rüdiger Volk_web_461 joins the room
[19:05:10] Hesham ElBakoury_web_611 joins the room
[19:05:20] Mirja Kühlewind_web_852 joins the room
[19:05:21] <Daniel King_web_174> Then we should seek a mutual settlement.
[19:05:22] Ahmed Bashandy_web_129 joins the room
[19:05:30] Ian Duncan_web_933 joins the room
[19:05:37] Kausik Majumdar_web_729 joins the room
[19:05:38] Stefano Previdi_web_646 leaves the room
[19:05:40] Ole Trøan_web_943 joins the room
[19:05:42] Stefano Previdi_web_594 joins the room
[19:05:49] Alissa Cooper_web_439 joins the room
[19:05:58] Stefano Previdi_web_594 leaves the room
[19:05:59] Uma Chunduri_web_827 joins the room
[19:06:02] Stefano Previdi_web_585 joins the room
[19:06:11] Mike Koldychev_web_976 joins the room
[19:06:13] Luay Jalil_web_593 joins the room
[19:06:21] Jordan Head_web_562 joins the room
[19:06:43] Jordan Head_web_562 leaves the room
[19:06:45] Fan Yang_web_829 joins the room
[19:06:49] Jordan Head_web_771 joins the room
[19:07:47] Martin Duke_web_984 joins the room
[19:07:59] Ehsan Hemmati_web_626 joins the room
[19:08:00] Christian Hopps_web_861 joins the room
[19:08:07] Ehsan Rezaaifar_web_910 joins the room
[19:08:08] Fengwei Qin_web_134 joins the room
[19:08:14] Giuseppe Fioccola_web_327 leaves the room
[19:08:16] Frédéric Fieau_web_783 joins the room
[19:08:22] Jordi Domingo-Pascual_web_802 joins the room
[19:08:35] Srihari Sangli_web_710 leaves the room
[19:08:40] Giuseppe Fioccola_web_724 joins the room
[19:08:41] Srihari Sangli_web_517 joins the room
[19:08:43] Paul Bottorff_web_233 joins the room
[19:08:44] Toerless Eckert_web_192 joins the room
[19:09:32] Jordan Head_web_771 leaves the room
[19:09:36] Jordan Head_web_133 joins the room
[19:09:51] Matthew Quick_web_828 joins the room
[19:10:20] Mach Chen_web_786 joins the room
[19:10:25] Cedric Westphal_web_342 joins the room
[19:10:50] Nigel Davis_web_606 joins the room
[19:11:24] John Kaippallimalil_web_664 leaves the room
[19:11:34] John Kaippallimalil_web_876 joins the room
[19:11:35] Yiannis Yiakoumis_web_302 joins the room
[19:11:47] Mach Chen_web_786 leaves the room
[19:11:52] Nigel Davis_web_606 leaves the room
[19:11:56] Nigel Davis_web_681 joins the room
[19:12:23] Joey Salazar_web_755 joins the room
[19:12:28] Mach Chen_web_794 joins the room
[19:12:33] Deborah Brungard_web_195 leaves the room
[19:12:37] Deborah Brungard_web_187 joins the room
[19:12:59] Jana Iyengar_web_243 joins the room
[19:13:57] Dawei Fan_web_662 joins the room
[19:14:39] Yali Wang_web_354 joins the room
[19:14:43] Srihari Sangli_web_517 leaves the room
[19:14:49] Srihari Sangli_web_133 joins the room
[19:14:59] Ehsan Hemmati_web_626 leaves the room
[19:15:01] Matthew Quick_web_828 leaves the room
[19:15:04] Srihari Sangli_web_133 leaves the room
[19:15:10] Srihari Sangli_web_780 joins the room
[19:15:20] Matthew Quick_web_769 joins the room
[19:15:23] Xavier de Foy_web_277 joins the room
[19:15:24] Boris Khasanov_web_722 leaves the room
[19:15:37] Boris Khasanov_web_716 joins the room
[19:16:10] Jason Livingood_web_740 joins the room
[19:16:15] <Lars Eggert_web_364> to help me check if i have the right mental model of this: could an instantiation of this architecture use a packet classifier that then tunneled a given packet, and apply a diffserv mark to the outside of the tunneled packet?
[19:16:31] <mcr> @Lars, I think so.
[19:17:00] Ignas Bagdonas_web_348 joins the room
[19:17:20] Ram Santhanakrishnan_web_517 joins the room
[19:17:30] <Spencer Dawkins_web_685> @Lars - I HOPE so. If it's not doing that, what else could it be using? /me wonders.
[19:17:44] Radu Valceanu_web_553 joins the room
[19:18:02] <Adrian Farrel_web_934> @Lars, that is how I understand the separation of function at the edge into APN edge and APN head
[19:18:16] <Lars Eggert_web_364> thanks all
[19:18:22] <Spencer Dawkins_web_685> So, when the port number is always 443 ...
[19:18:23] <kaduk@jabber.org/barnowl> What Lars describes seems consistent with the understanding I am
gaining from the presentation so far.
[19:18:32] Naoya Kaneko_web_219 joins the room
[19:18:41] <Stewart Bryant_web_274> .. assuming that diff serve is a sufficiently sophisticated QoS indicator
[19:18:46] <Jana Iyengar_web_243> I'm wondering what more this does.
[19:19:02] <Cedric Westphal_web_342> Is the APN node a router or a server?
[19:19:02] David Pelton_web_185 joins the room
[19:19:04] Aihua Guo_web_687 leaves the room
[19:19:19] Ali Begen_web_810 joins the room
[19:19:25] <Joey Salazar_web_755> I'm wondering about that "etc" in the attribute fields....
[19:19:40] <Spencer Dawkins_web_685> @Stewart, if that's accurate, I can switch to a conflictiing meeting with a clear conscience
[19:19:52] <Antoine Fressancourt_web_108> Isn't Diffserv manipualted inconsistently in routers so using it is not reliable now?
[19:19:59] Aihua Guo_web_802 joins the room
[19:20:37] <Toerless Eckert_web_192> @Antoine: there is no mandatory IETFrequirement to configure DiffServ inconsistently ;-)
[19:20:43] <Shuping Peng_web_302> @Lars, yes, that is the case.
[19:20:57] <Stewart Bryant_web_274> I think we need a more sophisticated ingress marker to specify the required behaviour
[19:21:01] <Tarek Saad_web_966> there's a lot of similarity in what a network needs to do to support network slices and what seems required from it to do to support APN
[19:21:01] Ali Begen_web_810 leaves the room
[19:21:04] Jason Livingood_web_740 leaves the room
[19:21:19] Mohit Sethi_web_702 joins the room
[19:21:32] Jason Livingood_web_794 joins the room
[19:21:43] <mcr> @Antoine, but 90% of networks are consistent, and in any case, all of this APN would be occuring within a (set of) cooperating operators.
[19:21:49] <Toerless Eckert_web_192> @Aontoine: Kidding aside, there are a lot more network features easily inconsistent if configured manually.
[19:22:13] <Shuping Peng_web_302> @Jana, with this added attribute, policy can be enforced at the policy enforcement points within the APN domain, such as traffic steering or IOAM
[19:22:17] <Ted Hardie_web_575> How large is the space of APN attributes?  If the data on the previous slide were enough to identify and individual (e.g. by physical port), could the attribute carry a user identifier?
[19:22:23] <Jen Linkova_web_744> 5 tuple vs thing to inspect - oh, it's called MPLS ;)
[19:22:26] Ram Santhanakrishnan_web_517 leaves the room
[19:22:29] km leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:22:30] Ram Santhanakrishnan_web_641 joins the room
[19:22:31] <Stewart Bryant_web_274> Why do we need to restrict ourselves to deducing the required behaviour rather than introducing a method for the application to specify what it needs
[19:22:33] Ram Santhanakrishnan_web_641 leaves the room
[19:22:35] <Shuping Peng_web_302> @Cedric, the APN node is a router within the APN network domain
[19:22:42] <Erik Kline_web_730> @linkova: I was thinking the same thing
[19:22:47] Ram Santhanakrishnan_web_853 joins the room
[19:22:53] <mcr> @Ted, it's a good question. @Jen, they claim that a single MPLS label isn't enough. But, haven't gotten a reply to why a stack of MPLS labels couldn't be used.
[19:22:57] Jie Dong_web_139 leaves the room
[19:23:01] Jie Dong_web_767 joins the room
[19:23:08] <Jari Arkko_web_150> @Jana: You asked what more is done. I'd observe that if all ports are 443 and all packets are destined to Amazon & friends, and all connections are fully encrypted, I don't think there's other things the network even could do. But maybe there's another question of whether we need a new mechanism to handle 5-tuple mappings.
[19:23:13] <Antoine Fressancourt_web_108> @Toerless, sure, my point was mor ethat using Diffserv in the current situation would be placing faith in the fact diffserv is not manipulated in a way nobody knows exactly
[19:23:16] <Watson Ladd_web_701> A structured general tag seems incompatible with fast hardware handling to me. Also can't apply all preferences hop by hop iirc: this is not my strongest area.
[19:23:17] Ehsan Hemmati_web_369 joins the room
[19:23:28] <Ole Trøan_web_943> The "application" (or user) has no way to express "want" here right?
[19:23:43] Spencer Dawkins_web_685 leaves the room
[19:24:14] <mcr> @Ole, @Jari, despite the name, many proponents don't intend to connect to the application, or create an API. (I think they should do exactly that, and this belongs in ART)
[19:24:17] Steve Dickson_web_192 joins the room
[19:24:18] <David Black_web_656> This has some structural similarities to Geneve (nvo3 network virtualization) - TLV header structure would accommodate APN attribute.
[19:24:46] <Stewart Bryant_web_274> @Antoine - depends on the trust between the host/application and the network
[19:25:07] Dino Farinacci_web_883 joins the room
[19:25:09] <Roland Bless_web_943> Currently, I don't see any difference to SFC or SR
[19:25:27] <Eduard V_web_805> DSCP has just 6bits. Here could be a much bigger granularity.
[19:25:29] <Watson Ladd_web_701> @David: i think the goal of this work is to make the contents of that per tunnel header? not terribly clear on this
[19:25:40] <Toerless Eckert_web_192> @Antoine: even as much as 5 years back, i have seen SDN controllers configuring per-5-tupl flow ACLs to give required service level objetives to individual users telephony 5-tuple flows.
[19:25:52] Mercia Zheng_web_321 joins the room
[19:26:08] <Tony Przygienda_web_515> @roland yep
[19:27:21] <Daniel Bernier_web_884> there are a myriad of mechanisms to achieve this, some better than others ... however how to express such "policies" so that a developper does not hardcode DSCP bits with a Excel spreadsheet on it's desk to know what mapping means what
[19:27:52] Shuai Zhang_web_941 leaves the room
[19:28:05] Shuai Zhang_web_701 joins the room
[19:28:05] Shunwan Zhuang_web_101 joins the room
[19:28:11] Stefano Previdi_web_585 leaves the room
[19:28:22] Stefano Previdi_web_927 joins the room
[19:28:27] Geng-Da Tsai_web_274 joins the room
[19:28:32] <Adrian Farrel_web_934> @all Don't be afraid to wait for the later presentations to hear answers to detailed questions :o)
[19:28:44] <Daniel Bernier_web_884> :D
[19:28:52] Ahmed Bashandy_web_129 leaves the room
[19:29:07] Ahmed Bashandy_web_576 joins the room
[19:29:16] <Antoine Fressancourt_web_108> @Toerless, the problem with QoS, being that everybody believes his packets are special, I am not that astonished.
[19:29:24] Cengiz Alaettinoglu_web_967 leaves the room
[19:29:28] Cengiz Alaettinoglu_web_263 joins the room
[19:30:11] <Toerless Eckert_web_192> @Toerless: sure, and if they would pay the nework operator more money for that traffic, the operator would be happy to make them special. Right now thats just very difficult to buy at the granularity of VPNs.
[19:30:25] <Toerless Eckert_web_192> oops, @antoine.. not meaning to talk to myelf ;-)
[19:30:56] <Roland Bless_web_943> :-)
[19:31:31] Scott Mansfield_web_836 leaves the room
[19:31:34] Eve Schooler_web_533 leaves the room
[19:31:36] <Gorry Fairhurst_web_252> @Eduard - but a DSCP is associated with a treatment by the network (likely few), not a category of traffic (there could be many) - Many people think of a limited set of treatments, albeit with a complex classifcation at the edge - but do you need to carry the classification info in the packet, only the required treatment?
[19:31:47] <David Black_web_656> @Watson: Will be interesting to see what is emphasized in gap analysis.
[19:31:53] Zaheduzzaman Sarker_web_778 joins the room
[19:32:20] Steve Dickson_web_192 leaves the room
[19:32:29] <Shuping Peng_web_302> @Tom, the states at the edge are always there for flow identification and classification. The good thing with APN is that at the APN edge an APN attribute is added and with attribute at the network intermediate nodes the table for policy enforcement is significantly reduced. Please pay attention to the use cases being presented.
[19:32:35] Ehsan Rezaaifar_web_910 leaves the room
[19:32:36] Cengiz Alaettinoglu_web_263 leaves the room
[19:32:41] Cengiz Alaettinoglu_web_749 joins the room
[19:32:49] Dirk Hugo_web_914 leaves the room
[19:33:01] Dirk Hugo_web_191 joins the room
[19:33:04] Scott Mansfield_web_400 joins the room
[19:33:33] <Tom Hill_web_186> I was paying attention, Shuping. Hence my question. :)
[19:33:48] Ram Santhanakrishnan_web_853 leaves the room
[19:33:50] Cengiz Alaettinoglu_web_749 leaves the room
[19:33:52] Ram Santhanakrishnan_web_783 joins the room
[19:33:57] Cengiz Alaettinoglu_web_833 joins the room
[19:34:00] <Eduard V_web_805> Gorry, if the category would not receive special treatment - then what is the purpose of a category?
[19:34:07] <Jari Arkko_web_150> @watson @david I think what is being presented is largely usual policy application, the main question in my mind is whether we need a new mechanism for that. Earlier versions of APN went way beyond the usual policy application btw and had issues there, that does not seem to be a problem any more.
[19:34:35] <Dan Voyer_web_901> @Jari, good question
[19:34:43] Philip Eardley_web_494 leaves the room
[19:34:47] Philip Eardley_web_182 joins the room
[19:34:58] <Shuping Peng_web_302> @Tarek, network slicing is just one network services that can be better supported by APN but APN is not bound to network slicing. There does not have to be network sicing within an APN domain.
[19:35:06] Cengiz Alaettinoglu_web_833 leaves the room
[19:35:11] Cengiz Alaettinoglu_web_811 joins the room
[19:35:34] Ehsan Rezaaifar_web_974 joins the room
[19:36:24] <Lou Berger_web_111> why not mpls or SR without apn?
[19:36:52] <David Black_web_656> Wondering about what APN attribute will grow to - suspect that "structured attribute" is more accurate than "tag" and wonder how resulting resolution complexity will compare with 5-tuples being used as bogey in current preso.
[19:36:54] Susan Hares_web_585 joins the room
[19:36:57] Ehsan Hemmati_web_369 leaves the room
[19:37:09] <Shuping Peng_web_302> @Ted, the APN attribute will be introduced in more details in the following presentation. The proper design of the APN attribute is one of the work that we will need to work on.  Your suggestions are always welcome.
[19:37:15] <Tom Hill_web_186> Ironically, I suspect that an SRv6 SID could completely replace APN.  Anything here that isn't covered by that?
[19:37:25] <Boris Khasanov_web_716> Might be that SPL in MPLS could be an APN attribute too
[19:37:49] Karen O'Donoghue_web_413 joins the room
[19:37:55] <Gorry Fairhurst_web_252> @Eduard: e.g. Classify IP fields  -> Class (traffic category) -> Per Hop Treatment  (indicated by DSCP)-> Schedular, traffic policing and other configured policy
[19:37:57] <Toerless Eckert_web_192> @Lou: if i wanted to get special treatment for my packets across my access SP to e.g.: the third-party edge-cloud content provider i am streaming from, which existing SR/MPLS policy signaling mechanism could i use ?
[19:38:03] <Ted Hardie_web_575> @Shuping. Thanks.  David's question has similar implications, so hopefully both aspects are addressed.
[19:38:15] Zafar Ali_web_596 joins the room
[19:38:20] Naoya Kaneko_web_219 leaves the room
[19:38:24] <Charles Eckel_web_741> I thought the first presentation said APN attributes were applicable within a single domain only, whereas this one focuses on its use across multiple domains. The requirements are very different for these two cases.
[19:38:34] <Russ White_web_329> I assume there will need to be some mechanism for the provider to be paid differently based on the kind of service the application is asking for ...  and the control plane will need to be modified to support these various kinds of paths ... I wonder what the additional complexity will be to go beyond "mark the packets and do fancy QoS" that seems to be implied here ...
[19:38:35] Naoya Kaneko_web_252 joins the room
[19:38:55] Philip Eardley_web_182 leaves the room
[19:39:02] Philip Eardley_web_492 joins the room
[19:39:03] <Toerless Eckert_web_192> @Lou: maybe this could be a good policy signaling mechanism to faster proliferate DetNet services into SPs ;-))
[19:39:17] <dhruvdhody> @Tom - I see APN trying to be agnostic and support multiple tunnel encapsulation include SRv6/IPv6
[19:39:26] Ram Santhanakrishnan_web_783 leaves the room
[19:39:30] Ram Santhanakrishnan_web_395 joins the room
[19:39:47] <Lou Berger_web_111> @toreless well that's another question, what does APN bring that isn't already being done within detnet
[19:39:52] <Jana Iyengar_web_243> What Charles said.
[19:40:10] Dave Sinicrope_web_397 joins the room
[19:40:11] <Ted Hardie_web_575> @Greg I have optical service and wireless service from the same operator, and this would not be unusual for that operator, from what I can tell.
[19:40:11] <Tom Hill_web_186> @Dhruv, that's a fair point - though a whole new protocol? hmm.
[19:40:13] Ehsan Rezaaifar_web_974 leaves the room
[19:40:21] Mohit Sethi_web_702 leaves the room
[19:40:31] <Ted Hardie_web_575> @Greg But I agree with your characterization of "single operator, multi domain".
[19:40:36] <kaduk@jabber.org/barnowl> For what it's worth, I did perceive "only a single operator" from the
first presentation.
[19:40:40] <Tarek Saad_web_966> @Shuping Peng: what I meant the tools introduced to support network slicing are reusable to a big extent here in APN
[19:40:41] Ehsan Rezaaifar_web_157 joins the room
[19:40:41] <Jana Iyengar_web_243> I understand the request to not over-pivot on the name, but I'm struggling to understand how any of this is "application-aware" in the slightest.
[19:40:47] Mohit Sethi_web_860 joins the room
[19:40:48] <John Scudder_web_873> @Charles I believe the use of "domain" is very imprecise. The first speaker said it was applicable when multiple "domains" are owned by a single entity.
[19:41:01] <Watson Ladd_web_701> Why doesn't the head know how to encapsulate with the treatment that will be applied?
[19:41:05] <Eduard V_web_805> I do not agree with Greg. It is very often that a big Carrier has separate ASs (IGP, BGP) for the backbone and all metros.
[19:41:17] Martin Duke_web_984 leaves the room
[19:41:19] <Lou Berger_web_111> very true
[19:41:21] <frodek> @charles, they used the term "APN domain", not "network domain"
[19:41:21] Martin Duke_web_770 joins the room
[19:41:35] <David Black_web_656> Expecting diffserv domain/region model and notion of cooperating operators to be applicable scopes.
[19:41:35] Georgios Karagiannis_web_458 joins the room
[19:41:35] Mohit Sethi_web_860 leaves the room
[19:41:39] <Uma Chunduri_web_827> @Greg Mirsky, I agree with Luis on this. Crossing operator boundaries when packet crossing metro is an exception. Lot of backhaul networks have multiple subdomains all maintained by same operators.
[19:41:41] Mohit Sethi_web_682 joins the room
[19:41:45] Mohit Sethi_web_682 leaves the room
[19:41:47] Mohit Sethi_web_436 joins the room
[19:41:54] <Watson Ladd_web_701> Different AS's exchanging non IP traffic? didn't know that worked!
[19:41:57] <Ted Hardie_web_575> I am now convinced that 25 minutes is not going to be enough....
[19:42:11] <Ted Hardie_web_575> Can we speed through any of the other aspects?
[19:42:19] <Toerless Eckert_web_192> videos of speakers are nice!
[19:42:30] <Shuping Peng_web_302> @Greg, the APN domain owned by a single operator is always clearly stated in the APN Introduction slides.
[19:43:18] <Bob Hinden_web_187> We will try, currently about 8 minutes ahead
[19:43:44] <Jen Linkova_web_744> I read the traffic steering slides as "there are multiple srv6 domains so need to do multiple 5 tuples lookups - but it can be one APN domain". I'm a bit confused why/how this happens..
[19:43:46] <Zhenbin Li_web_980> @Greg It has been explained in the introduction APN, the APN domain should be the network domains controlled by the same operators. The case to cross muliti domains controlled multi operators is out of the scope of the APN work.
[19:43:57] <mcr> I really think we should make HSS-LMS be the MTI for any device with an expected lifetime of more than about 2 years.  (Where smartphones fit into "2 years" is a marketing problem)
[19:44:06] <Watson Ladd_web_701> HSS-LMS?
[19:44:06] Xufeng Liu_web_907 joins the room
[19:44:12] <Bob Hinden_web_187> The flow label could be used for anything given that a tunnel is created
[19:44:21] <kaduk@jabber.org/barnowl> mcr: are you typing into the room you thought you are?
[19:44:27] Ram Santhanakrishnan_web_395 leaves the room
[19:44:31] Ram Santhanakrishnan_web_583 joins the room
[19:44:32] <Roland Bless_web_943> @Bob: true
[19:44:41] <mcr> clearly, I wasn't. Sorry. That was for SUIT.... waiting for the open mic on APN.
[19:44:46] <Shuping Peng_web_302> @Greg, I would not say that this is a rare case, and I thought you would be very farmiliar with this case since it is a very normal deployment case in China's network setup.  :p Generally the network in a country like China for example is always very large. It will go through multiple domains belonging to different department of the same operator.
[19:45:26] <Jen Linkova_web_744> 5 tuples are also used for load balancing, it doesn't prevent them being used for other things..
[19:45:26] <Zhenbin Li_web_980> @Jen I explained that in the introduction, the APN domain is a logic concept. In the physical environment, it can be network domains controlled by one operators.
[19:45:30] Darren Dukes_web_775 joins the room
[19:45:33] <Martin Duke_web_770> I don't understand how the bullets for #2 answer the question
[19:45:33] <Shuping Peng_web_302> @Jen, it doesnot have to be MPLS, it could be any payload protocol.
[19:45:55] Zafar Ali_web_596 leaves the room
[19:46:07] <Martin Duke_web_770> likewise #7
[19:46:18] Jason Livingood_web_794 leaves the room
[19:46:20] <Adrian Farrel_web_934> @Jana (wrt the name) I understand your point. Possibly it "delivers network performance appropriate for the network", but also possibly it really has just evolved and not changed its name as it went
[19:46:25] <mcr> @martin, the gap analysis document is also lacking conclusions, a comment I made months ago.
[19:46:40] <Gorry Fairhurst_web_252> I thought the previous speaker said the APN domains were all under the conrol of one oeprator, so doesn't that match the scope of the IOAM header?
[19:46:56] <Watson Ladd_web_701> Not sure why if you're going to update all your equipement to do this you don't make them all use the same tunneling solution
[19:47:07] <kaduk@jabber.org/barnowl> Gorry: I think the scope matches, yes
[19:47:14] <Justin Iurman_web_849> +1 Gorry
[19:47:16] <Jana Iyengar_web_243> @Adrian -- That happens. But by the time it's a BoF, it's worth revisiting that, especially if everyone has to go out of their way to say "please don't pay attention to the name"
[19:47:18] <Watson Ladd_web_701> also China network very unique history and structure.
[19:47:24] <Jen Linkova_web_744> @Bob: +1. I'm not sure why the outer header flow label is not enough.
[19:47:33] <Watson Ladd_web_701> name changes are hard, but better sooner than later
[19:47:35] <Dirk Hugo_web_191> BTW SFC service Id draft is meanwhile rfc8979  :grin:
[19:47:38] <Jari Arkko_web_150> @martinduke I also don't see a conclusion for items except the DSCP one. They are used in specific situations. Wouldn't a new APN thing be also used in the specific APN networks?
[19:47:42] <Shuping Peng_web_302> @Jari, with APN the 5-tuple mapping only happens at the APN edge. Within the APN domain, there is no need to that anymore. You can only use the APN attribute in the single field to do the policy enforcement and no need to do the further resolving of the 5 tuples.
[19:47:46] <Jari Arkko_web_150> Or am I missing something?
[19:48:19] <Daniel Bernier_web_884> comparison should include SRv6 independent from BSID, use of TLVs (srh, nsh, geneve, ...)
[19:48:22] Cengiz Alaettinoglu_web_811 leaves the room
[19:48:27] <Martin Duke_web_770> wait, aren't flow labels generic?
[19:48:45] <Zhenbin Li_web_980> @Gorry the IOAM is the policy enforcement in the backbone domain according to the APN attributes. The IOAM is only used in the backbone daomain.
[19:48:46] Daphanie Nisbeth_web_555 joins the room
[19:48:47] <Jari Arkko_web_150> @Shuping: understood. The question is if that clear benefit is enough though. Not saying it isn't but that's a question we need to ask. One could do the 5-tuple lookup every time, if one wanted to.
[19:49:01] <Lou Berger_web_111> @jari - think you're not missing anything
[19:49:28] Chenhao Ma_web_595 leaves the room
[19:49:49] <Kireeti Kompella_web_499> @martin duke they are indeed, simply flow labels -- they can be used for all sorts of things
[19:49:52] Martin Duke_web_770 leaves the room
[19:49:56] Martin Duke_web_892 joins the room
[19:50:25] Susan Hares_web_585 leaves the room
[19:50:40] Cengiz Alaettinoglu_web_678 joins the room
[19:50:46] <Jen Linkova_web_744> "20 bits ought to be enough for anybody" ;))
[19:50:47] <Tom Hill_web_186> Ah, 4B permutations. OK.
[19:51:02] Chenhao Ma_web_217 joins the room
[19:51:13] Russ White_web_329 leaves the room
[19:51:18] <Tom Hill_web_186> I got loads of FIB in my edge devices for that.
[19:51:27] LucAndré Burdet_web_948 joins the room
[19:51:29] Kazuho Oku_web_197 joins the room
[19:51:43] Susan Hares_web_279 joins the room
[19:52:31] <Eduard V_web_805> whatever time is reserved for discussion - it would be not enough.
[19:52:46] <Lars Eggert_web_364> @jari one difference between "a 5-tuple lookup at each hop" and adding a packet field at the edge is that you could use a bunch of ML at the edge that analyzes a flow's history, and then encode that in the field so you don't need to ML at each hop. in other words, you can afford to do much more at the edge. there are upsides and downsides to this, as always
[19:52:48] <Shuping Peng_web_302> @Ole, @mcr, yes, the APN work only focuses on what we can do within the network.
[19:52:58] <Bob Hinden_web_187> We are 15 minutes ahead at the moment
[19:53:02] <Roland Bless_web_943> So either flow labels are sufficient or SFC: also classify once and then use the NSH that should be expressive enough. Then you need to map your policies to SFPs and that's it? #3 wasn't showing any gap to the use case or I didn't understand.
[19:53:08] <Watson Ladd_web_701> this seems way to generic to actually work across devices of very different capabilities
[19:54:19] <Rick Taylor_web_700> I keep thinking abusing LISP may yield the same results...  if the APN becomes encoded in your Identifier at the edges...
[19:54:24] <Jari Arkko_web_150> @lars good point!
[19:54:24] <Ted Hardie_web_575> @Lars There appears to be a fundamental assumption in this that the edge operator takes all available information (including the five tuple) and assigns an APN structured ID.  This means that the ID carries a piece of information that is potentially semantically *richer* than the five tuple and making that available to path elements that would not otherwise have that data.  The size of the ID is high enough that the policy could identify emitters or characteristics that would not be available in the current Internet.  As you note, there are major downsides of that, and I am struggling to see how this could work within the advice of 8558.  That's an IAB doc, not IETF consensus, but these path signals don't match the limitations it advises.
[19:54:25] <kaduk@jabber.org/barnowl> I'm not sure how a "user group ID" would be extracted from 5-tuple/etc
at the edge node.  Unless we're equating src IP with user...
[19:54:31] <Lars Eggert_web_364> what happens to a flow if a hop can't meet the apn requirements?
[19:54:44] Ruixue Wang_web_825 leaves the room
[19:54:51] Ruixue Wang_web_130 joins the room
[19:54:53] <dhruvdhody> @roland - from what i understand is that re-purposing NSH for non-SFC usecase would be a bit of a mess
[19:54:56] <Ted Hardie_web_575> @kaduk the edge has access to physical port as well.
[19:55:11] Taiji Kimura_web_141 joins the room
[19:55:15] <Takuya Miyasaka_web_704> I'm not sure how edge routers can estimate APN ID and parameters ( latency, bandwidth, etc.) just from 5-tuple. Is there any interface or API between application and APN domain controller?
[19:55:17] <Sergey Fomin_web_937> Feels like a false dichotomy: this APN id is presented as something that works with any data plane.. but in reality it is the new dataplane
[19:55:19] <Watson Ladd_web_701> @Ted: but a rich identifier is hard to switch on, which seems to go against some of the envisioned applications
[19:55:45] <Adrian Farrel_web_934> @Ted. In fact even virtual port id. Various APN implications
[19:56:00] <kaduk@jabber.org/barnowl> "can be treated as opaque", not "is opaque"
[19:56:08] <Ted Hardie_web_575> @Watson I have no doubt that you could build those with this rich an identifier.  But it also looks like a privacy footgun in the making.
[19:56:42] <Watson Ladd_web_701> can build yes. Can build faster than 5 tuple extraction or MPLS label popping? dubious
[19:56:44] Aihua Guo_web_802 leaves the room
[19:56:45] Nicolas Kuhn_web_775 joins the room
[19:56:48] Aihua Guo_web_533 joins the room
[19:56:54] Y. Richard Yang_web_225 leaves the room
[19:57:00] <David Black_web_656> If treated as opaque, how does attribute richness interact with opaque lookup?  Is that just opaque lookup based on ID (would make more sense)?
[19:57:02] Y. Richard Yang_web_558 joins the room
[19:57:49] <kaduk@jabber.org/barnowl> I'm interpreting "can be treated as opaque" as indicating that a given
device might only need to process a handful of APN values.  Those
specific values do have internal structure that could be interpreted,
but for this particular device it just uses a lookup table for those
fixed values.
[19:57:52] <Gorry Fairhurst_web_252> It seems that there is edge policy that sets up a set if IDs in each packet; then each node is configured with policies that match an extensible set of IDs (in some combination) and make a decision about how to map/lookup the packet to decide on scheduling, policing, etc. This is gloriously flexible and amazingly complex to coordinate between nodes ...
[19:58:03] Nicolas Kuhn_web_775 leaves the room
[19:58:08] <Adrian Farrel_web_934> @David I *think* (but unsure) that you can apply bit masks to the opaque identifier if (and only if) everyone sets the identifier in the same way.
[19:58:08] <kaduk@jabber.org/barnowl> So, such a "treat as opaque" case could not actually use the full
richness of attributes
[19:58:18] Nicolas Kuhn_web_898 joins the room
[19:58:19] Ole Trøan_web_943 leaves the room
[19:58:23] Ole Trøan_web_257 joins the room
[19:58:34] Ole Trøan_web_257 leaves the room
[19:58:40] Ole Trøan_web_750 joins the room
[19:59:07] HannuF joins the room
[19:59:57] Susan Hares_web_279 leaves the room
[20:00:37] Y. Richard Yang_web_558 leaves the room
[20:00:48] Y. Richard Yang_web_830 joins the room
[20:01:02] <Adrian Farrel_web_934> @ Gorry Can I use your quote "This is gloriously flexible and amazingly complex to coordinate" ?
[20:01:03] <Rick Taylor_web_700> @lou - +1 on similarities to DetNet
[20:01:06] Nigel Davis_web_681 leaves the room
[20:01:10] Karen O'Donoghue_web_413 leaves the room
[20:01:12] Nigel Davis_web_606 joins the room
[20:01:49] <kaduk@jabber.org/barnowl> Adrian: I'm pretty sure that quote was an IETF Contribution ;)
[20:01:52] <Jana Iyengar_web_243> @Ted -- exactly. It seems to me that we're staring at a giant privacy issue in the making here. An arbitrary generic structured field that can be shared across operator domains enables significant sharing of metadata across operators. That concerns me.
[20:01:56] Y. Richard Yang_web_830 leaves the room
[20:02:06] Martin Duke_web_892 leaves the room
[20:02:14] Martin Duke_web_741 joins the room
[20:02:15] Philip Eardley_web_492 leaves the room
[20:02:22] <Gorry Fairhurst_web_252> @Adrian.. yes - that's where I am, until someone explains this differently
[20:02:50] Philip Eardley_web_504 joins the room
[20:03:41] <dhruvdhody> @jana - the claim is that the APN information is stripped along with tunnel encapsulation when it leaves the one operator domain (something like IOAM)
[20:03:49] HannuF leaves the room
[20:03:53] Philip Eardley_web_504 leaves the room
[20:03:55] Kireeti Kompella_web_499 leaves the room
[20:03:57] Philip Eardley_web_777 joins the room
[20:04:26] <Alexander Clemm_web_354> is "treat as opaque" the same here as "treat as optional"?
[20:04:44] <David Black_web_656> @kaduk Sounds like opaque was used solely wrt privacy of info from which APN ID is derived.
[20:04:49] <kaduk@jabber.org/barnowl> David Black: would you mind typing up your understanding of the answer
you got?  I think I missed part of it, unfortunately
[20:05:26] <dhruvdhody> @alex - maybe part of how the policy is enforced
[20:05:30] <Jingrong Xie_web_938> so opaque means something like "RBAC(Role-Based Access Control)"  instead of some known the specific user. some kind of "indirect"
[20:05:31] <Jana Iyengar_web_243> @dhruv: my understanding is that the entire value of these APN tunnels is to communicate information across domains.
[20:05:39] <David Black_web_656> @kaduk What I understood is that "opaque" refers solely to hiding of information used to construct/derive APN ID, thereby affording privacy properties, but APN ID is completely non-opaque to network elements.
[20:05:50] <Ted Hardie_web_575> @Dhruvdhody The current privacy and security doc makes that claim, but it is an operational practice, not a characteristic of the protocol.  For the one operator, multiple domain case, you can't really put it into the protocol mechanics.
[20:05:52] <dhruvdhody> @jana - but within a single operator
[20:05:56] <Watson Ladd_web_701> so what's between the domains
[20:05:59] <Jie Dong_web_767> @Gorry, in your "then each node is configured with policies...", to my understanding APN does not require each transit node to have that policy configured, only the nodes which need to perform APN specific manipulation
[20:06:02] Zhibo Hu_web_638 leaves the room
[20:06:04] Y. Richard Yang_web_932 joins the room
[20:06:16] <kaduk@jabber.org/barnowl> David: thanks!
[20:06:16] Kazuho Oku_web_197 leaves the room
[20:06:18] Zhibo Hu_web_879 joins the room
[20:06:24] <Daniel Bernier_web_884> is it expected that the APN ID and parameters be "normalized' (standardized) or be defined domain specific
[20:06:27] <Daniel Bernier_web_884> ?
[20:06:28] Kireeti Kompella_web_782 joins the room
[20:06:29] <Alexander Clemm_web_354> @dhruv - not sure policy is sufficient here.  If optional, other questions come up like how to know whether or not it is being acted upon by intermediate nodes
[20:06:37] <David Black_web_656> suspect that Greg and Shuping do not have a common understanding of "transit node" term ...
[20:06:38] <Rick Taylor_web_700> ... and Greg just underlines why this is just DetNet
[20:06:38] <Jingrong Xie_web_938> @David Black, I have similar understanding with yours after explaination by Shuping.
[20:06:47] <Jari Arkko_web_150> @dhruvdhody @jana We can look at this in different ways. Can information, if it exists, be used for a bad policy? Yes. Can it be shared with others? Yes. However, modern operator networks don't really have much metadata to share, given progress in encryption. At least in most parts of the world. If we are concerned about metadata, we should be concerned about CDN, Google, etc. user tracking and how that data is shared eg with advertisers. This does not mean that I'm in favour of APN, because I happen to believe we have the plumbing tools for this already available, so no new tech needed.
[20:07:13] Susan Hares_web_786 joins the room
[20:07:56] <Ted Hardie_web_575> @Jari the structure of this enable the sharing of information that is not normally available by on-path inspection, because of the priviledged place the marking occurs.  I think that's different from the "not much metadata to share" case.
[20:08:12] John Kaippallimalil_web_876 leaves the room
[20:08:23] John Kaippallimalil_web_299 joins the room
[20:08:23] <Alissa Cooper_web_439> What is the mechanism that forces this attribute to be stripped at the network operator's boundary?
[20:08:35] <Jeffrey Haas_web_126> The meta data is a wonderful place to carry a Google FLoC.
[20:08:53] <Zhenbin Li_web_980> @Greg How to process the bw req para is about the solutions. It is open now. There is the possible way to configure the local policy for best effort if there is enough bw for the bw req para. There can be other policies to process your mentioned cases.
[20:08:57] <Bob Hinden_web_187> I think it stripped when the packet is deencapsulated
[20:09:01] Zheng Zhang_web_308 joins the room
[20:09:10] <Jen Linkova_web_744> why am I thinking about lawful intercept..
[20:09:22] <Jeffrey Haas_web_126> s/lawful//
[20:09:29] Julien Maisonneuve_web_989 leaves the room
[20:09:33] <Jana Iyengar_web_243> @Jari -- I strongly disagree. Making that information flow richer (arbitrarily so), allowing arbitrary aggregates of users, and making it possible for this information can be shared across operators IS a pretty big difference from existing mechanisms such as DiffServ.
[20:09:34] Julien Maisonneuve_web_297 joins the room
[20:09:47] <Ted Hardie_web_575> @Bob Unless decap and re-encap are guaranteed to be in different boxes, then you still have practice, not protocol mechanism.
[20:09:47] <Watson Ladd_web_701> I think many people would disagree with the idea we have a clear program
[20:09:52] <Jen Linkova_web_744> @Jeff: sorry, should have used double-quotes
[20:09:57] <Jingrong Xie_web_938> "APN domain" boundary to ensure this attribute to be stripped I guess @Alissa
[20:10:07] <Sergey Fomin_web_937> @Jana - i don't think they propose to share between operators, though
[20:10:17] <Sergey Fomin_web_937> it can be, but shouldn't
[20:10:20] <Zhenbin Li_web_980> @Alissa The apn attribute is carried along with the tunnel.  When the tunnel is removed, the APN attribute will be removed at the same time.
[20:10:32] <Jana Iyengar_web_243> @Sergey -- see @Ted's point above. That's an operational point, not something the protocol can enforce.
[20:10:34] <Erik Kline_web_730> similar to SRH mechanics then?
[20:10:42] Lijun Dong_web_185 joins the room
[20:10:46] <Watson Ladd_web_701> so the tunnel goes across the domains? Why doesn't that allow all the mechanisms we already have like detnet, etc. to work?
[20:11:07] <Jeffrey Haas_web_126> I think the idea that they can remove the privacy implications of these mechanisms by charter is ludicrous.
[20:11:10] <Lou Berger_web_111> for those who may be  interested - DetNet session is 30 minutes after this session ends - see https://datatracker.ietf.org/wg/detnet/about/ and https://datatracker.ietf.org/meeting/111/session/detnet
[20:11:11] <Rick Taylor_web_700> @Watson:  this is just DetNet - but the "attribute" is "policy-compliance" rather than latency or reliability.
[20:11:29] Martin Duke_web_741 leaves the room
[20:11:33] Martin Duke_web_643 joins the room
[20:11:47] <kaduk@jabber.org/barnowl> There is the question of who decides whether there is violation of the
user's privacy/security, yes.  I can imagine some people whose
decisions would essentially not let anything be published
[20:11:52] <Alissa Cooper_web_439> I guess I was wondering about the case when the interconnecting network says, "hey, I'll pay you to leave that attribute there after decap"
[20:12:04] Martin Duke_web_643 leaves the room
[20:12:06] <Toerless Eckert_web_192> @Lou: so if a user wants to get DetNet service for a flow, the user and network need to le to know network know 5 tuple flow. Is that a violation of user privacy ?
[20:12:16] <Watson Ladd_web_701> @Rick +1, think this should happen there
[20:12:16] Martin Duke_web_991 joins the room
[20:12:17] Dino Farinacci_web_883 leaves the room
[20:12:21] Dino Farinacci_web_513 joins the room
[20:12:35] Ahmed Bashandy_web_576 leaves the room
[20:12:44] <Ted Hardie_web_575> @Alissa it's even simpler; let me do the decap on my side of the peering point.
[20:12:48] <Rick Taylor_web_700> @Watson - It has already happened...  there's even YANG models, and we all know they get done last
[20:12:58] <Boris Khasanov_web_716> What's the point for using GTP-U there?
[20:12:59] <Zhenbin Li_web_980> @Watson the detnet is the network service to be policy-enforced. It can be done according to the APN atttribute carried in the tunnel.
[20:13:00] <Lou Berger_web_111> @toreless the stated scope was single provider, so they already have the info
[20:13:07] Shuai Zhao_web_593 joins the room
[20:13:09] <Watson Ladd_web_701> why can't detnet carry the info?
[20:13:19] <Rick Taylor_web_700> It can
[20:13:29] <Watson Ladd_web_701> why do we need an abstract container for service info across all tunneling mechanisms?
[20:13:32] <Justin Iurman_web_849> ... why can't IOAM carry the info?
[20:13:36] <kaduk@jabber.org/barnowl> Does DetNet-IP have ways to convey information other than 6-tuple?
[20:13:37] <Lou Berger_web_111> @watson, was about to say that's an option too
[20:13:46] <Sergey Fomin_web_937> @Watson that's a great question
[20:14:02] <Lou Berger_web_111> we have an mpls  service label already and have a proposal for a service IP label
[20:14:03] <kaduk@jabber.org/barnowl> I think I remember DetNet-MPLS having more flexibility than DetNet-IP
[20:14:09] <David Black_web_656> "will not publish anything that violates user's privacy and security" seems to be both untestable and miss the point - "that can be used to violate ..." is where the problems reside ... and looks like I'm not the only person thinking along these lines - +1 @Jeff & @kaduk
[20:14:10] <Sergey Fomin_web_937> Don't see a need to define a new dataplane to carry this info, while you could use existing mechanisms
[20:14:12] <Watson Ladd_web_701> when open mic starts i;ll ask it
[20:14:16] Cong Li_web_541 leaves the room
[20:14:22] Cong Li_web_122 joins the room
[20:14:43] <Dan Voyer_web_901> @watson that's what coming next
[20:15:21] Chenhao Ma_web_217 leaves the room
[20:15:36] Chenhao Ma_web_330 joins the room
[20:15:39] <Dino Farinacci_web_513> the question is not being answered, what is the OUTER HEADER?
[20:15:40] <Tom Hill_web_186> @david We're all quite well aware of the power (danger) of metadata.
[20:15:48] <Tom Hill_web_186> No different here tbh
[20:15:49] <Toerless Eckert_web_192> @lou: thanks
[20:16:16] Markus Amend_web_532 joins the room
[20:16:26] <kaduk@jabber.org/barnowl> Lou: do you have a link to the service IP label draft handy?
[20:16:42] <Tom Hill_web_186> Basically taking a bunch of factors and giving every user an identification number in the core.
[20:17:01] Dino Farinacci_web_513 leaves the room
[20:17:05] Dino Farinacci_web_876 joins the room
[20:17:12] <Kireeti Kompella_web_782> "talked out" at a BoF???
[20:17:25] <Lou Berger_web_111> sure there are two: https://datatracker.ietf.org/doc/html/draft-varga-detnet-ip-preof-00 and https://datatracker.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh-04
[20:17:28] <Shuping Peng_web_302> @Tarek, that is true. APN and network slicing do not conflict each other.
[20:17:34] <kaduk@jabber.org/barnowl> Thanks Lou!
[20:17:38] Yimin Shen_web_572 joins the room
[20:17:52] <Lou Berger_web_111> NP - they are both individual so still working this part out
[20:17:53] <David Black_web_656> @Tom - if that's done, "opaque" != "private"
[20:18:07] <Dino Farinacci_web_876> my big concern is an "APN setter" can DoS the network
[20:18:25] Markus Amend_web_532 leaves the room
[20:18:31] Shuai Zhao_web_593 leaves the room
[20:18:32] Markus Amend_web_312 joins the room
[20:18:35] Marcus Ihlar_web_876 joins the room
[20:18:48] <Jim Guichard_web_804> i dont think they mean opaque in this sense
[20:18:49] <Jari Arkko_web_150> @Ted we may agree actually on the conclusion on what we should be doing in the IETF on this. So I'm not sure I want to argue too much with you. But I am not sure the point about privileged place. In many networks -- mobile networks in particular -- you already carry a lot of information about ingress "ports" for instance, as there is a technical reason for tunneling and that involves some identification of the connection. Lars' point is valid that one could set up an AI thing, but that sees more about the need to have enough resources at a stable node to do that if one really needs to. That could be somewhere else than in the edge. In fact in mobile placing it in edge might be a bad idea. But Lars is right that if one does that, then attributes would be a way to distribute the information further. Although maybe not in order that the APN diagrams show it. You'd have. to deliver it in reverse order, if the analysis point was in centralized cloud facility, for instance.
[20:18:55] <Lou Berger_web_111> @dino its really the same issue as interdomain mpls
[20:18:56] <Jingrong Xie_web_938> OUTER HEADER is the header prepended to the original packet during encapsulation I guess @Dino
[20:19:07] Yimin Shen_web_572 leaves the room
[20:19:28] Dirk Hugo_web_191 leaves the room
[20:19:31] Andrew Stone_web_209 leaves the room
[20:19:31] <Dino Farinacci_web_876> agree @lou, but since mistakes of the past are repeated, that's the definition of insanity
[20:19:36] Yimin Shen_web_398 joins the room
[20:19:36] Dirk Hugo_web_120 joins the room
[20:19:37] Andrew Stone_web_445 joins the room
[20:19:42] Loa Andersson_web_368 leaves the room
[20:19:44] Jordan Head_web_133 leaves the room
[20:19:49] Loa Andersson_web_211 joins the room
[20:19:50] Xufeng Liu_web_907 leaves the room
[20:19:50] Jordan Head_web_803 joins the room
[20:19:51] <Lou Berger_web_111> ;-)
[20:19:55] Xufeng Liu_web_657 joins the room
[20:20:22] <Rick Taylor_web_700> I'm still not sure what the problem domain is...  What is the problem APN is trying to solve?
[20:20:28] Srihari Sangli_web_780 leaves the room
[20:20:35] Srihari Sangli_web_416 joins the room
[20:20:37] <Ted Hardie_web_575> put a link to the slide here instead of reading it aloud?
[20:20:55] <Dino Farinacci_web_876> the problem statement is simply this "what can an app do to get better service for it, from the network"
[20:21:06] <Shuping Peng_web_302> @frodek, APN domain is Application-ware Network domain :)
[20:21:06] <Dino Farinacci_web_876> and of course all apps want the best service, so what gives?
[20:21:20] <Sergey Fomin_web_937> @Dino an app does not participate in this, per my understanding
[20:21:27] <Rick Taylor_web_700> Aaah.. "How can an app get a determinsitic service from the network" ?
[20:21:33] <Lou Berger_web_111> @chairs how does this listing of slicing related to APN???
[20:21:35] <Dino Farinacci_web_876> what would Sally Floyd say about this?
[20:21:39] <Jana Iyengar_web_243> About privacy -- an arbitrary structure that can be (i) defined by an operator at runtime, and (ii) shared arbitrarily makes this particularly problematic. This is literally a mechanism for creating and sharing arbitrary metadata about arbitrary aggregates across arbitrary boundaries. That solves many problems, sure, but it creates as much or more room for trouble.
If there are specific problems that we want to solve, let's consider them individually and try to solve them. If general themes arise, let's see if we can generalize to cover the use cases. Arguing for a completely general mechanism based on two use cases is an academic exercise, not an engineering one.
[20:21:43] <kaduk@jabber.org/barnowl> An optimist might say that different apps care about "best" on
different axes (bandwidth, latency)
[20:21:46] <Watson Ladd_web_701> i don't think that's the problem. much simpler solutions. And some apps deliberately deprivilege flows: bittorent choking and scavenger tcp controllers
[20:22:07] Ehsan Rezaaifar_web_157 leaves the room
[20:22:27] <Dino Farinacci_web_876> @kaduk, then we have a multi-dimensiona "what gives"
[20:22:39] <Jim Guichard_web_804> this is not network slicing
[20:22:56] <Antoine Fressancourt_web_108> @Jana, Funny how you describe Flow label
[20:23:01] <dhruvdhody> Creating a network slice for the APN usecase for policy enforcement seems extreme
[20:24:15] <Jie Dong_web_767> in my understanding APN and network slice are concept at different layers/granularity
[20:24:19] <John Scudder_web_873> @Jim it's too bad Jeffrey's slide didn't project, because it would be interesting to hear your specific rebuttal of his specific points.
[20:24:52] <kaduk@jabber.org/barnowl> Hopefully Jeffrey could still put a link to his slide in the chat?
[20:25:09] Jordan Head_web_803 leaves the room
[20:25:43] <Jim Guichard_web_804> @John Scudder i guess it will go on the mailing list but the main point is that APN *could* be used to forward a traffic into a specific network slice but i would doubt having a slice per APN given that the permutations could be very large
[20:25:58] <John Scudder_web_873> I took his point broadly speaking to be that if one focuses on the definition of network slicing and ignores the marketing name, the definition matches. Which if true, is a good thing, that's what you want out of a well thought-out architecture. "If the shoe fits, wear it."
[20:26:15] <Joel Halpern_web_736> @Jim Guichard - I hope this is not network slicing.  However, it is hard to distinguish the two apparently different meanings of assigning behavior to subsets of traffic.  The IETF network slicing work has been focusing on making sure that the result is aggregatable and scalable.   So it seems to be tackling the harder problems.  Beyond that, we have plenty of tools.
[20:26:15] Zheng Zhang_web_308 leaves the room
[20:26:55] Bron Gondwana_web_353 joins the room
[20:27:17] <Dirk Hugo_web_120> is the gap that existing approaches only provide limited granularity but APN an unlimited one?
[20:27:23] asai joins the room
[20:27:32] <Zhaohui Zhang_web_834> Here are the text from the slide that I tried to share:
[20:28:42] asai leaves the room
[20:29:15] <kaduk@jabber.org/barnowl> Right, we have no protocol mechanism to enforce what's in the APN
marking and when it's removed, which I think relates to a question
Joey had asked near the start of the session.
[20:29:27] <Dino Farinacci_web_876> I really agree with Ted
[20:29:29] <Zhaohui Zhang_web_834> Ongoing IETF Network Slicing work already addresses the problem domain and solution
- An IETF Network Slice provides the required connectivity between different entities in RAN and CN segments of an end-to-end network slice, with a specific performance commitment.
- It is intended that IETF Network Slices can be created to meet specific requirements, typically expressed as bandwidth, latency, latency variation, and other desired or required characteristics.
- An IETF Network Slice combines the connectivity resource requirements and associated network behaviors such as bandwidth, latency, jitter, and network functions with other resource behaviors such as compute and storage availability.
- Term "Slice" refers to a set of characteristics and behaviors that separate one type of user-traffic from another.  IETF Network Slice assumes that an underlying network is capable of ... fulfilling all or some of SLOs to all of the traffic in the slice or to specific flows
- Many approaches are currently being worked on to support IETF Network Slices in IP and MPLS networks with or without the use of Segment Routing.  Most of these approaches utilize a way of marking packets so that network nodes can apply specific routing and forwarding behaviors to packets that belong to different IETF Network Slices. Different mechanisms for marking packets have been proposed (including using MPLS labels and Segment Rouing segment IDs)
- The realization can be achieved in a form of either physical or logical connectivity using VPNs, virtual networks (VNs), or a variety of tunneling technologies such as Segment Routing, MPLS, etc.
- Slice Aggregate concept (similar to DiffServ Behavior Aggregate) in draft-bestbar is about identifying some or all traffic in a slice using opaque numbers and providing corresponding forwarding treatment
[20:29:50] <Shuping Peng_web_302> @Jen, that is because the 5 tuples of the original packet have encapsulated within the tunnel. If people want to do the policy enforcement again within the network domain, they will have to resolve the 5 tuples.
[20:29:57] <Zhaohui Zhang_web_834> The bullets are quotes from the IETF Network Slice framework
[20:30:08] <Watson Ladd_web_701> so it's just pulling the 5 tuple to the front?
[20:30:51] <Lou Berger_web_111> @zhaohui -- thanks for clarifying, it wasn't clear to me why you were reading this definition
[20:31:41] Markus Amend_web_312 leaves the room
[20:31:49] <Dino Farinacci_web_876> right, and leave some packet bits for the app ;-)
[20:31:55] <Rüdiger Volk_web_461> is slicing more general because addressing MULTI operator scenarios?
[20:32:10] Markus Amend_web_406 joins the room
[20:32:15] <Jari Arkko_web_150> +1 on Watson's argument about picking an existing tunneling layer
[20:32:44] Zheng Zhang_web_427 joins the room
[20:32:47] <Dino Farinacci_web_876> +2
[20:33:06] Markus Amend_web_406 leaves the room
[20:33:16] <Shuping Peng_web_302> @Waston, we are not creating new tunnels, we are using the exisitng tunnel to carry the APN attribute, to that, we would need some extensions and new specifications.
[20:33:33] <Watson Ladd_web_701> but why not extend existing tunnel across your entire network?
[20:33:52] Jeffrey Haas_web_126 leaves the room
[20:33:59] <Dino Farinacci_web_876> putting the solution in the overlay alone doesn't solve the problem, the underlay needs to support it too
[20:34:10] Cullen Jennings_web_768 leaves the room
[20:34:20] Cullen Jennings_web_127 joins the room
[20:34:22] <Watson Ladd_web_701> from the first slide you've got one entity controlling different incompatible pieces with different tunneling mechanisms. just pick one: you've got to change everything anyway
[20:34:24] <Antoine Fressancourt_web_108> With properly anonymized packets, APN could in teh end represent less metadata than want an encapsulated packet sent on a mobiel network would leak
[20:34:28] Markus Amend_web_574 joins the room
[20:34:36] Roman Danyliw joins the room
[20:34:38] <Dino Farinacci_web_876> tell me why copying outer TOS to inner TOS and using existing equipment is not enough?
[20:34:51] <Dino Farinacci_web_876> I mean inner to outer on encap
[20:35:06] Ole Trøan_web_750 leaves the room
[20:35:06] Srihari Sangli_web_416 leaves the room
[20:35:12] Markus Amend_web_574 leaves the room
[20:35:13] Srihari Sangli_web_797 joins the room
[20:35:16] Markus Amend_web_394 joins the room
[20:35:18] Ole Trøan_web_473 joins the room
[20:35:28] <Sergey Fomin_web_937> @Shuping is that just an attribute, though? or a new encapsulation which should be processed in fastpath on each hop?
[20:35:33] <Sergey Fomin_web_937> feels like the latter.
[20:35:54] Shraddha Hegde_web_654 leaves the room
[20:36:44] <Roland Bless_web_943> I didn't find the gap analysis convincing. IMHO there are plenty of solutions available to do this.
[20:36:57] <Lou Berger_web_111> +1
[20:37:05] <Watson Ladd_web_701> +1
[20:37:07] <Sergey Fomin_web_937> Agree with Roland.
[20:37:20] <Tarek Saad_web_966> @ Roland +1
[20:37:32] Deborah Brungard_web_187 leaves the room
[20:37:43] Deborah Brungard_web_784 joins the room
[20:37:53] <Joel Halpern_web_736> @roland +1
[20:37:56] <Tarek Saad_web_966> though Gyan started on it (thanks) - but was not exhaustive
[20:38:02] Pablo Camarillo_web_438 joins the room
[20:38:03] Carlos Bernardos_web_961 leaves the room
[20:38:13] <David Black_web_656> @Shuping - suggest starting by picking one encapsulation to carry APN, focus on that and ensure that APN solves a problem that the existing encapsulation does not.  The assertion that the APN must be encapsulation-independent is poorly supported by what I've seen.
[20:38:24] Markus Amend_web_394 leaves the room
[20:38:29] <Kireeti Kompella_web_782> @roland +1 @tarek +1
[20:38:32] <Nicolas Kuhn_web_898> I think inter-domain relies on protocols inter-operability that is dealt with a protocol-per-protocol basis ; not sure a specific WG is necessary to do so. this needs to be discussed in specific and existing WG
[20:38:35] <Luis Contreras_web_441> I see some contradiction between the positions that "this can be done with other existing capabilities" with the argument of "this is potntially problematic". If the first argument apply, then the second does not (or at least the risk is already there).
[20:38:57] <Srihari Sangli_web_797> @roland + 1
[20:39:00] <Roland Bless_web_943> The other thing I find a bit odd: 5 tuple is considered to be complex, but processing the attribute parameters on bandwidth, delay, jitter requirements etc. not? I mean I understood, that the latter is probably only required for some attributes, but nevertheless...
[20:39:07] <Antoine Fressancourt_web_108> @Luis +1
[20:39:11] <Watson Ladd_web_701> @Luis: it's "the claimed application can be done with existing technology" and "the generality is dangerous"
[20:39:23] Carlos Bernardos_web_458 joins the room
[20:39:24] <Watson Ladd_web_701> @Roland+1
[20:39:25] <Dan Voyer_web_901> @Dino, how about you come to the mic with your views ? :)
[20:39:29] <Kazuaki Ueda_web_615> @Roland+1
[20:39:31] Ahmed Aldabbagh_web_420 joins the room
[20:39:42] <Uma Chunduri_web_827> @Luis +1
[20:39:54] <John Scudder_web_873> @Roland thanks for saying that
[20:40:01] <Antoine Fressancourt_web_108> @Watson if privacy is a concern, I encourage you to look at the academic litterature on AI uses for Traffic classification
[20:40:05] Alessandro Amirante_web_313 joins the room
[20:40:09] Susan Hares_web_786 leaves the room
[20:40:21] <Jim Guichard_web_804> @chairs maybe let folks talk that have not already been to the mic multiple times?
[20:40:21] Pablo Camarillo_web_438 leaves the room
[20:40:36] Jordi Domingo-Pascual_web_802 leaves the room
[20:40:37] <Dan Voyer_web_901> yes
[20:40:38] <Alissa Cooper_web_439> @Luis, as Jana said, the threat model for a generic attribute is different than for a narrowly scoped attribute specific to a particular tunneling mechanism
[20:40:38] <Kireeti Kompella_web_782> @dan bernier: change APN to API?
[20:40:53] <Uma Chunduri_web_827> @proponents - Slicing solutions and it's overlap should be addressed in the gaps
[20:40:53] Markus Amend_web_966 joins the room
[20:41:27] <Daniel Bernier_web_884> @kireeti did not want to go to "intent". but API  oh yes
[20:41:31] <Daniel Bernier_web_884> :D
[20:41:33] <Jen Linkova_web_744> Luis: (re your "existing mechanism vs risk arguments) - we might have  mechanisms to solve the proposed use cases. New mechanism might have *additional* security/privacy implications which existing mechanisms don't (or have but not to that degree).
[20:41:40] Susan Hares_web_274 joins the room
[20:42:12] <Uma Chunduri_web_827> @proponents is the structure for APN-ID (if there) has to be defined and standardized case by case? or it's generic 16/32/8 bit metdata
[20:42:28] Alessandro Amirante_web_313 leaves the room
[20:42:29] <Watson Ladd_web_701> +1 Ron: avoid making desert wax and floor topping
[20:42:48] Yimin Shen_web_398 leaves the room
[20:42:55] <Kireeti Kompella_web_782> @dan API = application intent?
[20:43:04] Bhavit Shah_web_165 leaves the room
[20:43:14] <Daniel Bernier_web_884> yup !
[20:43:20] Ron Bonica_web_687 leaves the room
[20:43:43] Matthew Quick_web_769 leaves the room
[20:43:49] Matthew Quick_web_349 joins the room
[20:44:29] <Daniel Bernier_web_884> a network domain might decide to convey it by any means available
[20:44:41] <Daniel Bernier_web_884> or not if the intent is ludicrous
[20:44:43] <Shuping Peng_web_302> @Jari, thank you for your suggestions!
[20:45:09] Ron Bonica_web_293 joins the room
[20:45:28] Karen O'Donoghue_web_581 joins the room
[20:45:38] <Shuping Peng_web_302> @Uma, thank you. That is up to the working group to decide the proper design.
[20:45:52] Ruixue Wang_web_130 leaves the room
[20:46:06] Deb Cooley_web_637 joins the room
[20:46:06] Chenhao Ma_web_330 leaves the room
[20:46:26] Chenhao Ma_web_532 joins the room
[20:47:09] Marco Schrieck_web_398 joins the room
[20:47:29] <Daniel Bernier_web_884> the trick is how an app developper can know what capabilities are available from a given  network (sdk ?)
[20:47:48] <Shuping Peng_web_302> @Ron, the use cases presented here are intended to be kept simple, clear and strightforward so people could get the point immediately within the 10mintues presentation. But since ietf108 we have presented so many times on the use cases and usage scenarios and no need to repeat here and we already drafts
[20:48:25] <Dino Farinacci_web_876> that's why we only have TOS bits to play with Erik
[20:48:42] Rob Hamilton_web_328 joins the room
[20:48:58] <Dino Farinacci_web_876> and TOS has an advanage, you only have 8 bits of combinations, a feaure, less profiles better
[20:49:24] <Boris Khasanov_web_716> @Daniel - very important question! Agree that APN should think about it too.
[20:49:36] <Shuping Peng_web_302> @Dirk, we are not creating new domains. We are building upon the existing networks.
[20:50:04] <Dino Farinacci_web_876> who you are? That can't be good
[20:50:05] Mike Koldychev_web_976 leaves the room
[20:50:43] <Shuping Peng_web_302> @Daniel Bernier, APN is only about the network
[20:51:04] <cabo> Dino: Many people confuse "who am I" with "what are my attributes"
[20:51:06] <Dino Farinacci_web_876> no its not, IMO, its about the packets anyone or anything could send
[20:51:07] <Kireeti Kompella_web_782> if you weren't scared before, jim's made a case for really being scared
[20:51:14] <cabo> That is even our definition of identity
[20:51:17] <Watson Ladd_web_701> APN is about the network doing what? feel like we've had the same conversation after 110
[20:51:22] Marco Schrieck_web_398 leaves the room
[20:51:26] Aihua Guo_web_533 leaves the room
[20:51:44] <Jim Guichard_web_804> @kireeti i am scary, terribly so ;-)
[20:51:53] Aihua Guo_web_555 joins the room
[20:51:59] <Watson Ladd_web_701> if there isn't a succinct usecase that doesn't fit existing work, the case for doing it sounds week to me?
[20:52:00] <Dino Farinacci_web_876> right, @cabo
[20:52:02] <cabo> 32 bits is not enough to tell who you are, need 1 or 2 more bits
[20:52:24] <Dino Farinacci_web_876> well a hash(jimG) could fit in 32-bits
[20:52:29] <Dino Farinacci_web_876> but just don't do it
[20:52:52] <Zhenbin Li_web_980> @Ted regarding your issues, though the entry/exit points is flexible, the APN attribute must be carried along with tunnel in the domain. Then the APN attribute will be removed along with the tunnel.
[20:52:52] Chi-Jiun Su_web_298 joins the room
[20:52:57] <Jim Guichard_web_804> @kireeti maybe identify is a better way to put it so identity to attribute mapping to be used to identify which policy to enforce
[20:52:57] Éric Vyncke_web_702 joins the room
[20:53:06] Florence D_web_459 joins the room
[20:53:11] <cabo> But it is nearly irrelevant for a router, no?  What the application *is* (not wants) is of interest — API (intent) indeed
[20:53:19] <Zongpeng Du_web_361> IMO, APN is a kind of network programming mechanism,and it increases the network intelligence capability. It should be helpful to the operator, and hope it to be flexible.
[20:53:43] Rob Hamilton_web_328 leaves the room
[20:53:58] <Kireeti Kompella_web_782> @jim, post mapping, sure. but identity itself? and location, what they are doing, ...? that gets truly scary
[20:54:10] Carlos Bernardos_web_458 leaves the room
[20:54:11] Deb Cooley_web_637 leaves the room
[20:54:39] <Dirk Hugo_web_120> @Toerless: DIUYC that machines need no privacy? They are very often strongly related to humans IMO
[20:54:49] <Ted Hardie_web_575> @Toerless the fact it came from a device and not a human does not eliminate privacy concerns, it changes them.  Consider the privacy characteristics of a set of CO2 sensors--within the application they demonstrate which rooms are occupied and can tell you whether a specific dwelling has people home or not.  That still has privacy implications, even though not emitted by a human.  That's a very simple example, but hopefully you can extrapolate to other applications from there.
[20:55:10] <kaduk@jabber.org/barnowl> What different treatment will the network give my traffic if I'm in
finance vs. marketing?
[20:55:17] Jim Uttaro_web_649 leaves the room
[20:55:22] <Jim Guichard_web_804> @kireeti sure but locality is interesting and perhaps what you are doing in terms of which application (not what your doing in the application)
[20:55:31] <Dino Farinacci_web_876> but how do you scale for "granular treatment" for 1000 flows on the other side of that leased line?
[20:55:34] <Lou Berger_web_111> @tes +1
[20:55:42] Eric Voit_web_966 leaves the room
[20:56:01] Zafar Ali_web_931 joins the room
[20:57:05] Y. Richard Yang_web_932 leaves the room
[20:57:50] Justin Iurman_web_849 leaves the room
[20:57:55] Justin Iurman_web_658 joins the room
[20:58:00] <Tony Przygienda_web_515> Classify on the edge map on whatever tunnel flavor rocks your boat all done last 2nr seemed like grappling for some nebulous usecase and since it’s not apparently visible it seems general solution for the unknown case is summoned :grinning:
[20:58:23] <Dan Voyer_web_901> @kaduk@jabber.org/barnowl your question seems to also be a question for slicing
[20:58:33] <Shuping Peng_web_302> APN does not conflict with the existing solutions on the fine granular network services such as network slicing and detnet. APN is a way to express the services for the operators to better perform service provisioning, which is for sure based on customer's consent.
[20:58:44] <Watson Ladd_web_701> why does the operator need that?
[20:58:52] <Watson Ladd_web_701> they already deploy slicing to deliver the service
[20:59:00] Zheng Zhang_web_427 leaves the room
[20:59:00] <Watson Ladd_web_701> or MPLS to deliver the service
[20:59:02] <Toerless Eckert_web_192> @ted; i didn't say all m2m has no privacy concerns, bit significant and important cases do not
[20:59:27] <Kireeti Kompella_web_782> the gap is in understanding what's there today
[20:59:33] <Shuping Peng_web_302> this use cases presentation has shown some benefits
[20:59:52] <Kireeti Kompella_web_782> benefits that are delivered by network slicing
[21:00:11] <Zongpeng Du_web_361> we do not think it is conflicted between Network slicing and APN
[21:00:27] <Kireeti Kompella_web_782> great! that's a good place to start
[21:00:51] <Toerless Eckert_web_192> @ted: btw: still interested to better understand your iabopen comment ;-)
[21:00:59] <Lou Berger_web_111> what does the apn architecture add that isn't in existing IETF architectures and solutions
[21:01:19] Mohit Sethi_web_436 leaves the room
[21:01:25] <kaduk@jabber.org/barnowl> Huge thanks to the chairs for organizing/running the session and
providing the summary at the end!
[21:01:33] <Joey Salazar_web_755> +1 Martin, a draft is needed to clarify the points we've been going in circles for a while
[21:01:42] Mike McBride_web_873 leaves the room
[21:01:48] Hesham ElBakoury_web_611 leaves the room
[21:01:51] Ville Hallivuori_web_757 leaves the room
[21:01:53] Mark McFadden_web_265 leaves the room
[21:01:55] Michael Richardson_web_958 leaves the room
[21:01:56] Joel Halpern_web_736 leaves the room
[21:01:57] Greg White_web_341 leaves the room
[21:01:58] <Dirk Hugo_web_120> kusto to minute takers!
[21:01:58] Kiran Makhijani_web_245 leaves the room
[21:01:59] Hannu Flinck_web_445 leaves the room
[21:01:59] Eduard V_web_805 leaves the room
[21:01:59] Jen Linkova_web_744 leaves the room
[21:02:00] Florence D_web_459 leaves the room
[21:02:01] Tony Przygienda_web_515 leaves the room
[21:02:02] David Pelton_web_185 leaves the room
[21:02:02] Uma Chunduri_web_827 leaves the room
[21:02:03] Martin Duke_web_991 leaves the room
[21:02:03] John Kaippallimalil_web_299 leaves the room
[21:02:03] Watson Ladd_web_701 leaves the room
[21:02:03] Takuya Miyasaka_web_704 leaves the room
[21:02:03] Jana Iyengar_web_243 leaves the room
[21:02:03] Chi-Jiun Su_web_298 leaves the room
[21:02:04] Mercia Zheng_web_321 leaves the room
[21:02:04] Zhaohui Zhang_web_834 leaves the room
[21:02:04] Peter Campbell_web_172 leaves the room
[21:02:05] <Joey Salazar_web_755> thank you all
[21:02:05] Shu-Fang Hsu_web_808 leaves the room
[21:02:05] Zhe Lou_web_621 leaves the room
[21:02:06] Georgios Karagiannis_web_458 leaves the room
[21:02:06] Yang Guo_web_718 leaves the room
[21:02:06] <Daniel Bernier_web_884> great job chairs
[21:02:06] Tarek Saad_web_966 leaves the room
[21:02:07] Greg Mirsky_web_877 leaves the room
[21:02:08] <Lou Berger_web_111> thanks all!
[21:02:09] Carlos Bernardos_web_320 joins the room
[21:02:10] Yuji Tochio_web_972 leaves the room
[21:02:10] Alexander Clemm_web_354 leaves the room
[21:02:11] Haibo Wang_web_115 leaves the room
[21:02:11] Julien Maisonneuve_web_297 leaves the room
[21:02:11] Ole Trøan_web_473 leaves the room
[21:02:12] Charles Eckel_web_741 leaves the room
[21:02:12] Roland Bless_web_943 leaves the room
[21:02:12] Stefano Previdi_web_927 leaves the room
[21:02:13] Lijun Dong_web_185 leaves the room
[21:02:13] Anna Blasiak_web_675 leaves the room
[21:02:13] Srihari Sangli_web_797 leaves the room
[21:02:13] Loa Andersson_web_211 leaves the room
[21:02:13] Carlos Bernardos_web_320 leaves the room
[21:02:14] Yoshifumi Atarashi_web_650 leaves the room
[21:02:14] Zafar Ali_web_931 leaves the room
[21:02:14] Lou Berger_web_111 leaves the room
[21:02:14] Yingzhen Qu_web_646 leaves the room
[21:02:15] Taiji Kimura_web_141 leaves the room
[21:02:16] Jiao Kang_web_787 leaves the room
[21:02:16] Enke Chen_web_811 leaves the room
[21:02:16] Eckard Bogenfeld_web_496 leaves the room
[21:02:17] Huaimo Chen_web_590 leaves the room
[21:02:17] Jim Guichard_web_804 leaves the room
[21:02:17] Mach Chen_web_794 leaves the room
[21:02:17] Francois Clad_web_717 leaves the room
[21:02:18] Luis Contreras_web_441 leaves the room
[21:02:18] Tianji Jiang_web_508 leaves the room
[21:02:19] Benjamin Kaduk_web_615 leaves the room
[21:02:20] Greg Wood_web_561 leaves the room
[21:02:20] Haoyu Song_web_176 leaves the room
[21:02:20] Ted Hardie_web_575 leaves the room
[21:02:20] Lin Han_web_866 leaves the room
[21:02:21] Nalini Elkins_web_833 leaves the room
[21:02:21] Frode Sorensen_web_708 leaves the room
[21:02:21] <dhruvdhody> Leave the room :)
[21:02:21] Zhenbin Li_web_980 leaves the room
[21:02:21] Jari Arkko_web_150 leaves the room
[21:02:22] Ike Kunze_web_708 leaves the room
[21:02:22] Tadahiko Ito_web_316 leaves the room
[21:02:23] John Border_web_857 leaves the room
[21:02:23] John Scudder_web_873 leaves the room
[21:02:23] sheng fang_web_191 leaves the room
[21:02:23] Alissa Cooper_web_439 leaves the room
[21:02:24] Ron Bonica_web_293 leaves the room
[21:02:25] <cabo> Meetecho: done
[21:02:25] <Cedric Westphal_web_342> thanks all!
[21:02:26] Donald Eastlake_web_106 leaves the room
[21:02:27] Alvaro Retana_web_722 leaves the room
[21:02:28] Cedric Westphal_web_342 leaves the room
[21:02:28] Sergey Fomin_web_937 leaves the room
[21:02:29] Lars Eggert_web_364 leaves the room
[21:02:29] Shuai Zhang_web_701 leaves the room
[21:02:30] Alessandro Amirante_web_977 joins the room
[21:02:30] Cengiz Alaettinoglu_web_678 leaves the room
[21:02:30] John Drake_web_482 leaves the room
[21:02:31] David Millman_web_293 leaves the room
[21:02:31] Wim Henderickx_web_410 leaves the room
[21:02:33] Shuping Peng_web_302 leaves the room
[21:02:33] Gyan Mishra_web_159 leaves the room
[21:02:34] Nicolas Kuhn_web_898 leaves the room
[21:02:34] Dirk Hugo_web_120 leaves the room
[21:02:34] Luigi Iannone_web_372 leaves the room
[21:02:35] Antoine Fressancourt_web_108 leaves the room
[21:02:35] <Boris Khasanov_web_716> thanks
[21:02:37] Chongfeng Xie_web_787 leaves the room
[21:02:39] Rick Taylor_web_700 leaves the room
[21:02:39] Ian Duncan_web_933 leaves the room
[21:02:40] Boris Khasanov_web_716 leaves the room
[21:02:40] Mirja Kühlewind_web_852 leaves the room
[21:02:40] Frode Kileng_web_428 leaves the room
[21:02:42] Susan Hares_web_274 leaves the room
[21:02:44] Adrian Farrel_web_934 leaves the room
[21:02:44] Fengwei Qin_web_134 leaves the room
[21:02:45] Robert Wilton_web_169 leaves the room
[21:02:45] Tom Hill_web_186 leaves the room
[21:02:46] Ram Santhanakrishnan_web_583 leaves the room
[21:02:46] <Olaf Kolkman_web_932> Thanks
[21:02:46] Xufeng Liu_web_657 leaves the room
[21:02:46] Diego Lopez_web_692 leaves the room
[21:02:46] Daniel Huang_web_612 leaves the room
[21:02:46] Stewart Bryant_web_274 leaves the room
[21:02:46] Martin Horneffer_web_889 leaves the room
[21:02:46] Dan Voyer_web_901 leaves the room
[21:02:46] Liu Yao_web_262 leaves the room
[21:02:46] Kazuaki Ueda_web_615 leaves the room
[21:02:47] Cullen Jennings_web_127 leaves the room
[21:02:48] Kireeti Kompella_web_782 leaves the room
[21:02:48] Yuefeng Qiu_web_196 leaves the room
[21:02:48] Wesley Eddy_web_858 leaves the room
[21:02:49] Marcus Ihlar_web_876 leaves the room
[21:02:50] Karen O'Donoghue_web_581 leaves the room
[21:02:50] Bob Hinden_web_187 leaves the room
[21:02:50] Stewart Bryant_web_336 joins the room
[21:02:50] Olaf Kolkman_web_932 leaves the room
[21:02:50] Xiao Min_web_772 leaves the room
[21:02:50] Hermin Anggawijaya_web_197 leaves the room
[21:02:51] Renan Krishna_web_694 leaves the room
[21:02:52] Cong Li_web_122 leaves the room
[21:02:52] Martin Vigoureux_web_135 leaves the room
[21:02:52] Feng Yang_web_394 leaves the room
[21:02:52] Daniel Bernier_web_884 leaves the room
[21:02:53] Yiannis Yiakoumis_web_302 leaves the room
[21:02:54] Naoya Kaneko_web_252 leaves the room
[21:02:54] Christian Hopps_web_861 leaves the room
[21:02:54] Chonggang Wang_web_328 leaves the room
[21:02:55] Philip Eardley_web_777 leaves the room
[21:02:55] Éric Vyncke_web_702 leaves the room
[21:02:56] Balazs Varga_web_940 leaves the room
[21:02:57] Ketan Talaulikar_web_700 leaves the room
[21:02:58] Kausik Majumdar_web_729 leaves the room
[21:02:58] Dawei Fan_web_662 leaves the room
[21:02:58] Daphanie Nisbeth_web_555 leaves the room
[21:02:59] János Farkas_web_454 leaves the room
[21:02:59] Luay Jalil_web_593 leaves the room
[21:03:00] David Black_web_656 leaves the room
[21:03:00] Scott Mansfield_web_400 leaves the room
[21:03:01] Eric Kinnear_web_641 leaves the room
[21:03:02] Yali Wang_web_354 leaves the room
[21:03:02] Shunwan Zhuang_web_101 leaves the room
[21:03:03] Deborah Brungard_web_784 leaves the room
[21:03:03] Ahmed Aldabbagh_web_420 leaves the room
[21:03:03] Geng-Da Tsai_web_274 leaves the room
[21:03:04] Meetecho leaves the room
[21:03:05] Ignas Bagdonas_web_348 leaves the room
[21:03:05] Bruno Decraene_web_217 leaves the room
[21:03:13] Carsten Bormann_web_132 leaves the room
[21:03:14] Frédéric Fieau_web_783 leaves the room
[21:03:16] Zaheduzzaman Sarker_web_778 leaves the room
[21:03:17] Jie Dong_web_767 leaves the room
[21:03:18] James Galvin_web_259 leaves the room
[21:03:22] Chenhao Ma_web_532 leaves the room
[21:03:25] Andrew Stone_web_445 leaves the room
[21:03:25] Toerless Eckert_web_192 leaves the room
[21:03:26] Lorenzo Miniero_web_404 leaves the room
[21:03:26] Dhruv Dhody_web_740 leaves the room
[21:03:26] Hirochika Asai_web_459 leaves the room
[21:03:26] Erik Kline_web_730 leaves the room
[21:03:26] Daniel King_web_174 leaves the room
[21:03:26] Mazen Khaddam_web_167 leaves the room
[21:03:26] Peng Liu_web_158 leaves the room
[21:03:26] Jingrong Xie_web_938 leaves the room
[21:03:26] Linda Dunbar_web_489 leaves the room
[21:03:26] Gang Yan_web_172 leaves the room
[21:03:26] Zongpeng Du_web_361 leaves the room
[21:03:26] Richard Li_web_959 leaves the room
[21:03:26] Gorry Fairhurst_web_252 leaves the room
[21:03:26] Kentaro Ebisawa_web_403 leaves the room
[21:03:26] Wen Lin_web_190 leaves the room
[21:03:26] Rüdiger Volk_web_461 leaves the room
[21:03:26] Chris Bowers_web_241 leaves the room
[21:03:26] Giuseppe Fioccola_web_724 leaves the room
[21:03:26] Paul Bottorff_web_233 leaves the room
[21:03:26] Joey Salazar_web_755 leaves the room
[21:03:26] Fan Yang_web_829 leaves the room
[21:03:26] Xavier de Foy_web_277 leaves the room
[21:03:26] Radu Valceanu_web_553 leaves the room
[21:03:26] Dave Sinicrope_web_397 leaves the room
[21:03:26] Darren Dukes_web_775 leaves the room
[21:03:26] LucAndré Burdet_web_948 leaves the room
[21:03:26] Nigel Davis_web_606 leaves the room
[21:03:26] Zhibo Hu_web_879 leaves the room
[21:03:26] Dino Farinacci_web_876 leaves the room
[21:03:26] Bron Gondwana_web_353 leaves the room
[21:03:26] Markus Amend_web_966 leaves the room
[21:03:26] Matthew Quick_web_349 leaves the room
[21:03:26] Aihua Guo_web_555 leaves the room
[21:03:26] Justin Iurman_web_658 leaves the room
[21:03:26] Alessandro Amirante_web_977 leaves the room
[21:03:26] Stewart Bryant_web_336 leaves the room
[21:03:31] frodek leaves the room
[21:03:39] meetecho-alexamirante leaves the room
[21:21:39] mcr leaves the room
[21:31:02] kaduk@jabber.org/barnowl leaves the room
[22:12:29] dhruvdhody joins the room
[22:17:21] dhruvdhody leaves the room: Disconnected: closed
[22:19:20] dhruvdhody joins the room
[22:32:50] dhruvdhody leaves the room: Disconnected: No route to host
[22:47:59] Roman Danyliw leaves the room: Disconnected: closed
[22:49:01] roman joins the room
[22:53:43] dhruvdhody leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!