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

[Joel Halpern <[e-mail]>]

If the NRP concept does not map to how packets are treated, and does not 
map to some other configuration in the IETF network slice controller / 
entry / support, then what difference does it make?

As oine person put it, they thought that NRP corresponded to the 
proposal for Resource SIDs.  If it is a vague concept unrealted to 
behavior, then I don't know what it is.  And the current text in the 
framework does not lead me to understand it.  Whatever we end up with, 
please, let's clean up the definition.

Yours,

Joel

On 9/27/2022 10:23 AM, [e-mail] wrote:
> Hi Joel, all,
>
>> 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.
> The more we paint NRP with behavioral considerations, the more we lose the value of having the NRP concept (which is BTW no more than a generalization of another concept in the framework: filtered topology; both of them are optional and not required for implementing slices).
>
> As you mentioned diffserv in your message, and if we assume NRP is defined as behaviors, then one would say that an NRP is some sort of PDB ... which I think is not what is intended.
>
> That's said, I agree with you that the design of an NRP might be based on what would look like behavioral considerations (e.g., exclude satellite links for a topology to support delay-sensitive services), but that’s just a policy among others.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Teas <[e-mail]> De la part de Joel Halpern
>> Envoyé : jeudi 22 septembre 2022 19:12
>> À : [e-mail]
>> Cc : [e-mail]
>> Objet : Re: [Teas] NRP definition [Was: Repeated call for last
>> call on draft-ietf-teas-ietf-network-slices]
>>
>> (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
>>>
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>