Re: [Teas] NRP definition [Was: Repeated call for last call on draft-ietf-teas-ietf-network-slices]

[Joel Halpern <[e-mail]>]

(To deal with the side note first, even if the APN group is chartered, 
this does not belong there.)

I find your description below simultaneously helpful and quite 
confusing.  I had assumed, because it seems necessary, but maybe I am 
over-assuming, that a partition of buffer and queueing resources also 
was tied to the schedulign disciplines of those queues.  (Otherwise the 
fact that they are different queues does not actually partition the 
resources.  More generally, if as you say the point is to partition the 
link, the the representation has to be tied to the packet handling fo 
rthe link.  Otherwise the queues and buffers don't actually partition 
the link.   To take an extreme example, suppose I have two queueus, and 
I split the buffers across them, and treat that as two NRPs.  If the 
scheduling always schedules queue 1 in preference to queue 2, that is a  
very different partition of the link than a 50/50 scheduler, or a 
scheduler that always schedules queue 2.

Yes, describing this in a technokogy-agnostic fashion is tricky. But if 
the behavior delivered to packets in the NRP is not part of the NRP, 
then we don't know what the partition is.

And separately, if the bheavior is not tied to the conceptual grouping 
of packets for behavioral treatment, then any configuration of NRPs 
doesn't seem to actually address any problem.

Now to restate what I said at the end of my message, I can live with a 
definition that says that an NRP is a group of behaviors related to some 
well-defined characteristic such as diffserv code point or MPLS ToS 
bits.  I had started out thinking it was a single behavior in order to 
avoid becoming technology specific.

Yours,

Joel

On 9/22/2022 12:58 PM, Adrian Farrel wrote:
> Trying to split the thread into discussion of “default NRP” and “NRP”.
>
> This email replies to Joel’s more detailed email (Thanks, Joel, for taking the time to set out more clearly what your concerns are. Long emails are fine when clarity and detail is needed.)
>
>> First, let me be clear that I am not objecting to the description of one
>> NRP.  Depending upon the definition of NRP that is either fine and useful,
>> or harmless but useless.   Also, I apologize if this is a bit long.  Trying to
>> cover all the related points I see.
> OK. Let me interpret “one NRP” as the “single or default NRP” that is the subject of the other split thread.
>
> Here we can focus on…
>
>> My concern is the definition of NRP.  As far as I can tell, the definition in
>> the framework draft is so broad as to not help us do anything with the term.
> Understood. Broad concepts can be useful or not useful depending on the breadth and the clarity.
>
> Let us, for the sake of debate, assume that network links only have one type of resource: buffers.
> What goes on here is that the operator partitions the resources on the links into collections (that look a lot like virtual networks).
> On some network links all the resources may be assigned to one partition; on some links none of the resources may go to a particular partition.
> The operator, when provisioning a slice service, can simply say, this slice will be supported by that collection of resources.
> In this way, the operator can scale the operation of multiple slices within a single collection of resources by operating only on the collection.
>
> That is, as you say, pretty broadly scoped, but I believe it is operationally useful.
>
>> So first, let me state what I hope the term achieves.  I hope that it describes a
>> binding between a set of packets and some well-defined behavior(s) in the
>> network.  (We will get back to the plural question in a few lines.)
> Hmmm. I certainly didn't have that in mind when editing the text. That may mean I missed something.
> I thought that there was a difference between how you partition resources and how you operate on those resources.
> Perhaps this is because I have a connection-oriented background.
> So I thought an NRP was nothing more than a collection of resources.
>
>> The initial problem I heard about that drove the thing we now call NRP was
>> that there were networks that needed more behaviors than could be handled
>> with diffserv. Within a topology.  (Multiple topologies is a separate problem,
>> and has been as far as I can tell addressed.)
> Oh, I think I completely missed that conversation. Do you have a pointer to it?
> Perhaps you are looking at the draft-bestbar technology-specific problem space and solutions?
> I thought that the purpose of the NRP was "just" an operational simplicity.
> It's a bit like making a TE tunnel to support one or more VPNs: we could map individual VPN flows to individual network resources, but that doesn't scale.
>
>> That limit is 8 with SR-MPLS (because as far as I can tell we lost the ability to
>> do E-LSPs when we moved from MPLS to SR-MPLS) and 64 with IP (v4 or v6, I
>> care more about v6).  Yes, I was explciitly told that 64 was insufficient.
> OK. So that's interesting, but solution-specific.
> When we say "buffer/queuing/scheduling resources" we're being technology-independent.
>
>> So I started with thinking that an NRP was a generalization of a diffserv mark.
>> And represented, somehow in the packet, the behavioral treatment to be given
>> to a packet.
> I'm not surprised that you find the definition of NRP in the framework inconsistent with your thinking of what an NRP might be because the text is not trying to make that behavioral link.
> Yes, you could use the diffserv marker as a way of tagging packets as belonging to connectivity constructs assigned to particular NRPs. That approach might be argued by some people as being somewhat rash because it will conflict with the more established meaning of the diffserv marker. Indeed, others are suggesting other approaches for tagging packets for specifically this reason.
>
> Of course, if there is good policing and traffic steering, the slicing could all be achieved in a central controller without the need to mark the traffic as belonging to an NRP.
>
>> Which brings us to my problem with the definition in the framework draft.
>> As John (and I believe Krzysztof) read the definition, one could have an NRP
>> which, at each node of the topology encompassed 16 or 132 behaviors.
> I should let John and Krzysztof comment, but I don't believe that the definition we currently have is related to behaviors.
>
>> (Side note, I had read the collective portion of the definition as referring to the
>> fact that the NRP needed to be supported on multiple nodes, rather than referring
>> to multiple behaviors on a single node.)
> I'm still bothered that you think the NRP is related to behaviors. That is not something in the framework.
> Indeed, I can't see why, within a single slice you wouldn't run diffserv just as normal.
> It is certainly true that resources for an NRP would be present on multiple nodes. Indeed, the N in NRP is implying a widespread and connected set of resources.
>
>> But, the problem is that if an NRP can refer to more behaviors than diffserv
>> can represent, then we need another marking in the packet, called something
>> else (behavior group?) to tell us which set of diffserv behaviors within the NPR
>> the packet is bound to.
> Well, yes, let's call this collection of behaviors a "behavior group" so that it doesn't get confused or mixed with the term NRP with is about, erm, partitioning the resources in the network.
>
>> At which point we never need to configure the NRP, as what needs configuring
>> is just the behavior group.
> No. I would say that at this point what we have is two entirely separate things. One is a partition of network resources which you may make as a single partition encompassing all network resources, or as a set of partitions. The other is a set of behaviors if that is what you want.
>
>> Which is why I keep saying that the definition as given in the draft
>> does not address the need we have.
> OK. This is the nub of the issue. There is a need (no previously expressed to me) for using diffserv behaviors to support network slices.
> I have no understanding of how this would actually work and how it would or wouldn't clash with:
> - non-slice traffic using diffserv in the network
> - slice traffic using diffserv to cause differentiated behavior within a slice.
>
> It is, of course, a shame to get this far without uncovering this mismatch in expectations, but I dare say we can work it out. Have you got something that explains the use of diffserv for slicing and describes the needs?
>
>> Now, in fairness, the next question is what definition would work.  I started with
>> one simple definition, which I could still live with "An NRP refers to a behavioral
>> treatment for a packet supported by resources at the nodes within the associated
>> topology."  I could still live with that.
> Frankly, I could not!
> A partition of network resources is not a behavioral treatment.
>
>> I think we will find that we need another term to handle the marking that represent
>> a set of treatments distinguished by diffserv marks.
> I agree. If you want to have something that is a behavioral treatment for a packet supported by resources at the nodes within the associated topology then that is a new thing with a new name.
> And if we have it, we have to understand how it works and how it is used in slicing. We need (quite a lot of) text to explain how diffserv allows guarantees to be made about service delivery rather than just about traffic prioritisation.
>
>> Alternatively, we could define an NRP as a "set of behavioral treatments of a
>> packet, and their associated resources, across the nodes of the topology, where
>> the collected behaviors are discriminated by the diffserv marking."  The problem
>> with that is it may be too technology specific.  But I think it corresponds to what
>> is in several people's heads.  So I can live with it.  (And, as a side effect, makes
>> the single default NRP case understandable and valuable.
> I think that in you suggested definition, the "associated resources" are associated to the behavioral treatments, not to the packets, but I'm not clear.
>
> It seems that there is a specific solution in mind where the diffserv marker is used for two purposes simultaneously: to qualify the treatment behavior the packet should receive, and to identify which network resources it should consume.
>
> As my own side note, I wonder whether a lot of the QoS-based discussion that is implied by diffserv would be better placed in the soon-to-be-formed APN working group.
>
> Cheers,
> Adrian
>