Re: Reference based Routing (RbR)

[[e-mail]]

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 <[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 <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
> --------------------------------------------------------------------