Re: Reference based Routing (RbR)

[Robert Raszuk <[e-mail]>]

Oh yes ... I was part of this RRG. I like ILNP and LISP ... but here RbR
properties and use case is a bit different.

On Sun, May 24, 2020 at 11:10 PM Tom Herbert <[e-mail]> wrote:

> Robert,
>
> Have you looked a identifier/locator split for IPv6-- ILA or ILNP?
>
> Tom
>
> On Sun, May 24, 2020 at 5:59 AM Robert Raszuk <[e-mail]> 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:
> 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
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>