Reference based Routing (RbR)

[Robert Raszuk <[e-mail]>]

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:
https://tools.ietf.org/html/draft-raszuk-teas-ip-te-np-00

*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:  1.1.1.1 (101:101)
/32 RbR pointer:  1::1

R2

/64 RbR prefix 2001:0db8:85a3:0001
/32 Node's locator:  1.1.1.2 (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