[Teas] Offline discussions of scalable IETF network slicing

[Adrian Farrel <[e-mail]>]

Hi TEAS,

Over the last couple of months a self-selecting group has been chatting and
worrying about scalability in (IETF) network slicing solutions. What will
the impacts be on the existing routing infrastructure and protocols? Will
proposed approaches be able to support the scale required? Etc.

We came up with some text that describes the problems and guides where we
think the work should go. It's just our ideas and a first step towards the
WG agreeing what the parameters are.

As I understand it, this is not intended to specify requirements, but to
help people understand which solutions they put energy into, and what would
be the implications of deploying solutions in different scenarios and with
different objectives.

Jie has a slot in the meeting to talk about his NRP scaling draft. He plans
to cover this text, but it is quite wordy and makes for a long presentation.
So, if you care about this stuff, please read the text (below) and bring
your thoughts to the meeting and/or the list.

Cheers,
Adrian (only from me cos I was left holding the pen)

=====

Scaling of network slicing uses a hierarchy of aggregation in order to
achieve scalability. Multiple slices are supported by an NRP; multiple
NRPs are enabled on a filtered topology; multiple filtered topologies
utilise a single underlying network. The hierarchy at any stage may be
made trivial (i.e., collapsed) according to the deployment objectives
of the operator and the capabilities of the network technology.

To recap, and in general terms:
- The network slice is an edge-to-edge service
- The NRP is a set of network resources (e.g., buffers, bandwidth,
  queues) and assigned per-packet behaviors
- The filtered topology is a set of network resources (call it a
  virtual network if it makes it easier for you to think about) on
  which path computation or traffic steering can be performed.

Scalability concerns exist at multiple points in the solution:

- The control protocols must be able to handle the distribution of
  information necessary to support the slices, NRPs, and filtered
  topologies.
- The network nodes must be able to handle the computational load of
  determining paths
- The forwarding engines must be able to access the information in
  packets and make forwarding decisions at line speed
  Path selection tools must be able to process network information and
  determine paths on demand.
 
Assuming that it is achievable, it is desirable for NRPs to have no 
more than small impact (zero being preferred) on the IGP information
that is propagated, and to not required additional SPF computations 
beyond those that are already required.

Assuming that external mechanisms can deal with path selection, NRP
identification should be decoupled from forwarding decisions for
packets.

Given that, we can set out the following design principles.

1) A filtered topology is a subset of the underlying physical topology.
   Thus, it defines which links (and nodes) are eligible to be used by
   the NRPs. It may be selected as a set of links with particular
   characteristics, or it may be a set of forwarding paradigms applied
   to the topology. Thus, a filtered topology may be realised through
   multi-topology techniques (such as colored links), as a virtual TE
   topology, or using flex-algo.

2) It is not envisaged that there would be many filtered topologies
   active, and running SPF per filtered topology is not a high burden.

3) Multiple NRPs can run on a single filtered topology meaning that the
   NRPs can be associated with the same filtered topology and use that 
   topology's SPF computation results.

4) Three separate things need to be identified by information carried
   within a packet:
   - path
   - NRP
   - topology (i.e., filtered topology)
   How this information is encoded (separate fields, same field,
   overloading existing fields) forms part of the solution work.

5) NRP IDs should have domain-wide scope, and must be unique within a
   filtered topology.

6) Configuration mechanisms are used to set up packet / resource
   treatments on nodes

7) Configuration mechanisms (such as southbound protocols from a
   controller) are used to install bindings on network nodes between
   domain-wide resource treatment identifiers (NRP IDs) and configured
   packet treatment as per (6)

8) The path selection performed by or within a traffic engineering
   process, within or external to the head end node, (in particular
   the topology selection and path computation within that topology)
   may consider the characteristics of the filtered topology and the
   attributes of the NRP, but is agnostic to the resource treatment 
   that the packets will receive within the network.  Ensuring that
   the selected components of the path that are configured are capable
   of supporting the resource treatments identified by the NRP ID, is
   a separate matter.

9) The selected path is indicated in the packets using existing or new
   mechanisms. Whether that is SR-Policy (for some variety of SR),
   flex-algo (for whatever flex-algo expression you like), or even
   experiments like CRH, is something out of scope for now, but it will
   obviously form part of the full set of solution specifications.

10) The components or mechanisms that are responsible for deciding what
   path to select, for deciding how to mark the packets to follow the
   selected path, and for determining what resource treatment identifier
   (NRP ID) to apply to packets are also responsible for ensuring
   sufficient consistency so that the whole solution works.

11) Different packet transport mechanisms may use different means to
   carry the NRP ID.  The writeup we need at this stage is agnostic to
   that.
 
The result of this is that different operators can choose to deploy
things at different scales, and while we may have opinions about what
scales are sensible / workable / desirable, we do not have to get WG 
agreement on that aspect.

The routing protocols (IGP or BGP) do not need to involved in any of
these points, and it is important to isolate them from these aspects
in order that there is no impact on scaling or stability. Furthermore,
the complexity of SPF in the control plan is unaffected by this.

Note that there is always a trade-off between optimal solutions and
scalable solutions.
- We need to achieve a scalable solution that can be deployed in all
  circumstances. We should acknowledge that:
  - We may need some extensions to the data/control/management plane
    to achieve this result. I.e., it may be that this cannot be done
    today with existing tools.
  - The scalable solution might not be optimal everywhere.
- We must understand that optimal solutions are good for specific
  environments, but:
  - Might not work in other environments
  - May have scalability issues.
We should allow for both approaches, but we need to be clear of the
costs and benefits in all cases in order that:
- We support significant optimisations
- Do not let non-scalable solutions creep into wider deployment.
In particular, we should be open to the use of approaches that do not
require control plane extensions and that can be applied to deployments
with limited scope. Included in this are:
- resource SIDs
- L3VPN