Re: Reference based Routing (RbR)

Robert Raszuk <> Sun, 24 May 2020 16:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C5F83A0BD1 for <>; Sun, 24 May 2020 09:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c0Qyk9WsT70N for <>; Sun, 24 May 2020 09:44:59 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 40B0E3A0BC2 for <>; Sun, 24 May 2020 09:44:59 -0700 (PDT)
Received: by with SMTP id h21so18267283ejq.5 for <>; Sun, 24 May 2020 09:44:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4cq6KEA7JYHiI81VYkG7YeofFQSDNytx0+jvJGw+FW4=; b=Iw7ml8y/CzDunlk4tope2DakQGum9JMc1x6UqcKzwmIaNvjjLM0W4prK2GhA6pu1Vn cQRLpgmMTXeWCfXBeMvDu2kx4bidfOzs4TMiKdVFvs09QJTfUya7TRtKjoR7KIM7qICh qfmURaFnnwc3nYM6u13XXAukjpEbou5bj/Io1moV2HgEyO3m2FjYxKYzTFCJ9YZ9f6tg c9TKKMXlx/3RG0fP2yiP2Ek1lp690EQgghy0hBSS/Xf56muBGJC9XU//EGNGFqWfhwzv pVduYJbEJa6/9hD59W2bfQVeNbPGG9RBF862lBys+5PgiL7bYKFf91P+5i3gUrcMohh3 dung==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4cq6KEA7JYHiI81VYkG7YeofFQSDNytx0+jvJGw+FW4=; b=mob8S/lCUdgHX9AO4WLX20PnLChzTnRFpF/ejm4fp6GK1NWime09VO5vXWLMxIeTJR Yka6/Uc9lb+2/AheRiCdw2+kudvTAZIQAcwhhsZQg4asofEao4MndaEEruEhgoaoq2iT l4DDELX+neM87ZmLTVtPCq/PFAXoSKaRPb1rWsN5YqA/Lq6nU/Zq+nogdAFNhSfuqWaP VYOCsTNs8HWJltOgVW2zY33PmBjhp5pLERgidzckye28RQ6CCj9t2d/QK+twXI9CxmW/ My/CxVoMB+tSI0FLzt2+6G/QxxlKv64Q5zRPHaNYcH9nhHWakys6OjS0/So+yDS9y+y3 3Fzw==
X-Gm-Message-State: AOAM533mmIihblV4JTbLhM1K08wVaL7x5OwXlMunf/0sJOHAyBOm664N GcwvfP09RTbF+XNUZscK/dvg4yj0HsxcQUU1sbw2x7pD
X-Google-Smtp-Source: ABdhPJylwzYDoJKv1rhA9hE8TPQbRllp8m4c8+2gvm6k0325CXiBdCnE5yFwYbTy1MfVpBP3k8AodcUhzKjytkk5GwM=
X-Received: by 2002:a17:906:29d9:: with SMTP id y25mr15184478eje.198.1590338697414; Sun, 24 May 2020 09:44:57 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Sun, 24 May 2020 18:44:48 +0200
Message-ID: <>
Subject: Re: Reference based Routing (RbR)
To: Tony Li <>
Cc: 6man <>, 6man WG <>
Content-Type: multipart/alternative; boundary="00000000000021e0a205a6679531"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 May 2020 16:45:04 -0000

Hi Tony,

If I would insert a reference into flow label space I am afraid I would
lose the current flow label functionality which perhaps in some cases may
not be desired.

To your second hint - by all means yes - anyone could use the MPLS label in
an MPLS network to indicate a context. Pointer can be a context. Some may
argue that 20 bits may not be enough thought.

However the exercise here is to provide a form of path steering for IPv6
networks where transport MPLS is not enabled by design.

Last I am not sure what "messing with address space" comment really meant
to indicate ...

- a fear that allocation of /64 prefix for a domain is hard
- a concern that using /32 locators is problematic
- an observation that placing /32 bit pointer in least significant bits of
the packets (within an already encapsulated IPv6 header) is the wrong thing
to do ? If so let me observe that most SR approaches today do rewrite the
entire DA address at each segment endpoint.

Many thx,

On Sun, May 24, 2020 at 5:50 PM <> wrote:

> Robert,
> I’ll point out that you could avoid messing with the address space at all
> by using the IPv6 flow label or a single MPLS label.
> Tony
> On May 24, 2020, at 5:58 AM, Robert Raszuk <> wrote:
> Dear 6man WG,
> Number of concurrent discussions in this WG triggered an idea which I
> would like to share with you all to think about during the long weekend.
> For some unknown reasons an army of folks has been cornered to think that
> stuffing each packet with encoded or not, compressed or not hop by hop list
> of nodes to traverse is best we can do to provide some form of path
> engineering in some cases combined with network programming.
> Some put on such lists IPv6 addresses, some try to just put pieces of
> those addresses and some even try to squeeze mpls labels there under a
> different cover (brrrr).
> What if we come back to the roots and rethink the requirements ..
> Few months back I wrote IP TE + NP proposal however the summary below is a
> simplified version of it. Just for reference original document is here:
> *Description:*
> Let's assume that in my network I would like to be able to construct 1000
> engineered paths (different from what IGP would compute as SPF with its
> default algorithm). Perhaps say that number of those paths would be 10x or
> 100x more. That means that essentially the paths itself could be expressed
> in 16 bits.
> Let's further observe that what is needed to accomplish any form of
> traffic engineering are two elements:
> * mark packets which are subject to such path engineering
> * construct path engineered paths
> Note that while I am using TE as an example additional network programming
> functions including for example SFC processing is supported with no change
> as well.
> *Proposal: *
>    - Let's allocate a /64 prefix which will be used in entire domain for
>    the purpose of RbR
>    - Let's mark each node in a domain with different /32 address (it is
>    naturally ok to simply use current /32 IPv4 node addresses)
>    - Let's use remaining 32 bits of the IPv6 address to carry an RbR
>    pointer
> To illustrate format of the address of the packet after it is encapsulated
> on ingress into the domain looks like:
> *|<----  /64 PREFIX ----->|<--- /32 LOCATOR --->|<--- /32 RbR POINTER
> --->|*
> No need for any routing header at all ! No per packet overhead regardless
> of the number of hops to traverse (except 40 bytes of IPv6 encapsulation).
> What is Prefix & Locator is obvious. So now let's define Pointer:
> *Pointer (or reference)* - /32 bits string which would uniquely in entire
> domain identify the aggregates of flows. Indicates a reference to a set of
> local actions for those packets which carrying such reference. Only those
> routers which DA is in the /96 address need to inspect and execute the
> pointer.
> Pointers can be structured or unstructured - depending on
> operators's choice and network requirements. In structured case for example
> first 16 bits can represent 2^16 number of unique TE paths in the network
> while remaining 16 bits local functions in each network elements (segment
> endpoint). Such bit boundary is a local operators choice.
> RbR pointers are assigned by the same entity (human or controller) which
> normally is responsible for path engineering and network programming in the
> domain.
> RbR pointers are globally (domain wide) unique.
> *However actions indicated by said RbR pointers are locally significant to
> any network element. *
> That is accomplished by propagating actions which correspond to such
> references as tuple: LOCATOR + POINTER. Depending on the selected means of
> propagation of such actions it also can be: PREFIX+LOCATOR + POINTER.
> *Example: *
> R1
> /64 RbR prefix 2001:0db8:85a3:0001
> /32 Node's locator: (101:101)
> /32 RbR pointer:  1::1
> R2
> /64 RbR prefix 2001:0db8:85a3:0001
> /32 Node's locator: (101:102)
> /32 RbR pointer:  1::1
> Actions programming:
> 101:101 + 1::1  --> rewrite DA to   2001:0db8:85a3:0001 + 101:102 + 1::1
> 101:102 + 1::1  --> rewrite DA to   2001:0db8:85a3:0001 + 101:103 + 1::1
> etc ...
> *Actions distribution:*
> There are number of ways to distribute such instructions domain wide. One
> network can choose to use configuration push via ansible automation. The
> other may like to use existing BGP FlowSpec SAFI. Yet some other would like
> to use OpenR message bus on a pub-sub basis.
> Perhaps a yet one more set of engineers would like to get new BGP or IGP
> extension defined.
> At this stage all options are on the table.
> *Scaling: *
> As we all know there is no free lunch. Here I believe proposed solution is
> a sweet spot compromise between soft state path setup in network elements
> (MPLS RSVP-TE) and loading each packet with additional routing header
> information.
> Most importantly it needs to be observed that each participating midpoint
> *only* needs to store actions which correspond to his own node. That
> applies to both control plane(*) and especially local data plane RbR-FIB.
> If action is send by any means towards a network element and does not
> contain its LOCATOR in the first /32 bits it will be dropped either at
> inbound processing or never propagated from control plane to RIB/FIB.
> It has been studied that in real production networks to satisfy the
> requirements of most path steering needs at most 2-3 sometimes 4 segments
> may be needed. That effectively means that for such flows corresponding
> actions need to be kept only in 2-4 routers in the entire domain. Rest of
> the network elements may never need to be RbR aware as all they do is
> forward based on /96 IPv6 prefix.
> * For control plane it depends on the form of the distribution - if BGP is
> used and given node is a route reflector all RbR action "routes" or "rules"
> need to be stored there.
> After all routers are build to carry state. IP prefixes are nothing by
> state - more over - IP prefixes do change all the time (continues BGP
> churn). So while thinking about scaling and state one needs to also keep in
> mind the static nature of actions. Perhaps some TE paths will be pinned for
> weeks or months and will never require a change of either control plane nor
> RbR FIB.
> Last RbR cost (packet tax) is constant and equals zero. It does not
> increase if I need to engineer path at each of my 10 hops for specific
> adjacency on each hop.
> *Summarization: *
> It is my strong believe that in any network any scheme must allow for
> reachability summarization.
> RbR locators can be easily summarized/aggregated across ASNs (under the
> same administrative control) or across IGP areas/levels.
> Packets traverse IP network as normal IPv6 packets would.
> *Security: *
> Most networks already have inbound ACLs (setup manually or dynamically) to
> protect any external packet to enter their domain with destination address
> equal to infrastructure space.
> Here our /64 prefix can be either already part of this existing rule or a
> single ACL line dropping all packets with DA = PREFIX or longer applied on
> all external interfaces.
> ACLs supporting basic IPv6 filtering is all what is required and that is
> commonly supported by all IPv6 capable routers today.
> *RbR-FIB:*
> The /32 nature of node locators and RbR pointers have additional two
> benefits:
> - it can reuse years of operation experience and existing IPv4 addressing
> schema in any network as is.
> - it can reuse 32 bit RIB and FIBs and other data plane processing
> hardware on any network element making support of RbR really easy even by
> legacy hardware.
> *IETF aspect:*
> The RbR can be deployed today with full compliance of RFC8200 + use of
> RFC2473.
> Additional protocol enhancements for signalling actions can be
> standardized independently if needed.
> - - -
> Apologies for long note. I just thought to share this idea with the WG in
> the light of set of network requirements vs discussion of documents under
> adoption call (namely CRH).
> Kind regards,
> Robert Raszuk
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------