idnits 2.17.00 (12 Aug 2021) /tmp/idnits8808/draft-iannone-routing-and-addressing-manifesto-01.txt: -(791): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (20 April 2022) is 24 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-king-irtf-challenges-in-routing-07 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force (IRTF) L. Iannone, Ed. 3 Internet-Draft Huawei 4 Intended status: Informational 20 April 2022 5 Expires: 22 October 2022 7 Innovation in Internet Routing and Addressing 8 draft-iannone-routing-and-addressing-manifesto-01 10 Abstract 12 This document arguments that despite the ongoing research in routing 13 and addressing and the Internet innovation, researchers and engineers 14 lack a dedicated forum where they can interact. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 22 October 2022. 33 Copyright Notice 35 Copyright (c) 2022 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Driving Internet Innovation through Research on Routing and 50 Addressing . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. From Research to Engineering . . . . . . . . . . . . . . . . 3 52 2.1. Bringing Innovation to life . . . . . . . . . . . . . . . 3 53 2.2. Examples of Routing and Addressing Innovation . . . . . . 4 54 3. Interplay between Researchers and Engineers . . . . . . . . . 7 55 4. Need to Amplify the Dialogue . . . . . . . . . . . . . . . . 8 56 5. The role of the IETF . . . . . . . . . . . . . . . . . . . . 9 57 5.1. Enter the IRTF . . . . . . . . . . . . . . . . . . . . . 10 58 5.2. Routing and Addressing in the IRTF . . . . . . . . . . . 11 59 6. Discussing Routing and Addressing Innovation . . . . . . . . 12 60 7. Sign the Manifesto . . . . . . . . . . . . . . . . . . . . . 13 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 63 10. Informative References . . . . . . . . . . . . . . . . . . . 13 64 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 67 1. Driving Internet Innovation through Research on Routing and 68 Addressing 70 Despite the fact that the IP addressing and IP routing models have 71 remained stable for more than 40 years, the Internet has experienced 72 a huge evolution ever since. Even if later than expected, the 73 transition from IPv4 to IPv6 is finally happening, showing that the 74 Internet is able to make important leaps. Beyond such evolution, 75 other very important innovations have been introduced by the IETF or 76 are under active engineering development (e.g., SRv6 [RFC8986], MANET 77 [RFC2501], 6LowPAN [RFC4919], ICN [RFC7927], PCE [RFC4655]). 79 The research community has also made important progress in better 80 understanding the properties of the routing and addressing and also 81 exploring diverse possible evolutions. Some of them being relatively 82 disruptive, but worth to be considered. Such extraordinary work has 83 been also recognized by the IRTF, were 18 out of 61 (circa 29%) of 84 the Applied Networking Research Prize Awards have been granted to 85 routing-related papers. All of the main academic conferences in 86 networking, like [INFOCOM], [SIGCOMM], and [CONEXT] have sessions 87 dedicated to routing and addressing, but also workshops fully 88 dedicated to such topics [I-D.galis-irtf-sarnet21-report]. Quite a 89 number of multi-year and multi-million projects have been funded by 90 government entity specifically on routing, addressing, or more 91 generally on architectural evolution of the Internet ([EU-FIA], 92 [NSF-FIA]). A more thorough survey on research on routing, in the 93 last decade or so, can be found in 94 [I-D.king-irtf-semantic-routing-survey]. 96 Communication scenarios have also evolved through the years. In the 97 90s the killer application was the World Wide Web. It remains a main 98 use case of the Internet, but in the meantime several diverse 99 communication scenarios have and still are emerging ([BEZAHAF20], 100 [LIU20], [BALAKRISHNAN21], [CAMPISTA14]). While, the network layer 101 remained focused on identifying communication end-points through 102 addresses and determining paths between end-points through routing, 103 the research, pushed by these new communications scenarios, has 104 started to explore even more alternatives. In particular, 105 investigating the possibility to add some semantic to addresses (not 106 just for end-point identification) and developing semantically rich 107 routing (not strictly based on addresses and prefixes but also on 108 other information, not necessarily from the network layer). 110 The evolution described above, has to continue and it is of paramount 111 importance that it does not slowdown, in order to cope with future 112 use and business cases, overcoming the existing challenges 113 [I-D.king-irtf-challenges-in-routing]. 115 2. From Research to Engineering 117 Bringing consolidated research to the Internet is in general a hard 118 task involving a lot of interaction between researchers and 119 engineers. The former trying to abstract from the details of the 120 real problem, while the latter trying to adapt the research outcome 121 to the real context. This creates a sort of contention that only 122 continuous information exchange can solve. Early engineering 123 deployment are usually done in small size limited domains, which are 124 then interconnected. In the remaining of this section we first look 125 at how this "limited domains" approach helps innovation and then 126 show-case few examples. 128 2.1. Bringing Innovation to life 130 As previously mentioned, it is very common to bringing new solutions 131 to the Internet through an incremental deployment that at early 132 stages is very "limited" in size and secluded in dedicated and 133 controlled "domains". Limited domains have been formally defined in 134 [RFC8799], but they existed informally for a long time, helping 135 introducing innovations in the Internet. In a certain way they are a 136 fact of (Internet) life. Historically, the Internet emerged as a 137 limited domain, implementing the requirements and behaviors of its 138 originating stakeholders. Even early IPv6 deployments were nothing 139 more than interconnected limited domains (at that time called 140 "island" in the IPv4 Internet). Today, it provides the common 141 backbone for other limited domains, or, stated differently, provides 142 the common foundation for further innovation. Indeed, private 143 technologies isolated in a standalone domain are just less 144 interesting, while interconnecting new solutions through the 145 Internet, at different scale (cf. Section 5 [RFC8799]), is where 146 innovation spurs. As Section 4 of [RFC8799] shows, the Internet and 147 IETF's work contains a lot of technologies being deployed using such 148 limited domains model, like for instance DiffServ [RFC2474], IntServ 149 [RFC2205], SFC [RFC7665], DCN overlays [RFC8151], Segment routing 150 [RFC8402], to cite a few. 152 The limited domain deployment model enables research to become 153 reality through implementation and deployments, with requirements and 154 behaviors of stakeholders interested in solutions driving LD 155 development. Example of requirements and behaviors are: 157 * New capabilities: traffic steering, better/different security, 158 privacy, supporting different topologies, and mobility; 160 * Diverse technologies: routing on new identifiers (services, host, 161 etc.), routing on different network layers like in IoT, and 162 semantically enriched routing; 164 * Deep programmability: match-action capability of programmable data 165 planes and advances in software and hardware enabling more complex 166 packet processing; 168 * Innovation: Limited Domains enable incremental deployability in 169 isolated islands for innovative solutions, which may or may not 170 percolate to the whole Internet at later stages; 172 * Better QoS: provide some form of service differentiation which may 173 be compatible to the best effort model (e.g., MPTCP [RFC8684], 174 ALTO [RFC7285], Interconnected Traffic-Engineered Networks 175 [RFC7926], or may rely on communication model radically different 176 from the best effort model (e.g., DetNet [RFC8655]). 178 2.2. Examples of Routing and Addressing Innovation 180 Hereafter, we briefly overview a few interesting examples of routing 181 and addressing innovation that emerged (or is still emerging) as an 182 interconnection of limited domains. The examples have been selected 183 in no particular fashion or purpose beyond their self-explanatory 184 nature. Certainly, quite a number of examples could be proposed, 185 however there is no intention to be exhaustive here. 187 Content Delivery Networks (CDN) 189 CDNs and CSP (Content Service Providers) have long ago recognized 190 the existence of the need for interconnecting (previously) 191 standalone CDNs so they can interoperate and collectively behave 192 as a single delivery infrastructure [RFC6707]. That is why the 193 CDNI WG ([CDNIWG]) has been formed in the IETF. 195 From the charter: 197 "...to allow the interconnection of separately administered 198 CDNs in support of the end-to-end delivery of content from CSPs 199 through multiple CDNs and ultimately to end users..." 201 This is a very interesting approach to innovation. While each CSP 202 is free to develop their own technology, a general protocol is 203 defined in order to safely interconnect different limited domains, 204 not necessarily exposing internal policies and solutions 205 [RFC7337]. This in turn triggers further innovation, like moving 206 content closer to customers while maintaining a high level of 207 security [LELOUEDEC21], or introducing specific technology like 208 OpenFlow to deliver content across the Internet [CHANG12] 210 Internet of Things (IoT) 212 IoT actually has different meaning in different contexts, however, 213 IoT deployments better than any other technology shows how 214 innovation is facilitated by using deployments limited domains. 215 For instance, 6Lo(WPAN): define a Limited Domain that has: 217 - a specialized addressing architecture (multi-link subnet), 219 - a specialized neighbor discovery ([RFC6775], [RFC8505]), 221 - a specialized compression schemes ([RFC6282], [RFC8138]), 223 - a specialized routing protocol ([RFC6550]). 225 Scattered domains of this type can then be interconnected through 226 the so called 6LowPAN Border Routers (6LBR [RFC8929]), basically 227 bridging the limited domains into one. This is just an example of 228 constrained node networks ([RFC7228]) that will help building 229 smart cities in the coming years ([CANO18]). Beyond smart cities, 230 thanks to IoT, there is an increasing digitalization in various 231 non-ICT sectors, like for instance energy, healthcare, 232 transportation [NIZETIC20]. 234 Privacy and Security 236 In recent years, people are developing a growing awareness about 237 privacy and security issues [PRIV-TRENDS]. This is reflected in 238 new regulations (e.g., General Data Protection Regulation - GDPR 240 [GODDARD17]), but also privacy awareness in protocol design 241 [RFC6973]. 243 For private and secure communications a widely used approach are 244 mix networks (e.g. [TOR]). In this context, each node can be 245 seen as independent, untrusted, and interconnected through an 246 untrusted network. Mix networks offer the highest privacy level 247 at the cost of reduced performance (latency and/or bandwidth). 248 Further, the principles and technology are used also for other 249 emerging use cases (e.g. [OSMAN21], [NEDELTCHEVA19], [ICLOUD]). 251 Recently, Gartner coined the term "SASE" for "Secure Access 252 Service Edge" [SASE], defining products and services aiming at 253 securing the remote access of users or applications to enterprise 254 resources (think about VPN on steroids). SASE is another kind of 255 private/secure domain that needs to interface with the public 256 Internet and enterprise cloud services, hence acting actually as 257 an in-between limited domain. 259 Isolating mix networks and SASE solutions from the Internet (while 260 using it as an interconnecting backbone) allows to develop 261 innovative solutions that do not necessarily rely on privacy and 262 security mechanisms of the public Internet, hence better tailored 263 for their specific requirements, and is defining the future of 264 network security ([WOOD20], [DESHPANDE21]). 266 Industry 4.0 268 Today networked, smart factories are going beyond the limits of 269 physical production lines. Smart manufacturing, marries physical 270 production and operations with smart digital technology, machine 271 learning, and big data to create a more holistic and better 272 connected ecosystem for companies ([SANCHEZ20], [WANG15]). 274 Such eco-system is, in terms of manufacturing, the interconnection 275 of different (limited) domains, namely the entire operation-- 276 inventory and planning, financials, customer relationships, supply 277 chain management, and manufacturing execution, etc. Such 278 pervasive connectivity is expected to trigger the 4th revolution 279 in the industrial world (hence the name Industry 4.0). 281 One way to move toward this vision is the adoption of the digital 282 twin paradigm, or going beyond the best-effort model of the 283 Internet. By providing a live copy of physical systems, digital 284 twins bring to the table numerous advantages such as accelerated 285 business processes, enhanced productivity, and faster innovation 286 with reduced costs. However, this comes with strict requirements 287 from a networking perspective, such as low latency and 288 deterministic communication [MASHALY21]. Deterministic 289 communication in particular is one of the major requirements in 290 various industrial sectors [RFC8578]. However, such communication 291 model may have profound implications in terms of routing, 292 addressing, and security, substantially differing from the (best 293 effort) Internet ([BIGO21], [MADDIKUNTA21], [SCANZIO21]). 295 3. Interplay between Researchers and Engineers 297 Scientific research and engineering innovation are able to progress 298 because they are tight together in a loop and nurturing each other, 299 as depicted in Figure 1. On the one hand, researchers take concrete 300 problems that engineers needs to solve, perform an abstraction so to 301 get rid of unnecessary details, and solve the corresponding abstract 302 problem. On the other hand, engineers take the solution to the 303 abstract problem and adapt it to their specific context. Any 304 mismatch or issue in this process is solved through more interaction. 306 Abstraction from Details 307 +-------------+ 308 / \ 309 +-----------------/--+ +--\-----------------+ 310 | Engineers / | | \ Researchers| 311 | / | | \/ | 312 | +-----------+ | | +-----------+ | 313 | | Concrete | | | |Abstract | | 314 | | Problem | | | |Problem | | 315 | | Domain | | | |Domain | | 316 | +-----------+ | | +-----------+ | 317 | /\ | | / | 318 +---------------\----+ +---/----------------+ 319 \ / 320 \ / 321 +--------------+ 322 Engineering Context Adaptation 324 Figure 1: The Researchers<->Engineering innovation loop. 326 Research community and engineering community are not actually 327 separate (like in Figure 1), but rather overlapping. Numerous 328 researchers regularly participate to various SDOs to bring their 329 solutions, and similarly, numerous engineers participate in academic 330 conference and research work to bring their "real world" experience. 331 However, there is also some fragmentation, mirrored in the way the 332 Internet evolves. On the one hand, community of researchers orbiting 333 around specific conferences are certainly not disjoint but neither 334 the same. For instance, the conferences IEEE INFOCOM, ACM SIGCOMM, 335 and ACM SIGMETRICS, while being all top notch networking conferences, 336 they represent three different type of researchers, IEEE INFOCOM more 337 system oriented, ACM SIGCOMM more protocol oriented, and ACM 338 SIGMETRICS more system theory oriented. On the other hand, something 339 similar happens in SDOs. For instance, IEEE, 3GPP, and the IETF, all 340 have network standardization activities but they tackle different 341 aspects, where IEEE is more about link layer standards, 3GPP designs 342 the different generations of cellular networks, and the IETF playing 343 a key role on everything around the TCP/IP protocol suite. Yet, 344 those SDOs do not attract necessarily the same engineering 345 communities. 347 In order to keep up with innovation there is a need to ensure that 348 the information between the research communities and the engineering 349 communities flows smoothly, through continue interaction, exchange of 350 opinions, experiences, problems, and viewpoints. This is certainly 351 true in any field, including routing and addressing. 353 4. Need to Amplify the Dialogue 355 Deploying and interconnecting new solutions is not just about using 356 the right interconnection protocol, it is also about "good" design. 357 This raises a tussle between the Internet and innovation. On the one 358 hand, the Internet is a well-functioning system whose core design 359 represents sunk investments. Furthermore, changing a running system 360 is pretty hard. On the other hand, there is an undeniable need for 361 sustaining innovation, because of emerging communication scenarios 362 where new stakeholders do not see their requirements adequately 363 realized. 365 Increasingly widening stakeholder interests will continue to drive 366 research and innovation (often in limited domain development). The 367 interconnection is increasingly done based on various field/ 368 information with semantics that can be found, added, associated to an 369 IP packet. The challenge lays in how to enable more innovation to be 370 carried across to other limited domains or the Internet? How to 371 share information about evolutions that are not harmful to the 372 overall system? 374 Business as usual is not enough to answer the above questions. If 375 there is not enough information sharing there is a risk to see a 376 fragmented evolution, due to independent innovation carried out in 377 the different communities mentioned above. Such a fragmented 378 evolution may create some risks, like for instance: 380 * Too many scattered unrelated domains interconnecting through the 381 Internet may actually hamper Internet robustness and its lean 382 design. 384 * Too many ad-hoc solutions/building blocks lead to high complexity 385 and augmented fragility. 387 * The need for 'offset' operations may decrease overall efficiency. 389 * The desire for a common denominator (IPv6 plus associated routing) 390 affects all interconnected domains, possibly impacting performance 391 and ultimately innovation capability. 393 * Nodes behavior gets more complicated, particularly at domain 394 boundaries, leading to unexpected/unwanted behavior, like: 396 - semantic leakage, i.e., routing information, leading to 397 fragility or security issues; 399 - privacy related information leakage that is pertinent for 400 security (e.g., sensors' MAC addresses or user identifiers); 402 - Specific technology islands may become more isolated, therefore 403 hampering interconnection and interoperability. 405 It can be observed that "The Time is Right to make it Right", because 406 we are at a juncture point. 408 The Internet technology is quite mature connecting a huge number of 409 networking technologies and providing global connectivity. Actually, 410 the TCP/IP protocol stack is so mature that is becoming commodity, 411 hence the fragmented evolution previously mentioned. While TCP/IP is 412 the more and more the converging technology, services are 413 differentiating, raising the need for making the Internet to continue 414 to evolve as well. When IPv6 started to be discussed, there was a 415 general sense of "urgency", because of the address shortage 416 forecasted by early 2000s (this was before NAT). This lead to some 417 conservative choices in order to somehow smooth the transition. In 418 this point in time, we have the luxury not being in such an 419 situation, there is no need to hurry up, instead there is the 420 opportunity, which we hopefully will not miss, to take the time to 421 carefully think about how to structure the unstructured by looking 422 forward. 424 5. The role of the IETF 426 As mentioned in Section 1, the IETF has always worked in introducing 427 important innovations in the Internet so to make it evolve and adapt 428 to the different emerging use cases. More importantly, the IETF has 429 recognized the importance of the interaction between researchers and 430 engineers a long time ago when its research branch, namely the 431 Internet Research Task Force ([IRTF]) was created. 433 5.1. Enter the IRTF 435 The IRTF has a privileged position close to the engineering 436 community, and already in [RFC2014], the first document setting the 437 IRTF guidelines, the importance of making engineers discuss with 438 researchers was recognized: 440 "... The expectation is that by sponsoring Research Groups, the 441 IRTF can foster cross-organizational collaboration, help to create 442 "critical mass" in important research areas, and add to the 443 visibility and impact of the work. ... " 445 Figure 2 tries to position the IRTF in the researchers<->engineering 446 innovation loop previously presented. Clearly the IRTF, has a 447 central role, helping in formalizing real problems and requirements, 448 so that afterwards an abstraction of the former can be tackled by 449 researchers. The IRTF can then help deciding whether the resulting 450 solution is mature enough to be transferred in the engineering domain 451 by first deriving detailed specifications so to facilitate later on 452 the adaptation to the engineering context. 454 Problem Abstraction 455 Formalization from Details 456 +-----+ +----+ 457 / \ / \ 458 +------------/--+ \ / +-\--------------+ 459 |Engineers / | \/ / | \ Researchers| 460 | / | +------------+ | \/ | 461 | +---------+ | | | | +---------+ | 462 | | Concrete| | | IRTF | | |Abstract | | 463 | | Problem | | | (RG) | | |Problem | | 464 | | Domain | | | | | |Domain | | 465 | +---------+ | +------------+ | +---------+ | 466 | /\ | / /\ | / | 467 +----------\----+ / \ +-/--------------+ 468 \ / \ / 469 +------+ +----+ 470 Engineering Research 471 Context Solution 472 Adaptation Specifications 474 Figure 2: The role of IRTF in the Researchers<->Engineering 475 innovation loop. 477 5.2. Routing and Addressing in the IRTF 479 Because of the above-mentioned role of the IRTF it is worth to have a 480 better look at the activities related to routing and addressing. 481 However, before overviewing such activities, it is worth noting that 482 because routing and addressing are cornerstones of the protocol stack 484 * everything relates to routing and addressing, 486 * routing and addressing relates to everything. 488 In other words, any IRTF's research group may include routing/ 489 addressing aspects and/or discuss them in the scope of their specific 490 topics. Note as well that the text following the name of the 491 research groups listed below are an excerpt of their charter. 493 The following research groups can be considered as almost unrelated 494 to routing and addressing. 496 * [CFRG] - Crypto Forum Research Group: Forum for discussing and 497 reviewing uses of cryptographic mechanisms. 499 * [GAIA] - Global Access to the Internet for All Research Group: 500 Internet access considered a basic human right. 502 * [NWCRG] - Network Coding for Efficient Network Communications 503 Research Group: Research Network Coding principles and methods 504 that can benefit Internet communication. 506 * [QIRG] - Quantum Internet Research Group: Quantum secure 507 communication, distributed quantum computing, and quantum-enhanced 508 physical sensor systems. 510 * [HRPC] - Human Rights Protocol Considerations Research Group: 511 Research whether standards and protocols can enable, strengthen or 512 threaten human rights. 514 * [ICCRG] - Internet Congestion Control Research Group: To move 515 towards consensus on which technologies are viable long-term 516 solutions for the Internet congestion control architecture. 518 The following research groups can be considered as lightly related to 519 routing and addressing. 521 * [DINRG] - Decentralized Internet Infrastructure Research Group: 522 Research on decentralizing infrastructure services such as trust 523 management, identity management, name resolution, resource/asset 524 ownership management, and resource discovery. 526 * [PEARG] - Privacy Enhancements and Assessments Research Group: 527 General forum for discussing and reviewing privacy enhancing 528 technologies for network protocols and distributed systems in 529 general, and for the IETF in particular. 531 * [NMRG] - Network Management Research Group: Forum to explore new 532 technologies for the management of the Internet. Such as 533 communication services between management systems, which may 534 belong to different management domains, as well as customer- 535 oriented management services. 537 * [MAPRG] - Measurement and Analysis for Protocols Research Group: 538 Forum being a "landing pad" for the Internet measurement community 539 to introduce its efforts to the IETF. 541 * [ICNRG] - Information-Centric Networking Research Group: 542 Introducing uniquely named data as a core Internet principle. 543 Data becomes independent from location, application, storage, and 544 means of transportation, enabling in-network caching and 545 replication. 547 * [PANRG] - Path Aware Networking Research Group: Forum in support 548 of research aiming at bringing path awareness to transport and 549 application layer protocols. 551 * [T2TRG] - Thing-to-Thing Research Group: Research forum to 552 investigate open research issues in turning a true "Internet of 553 Things" into reality, an Internet where low-resource nodes 554 ("things", "constrained nodes") can communicate among themselves 555 and with the wider Internet, in order to partake in permissionless 556 innovation. 558 * [COINRG] - Computing In the Network Research Group: To explore 559 existing research and foster investigation of "compute in network" 560 and resultant impacts to the data plane. 562 From the above lists, a clear takeaway is that there is no research 563 group in the IRTF that has an explicit focus on innovation in the 564 specific context of routing and addressing. 566 6. Discussing Routing and Addressing Innovation 568 Previous sections have highlighted how the present situation is that 569 routing and addressing are discussed a little bit in numerous places 570 (conferences and SDOs), but have not a dedicated forum. Yet, as 571 [I-D.king-irtf-semantic-routing-survey] and 572 [I-D.king-irtf-challenges-in-routing] point out there is still 573 challenges to take up. 575 In order keep the research and the innovation in routing and 576 addressing consistent and ongoing, avoiding a fragmented evolution, 577 as described in the first part of the present memo, a specific 578 dedicated forum should exists. Recent meetings like: 580 * "Routing research challenges arising from evolving beyond and 581 revitalizing the Internet" [SIDEIETF111] 583 * Interim Workshop on Evolving Routing Security in the Internet 584 [INTERIM21] 586 look like an interesting and successful format. 588 7. Sign the Manifesto 590 If you agree that the kind of forum described above should exist and 591 make the above-listed meetings a regular event, please add your name 592 to the public list of supporters at: 594 https://etherpad.wikimedia.org/p/routing.addressing.manifesto 596 expressing the willingness to create, participate and contribute to 597 such a forum. 599 Alternatively, send an email at the address: 601 routing.addressing.manifesto@gmail.com 603 The editor of the draft will take care to add the information 604 provided by mail to the public list of supporters. 606 8. Security Considerations 608 The present memo does not introduce any new technology and/or 609 mechanism and as such does not introduce any security threat to the 610 TCP/IP protocol suite. 612 9. IANA Considerations 614 This document includes no request to IANA. 616 10. Informative References 618 [BALAKRISHNAN21] 619 Balakrishnan, H., Banerjee, S., Cidon, I., Culler, D., 620 Estrin, D., Katz-Bassett, E., Krishnamurthy, A., McCauley, 621 M., McKeown, N., Panda, A., Ratnasamy, S., Rexford, J., 622 Schapira, M., Shenker, S., Stoica, I., Tennenhouse, D., 623 Vahdat, A., and E. Zegura, "Revitalizing the public 624 internet by making it extensible", 625 DOI 10.1145/3464994.3464998, ACM SIGCOMM Computer 626 Communication Review Vol. 51, pp. 18-24, April 2021, 627 . 629 [BEZAHAF20] 630 Bezahaf, M., Hutchison, D., King, D., and N. Race, 631 "Internet Evolution: Critical Issues", 632 DOI 10.1109/mic.2020.3001519, IEEE Internet Computing Vol. 633 24, pp. 5-14, July 2020, 634 . 636 [BIGO21] Bigo, S., Benzaoui, N., Christodoulopoulos, K., Miller, 637 R., Lautenschlaeger, W., and F. Frick, "Dynamic 638 Deterministic Digital Infrastructure for Time-Sensitive 639 Applications in Factory Floors", 640 DOI 10.1109/jstqe.2021.3093281, IEEE Journal of Selected 641 Topics in Quantum Electronics Vol. 27, pp. 1-14, November 642 2021, . 644 [CAMPISTA14] 645 Campista, M., Rubinstein, M., Moraes, I., Costa, L., and 646 O. Duarte, "Challenges and Research Directions for the 647 Future Internetworking", 648 DOI 10.1109/surv.2013.100213.00143, IEEE Communications 649 Surveys & Tutorials Vol. 16, pp. 1050-1079, 2014, 650 . 652 [CANO18] Cano, J., Berrios, V., Garcia, B., and C. Toh, "Evolution 653 of IoT: An Industry Perspective", 654 DOI 10.1109/iotm.2019.1900002, IEEE Internet of Things 655 Magazine Vol. 1, pp. 12-17, December 2018, 656 . 658 [CDNIWG] "Content Delivery Networks Interconnection (CDNI)", 659 . 661 [CFRG] "Crypto Forum Research Group (CFRG)", 662 . 664 [CHANG12] Chang, D., Suh, J., Jung, H., Kwon, T., and Y. Choi, "How 665 to realize CDN interconnection (CDNI) over OpenFlow?", 666 DOI 10.1145/2377310.2377319, Proceedings of the 7th 667 International Conference on Future Internet Technologies - 668 CFI '12, 2012, . 670 [COINRG] "Computation in the Network Research Group (COINRG)", 671 . 673 [CONEXT] "Conference on emerging Networking EXperiments and 674 Technologies (CoNEXT)", . 677 [DESHPANDE21] 678 "A Study on Rapid Adoption of Zero Trust Network 679 Architectures by Global Organizations Due to COVID-19 680 Pandemic", BP International - New Visions in Science and 681 Technology, Vol. 1, pp. 26-33 , August 2021. 683 [DINRG] "Decentralized Internet Infrastructure Research Group 684 (DINRG)", . 686 [EU-FIA] "Future Internet", 687 . 690 [GAIA] "Global Access to the Internet for All Research Group 691 (GAIA)", . 693 [GODDARD17] 694 Goddard, M., "The EU General Data Protection Regulation 695 (GDPR): European Regulation that has a Global Impact", 696 DOI 10.2501/ijmr-2017-050, International Journal of Market 697 Research Vol. 59, pp. 703-705, November 2017, 698 . 700 [HRPC] "Human Rights Protocol Considerations Research Group 701 (HRPC)", . 703 [I-D.galis-irtf-sarnet21-report] 704 Galis, A. and D. Lou, "Semantic Addressing and Routing for 705 Future Networks (SARNET-21) Workshop Report", Work in 706 Progress, Internet-Draft, draft-galis-irtf-sarnet21- 707 report-01, 26 July 2021, . 710 [I-D.king-irtf-challenges-in-routing] 711 King, D., Farrel, A., and C. Jacquenet, "Challenges for 712 the Internet Routing Infrastructure Introduced by Semantic 713 Routing", Work in Progress, Internet-Draft, draft-king- 714 irtf-challenges-in-routing-07, 22 January 2022, 715 . 718 [I-D.king-irtf-semantic-routing-survey] 719 King, D. and A. Farrel, "A Survey of Semantic Internet 720 Routing Techniques", Work in Progress, Internet-Draft, 721 draft-king-irtf-semantic-routing-survey-03, 26 November 722 2021, . 725 [ICCRG] "Internet Congestion Control Research Group (ICCRG)", 726 . 728 [ICLOUD] "iCloud Private Relay", 729 . 732 [ICNRG] "Information-Centric Networking Research Group (ICNRG)", 733 . 735 [INFOCOM] "IEEE International Conference on Computer 736 Communications", . 738 [INTERIM21] 739 "Interim Workshop on Evolving Routing Security in the 740 Internet", 741 . 744 [IRTF] "Internet Engineering Task Force (IRTF)", 745 . 747 [LELOUEDEC21] 748 Le Louédec, Y., Yven, G., Bastide, V., Chen, Y., Delsart, 749 G., Dzida, M., Fieau, F., Fleming, P., Froger, I., Haddak, 750 L., Omnes, N., and V. Thiebaut, "Content Delivery 751 Networks: On the Path Towards Secure Cloud-Native 752 Platforms at the Edge", 753 DOI 10.4018/978-1-7998-7646-5.ch003, Design Innovation and 754 Network Architecture for the Future Internet pp. 66-95, 755 2021, . 757 [LIU20] Liu, G., Huang, Y., Li, N., Dong, J., Jin, J., Wang, Q., 758 and N. Li, "Vision, requirements and network architecture 759 of 6G mobile network beyond 2030", 760 DOI 10.23919/jcc.2020.09.008, China Communications Vol. 761 17, pp. 92-104, September 2020, 762 . 764 [MADDIKUNTA21] 765 Maddikunta, P., Pham, Q., B, P., Deepa, N., Dev, K., 766 Gadekallu, T., Ruby, R., and M. Liyanage, "Industry 5.0: A 767 survey on enabling technologies and potential 768 applications", DOI 10.1016/j.jii.2021.100257, Journal of 769 Industrial Information Integration Vol. 26, pp. 100257, 770 March 2022, . 772 [MAPRG] "Measurement and Analysis for Protocols Research Group 773 (MAPRG)", . 775 [MASHALY21] 776 Mashaly, M., "Connecting the Twins: A Review on Digital 777 Twin Technology & its Networking Requirements", 778 DOI 10.1016/j.procs.2021.03.039, Procedia Computer 779 Science Vol. 184, pp. 299-305, 2021, 780 . 782 [NEDELTCHEVA19] 783 Nedeltcheva, G., Vila, E., and M. Marinova, "The Onion 784 Router: Is the Onion Network Suitable for Cloud 785 Technologies", DOI 10.1007/978-3-030-01659-3_45, Smart 786 Technologies and Innovation for a Sustainable Future pp. 787 389-398, 2019, 788 . 790 [NIZETIC20] 791 Nižetić, S., Šolić, P., López-de-Ipiña González-de-Artaza, 792 D., and L. Patrono, "Internet of Things (IoT): 793 Opportunities, issues and challenges towards a smart and 794 sustainable future", DOI 10.1016/j.jclepro.2020.122877, 795 Journal of Cleaner Production Vol. 274, pp. 122877, 796 November 2020, 797 . 799 [NMRG] "Network Management Research Group (NMRG)", 800 . 802 [NSF-FIA] Fisher, D., "A look behind the future internet 803 architectures efforts", DOI 10.1145/2656877.2656884, ACM 804 SIGCOMM Computer Communication Review Vol. 44, pp. 45-49, 805 July 2014, . 807 [NWCRG] "Network Coding for Efficient Network Communications 808 Research Group (NWCRG)", . 810 [OSMAN21] Osman, M., Sedek, K., Othman, N., Rosli, M., and M. 811 Maghribi, "Enhancing Security and Privacy in Local Area 812 Network (LAN) with TORVPN Using Raspberry Pi as Access 813 Point: A Design and Implementation", 814 DOI 10.24191/jcrinn.v6i2.190, Journal of Computing 815 Research and Innovation Vol. 6, pp. 29-40, September 2021, 816 . 818 [PANRG] "Path Aware Networking Research Group (PANRG)", 819 . 821 [PEARG] "Privacy Enhancements and Assessments Research Group 822 (PEARG)", . 824 [PRIV-TRENDS] 825 "Focal Point - 9 Data Privacy Trends to Watch in 2020", 826 . 829 [QIRG] "Quantum Internet Research Group (QIRG)", 830 . 832 [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines 833 and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014, 834 October 1996, . 836 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 837 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 838 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 839 September 1997, . 841 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 842 "Definition of the Differentiated Services Field (DS 843 Field) in the IPv4 and IPv6 Headers", RFC 2474, 844 DOI 10.17487/RFC2474, December 1998, 845 . 847 [RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking 848 (MANET): Routing Protocol Performance Issues and 849 Evaluation Considerations", RFC 2501, 850 DOI 10.17487/RFC2501, January 1999, 851 . 853 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 854 Computation Element (PCE)-Based Architecture", RFC 4655, 855 DOI 10.17487/RFC4655, August 2006, 856 . 858 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 859 over Low-Power Wireless Personal Area Networks (6LoWPANs): 860 Overview, Assumptions, Problem Statement, and Goals", 861 RFC 4919, DOI 10.17487/RFC4919, August 2007, 862 . 864 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 865 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 866 DOI 10.17487/RFC6282, September 2011, 867 . 869 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 870 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 871 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 872 Low-Power and Lossy Networks", RFC 6550, 873 DOI 10.17487/RFC6550, March 2012, 874 . 876 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 877 Distribution Network Interconnection (CDNI) Problem 878 Statement", RFC 6707, DOI 10.17487/RFC6707, September 879 2012, . 881 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 882 Bormann, "Neighbor Discovery Optimization for IPv6 over 883 Low-Power Wireless Personal Area Networks (6LoWPANs)", 884 RFC 6775, DOI 10.17487/RFC6775, November 2012, 885 . 887 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 888 Morris, J., Hansen, M., and R. Smith, "Privacy 889 Considerations for Internet Protocols", RFC 6973, 890 DOI 10.17487/RFC6973, July 2013, 891 . 893 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 894 Constrained-Node Networks", RFC 7228, 895 DOI 10.17487/RFC7228, May 2014, 896 . 898 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 899 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 900 "Application-Layer Traffic Optimization (ALTO) Protocol", 901 RFC 7285, DOI 10.17487/RFC7285, September 2014, 902 . 904 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 905 Network Interconnection (CDNI) Requirements", RFC 7337, 906 DOI 10.17487/RFC7337, August 2014, 907 . 909 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 910 Chaining (SFC) Architecture", RFC 7665, 911 DOI 10.17487/RFC7665, October 2015, 912 . 914 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 915 Ceccarelli, D., and X. Zhang, "Problem Statement and 916 Architecture for Information Exchange between 917 Interconnected Traffic-Engineered Networks", BCP 206, 918 RFC 7926, DOI 10.17487/RFC7926, July 2016, 919 . 921 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 922 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 923 "Information-Centric Networking (ICN) Research 924 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 925 . 927 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 928 "IPv6 over Low-Power Wireless Personal Area Network 929 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 930 April 2017, . 932 [RFC8151] Yong, L., Dunbar, L., Toy, M., Isaac, A., and V. Manral, 933 "Use Cases for Data Center Network Virtualization Overlay 934 Networks", RFC 8151, DOI 10.17487/RFC8151, May 2017, 935 . 937 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 938 Decraene, B., Litkowski, S., and R. Shakir, "Segment 939 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 940 July 2018, . 942 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 943 Perkins, "Registration Extensions for IPv6 over Low-Power 944 Wireless Personal Area Network (6LoWPAN) Neighbor 945 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 946 . 948 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 949 RFC 8578, DOI 10.17487/RFC8578, May 2019, 950 . 952 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 953 "Deterministic Networking Architecture", RFC 8655, 954 DOI 10.17487/RFC8655, October 2019, 955 . 957 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 958 Paasch, "TCP Extensions for Multipath Operation with 959 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 960 2020, . 962 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 963 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 964 . 966 [RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, 967 "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, 968 November 2020, . 970 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 971 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 972 (SRv6) Network Programming", RFC 8986, 973 DOI 10.17487/RFC8986, February 2021, 974 . 976 [SANCHEZ20] 977 Sanchez, M., Exposito, E., and J. Aguilar, "Industry 4.0: 978 survey from a system integration perspective", 979 DOI 10.1080/0951192x.2020.1775295, International Journal 980 of Computer Integrated Manufacturing Vol. 33, pp. 981 1017-1041, June 2020, 982 . 984 [SASE] "Secure Access Service Edge", . 988 [SCANZIO21] 989 Scanzio, S., Wisniewski, L., and P. Gaj, "Heterogeneous 990 and dependable networks in industry - A survey", 991 DOI 10.1016/j.compind.2020.103388, Computers in 992 Industry Vol. 125, pp. 103388, February 2021, 993 . 995 [SIDEIETF111] 996 "Routing research challenges arising from evolving beyond 997 and revitalizing the Internet", 998 . 1001 [SIGCOMM] "ACM SIGCOMM Conference", 1002 . 1004 [T2TRG] "Thing-to-Thing Research Group (T2TRG)", 1005 . 1007 [TOR] "The Tor Project", . 1009 [WANG15] Wang, L., Törngren, M., and M. Onori, "Current status and 1010 advancement of cyber-physical systems in manufacturing", 1011 DOI 10.1016/j.jmsy.2015.04.008, Journal of Manufacturing 1012 Systems Vol. 37, pp. 517-527, October 2015, 1013 . 1015 [WOOD20] "How SASE is defining the future of network security", 1016 Elsevier - Network Security, Vol. 2020, Issue 12, pp. 1017 6-8 , December 2020. 1019 Contributors 1021 David Lou 1022 Huawei Technologies Duesseldorf GmbH 1023 Riesstrasse 25 1024 80992 Munich 1025 Germany 1027 Email: zhe.lou@huawei.com 1029 Dirk Trossen 1030 Huawei Technologies Duesseldorf GmbH 1031 Riesstr. 25C 1032 80992 Munich 1033 Germany 1035 Email: dirk.trossen@huawei.com 1037 Author's Address 1039 Luigi Iannone (editor) 1040 Huawei Technologies France S.A.S.U. 1041 18, Quai du Point du Jour 1042 92100 Boulogne-Billancourt 1043 France 1045 Email: luigi.iannone@huawei.com