Re: Reference based Routing (RbR)

[Robert Raszuk <[e-mail]>]

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,
Robert



On Sun, May 24, 2020 at 5:50 PM <[e-mail]> 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 <[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
> --------------------------------------------------------------------
>
>
>