[pim] FYI: draft-king-irtf-challenges-in-routing

Toerless Eckert <tte@cs.fau.de> Mon, 01 March 2021 10:05 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 848B73A1922; Mon, 1 Mar 2021 02:05:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.049
X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id gDXEiZdNB6Wj; Mon, 1 Mar 2021 02:05:06 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 075E83A1921; Mon, 1 Mar 2021 02:05:05 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de []) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D1569548053; Mon, 1 Mar 2021 11:04:59 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id CAEA8440166; Mon, 1 Mar 2021 11:04:59 +0100 (CET)
Date: Mon, 1 Mar 2021 11:04:59 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: mboned@ietf.org, bier@ietf.org, pim@ietf.org
Message-ID: <20210301100459.GA58538@faui48f.informatik.uni-erlangen.de>
Reply-To: irtf-discuss@irtf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/ojfOMsUctNEn3qYOGAMZZm2ZizI>
Subject: [pim] FYI: draft-king-irtf-challenges-in-routing
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Mar 2021 10:05:10 -0000

Dear Multicast folks

Hereby sending an FYI  about: https://datatracker.ietf.org/doc/draft-king-irtf-challenges-in-routing/
"Challenges for the Internet Routing Infrastructure Introduced by Changes in Address Semantics"

This work is intended to capture existing and hopefully spur interest in ongoing and
future IRTF research activity on routing challenges related to addressing.

Please comment on irtf-discuss@irtf.org if you have opinions/suggestions/comments  about this work,
and let that list especially know if you would like to see that draft presented at IETF110 mondays
irtf open meeting slot.

Of course, feel free to reach out to the authors and/or me if you have interest to contribute/participate
or otherwise discuss outside a list.


Why bring this up to the multicast mailing lists ? Well, in my maybe ?biased? opinion, the semantic
of not addressing a single destination, but some form of groups has created most innovative
additional network semantics that where successfully deployed, and i think we are far from done
with that work. I also think it would be great if we would also have the ability to use an IRTF
approach to maybe? spur the interest of more researchers.

Let me give you one example that might be closest to what engineers might think of, which
is that of driving multi-semantic addressing single network protocols instead of
"ships-in-the-night" multi-protocol hop-by-hop forwarding planes:

How about comparing the IP Multicast experience with the BIER experience:

 - In IP Multicast we could get the new (IP Multicast) semantic into the existing network protocol
   IPv4/IPv6 because that destination group semantic nicely fit into 32/128 bit. Heck, for IPv6, we
   (IMHO) even invented network programming via addresses with the embedded RP format, and SRv6
   just generalized the idea much later ;-).

 - In result, in IP Multicast we could by default reuse everything that was done
   for IP unicast and just needed to fixup/amend it:
   - QoS, - access lists, policy list, NAT
   - UDP / socket and higher layer API / stacks (RTP,...)
   - many operator interfaces/CLI
   - management plane tools

 - Was this a long and winding road ? Sure, but from my experience that approach mae it a lot easier
   to get the new technology (IP Multicast) proliferated /deployed than the BIER approach that
   w had to take because we couldn't fit BIER addrssing semantic into IPv6:

   - BIER is a new network hop-by-hop forwarding protocol
   - Everything of the above list had to / has to be reinvented
   - Where we quite innovative to develop a new header merging IP and MPLS header rquirements ?
     Sure... But wouldn't life have been easier if we didn't have to ? Overhead ? Overall system
     complexity... ?

Think of how BIER could/might have evolved if we had IPv6 with "variable length adddresses"
(supporting eg: up to 1024 bit addresses), and we would have had to simply ask (like in IP Multicast)
for a prefix for the new BIER semantic and then just define it to be used for the appropriate address lengths.
IMHO: We would have a much easier game proliferating BIER, very much in line with what we had in
IP Multicast.

I am sure there will be arguments to the counter side, but IMHO thats what would make
it even more a topic for a research discussion about multi-semantic addressing.