Re: [Teas] My unasked question about the draft-bestbar-teas-ns-packet and draft-bestbar-teas-yang-slice-policy

[Vishnu Pavan Beeram <[e-mail]>]

<As a WG participant>

Adrian, Hi!

Much Thanks for sending the email as promised. Conceptually, we seem to be
largely in sync with respect to several topics (pertinent to "realization"
of network slicing in packet networks) covered in the 2 drafts specified in
the subject. There seems to be an agreement that we need an aggregate
construct onto which one or more IETF Network Slices can be mapped. Let's
continue to discuss (thanks for the productive offline chat) the
differences between "slice aggregate" and "VTN" and determine if we can
converge on the relevant terminology.

Please see inline for some point responses/clarifications (prefixed VPB).

Regards,
-Pavan (on behalf of the co-authors)

On Thu, Mar 11, 2021 at 9:37 AM Adrian Farrel <[e-mail]> wrote:

> Hi,
>
> Thanks to Tarek for the presentation.
>
> It is something special about network slicing that makes us all struggle
> with terminology. I wonder why that it.
>
> Having gone through the slides and your drafts, I think one of the
> problems with the terminology is that one term "network slice policy" is
> trying to achieve too much. (I think John Drake would mutter about floor
> wax and desert topping 😊)
>

[VPB] I'm too polite to use an SNL retort ☺. Slice policy is a policy
construct that dictates how a slice aggregate can be realized. It is no
different than any other new-age policy construct currently being used in
the routing area.

>
> AFAIC, the policy serves at least the following purposes:
>
> 1. Provide a set of mapping rules that allow an edge router to determine
> to which slice aggregate a packet should be assigned.


[VPB] The slice policy (as is defined and modeled today) includes rules for
the forwarding engine on slice policy capable nodes to identify the traffic
belonging to a slice aggregate and apply the corresponding PHB. Mapping
traffic on to a slice aggregate at a slice policy ingress boundary node is
discussed separately (See
https://tools.ietf.org/html/draft-bestbar-teas-ns-packet-02#section-5.3) --
we intend to use existing service mapping techniques (with minor augments
if necessary) for this.


>
> 2. Provide a mechanism to map an aggregate onto a set of network resources
>
> 3. Provide a set of network configuration instructions that program the
> network elements to provide the topology and resources to support the slice
> aggregate.
>

[VPB] The slice policy does specify the set of topological elements that
form the slice policy membership -- this is done either by referencing a
pre-existing user-defined topology or by providing a set of topology
filtering rules. The slice policy also provides rules for facilitating
slice aggregate aware bandwidth engineering (preference based preemption,
bandwidth resource sharing).


>
> At the same time, the term "slice aggregate" is starting to serve multiple
> purposes:
>
> A. It is the collection of packets (i.e., aggregate flow) created by
> applying the policy to the packets.
>
> B. It is an identifier of the policy that was applied to the packets and
> can be used in the network when examining a packet.
>
> C. draft-bestbar-teas-yang-slice-policy describes "realizing an aggregate"
> rather than mapping an aggregate to a topology
>

[VPB] As stated above, the topology associated with a slice aggregate is
dictated by the slice policy membership. Multiple slice aggregates may use
the exact same set of topological elements.


>
>
> I think that 1, 2, and 3 are needed, but I think they are different
> things.
>
> a. Yes, we need to describe what traffic is mapped to a slice. And it is
> fine to call
>    the collection of traffic a slice aggregate. This corresponds to the
> "traffic
>    matching criteria" concept in
> draft-wd-teas-ietf-network-slice-nbi-yang. But it
>    is worth noting that in some applications, all traffic from an input
> (e.g., a port,
>    or an AC, or through an NS-AP) will map to the aggregate using the most
> trivial
>    of policies. I think other contexts refer to this process as "packet
> classification"
>    (sometimes "packet filtering") and the collection is quite often known
> as an
>    "aggregate flow".
>

[VPB] As noted in section 5.3 of <draft-bestbar-teas-ns-packet>, existing
service mapping techniques can be used (with minor augments to the model if
necessary) to steer traffic onto the slice aggregate.


>
> b. Yes, we need to say "once you have sifted the packets to make a slice
> aggregate,
>    what do you do with the packets?" In an MPLS-TE world (just mentioning
> this
>    to give context, not to say you have to use MPLS-TE) this would be the
> LSPs to
>    use (i.e., the labels to impose and the outbound interface). In an SR
> world it
>    would be the SID stacks to impose.
>

[VPB] The solution in <draft-bestbar-teas-ns-packet> allows for the use of
any existing path control technology to place the slice aggregate paths. It
allows multiple path placement options (See
https://tools.ietf.org/html/draft-bestbar-teas-ns-packet-02#section-3),
including slice-aggregate aware TE.


>
> c. Yes, we need to configure the network to reserve resources and set up
> paths.
>     In fact, we need to build a network slice topology. But since several
> network
>     slices may share resources (not least, in order to get a reasonable
> amount of
>     scaling) we want to build a topology over which one or more slices can
> be
>     carried. However, I think this process is explicitly not part of the
> steps for a.
>     and b. It is a separate thing: and once you look at it like this, you
> find it is
>     "configuration of VTN" using the terminology from the VPN+ documents.
>

[VPB] As noted above, service mapping and path placement are not part of
the slice policy definition. The slice policy does specify the rules for
determining which topological elements cater to the slice aggregate. A
subtle difference here is whether you want to build a new virtual topology
(VTN) for each slice aggregate or apply one or more filters (say, "include
red links") on the native topology for each slice aggregate. Note that the
same topology filter(s) can be used for multiple slice aggregates.


> As probably clear from my a., b., c. text, I think that A is a helpful use
> of the term "slice aggregate". It usefully mirrors terms like "traffic
> aggregate".
>
> But I don't see value to having the slice aggregate known within the
> network (B). What seems to be needed is an identifier of the resources and
> paths to which a packet should be applied. This is a slice identifier, but
> for scalability purposes what we really want is an identifier of the
> resources to use - that’s an aggregate of aggregates (!) and is the concept
> that draft-ief-teas-enhanced-vpn calls a VTN.
>

[VPB] In the data plane slice policy mode (option discussed in
https://tools.ietf.org/html/draft-bestbar-teas-ns-packet-02#section-4.1),
we do require the forwarding engine to identify the traffic belonging to a
specific slice aggregate AND to apply the corresponding Per-Hop Behavior
(PHB). In other words, the PHB associated with the slice aggregate has to
be known by the node in order for it to provide the corresponding treatment
(this is dictated by the slice policy).


>
>
> Finally, in his presentation, I am sure that Tarek talked about mapping an
> aggregate to a topology. But draft-bestbar-teas-yang-slice-policy is pretty
> clear that it is describing "realizing an aggregate" (C).


[VPB] Hope the above clarifies what is proposed in the drafts. The YANG
model specified in <draft-bestbar-teas-yang-slice-policy> is consistent
with the definition of the slice policy described in
<draft-bestbar-teas-ns-packet>.


> I think that what is needed is step back a bit and sort out the functional
> steps. That will give us access to the terminology, and then we can settle
> into the real technical work. (I use the term "VTN" below to mean "the
> resources and topology assigned to support one or more network slice").
>
> Consumer wants a slice
> Consumer specifies slice characteristics to operator
> Consumer specifies what traffic will be carried on the slice (the policy
> or matching criteria that defines the aggregate)
> Consumer may add further descriptions of traffic (policy to aggregate is
> n:1)
> Other consumer end points may define traffic to be carried on the same
> slice (aggregate to slice is n:1)
> Operator looks for how to support the slice
>

[VPB] No issues with the above steps (the focus in the 2 drafts is on what
happens after you map an IETF network slice onto an "aggregate").


> Operator builds or nominates existing VTN to carry slice
> Operator may host multiple slices on one VTN (slice to VTN is n:1)
> Within the operator's network the devices need to know which resources to
> apply to a packet (VTN-ID)
>

[VPB] Let me rephrase the above using terminology that is used in
draft-bestbar-teas-ns-packet:
- Operator may map the IETF network slice to an existing slice aggregate or
to a new slice aggregate;
- If a new slice aggregate is needed, the corresponding slice policy is
provisioned in the network;
- If new slice aggregate paths are needed, they get added using a specific
path control technology (operator's choice);
- If a new service mapping is needed at the slice policy ingress boundary
node, it gets applied.


>
> Note that this leaves us with THREE concepts of aggregation:
>
> i. Traffic is aggregated into a slice aggregate (as per flow aggregation)
> ii. Slices are aggregated onto topologies (as per service aggregation)
> iii. Resources are aggregated into topologies (as per abstraction)
>
>
> Thanks,
> Adrian
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>