[pim] FYI: draft-eckert-msr6-rbs-00

Toerless Eckert <tte@cs.fau.de> Tue, 12 July 2022 16:11 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A06C14CF00; Tue, 12 Jul 2022 09:11:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.658
X-Spam-Level:
X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QOQwgXhTYqV; Tue, 12 Jul 2022 09:11:34 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E682AC14F741; Tue, 12 Jul 2022 09:11:26 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id EA99358C4AF; Tue, 12 Jul 2022 18:11:20 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id D65944EB43E; Tue, 12 Jul 2022 18:11:20 +0200 (CEST)
Date: Tue, 12 Jul 2022 18:11:20 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: spring@ietf.org, pim@ietf.org, msr6@ietf.org, ipv6@ietf.org
Cc: draft-eckert-msr6-rbs@ietf.org
Message-ID: <Ys2dKLu5MZ9WQF+t@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/WI3VdCKJRFH0q_GNOnQYP6x_VfY>
Subject: [pim] FYI: draft-eckert-msr6-rbs-00
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 12 Jul 2022 16:11:36 -0000

Dear colleagues, [sorry for cross-posting, but alas, the work seems to be so scattered
across IETF WG, that it is hard to reach stakeholders through a single WG mailing list. At
least as long as we have not decided to have a common solution WG via MSR6 ;-)]

The co-authors just posted subject draft:

https://datatracker.ietf.org/doc/draft-eckert-msr6-rbs/

I would like to encourage you to check it out and let us know if you are interested
to help work on it as co-authors/contributor.

I did ask the MSR6 BOF chairs for a slot to present it, and our thoughts on
the overall MSR6 concept at the BOF. 

This draft is an update from the prior draft-xu-msr6-rbs, proposing a particular
variant of an MSR6 IPv6 routing header. Let me highlight three areas of specific interest:

a) Inclusion of destination address field in the MSR6/RBS IPv6 routing (extension) header.

The header supports native IPv6 multicast source routing with intent to be aligned
with the SRv6/SRH architecture, specifically by including a field to carry the IPv6 multicast
destination address, eliminating potentially another redundant IPinIP encapsulation
to carry it.

This enhancement should make this routing header an immediate replacement of stateful
native IPv6 multicast in native IPv6 networks (with/without SRv6) with a stateless
source-routing/tree-steering solution.

This should be especially beneficially to transition existing stateful PIM IPv6
multicast deployments in native-IPv6 / SRv6 networks because it minimizes the
overall changes required to eliminate stateful trees in IPv6 multicast, which
is the main operational, scalability, and performance concern of operators with
IPv6 multicast.

Note that this also allows to use pre-existing MVPN control plane signaling via BGP or PIM,
both of which rely on IPv6 multicast group addresses to indicate VPN groups (PMSI).

Of course, this field could also hold a SID (maybe we should also turn multicast
group addresses into SIDs ?), therefore allowing us to apply
the more flexible IPv6 programmability to IPv6 MVPNs, in the same way they 
can be used for the unicast part. It is optional, so by not including it, one could
equally design further header-space optimized services, such as L2.5'ish, maybe L2VPN.

b) Enhanced RBS structure

The "Recursive Bitstring Structure" (RBS) for compact encoding of the engineered
multicast tree has been improved to minimize per-steering-hop rewrite. It
now does not require rewrite of the complete RBS structure (as in our prior draft-xu-msr6-rbs),
but instead by incrementing two offset fields into the RBS structure, pretty
similar to decreasing the Segments Left in the SRH header. This minimizes the write-cycles
for high-speed router in the packet header and avoids having to change the
packet/header length along the path (only 24 more bits rewrite on top of the
128 bit IPv6 destination address rewrite required by RFC8200).

c) Efficiency = use for MSR6 TE and BE mode

The RBS structure primarily supports what MSR6 calls the "Traffic Engineering" mode,
by allowing to have traffic-steered forwarding & replication, but our (initial) simulations
have shown that the performance in large SP networks  (with many PE) can actually be better than
the multiple "flat bitstrings" as in RFC8279 or draft-lx-msr6-rgb-segment, so
msr6-rbs should be able to also quite well provide what MSR6 calls the
BE (non TE) solution.

[ Hint: the 4 MVPN-PE you need to replicate to are sadly in 4 different flat bitstrings,
  so you need to send 4 packets, whereas in RBS you can always encode any set
  of a small number of PE into a single RBS structure. ]

Hope this all sounds interesting and makes you at least attend the MSR6 BOF ;-)

Cheers
    Toerless