Skip to main content

Innovation in Internet Routing and Addressing
draft-iannone-routing-and-addressing-manifesto-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Luigi Iannone
Last updated 2021-10-20
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-iannone-routing-and-addressing-manifesto-00
Internet Research Task Force (IRTF)                      L. Iannone, Ed.
Internet-Draft                                                    Huawei
Intended status: Informational                           20 October 2021
Expires: 17 April 2022

             Innovation in Internet Routing and Addressing
           draft-iannone-routing-and-addressing-manifesto-00

Abstract

   This document arguments that despite the ongoing research in routing
   and addressing and the Internet innovation, researchers and engineers
   lack a dedicated forum where they can interact.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 17 April 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Iannone                   Expires 17 April 2022                 [Page 1]
Internet-Draft      Routing and Addressing Manifesto        October 2021

Table of Contents

   1.  Driving Internet Innovation through Research on Routing and
           Addressing  . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  From Research to Engineering  . . . . . . . . . . . . . . . .   3
     2.1.  Bringing Innovation to life . . . . . . . . . . . . . . .   3
     2.2.  Examples of Routing and Addressing Innovation . . . . . .   4
   3.  Interplay between Researchers and Engineers . . . . . . . . .   7
   4.  Need to Amplify the Dialogue  . . . . . . . . . . . . . . . .   8
   5.  The role of the IETF  . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Enter the IRTF  . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Routing and Addressing in the IRTF  . . . . . . . . . . .  11
   6.  Discussing Routing and Addressing Innovation  . . . . . . . .  12
   7.  Sign the Manifesto  . . . . . . . . . . . . . . . . . . . . .  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   10. Informative References  . . . . . . . . . . . . . . . . . . .  13
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  22
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Driving Internet Innovation through Research on Routing and
    Addressing

   Despite the fact that the IP addressing and IP routing models have
   remained stable for more than 40 years, the Internet has experienced
   a huge evolution ever since.  Even if later than expected, the
   transition from IPv4 to IPv6 is finally happening, showing that the
   Internet is able to make important leaps.  Beyond such evolution,
   other very important innovations have been introduced by the IETF or
   are under active engineering development (e.g., SRv6 [RFC8986], MANET
   [RFC2501], 6LowPAN [RFC4919], ICN [RFC7927], PCE [RFC4655]).

   The research community has also made important progress in better
   understanding the properties of the routing and addressing and also
   exploring diverse possible evolutions.  Some of them being relatively
   disruptive, but worth to be considered.  Such extraordinary work has
   been also recognized by the IRTF, were 18 out of 61 (circa 29%) of
   the Applied Networking Research Prize Awards have been granted to
   routing-related papers.  All of the main academic conferences in
   networking, like [INFOCOM], [SIGCOMM], and [CONEXT] have sessions
   dedicated to routing and addressing, but also workshops fully
   dedicated to such topics [I-D.galis-irtf-sarnet21-report].  Quite a
   number of multi-year and multi-million projects have been funded by
   government entity specifically on routing, addressing, or more
   generally on architectural evolution of the Internet ([EU-FIA],
   [NSF-FIA]).  A more thorough survey on research on routing, in the
   last decade or so, can be found in
   [I-D.king-irtf-semantic-routing-survey].

Iannone                   Expires 17 April 2022                 [Page 2]
Internet-Draft      Routing and Addressing Manifesto        October 2021

   Communication scenarios have also evolved through the years.  In the
   90s the killer application was the World Wide Web. It remains a main
   use case of the Internet, but in the meantime several diverse
   communication scenarios have and still are emerging ([BEZAHAF20],
   [LIU20], [BALAKRISHNAN21], [CAMPISTA14]).  While, the network layer
   remained focused on identifying communication end-points through
   addresses and determining paths between end-points through routing,
   the research, pushed by these new communications scenarios, has
   started to explore even more alternatives.  In particular,
   investigating the possibility to add some semantic to addresses (not
   just for end-point identification) and developing semantically rich
   routing (not strictly based on addresses and prefixes but also on
   other information, not necessarily from the network layer).

   The evolution described above, has to continue and it is of paramount
   importance that it does not slowdown, in order to cope with future
   use and business cases, overcoming the existing challenges
   [I-D.king-irtf-challenges-in-routing].

2.  From Research to Engineering

   Bringing consolidated research to the Internet is in general a hard
   task involving a lot of interaction between researchers and
   engineers.  The former trying to abstract from the details of the
   real problem, while the latter trying to adapt the research outcome
   to the real context.  This creates a sort of contention that only
   continuous information exchange can solve.  Early engineering
   deployment are usually done in small size limited domains, which are
   then interconnected.  In the remaining of this section we first look
   at how this "limited domains" approach helps innovation and then
   show-case few examples.

2.1.  Bringing Innovation to life

   As previously mentioned, it is very common to bringing new solutions
   to the Internet through an incremental deployment that at early
   stages is very "limited" in size and secluded in dedicated and
   controlled "domains".  Limited domains have been formally defined in
   [RFC8799], but they existed informally for a long time, helping
   introducing innovations in the Internet.  In a certain way they are a
   fact of (Internet) life.  Historically, the Internet emerged as a
   limited domain, implementing the requirements and behaviors of its
   originating stakeholders.  Even early IPv6 deployments were nothing
   more than interconnected limited domains (at that time called
   "island" in the IPv4 Internet).  Today, it provides the common
   backbone for other limited domains, or, stated differently, provides
   the common foundation for further innovation.  Indeed, private
   technologies isolated in a standalone domain are just less

Iannone                   Expires 17 April 2022                 [Page 3]
Internet-Draft      Routing and Addressing Manifesto        October 2021

   interesting, while interconnecting new solutions through the
   Internet, at different scale (cf.  Section 5 [RFC8799]), is where
   innovation spurs.  As Section 4 of [RFC8799] shows, the Internet and
   IETF's work contains a lot of technologies being deployed using such
   limited domains model, like for instance DiffServ [RFC2474], IntServ
   [RFC2205], SFC [RFC7665], DCN overlays [RFC8151], Segment routing
   [RFC8402], to cite a few.

   The limited domain deployment model enables research to become
   reality through implementation and deployments, with requirements and
   behaviors of stakeholders interested in solutions driving LD
   development.  Example of requirements and behaviors are:

   *  New capabilities: traffic steering, better/different security,
      privacy, supporting different topologies, and mobility;

   *  Diverse technologies: routing on new identifiers (services, host,
      etc.), routing on different network layers like in IoT, and
      semantically enriched routing;

   *  Deep programmability: match-action capability of programmable data
      planes and advances in software and hardware enabling more complex
      packet processing;

   *  Innovation: Limited Domains enable incremental deployability in
      isolated islands for innovative solutions, which may or may not
      percolate to the whole Internet at later stages;

   *  Better QoS: provide some form of service differentiation which may
      be compatible to the best effort model (e.g., MPTCP [RFC8684],
      ALTO [RFC7285], Interconnected Traffic-Engineered Networks
      [RFC7926], or may rely on communication model radically different
      from the best effort model (e.g., DetNet [RFC8655]).

2.2.  Examples of Routing and Addressing Innovation

   Hereafter, we briefly overview a few interesting examples of routing
   and addressing innovation that emerged (or is still emerging) as an
   interconnection of limited domains.  The examples have been selected
   in no particular fashion or purpose beyond their self-explanatory
   nature.  Certainly, quite a number of examples could be proposed,
   however there is no intention to be exhaustive here.

   Content Delivery Networks (CDN)

      CDNs and CSP (Content Service Providers) have long ago recognized
      the existence of the need for interconnecting (previously)
      standalone CDNs so they can interoperate and collectively behave

Iannone                   Expires 17 April 2022                 [Page 4]
Internet-Draft      Routing and Addressing Manifesto        October 2021

      as a single delivery infrastructure [RFC6707].  That is why the
      CDNI WG ([CDNIWG]) has been formed in the IETF.

      From the charter:

         "...to allow the interconnection of separately administered
         CDNs in support of the end-to-end delivery of content from CSPs
         through multiple CDNs and ultimately to end users..."

      This is a very interesting approach to innovation.  While each CSP
      is free to develop their own technology, a general protocol is
      defined in order to safely interconnect different limited domains,
      not necessarily exposing internal policies and solutions
      [RFC7337].  This in turn triggers further innovation, like moving
      content closer to customers while maintaining a high level of
      security [LELOUEDEC21], or introducing specific technology like
      OpenFlow to deliver content across the Internet [CHANG12]

   Internet of Things (IoT)

      IoT actually has different meaning in different contexts, however,
      IoT deployments better than any other technology shows how
      innovation is facilitated by using deployments limited domains.
      For instance, 6Lo(WPAN): define a Limited Domain that has:

      -  a specialized addressing architecture (multi-link subnet),

      -  a specialized neighbor discovery ([RFC6775], [RFC8505]),

      -  a specialized compression schemes ([RFC6282], [RFC8138]),

      -  a specialized routing protocol ([RFC6550]).

      Scattered domains of this type can then be interconnected through
      the so called 6LowPAN Border Routers (6LBR [RFC8929]), basically
      bridging the limited domains into one.  This is just an example of
      constrained node networks ([RFC7228]) that will help building
      smart cities in the coming years ([CANO18]).  Beyond smart cities,
      thanks to IoT, there is an increasing digitalization in various
      non-ICT sectors, like for instance energy, healthcare,
      transportation [NIZETIC20].

   Privacy and Security

      In recent years, people are developing a growing awareness about
      privacy and security issues [PRIV-TRENDS].  This is reflected in
      new regulations (e.g., General Data Protection Regulation - GDPR

Iannone                   Expires 17 April 2022                 [Page 5]
Internet-Draft      Routing and Addressing Manifesto        October 2021

      [GODDARD17]), but also privacy awareness in protocol design
      [RFC6973].

      For private and secure communications a widely used approach are
      mix networks (e.g.  [TOR]).  In this context, each node can be
      seen as independent, untrusted, and interconnected through an
      untrusted network.  Mix networks offer the highest privacy level
      at the cost of reduced performance (latency and/or bandwidth).
      Further, the principles and technology are used also for other
      emerging use cases (e.g.  [OSMAN21], [NEDELTCHEVA19], [ICLOUD]).

      Recently, Gartner coined the term "SASE" for "Secure Access
      Service Edge" [SASE], defining products and services aiming at
      securing the remote access of users or applications to enterprise
      resources (think about VPN on steroids).  SASE is another kind of
      private/secure domain that needs to interface with the public
      Internet and enterprise cloud services, hence acting actually as
      an in-between limited domain.

      Isolating mix networks and SASE solutions from the Internet (while
      using it as an interconnecting backbone) allows to develop
      innovative solutions that do not necessarily rely on privacy and
      security mechanisms of the public Internet, hence better tailored
      for their specific requirements, and is defining the future of
      network security ([WOOD20], [DESHPANDE21]).

   Industry 4.0

      Today networked, smart factories are going beyond the limits of
      physical production lines.  Smart manufacturing, marries physical
      production and operations with smart digital technology, machine
      learning, and big data to create a more holistic and better
      connected ecosystem for companies ([SANCHEZ20], [WANG15]).

      Such eco-system is, in terms of manufacturing, the interconnection
      of different (limited) domains, namely the entire operation--
      inventory and planning, financials, customer relationships, supply
      chain management, and manufacturing execution, etc.  Such
      pervasive connectivity is expected to trigger the 4th revolution
      in the industrial world (hence the name Industry 4.0).

      One way to move toward this vision is the adoption of the digital
      twin paradigm, or going beyond the best-effort model of the
      Internet.  By providing a live copy of physical systems, digital
      twins bring to the table numerous advantages such as accelerated
      business processes, enhanced productivity, and faster innovation
      with reduced costs.  However, this comes with strict requirements
      from a networking perspective, such as low latency and

Iannone                   Expires 17 April 2022                 [Page 6]
Internet-Draft      Routing and Addressing Manifesto        October 2021

      deterministic communication [MASHALY21].  Deterministic
      communication in particular is one of the major requirements in
      various industrial sectors [RFC8578].  However, such communication
      model may have profound implications in terms of routing,
      addressing, and security, substantially differing from the (best
      effort) Internet ([BIGO21], [MADDIKUNTA21], [SCANZIO21]).

3.  Interplay between Researchers and Engineers

   Scientific research and engineering innovation are able to progress
   because they are tight together in a loop and nurturing each other,
   as depicted in Figure 1.  On the one hand, researchers take concrete
   problems that engineers needs to solve, perform an abstraction so to
   get rid of unnecessary details, and solve the corresponding abstract
   problem.  On the other hand, engineers take the solution to the
   abstract problem and adapt it to their specific context.  Any
   mismatch or issue in this process is solved through more interaction.

                  Abstraction from Details
                       +-------------+
                      /               \
   +-----------------/--+           +--\-----------------+
   | Engineers      /   |           |   \     Researchers|
   |               /    |           |   \/               |
   |      +-----------+ |           | +-----------+      |
   |      | Concrete  | |           | |Abstract   |      |
   |      | Problem   | |           | |Problem    |      |
   |      | Domain    | |           | |Domain     |      |
   |      +-----------+ |           | +-----------+      |
   |              /\    |           |    /               |
   +---------------\----+           +---/----------------+
                    \                  /
                     \                /
                      +--------------+
               Engineering Context Adaptation

          Figure 1: The Researchers<->Engineering innovation loop.

   Research community and engineering community are not actually
   separate (like in Figure 1), but rather overlapping.  Numerous
   researchers regularly participate to various SDOs to bring their
   solutions, and similarly, numerous engineers participate in academic
   conference and research work to bring their "real world" experience.
   However, there is also some fragmentation, mirrored in the way the
   Internet evolves.  On the one hand, community of researchers orbiting
   around specific conferences are certainly not disjoint but neither
   the same.  For instance, the conferences IEEE INFOCOM, ACM SIGCOMM,
   and ACM SIGMETRICS, while being all top notch networking conferences,

Iannone                   Expires 17 April 2022                 [Page 7]
Internet-Draft      Routing and Addressing Manifesto        October 2021

   they represent three different type of researchers, IEEE INFOCOM more
   system oriented, ACM SIGCOMM more protocol oriented, and ACM
   SIGMETRICS more system theory oriented.  On the other hand, something
   similar happens in SDOs.  For instance, IEEE, 3GPP, and the IETF, all
   have network standardization activities but they tackle different
   aspects, where IEEE is more about link layer standards, 3GPP designs
   the different generations of cellular networks, and the IETF playing
   a key role on everything around the TCP/IP protocol suite.  Yet,
   those SDOs do not attract necessarily the same engineering
   communities.

   In order to keep up with innovation there is a need to ensure that
   the information between the research communities and the engineering
   communities flows smoothly, through continue interaction, exchange of
   opinions, experiences, problems, and viewpoints.  This is certainly
   true in any field, including routing and addressing.

4.  Need to Amplify the Dialogue

   Deploying and interconnecting new solutions is not just about using
   the right interconnection protocol, it is also about "good" design.
   This raises a tussle between the Internet and innovation.  On the one
   hand, the Internet is a well-functioning system whose core design
   represents sunk investments.  Furthermore, changing a running system
   is pretty hard.  On the other hand, there is an undeniable need for
   sustaining innovation, because of emerging communication scenarios
   where new stakeholders do not see their requirements adequately
   realized.

   Increasingly widening stakeholder interests will continue to drive
   research and innovation (often in limited domain development).  The
   interconnection is increasingly done based on various field/
   information with semantics that can be found, added, associated to an
   IP packet.  The challenge lays in how to enable more innovation to be
   carried across to other limited domains or the Internet?  How to
   share information about evolutions that are not harmful to the
   overall system?

   Business as usual is not enough to answer the above questions.  If
   there is not enough information sharing there is a risk to see a
   fragmented evolution, due to independent innovation carried out in
   the different communities mentioned above.  Such a fragmented
   evolution may create some risks, like for instance:

   *  Too many scattered unrelated domains interconnecting through the
      Internet may actually hamper Internet robustness and its lean
      design.

Iannone                   Expires 17 April 2022                 [Page 8]
Internet-Draft      Routing and Addressing Manifesto        October 2021

   *  Too many ad-hoc solutions/building blocks lead to high complexity
      and augmented fragility.

   *  The need for 'offset' operations may decrease overall efficiency.

   *  The desire for a common denominator (IPv6 plus associated routing)
      affects all interconnected domains, possibly impacting performance
      and ultimately innovation capability.

   *  Nodes behavior gets more complicated, particularly at domain
      boundaries, leading to unexpected/unwanted behavior, like:

      -  semantic leakage, i.e., routing information, leading to
         fragility or security issues;

      -  privacy related information leakage that is pertinent for
         security (e.g., sensors' MAC addresses or user identifiers);

      -  Specific technology islands may become more isolated, therefore
         hampering interconnection and interoperability.

   It can be observed that "The Time is Right to make it Right", because
   we are at a juncture point.

   The Internet technology is quite mature connecting a huge number of
   networking technologies and providing global connectivity.  Actually,
   the TCP/IP protocol stack is so mature that is becoming commodity,
   hence the fragmented evolution previously mentioned.  While TCP/IP is
   the more and more the converging technology, services are
   differentiating, raising the need for making the Internet to continue
   to evolve as well.  When IPv6 started to be discussed, there was a
   general sense of "urgency", because of the address shortage
   forecasted by early 2000s (this was before NAT).  This lead to some
   conservative choices in order to somehow smooth the transition.  In
   this point in time, we have the luxury not being in such an
   situation, there is no need to hurry up, instead there is the
   opportunity, which we hopefully will not miss, to take the time to
   carefully think about how to structure the unstructured by looking
   forward.

5.  The role of the IETF

   As mentioned in Section 1, the IETF has always worked in introducing
   important innovations in the Internet so to make it evolve and adapt
   to the different emerging use cases.  More importantly, the IETF has
   recognized the importance of the interaction between researchers and
   engineers a long time ago when its research branch, namely the
   Internet Research Task Force ([IRTF]) was created.

Iannone                   Expires 17 April 2022                 [Page 9]
Internet-Draft      Routing and Addressing Manifesto        October 2021

5.1.  Enter the IRTF

   The IRTF has a privileged position close to the engineering
   community, and already in [RFC2014], the first document setting the
   IRTF guidelines, the importance of making engineers discuss with
   researchers was recognized:

      "... The expectation is that by sponsoring Research Groups, the
      IRTF can foster cross-organizational collaboration, help to create
      "critical mass" in important research areas, and add to the
      visibility and impact of the work. ... "

   Figure 2 tries to position the IRTF in the researchers<->engineering
   innovation loop previously presented.  Clearly the IRTF, has a
   central role, helping in formalizing real problems and requirements,
   so that afterwards an abstraction of the former can be tackled by
   researchers.  The IRTF can then help deciding whether the resulting
   solution is mature enough to be transferred in the engineering domain
   by first deriving detailed specifications so to facilitate later on
   the adaptation to the engineering context.

                 Problem               Abstraction
                 Formalization         from Details
                  +-----+              +----+
                 /       \            /      \
   +------------/--+      \          /      +-\--------------+
   |Engineers  /   |      \/        /       |  \  Researchers|
   |          /    |     +------------+     |  \/            |
   |   +---------+ |     |            |     | +---------+    |
   |   | Concrete| |     |    IRTF    |     | |Abstract |    |
   |   | Problem | |     |    (RG)    |     | |Problem  |    |
   |   | Domain  | |     |            |     | |Domain   |    |
   |   +---------+ |     +------------+     | +---------+    |
   |         /\    |      /         /\      |  /             |
   +----------\----+     /           \      +-/--------------+
               \        /             \      /
                +------+               +----+
               Engineering             Research
               Context                 Solution
               Adaptation              Specifications

        Figure 2: The role of IRTF in the Researchers<->Engineering
                              innovation loop.

Iannone                   Expires 17 April 2022                [Page 10]
Internet-Draft      Routing and Addressing Manifesto        October 2021

5.2.  Routing and Addressing in the IRTF

   Because of the above-mentioned role of the IRTF it is worth to have a
   better look at the activities related to routing and addressing.
   However, before overviewing such activities, it is worth noting that
   because routing and addressing are cornerstones of the protocol stack

   *  everything relates to routing and addressing,

   *  routing and addressing relates to everything.

   In other words, any IRTF's research group may include routing/
   addressing aspects and/or discuss them in the scope of their specific
   topics.  Note as well that the text following the name of the
   research groups listed below are an excerpt of their charter.

   The following research groups can be considered as almost unrelated
   to routing and addressing.

   *  [CFRG] - Crypto Forum Research Group: Forum for discussing and
      reviewing uses of cryptographic mechanisms.

   *  [GAIA] - Global Access to the Internet for All Research Group:
      Internet access considered a basic human right.

   *  [NWCRG] - Network Coding for Efficient Network Communications
      Research Group: Research Network Coding principles and methods
      that can benefit Internet communication.

   *  [QIRG] - Quantum Internet Research Group: Quantum secure
      communication, distributed quantum computing, and quantum-enhanced
      physical sensor systems.

   *  [HRPC] - Human Rights Protocol Considerations Research Group:
      Research whether standards and protocols can enable, strengthen or
      threaten human rights.

   *  [ICCRG] - Internet Congestion Control Research Group: To move
      towards consensus on which technologies are viable long-term
      solutions for the Internet congestion control architecture.

   The following research groups can be considered as lightly related to
   routing and addressing.

   *  [DINRG] - Decentralized Internet Infrastructure Research Group:
      Research on decentralizing infrastructure services such as trust
      management, identity management, name resolution, resource/asset
      ownership management, and resource discovery.

Iannone                   Expires 17 April 2022                [Page 11]
Internet-Draft      Routing and Addressing Manifesto        October 2021

   *  [PEARG] - Privacy Enhancements and Assessments Research Group:
      General forum for discussing and reviewing privacy enhancing
      technologies for network protocols and distributed systems in
      general, and for the IETF in particular.

   *  [NMRG] - Network Management Research Group: Forum to explore new
      technologies for the management of the Internet.  Such as
      communication services between management systems, which may
      belong to different management domains, as well as customer-
      oriented management services.

   *  [MAPRG] - Measurement and Analysis for Protocols Research Group:
      Forum being a "landing pad" for the Internet measurement community
      to introduce its efforts to the IETF.

   *  [ICNRG] - Information-Centric Networking Research Group:
      Introducing uniquely named data as a core Internet principle.
      Data becomes independent from location, application, storage, and
      means of transportation, enabling in-network caching and
      replication.

   *  [PANRG] - Path Aware Networking Research Group: Forum in support
      of research aiming at bringing path awareness to transport and
      application layer protocols.

   *  [T2TRG] - Thing-to-Thing Research Group: Research forum to
      investigate open research issues in turning a true "Internet of
      Things" into reality, an Internet where low-resource nodes
      ("things", "constrained nodes") can communicate among themselves
      and with the wider Internet, in order to partake in permissionless
      innovation.

   *  [COINRG] - Computing In the Network Research Group: To explore
      existing research and foster investigation of "compute in network"
      and resultant impacts to the data plane.

   From the above lists, a clear takeaway is that there is no research
   group in the IRTF that has an explicit focus on innovation in the
   specific context of routing and addressing.

6.  Discussing Routing and Addressing Innovation

   Previous sections have highlighted how the present situation is that
   routing and addressing are discussed a little bit in numerous places
   (conferences and SDOs), but have not a dedicated forum.  Yet, as
   [I-D.king-irtf-semantic-routing-survey] and
   [I-D.king-irtf-challenges-in-routing] point out there is still
   challenges to take up.

Iannone                   Expires 17 April 2022                [Page 12]
Internet-Draft      Routing and Addressing Manifesto        October 2021

   In order keep the research and the innovation in routing and
   addressing consistent and ongoing, avoiding a fragmented evolution,
   as described in the first part of the present memo, a specific
   dedicated forum should exists.  Recent meetings like:

   *  "Routing research challenges arising from evolving beyond and
      revitalizing the Internet" [SIDEIETF111]

   *  Interim Workshop on Evolving Routing Security in the Internet
      [INTERIM21]

   look like an interesting and successful format.

7.  Sign the Manifesto

   If you agree that the kind of forum described above should exist and
   make the above-listed meetings a regular event, please add your name
   to the public list of supporters at:

      https://etherpad.wikimedia.org/p/routing.addressing.manifesto

   expressing the willingness to create, participate and contribute to
   such a forum.

   Alternatively, send an email at the address:

      routing.addressing.manifesto@gmail.com

   The editor of the draft will take care to add the information
   provided by mail to the public list of supporters.

8.  Security Considerations

   The present memo does not introduce any new technology and/or
   mechanism and as such does not introduce any security threat to the
   TCP/IP protocol suite.

9.  IANA Considerations

   This document includes no request to IANA.

10.  Informative References

   [BALAKRISHNAN21]
              Balakrishnan, H., Banerjee, S., Cidon, I., Culler, D.,
              Estrin, D., Katz-Bassett, E., Krishnamurthy, A., McCauley,
              M., McKeown, N., Panda, A., Ratnasamy, S., Rexford, J.,
              Schapira, M., Shenker, S., Stoica, I., Tennenhouse, D.,

Iannone                   Expires 17 April 2022                [Page 13]
Internet-Draft      Routing and Addressing Manifesto        October 2021

              Vahdat, A., and E. Zegura, "Revitalizing the public
              internet by making it extensible",
              DOI 10.1145/3464994.3464998, ACM SIGCOMM Computer
              Communication Review Vol. 51, pp. 18-24, April 2021,
              <https://doi.org/10.1145/3464994.3464998>.

   [BEZAHAF20]
              Bezahaf, M., Hutchison, D., King, D., and N. Race,
              "Internet Evolution: Critical Issues",
              DOI 10.1109/mic.2020.3001519, IEEE Internet Computing Vol.
              24, pp. 5-14, July 2020,
              <https://doi.org/10.1109/mic.2020.3001519>.

   [BIGO21]   Bigo, S., Benzaoui, N., Christodoulopoulos, K., Miller,
              R., Lautenschlaeger, W., and F. Frick, "Dynamic
              Deterministic Digital Infrastructure for Time-Sensitive
              Applications in Factory Floors",
              DOI 10.1109/jstqe.2021.3093281, IEEE Journal of Selected
              Topics in Quantum Electronics Vol. 27, pp. 1-14, November
              2021, <https://doi.org/10.1109/jstqe.2021.3093281>.

   [CAMPISTA14]
              Campista, M., Rubinstein, M., Moraes, I., Costa, L., and
              O. Duarte, "Challenges and Research Directions for the
              Future Internetworking",
              DOI 10.1109/surv.2013.100213.00143, IEEE Communications
              Surveys & Tutorials Vol. 16, pp. 1050-1079, 2014,
              <https://doi.org/10.1109/surv.2013.100213.00143>.

   [CANO18]   Cano, J., Berrios, V., Garcia, B., and C. Toh, "Evolution
              of IoT: An Industry Perspective",
              DOI 10.1109/iotm.2019.1900002, IEEE Internet of Things
              Magazine Vol. 1, pp. 12-17, December 2018,
              <https://doi.org/10.1109/iotm.2019.1900002>.

   [CDNIWG]   "Content Delivery Networks Interconnection (CDNI)",
              <https://datatracker.ietf.org/wg/cdni/about/>.

   [CFRG]     "Crypto Forum Research Group (CFRG)",
              <https://irtf.org/cfrg>.

   [CHANG12]  Chang, D., Suh, J., Jung, H., Kwon, T., and Y. Choi, "How
              to realize CDN interconnection (CDNI) over OpenFlow?",
              DOI 10.1145/2377310.2377319, Proceedings of the 7th
              International Conference on Future Internet Technologies -
              CFI '12, 2012, <https://doi.org/10.1145/2377310.2377319>.

Iannone                   Expires 17 April 2022                [Page 14]
Internet-Draft      Routing and Addressing Manifesto        October 2021

   [COINRG]   "Computation in the Network Research Group (COINRG)",
              <https://irtf.org/coinrg>.

   [CONEXT]   "Conference on emerging Networking EXperiments and
              Technologies (CoNEXT)", <https://conferences2.sigcomm.org/
              co-next/2021/#!/pastvenues>.

   [DESHPANDE21]
              "A Study on Rapid Adoption of Zero Trust Network
              Architectures by Global Organizations Due to COVID-19
              Pandemic", BP International - New Visions in Science and
              Technology, Vol. 1, pp. 26-33 , August 2021.

   [DINRG]    "Decentralized Internet Infrastructure Research Group
              (DINRG)", <https://irtf.org/dinrg>.

   [EU-FIA]   "Future Internet",
              <https://ec.europa.eu/programmes/horizon2020/en/h2020-
              section/future-internet>.

   [GAIA]     "Global Access to the Internet for All Research Group
              (GAIA)", <https://irtf.org/gaia>.

   [GODDARD17]
              Goddard, M., "The EU General Data Protection Regulation
              (GDPR): European Regulation that has a Global Impact",
              DOI 10.2501/ijmr-2017-050, International Journal of Market
              Research Vol. 59, pp. 703-705, November 2017,
              <https://doi.org/10.2501/ijmr-2017-050>.

   [HRPC]     "Human Rights Protocol Considerations Research Group
              (HRPC)", <https://irtf.org/hrpc>.

   [I-D.galis-irtf-sarnet21-report]
              Galis, A. and D. Lou, "Semantic Addressing and Routing for
              Future Networks (SARNET-21) Workshop Report", Work in
              Progress, Internet-Draft, draft-galis-irtf-sarnet21-
              report-01, 26 July 2021, <https://www.ietf.org/archive/id/
              draft-galis-irtf-sarnet21-report-01.txt>.

   [I-D.king-irtf-challenges-in-routing]
              King, D. and A. Farrel, "Challenges for the Internet
              Routing Infrastructure Introduced by Changes in Address
              Semantics", Work in Progress, Internet-Draft, draft-king-
              irtf-challenges-in-routing-03, 14 June 2021,
              <https://www.ietf.org/archive/id/draft-king-irtf-
              challenges-in-routing-03.txt>.

Iannone                   Expires 17 April 2022                [Page 15]
Internet-Draft      Routing and Addressing Manifesto        October 2021

   [I-D.king-irtf-semantic-routing-survey]
              King, D. and A. Farrel, "A Survey of Semantic Internet
              Routing Techniques", Work in Progress, Internet-Draft,
              draft-king-irtf-semantic-routing-survey-02, 28 June 2021,
              <https://www.ietf.org/archive/id/draft-king-irtf-semantic-
              routing-survey-02.txt>.

   [ICCRG]    "Internet Congestion Control Research Group (ICCRG)",
              <https://irtf.org/iccrg>.

   [ICLOUD]   "iCloud Private Relay",
              <https://datatracker.ietf.org/meeting/111/materials/
              slides-111-pearg-private-relay-00>.

   [ICNRG]    "Information-Centric Networking Research Group (ICNRG)",
              <https://irtf.org/icnrg>.

   [INFOCOM]  "IEEE International Conference on Computer
              Communications", <https://ieee-infocom.org>.

   [INTERIM21]
              "Interim Workshop on Evolving Routing Security in the
              Internet",
              <https://github.com/danielkinguk/sarah/tree/main/
              conferences/security-workshop>.

   [IRTF]     "Internet Engineering Task Force (IRTF)",
              <https://irtf.org/>.

   [LELOUEDEC21]
              Le Louédec, Y., Yven, G., Bastide, V., Chen, Y., Delsart,
              G., Dzida, M., Fieau, F., Fleming, P., Froger, I., Haddak,
              L., Omnes, N., and V. Thiebaut, "Content Delivery
              Networks: On the Path Towards Secure Cloud-Native
              Platforms at the Edge",
              DOI 10.4018/978-1-7998-7646-5.ch003, Design Innovation and
              Network Architecture for the Future Internet pp. 66-95,
              2021, <https://doi.org/10.4018/978-1-7998-7646-5.ch003>.

   [LIU20]    Liu, G., Huang, Y., Li, N., Dong, J., Jin, J., Wang, Q.,
              and N. Li, "Vision, requirements and network architecture
              of 6G mobile network beyond 2030",
              DOI 10.23919/jcc.2020.09.008, China Communications Vol.
              17, pp. 92-104, September 2020,
              <https://doi.org/10.23919/jcc.2020.09.008>.

   [MADDIKUNTA21]
              Maddikunta, P., Pham, Q., B, P., Deepa, N., Dev, K.,

Iannone                   Expires 17 April 2022                [Page 16]
Internet-Draft      Routing and Addressing Manifesto        October 2021

              Gadekallu, T., Ruby, R., and M. Liyanage, "Industry 5.0: A
              survey on enabling technologies and potential
              applications", DOI 10.1016/j.jii.2021.100257, Journal of
              Industrial Information Integration pp. 100257, August
              2021, <https://doi.org/10.1016/j.jii.2021.100257>.

   [MAPRG]    "Measurement and Analysis for Protocols Research Group
              (MAPRG)", <https://irtf.org/maprg>.

   [MASHALY21]
              Mashaly, M., "Connecting the Twins: A Review on Digital
              Twin Technology & its Networking Requirements",
              DOI 10.1016/j.procs.2021.03.039, Procedia Computer
              Science Vol. 184, pp. 299-305, 2021,
              <https://doi.org/10.1016/j.procs.2021.03.039>.

   [NEDELTCHEVA19]
              Nedeltcheva, G., Vila, E., and M. Marinova, "The Onion
              Router: Is the Onion Network Suitable for Cloud
              Technologies", DOI 10.1007/978-3-030-01659-3_45, Smart
              Technologies and Innovation for a Sustainable Future pp.
              389-398, 2019,
              <https://doi.org/10.1007/978-3-030-01659-3_45>.

   [NIZETIC20]
              Nižetić, S., Šolić, P., López-de-Ipiña González-de-Artaza,
              D., and L. Patrono, "Internet of Things (IoT):
              Opportunities, issues and challenges towards a smart and
              sustainable future", DOI 10.1016/j.jclepro.2020.122877,
              Journal of Cleaner Production Vol. 274, pp. 122877,
              November 2020,
              <https://doi.org/10.1016/j.jclepro.2020.122877>.

   [NMRG]     "Network Management Research Group (NMRG)",
              <https://irtf.org/nmrg>.

   [NSF-FIA]  Fisher, D., "A look behind the future internet
              architectures efforts", DOI 10.1145/2656877.2656884, ACM
              SIGCOMM Computer Communication Review Vol. 44, pp. 45-49,
              July 2014, <https://doi.org/10.1145/2656877.2656884>.

   [NWCRG]    "Network Coding for Efficient Network Communications
              Research Group (NWCRG)", <https://irtf.org/nwcrg>.

   [OSMAN21]  Osman, M., Sedek, K., Othman, N., Rosli, M., and M.
              Maghribi, "Enhancing Security and Privacy in Local Area
              Network (LAN) with TORVPN Using Raspberry Pi as Access
              Point: A Design and Implementation",

Iannone                   Expires 17 April 2022                [Page 17]
Internet-Draft      Routing and Addressing Manifesto        October 2021

              DOI 10.24191/jcrinn.v6i2.190, Journal of Computing
              Research and Innovation Vol. 6, pp. 29-40, September 2021,
              <https://doi.org/10.24191/jcrinn.v6i2.190>.

   [PANRG]    "Path Aware Networking Research Group (PANRG)",
              <https://irtf.org/panrg>.

   [PEARG]    "Privacy Enhancements and Assessments Research Group
              (PEARG)", <https://irtf.org/pearg>.

   [PRIV-TRENDS]
              "Focal Point - 9 Data Privacy Trends to Watch in 2020",
              <https://blog.focal-point.com/9-data-privacy-trends-to-
              watch-in-2020>.

   [QIRG]     "Quantum Internet Research Group (QIRG)",
              <https://irtf.org/qirg>.

   [RFC2014]  Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
              and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014,
              October 1996, <https://www.rfc-editor.org/info/rfc2014>.

   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
              September 1997, <https://www.rfc-editor.org/info/rfc2205>.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <https://www.rfc-editor.org/info/rfc2474>.

   [RFC2501]  Corson, S. and J. Macker, "Mobile Ad hoc Networking
              (MANET): Routing Protocol Performance Issues and
              Evaluation Considerations", RFC 2501,
              DOI 10.17487/RFC2501, January 1999,
              <https://www.rfc-editor.org/info/rfc2501>.

   [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
              Computation Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <https://www.rfc-editor.org/info/rfc4655>.

   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals",

Iannone                   Expires 17 April 2022                [Page 18]
Internet-Draft      Routing and Addressing Manifesto        October 2021

              RFC 4919, DOI 10.17487/RFC4919, August 2007,
              <https://www.rfc-editor.org/info/rfc4919>.

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,
              <https://www.rfc-editor.org/info/rfc6282>.

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <https://www.rfc-editor.org/info/rfc6550>.

   [RFC6707]  Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", RFC 6707, DOI 10.17487/RFC6707, September
              2012, <https://www.rfc-editor.org/info/rfc6707>.

   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
              Bormann, "Neighbor Discovery Optimization for IPv6 over
              Low-Power Wireless Personal Area Networks (6LoWPANs)",
              RFC 6775, DOI 10.17487/RFC6775, November 2012,
              <https://www.rfc-editor.org/info/rfc6775>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <https://www.rfc-editor.org/info/rfc6973>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

   [RFC7285]  Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
              Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
              "Application-Layer Traffic Optimization (ALTO) Protocol",
              RFC 7285, DOI 10.17487/RFC7285, September 2014,
              <https://www.rfc-editor.org/info/rfc7285>.

   [RFC7337]  Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
              Network Interconnection (CDNI) Requirements", RFC 7337,
              DOI 10.17487/RFC7337, August 2014,
              <https://www.rfc-editor.org/info/rfc7337>.

Iannone                   Expires 17 April 2022                [Page 19]
Internet-Draft      Routing and Addressing Manifesto        October 2021

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

   [RFC7926]  Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
              Ceccarelli, D., and X. Zhang, "Problem Statement and
              Architecture for Information Exchange between
              Interconnected Traffic-Engineered Networks", BCP 206,
              RFC 7926, DOI 10.17487/RFC7926, July 2016,
              <https://www.rfc-editor.org/info/rfc7926>.

   [RFC7927]  Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
              Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
              "Information-Centric Networking (ICN) Research
              Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
              <https://www.rfc-editor.org/info/rfc7927>.

   [RFC8138]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
              "IPv6 over Low-Power Wireless Personal Area Network
              (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
              April 2017, <https://www.rfc-editor.org/info/rfc8138>.

   [RFC8151]  Yong, L., Dunbar, L., Toy, M., Isaac, A., and V. Manral,
              "Use Cases for Data Center Network Virtualization Overlay
              Networks", RFC 8151, DOI 10.17487/RFC8151, May 2017,
              <https://www.rfc-editor.org/info/rfc8151>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8505]  Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
              Perkins, "Registration Extensions for IPv6 over Low-Power
              Wireless Personal Area Network (6LoWPAN) Neighbor
              Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
              <https://www.rfc-editor.org/info/rfc8505>.

   [RFC8578]  Grossman, E., Ed., "Deterministic Networking Use Cases",
              RFC 8578, DOI 10.17487/RFC8578, May 2019,
              <https://www.rfc-editor.org/info/rfc8578>.

   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655,
              DOI 10.17487/RFC8655, October 2019,
              <https://www.rfc-editor.org/info/rfc8655>.

Iannone                   Expires 17 April 2022                [Page 20]
Internet-Draft      Routing and Addressing Manifesto        October 2021

   [RFC8684]  Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
              Paasch, "TCP Extensions for Multipath Operation with
              Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
              2020, <https://www.rfc-editor.org/info/rfc8684>.

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/info/rfc8799>.

   [RFC8929]  Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,
              "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,
              November 2020, <https://www.rfc-editor.org/info/rfc8929>.

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

   [SANCHEZ20]
              Sanchez, M., Exposito, E., and J. Aguilar, "Industry 4.0:
              survey from a system integration perspective",
              DOI 10.1080/0951192x.2020.1775295, International Journal
              of Computer Integrated Manufacturing Vol. 33, pp.
              1017-1041, June 2020,
              <https://doi.org/10.1080/0951192x.2020.1775295>.

   [SASE]     "Secure Access Service Edge", <https://blogs.gartner.com/
              andrew-lerner/2019/12/23/say-hello-sase-secure-access-
              service-edge/>.

   [SCANZIO21]
              Scanzio, S., Wisniewski, L., and P. Gaj, "Heterogeneous
              and dependable networks in industry - A survey",
              DOI 10.1016/j.compind.2020.103388, Computers in
              Industry Vol. 125, pp. 103388, February 2021,
              <https://doi.org/10.1016/j.compind.2020.103388>.

   [SIDEIETF111]
              "Routing research challenges arising from evolving beyond
              and revitalizing the Internet",
              <https://github.com/danielkinguk/sarah/tree/main/IETF-
              111>.

   [SIGCOMM]  "ACM SIGCOMM Conference",
              <http://sigcomm.org/events/sigcomm-conference>.

Iannone                   Expires 17 April 2022                [Page 21]
Internet-Draft      Routing and Addressing Manifesto        October 2021

   [T2TRG]    "Thing-to-Thing Research Group (T2TRG)",
              <https://irtf.org/t2trg>.

   [TOR]      "The Tor Project", <https://www.torproject.org/>.

   [WANG15]   Wang, L., Törngren, M., and M. Onori, "Current status and
              advancement of cyber-physical systems in manufacturing",
              DOI 10.1016/j.jmsy.2015.04.008, Journal of Manufacturing
              Systems Vol. 37, pp. 517-527, October 2015,
              <https://doi.org/10.1016/j.jmsy.2015.04.008>.

   [WOOD20]   "How SASE is defining the future of network security",
              Elsevier - Network Security, Vol. 2020, Issue 12, pp.
              6-8 , December 2020.

Contributors

   David Lou
   Huawei Technologies Duesseldorf GmbH
   Riesstrasse 25
   80992 Munich
   Germany

   Email: zhe.lou@huawei.com

   Dirk Trossen
   Huawei Technologies Duesseldorf GmbH
   Riesstr. 25C
   80992 Munich
   Germany

   Email: dirk.trossen@huawei.com

Author's Address

   Luigi Iannone (editor)
   Huawei Technologies France S.A.S.U.
   18, Quai du Point du Jour
   92100 Boulogne-Billancourt
   France

   Email: luigi.iannone@huawei.com

Iannone                   Expires 17 April 2022                [Page 22]