Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

[Adrian Farrel <[e-mail]>]

Hi Gyan,

 

I realise I didn’t give an answer to this.

 

As editor, I’m not sure I’m required to do more than capture the discussion in the document, but I think there is an important nugget in your email.

 

It seems to me that IETF network slicing is about two things:

*	How the customer requests connectivity services with associated SLOs/SLEs
*	How the network operator marshals existing tools and techniques to operate the network to deliver the services

 

In some cases (some sets of connectivity and SLOs) we can already do it all. I think the view of L3VPNs that Krysztof has been talking about fits here, and it is important that our framework encompasses this prior art so that a network slice is just another way of looking at these existing services. 

 

In other cases (some sets of connectivity with advanced SLOs) we may need to tweak what we can already do. Probably eVPN is the best simple example of that.

 

In still more cases it is possible that new network tools will be needed to meet the service needs as the SLOs and SLEs demand more control than is currently available.

 

Furthermore, allowing a network to support a variety of services at once might mean that the network needs modifications to the available tools.

 

In summary, then, IETF network slicing is about specifying the services, and then seeing what needs to be done in the network to support them. If that is “not much” then we win!

 

Cheers,

Adrian

 

From: Gyan Mishra <[e-mail]> 
Sent: 20 May 2022 04:14
To: Dongjie (Jimmy) <jie.dong=[e-mail]>
Cc: John E Drake <[e-mail]>; Krzysztof Szarkowicz <[e-mail]>; adrian <[e-mail]>; mohamed.boucadair <[e-mail]>; teas <[e-mail]>
Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

 

 

Reading through this thread again I had some thoughts related to IETF network slicing and what differentiates IETF network slicing from IETF technology that exit today as well as the in past decades that has been able to provide network slicing capabilities but not the realization of an “IETF Network Slice”.

 

If we are not creating a significant  enhancements to a customer SLA with IETF network slicing for 5G, and if we say that what exists today with current and past IETF technologies fits the bill by making a very broad generalization about what IETF network slicing is, then it makes me question if we will be able to meet the requirements of 5G.

 

We should not forget that the concept of network slicing has gained traction and has been driven largely by 5G and as well has expanded beyond 5G for an Enhanced VPN service delivery use cases. 

 

We still have to be able to meet the expectations and be able to deliver enhanced SLA requirements for 5G services.  We should lower the bar or generalize what constitutes an IETF network slice.

 

The main difference in what has existed in the past as well as current technologies including Segment Routing and Flex Algo is the concept of being able to provision subset of underlay resources realization of an NRP or multiple NRPs that now constitute an network slice with some degree of path isolation.  

 

Path isolation has existed as well with steering mechanisms  RSVP-TE, ACTN  to realize a network slice and even now in recent with Segment Routing and Flex Algo low latency sub topology constraint based network slicing.  As well as QOS differential services  which has been the Service Provider hallmark  for value added tiered classes of service which has existed for decades to provide network slicing based on differential service.

 

Overall what I believe  has not existed in the past is the concept of being able to provisioning a subset of underlay resources that constitutes an NRP which is the building block of the underlay network slice that provides the underpinning for Enhanced VPN services for 5G and other use cases.  

 

Underlay resource provisioning is the key ingredient and the value add that has been missing that the NSC will now be able to provide the enhanced SLA for 5G services to realize IETF network slice.

 

Thoughts??

 

Gyan

 

On Thu, May 19, 2022 at 9:54 PM Dongjie (Jimmy) <jie.dong=[e-mail] <mailto:[e-mail]> > wrote:

Hi John,

 

Please see inline.

 

Best regards,

Jie

 

From: John E Drake [mailto:[e-mail] <mailto:[e-mail]> ] 
Sent: Thursday, May 19, 2022 10:52 PM
To: Dongjie (Jimmy) <[e-mail] <mailto:[e-mail]> >; Krzysztof Szarkowicz <[e-mail] <mailto:[e-mail]> >; adrian <[e-mail] <mailto:[e-mail]> >; mohamed.boucadair <[e-mail] <mailto:[e-mail]> >
Cc: teas <[e-mail] <mailto:[e-mail]> >
Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

 

Hi,

 

Comment inline.

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: Dongjie (Jimmy) <[e-mail] <mailto:[e-mail]> > 
Sent: Thursday, May 19, 2022 10:40 AM
To: John E Drake <[e-mail] <mailto:[e-mail]> >; Krzysztof Szarkowicz <[e-mail] <mailto:[e-mail]> >; adrian <[e-mail] <mailto:[e-mail]> >; mohamed.boucadair <[e-mail] <mailto:[e-mail]> >
Cc: teas <[e-mail] <mailto:[e-mail]> >
Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

 

[External Email. Be cautious of content]

 

Hi John, 

 

Please see inline.

 

Best regards,

Jie

 

From: John E Drake [mailto:[e-mail]] 
Sent: Thursday, May 19, 2022 8:50 PM
To: Dongjie (Jimmy) <[e-mail] <mailto:[e-mail]> >; Krzysztof Szarkowicz <[e-mail] <mailto:[e-mail]> >; adrian <[e-mail] <mailto:[e-mail]> >; mohamed.boucadair <[e-mail] <mailto:[e-mail]> >
Cc: teas <[e-mail] <mailto:[e-mail]> >
Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

 

Hi,

 

Comment inline.

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: Dongjie (Jimmy) <[e-mail] <mailto:[e-mail]> > 
Sent: Wednesday, May 18, 2022 9:52 PM
To: Krzysztof Szarkowicz <[e-mail] <mailto:[e-mail]> >; John E Drake <[e-mail] <mailto:[e-mail]> >; adrian <[e-mail] <mailto:[e-mail]> >; mohamed.boucadair <[e-mail] <mailto:[e-mail]> >
Cc: teas <[e-mail] <mailto:[e-mail]> >
Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

 

[External Email. Be cautious of content]

 

Hi Krzysztof and all,

 

Most of this text looks good to me except the last sentence. "A single NRP with the resources of the entire underlay network" is the same as a network without network resource partition. I think we agreed that an NRP refers to a subset of the underlay network resources (e.g. a subset of the buffer/queueing/scheduling resources), thus it is different from the whole underlay network. 

 

[JD]  A subset can consist of the entire set 

 

[Jie] Maybe this is true in general, while I’m not sure such generalization is helpful in the context of network slicing. Do you consider the whole physical underlay network can be called an NRP? 

 

[JD]  Absolutely

 

[Jie #2] Fine, then we could also generalize that network slicing is already supported in legacy networks for years:) 

 

 

That said, an NRP may have the same topology as the underlay network. 

 

IMO we need to keep in mind that resource and topology are two separate attributes of an NRP.


Best regards,

Jie

发件人：Krzysztof Szarkowicz <[e-mail] <mailto:[e-mail]> > 

收件人：Dongjie (Jimmy) <[e-mail] <mailto:[e-mail]> >;John E Drake <[e-mail] <mailto:[e-mail]> >;adrian <[e-mail] <mailto:[e-mail]> >;mohamed.boucadair <[e-mail] <mailto:[e-mail]> > 

抄 送：teas <[e-mail] <mailto:[e-mail]> > 

时 间：2022-05-19 03:16:57 

主 题：Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization 

 

Hi, 

 

So, do we have agreement for following change: 

 

 

          An NRP is simply a collection of resources identified in the underlay network. The amount and granularity of resources allocated in different portions of an NRP can be flexible. Depends on the operator’s policy and the service requirements, some NRP realizations may build the NRPs with dedicated topologies, while some other realizations may allow shared topology for multiple NRPs, one possible case is that the entire underlay network topology is used by all the NRPs. Some realization might as well use single NRP only with the resources of the entire underlay network topology. 

 

Best regards, 

Krzysztof 

 

 

On 2022 -Apr-29, at 14:57, Krzysztof Szarkowicz < [e-mail] <mailto:[e-mail]> > wrote: 

 

So, 

 

Are we OK now? From my perspective it look good. 

 

Best regards, 

Krzysztof 

 

 

On 2022 -Apr-28, at 16:58, John E Drake < [e-mail] <mailto:[e-mail]> > wrote: 

 

And I think it’s incorrect 

  

Yours Irrespectively, 

  

John 

  

  

Juniper Business Use Only 

From:  Dongjie (Jimmy) < <mailto:[e-mail]> [e-mail]> 
Sent: Thursday, April 28, 2022 10:57 AM
To: John E Drake < <mailto:[e-mail]> [e-mail]>; Krzysztof Szarkowicz < <mailto:[e-mail]> [e-mail]>
Cc:  <mailto:[e-mail]> [e-mail]; < <mailto:[e-mail]> [e-mail]> < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [e-mail]
Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization 

[External Email. Be cautious of content] 

  

Hi John, 

  

The sentence you quoted was the last sentence in Krzysztof ‘s proposal, and I just reused it in my proposed text: 

  

“… where the entire underlay network topology is used by all NRPs.” 

  

Best regards, 

Jie 

  

From:  John E Drake [ <mailto:[e-mail]> mailto:[e-mail]] 
Sent: Thursday, April 28, 2022 8:28 PM
To: Dongjie (Jimmy) < <mailto:[e-mail]> [e-mail]>; Krzysztof Szarkowicz < <mailto:[e-mail]> [e-mail]>
Cc:  <mailto:[e-mail]> [e-mail]; < <mailto:[e-mail]> [e-mail]> < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [e-mail]
Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization 

  

The text that I thought was incorrect: “, one possible case is that the entire underlay network topology is used by all the NRPs.” 

  

Yours Irrespectively, 

  

John 

  

  

Juniper Business Use Only 

From:  Dongjie (Jimmy) < <mailto:[e-mail]> [e-mail]> 
Sent: Thursday, April 28, 2022 12:56 AM
To: John E Drake < <mailto:[e-mail]> [e-mail]>; Krzysztof Szarkowicz < <mailto:[e-mail]> [e-mail]>
Cc:  <mailto:[e-mail]> [e-mail]; < <mailto:[e-mail]> [e-mail]> < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [e-mail]
Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization 

  

[External Email. Be cautious of content] 

  

Hi John, 

  

My understanding is that when NRP is introduced to the network for supporting IETF network slices, there would be at least two NRPs. Only one NRP with the entire underlay network topology would be same thing as the underlay network, do we need to call it an NRP? 

  

Besides, the text I proposed is general and can even apply to the “one NRP” case you mentioned. 

  

Best regards, 

Jie 

  

From:  John E Drake [ <mailto:[e-mail]> mailto:[e-mail]] 
Sent: Wednesday, April 27, 2022 9:15 PM
To: Dongjie (Jimmy) < <mailto:[e-mail]> [e-mail]>; Krzysztof Szarkowicz < <mailto:[e-mail]> [e-mail]>
Cc:  <mailto:[e-mail]> [e-mail]; < <mailto:[e-mail]> [e-mail]> < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [e-mail]
Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization 

  

Hi, 

  

I don’t think the text identified with [jie#4} is correct, because in the limiting case there is only one NRP and it consists of the entire underlay network topology. I think this was what Krzysztof and Med were noting, and adding a simple statement of this in the Framework draft would make sense. 

  

Yours Irrespectively, 

  

John 

  

  

Juniper Business Use Only 

From:  Dongjie (Jimmy) < <mailto:[e-mail]> [e-mail]> 
Sent: Wednesday, April 27, 2022 5:52 AM
To: Krzysztof Szarkowicz < <mailto:[e-mail]> [e-mail]>
Cc: John E Drake < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [e-mail]; < <mailto:[e-mail]> [e-mail]> < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [e-mail]
Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization 

  

[External Email. Be cautious of content] 

  

Hi Krzysztof, 

  

Please see inline [Jie #4]: 

  

From:  Krzysztof Szarkowicz [ <mailto:[e-mail]> mailto:[e-mail]] 
Sent: Tuesday, April 26, 2022 2:47 PM
To: Dongjie (Jimmy) < <mailto:[e-mail]> [e-mail]>
Cc: John E Drake < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [e-mail]; < <mailto:[e-mail]> [e-mail]> < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [e-mail]
Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization 

  

Hi Jie, 

  

  

Please see inline [Krzysztof #3] 

 

On 2022 -Apr-26, at 05:18, Dongjie (Jimmy) < <mailto:[e-mail]> [e-mail]> wrote: 

  

Hi Krzysztof, 

  

Please see inline [Jie #3]: 

  

From:   Krzysztof Szarkowicz [ <mailto:[e-mail]> mailto:[e-mail]] 
Sent: Tuesday, April 26, 2022 4:58 AM
To: Dongjie (Jimmy) <[e-mail] <mailto:[e-mail]> > 
Cc:  John E Drake < [e-mail] <mailto:[e-mail]> >;   [e-mail] <mailto:[e-mail]> ; < [e-mail] <mailto:[e-mail]> > < [e-mail]>;   [e-mail] <mailto:[e-mail]>  
Subject:  Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization 

  

Hi Jie, 

  

Please see inline [Krzysztof #2] 

 

On 2022 -Apr-21, at 09:41, Dongjie (Jimmy) <[e-mail] <mailto:[e-mail]> > wrote: 

  

Hi Krzysztof, 

  

Please see inline with [Jie #2]: 

  

  

From:   Krzysztof Szarkowicz [ <mailto:[e-mail]> mailto:[e-mail]] 
Sent: Wednesday, April 20, 2022 11:23 PM
To: Dongjie (Jimmy) <[e-mail] <mailto:[e-mail]> > 
Cc:  John E Drake < [e-mail] <mailto:[e-mail]> >;   [e-mail] <mailto:[e-mail]> ; < [e-mail] <mailto:[e-mail]> > < [e-mail] <mailto:[e-mail]> >;   [e-mail] <mailto:[e-mail]>  
Subject:  Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization 

  

Hi Jie, 

  

Please see inline. 

  

Thanks, 

Krzysztof 

 

On 2022 -Apr-20, at 10:31, Dongjie (Jimmy) <[e-mail] <mailto:[e-mail]> > wrote: 

  

Hi Krzysztof, 

  

Please see some replies inline: 

  

From:   Krzysztof Szarkowicz [ <mailto:[e-mail]> mailto:[e-mail]] 
Sent: Tuesday, April 19, 2022 12:17 AM
To: Dongjie (Jimmy) <[e-mail] <mailto:[e-mail]> > 
Cc:  John E Drake < [e-mail] <mailto:[e-mail]> >;   [e-mail] <mailto:[e-mail]> ; < [e-mail] <mailto:[e-mail]> > < [e-mail] <mailto:[e-mail]> >;   [e-mail] <mailto:[e-mail]>  
Subject:  Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization 

  

Hi Jie, 

  

I still see tight coupling between NRP and the topology. There will be realizations that do not use topology filtering (i.e, multiple NRPs use the same topology -> potentially entire network), so I am not sure, why realization with coupling between topology and NRP is so emphasized, while other realizations are not. 

  

[Jie] Totally agree that multiple NRPs can share the same topology, and as you said one extreme case is that the NRPs are created using the base topology of the network. While in any of these cases, an NRP needs to be associated with a topology to determine the set of links and nodes involved for resource management/reservation and path computation of the NRP. 

  

That said, I agree that topology filtering is just one optional approach to determine the topology of the NRP, and may not need to be highlighted in the text. 

  

What about following text (or something like that): 

  

  

    An NRP is simply a collection of resources identified in the underlay network. The details about tracked resources might depend on NRP realization. Some NRP realizations might put more focus on transport access resources, while some other NRP realizations might focus on transport core, or both transport access and transport core resources. Furthermore, some NRP realizations might build on tight coupling of an NRP with underlying filtered topology, while some other NRP realizations might not use separate filtered topologies at all. The framework is open for different NRP realizations, but the details of these realizations are out of scope for this document. 

  

[Jie] I’m not sure whether it is needed to mention access/core as they are only applicable to specific network types. And the term transport has been proved controversial in the past. 

  

[Krzysztof] I am OK to change the terms for something different, to be more technology agnostic. What I would like to see as the outcome of the framework document is, that different NRP realizations might have different focus on then granularity of resource tracking in different part of the underlay network. I.e.,  as a simple example, in case of packet switched network as the underlay technology, realizing e.g. P2P service slice might be achieved by kind of converting the packet switched network to circuit switched network (with granular tracking of resources across the entire path used for service delivery), but some other realization of such P2P service might only track the resources with high granularity at the access (AC), and use other techniques in other parts of the network to realize the service. 

  

I see the framework document should address that, without calling any technology details. 

  

[Jie #2] I can understand your point that the amount and granularity of resource management/reservation (I guess it is what your called resource tracking) for an NRP does not have to be the same everywhere, aggregation or sharing with certain criteria could be allowed. 

  

  

[Krzysztof #2] Indeed. Moreother, some NRP realizations might focus (=more granular resource management/reservation) in part ‘X’ of the network, while less granular in part Y, whole some other NRP realization just to the opposite - more granular in part Y, while less granular in part X. I see this should be somehow captured in the framework. 

  

[Jie #3] I think there could some text about the different granularity of resources for NRPs. 

  

[Krzysztof #3] I proposed some text regarding to this referring to ’transport access’ and ’transport core’. You didn’t liked this terms. So, can you propose some text? 

  

[Jie #4] How about some text like this: 

  

         An NRP is simply a collection of resources identified in the underlay network. The amount and granularity of resources allocated in different portions of an NRP can be flexible. Depends on the operator’s policy and the service requirements, some NRP realizations may build the NRPs with dedicated topologies, while some other realizations may allow shared topology for multiple NRPs, one possible case is that the entire underlay network topology is used by all the NRPs. 

  

  

 

 

  

Regarding the relationship between NRP and topology, here is my suggested text: 

  

              Depends on the operator’s policy and the service requirements, some NRP realizations may build the NRPs with dedicated topologies, while some other realizations may use shared topology for multiple NRPs, one extreme of which is to use the entire underlay network topology for the NRPs. 

  

[Krzysztof] What about following text: 

  

    Depends on the operator’s policy and the service requirements, some NRP realizations may build the NRPs with dedicated topologies, while some other realizations may use shared topology for multiple NRPs. Some realizations might even not use NRP topology differentiation at all, where the entire underlay network topology is used by all NRPs. 

  

[Jie #2] I see we are converging on this. The remaining small difference is whether all NRPs built on the entire underlay network topology can be seen as a special case of “multiple NRPs sharing the same topology”.   

  

The main point of this text is an NRP is associated with a topology, which can be either a dedicated topology or a shared topology, and can be either a sub-topology or the entire underlay network topology.  

  

Thus I’d prefer an description with enough generality, then the special case could be described under the general statement. What do you think? 

  

[Krzysztof #2] I am nart sure, what text are you proposing. 

  

[Jie #3] The generic text I propose is similar to what is in my previous mail: 

  

Depends on the operator’s policy and the service requirements, some NRP realizations may build the NRPs with dedicated topologies, while some other realizations may allow shared topology for multiple NRPs, one extreme case is that the entire underlay network topology is used by all the NRPs. 

  

[Krzysztof #3] What is ‘extreme’ for one realization, can be considered as ’normal’ (default) for another realization. So, my proposed text was avoiding such verbiage. 

  

[Jie #4] In my understanding, “each NRP with separated topologies” and “all NRPs with the same topology” are the two extremes of the solution space. And please see the modified text in reply to your last comment.  

  

Best regards, 

Jie

  

Please note that using shared topology for multiple NRPs is considered as one optimization approach in draft-dong-teas-nrp-scalability. 

  

Best regards, 

Jie

  

Best regards, 

Jie

  

Best regards, 

Jie 

  

Best regards, 

Krzysztof

 

On 2022 -Apr-18, at 12:18, Dongjie (Jimmy) <[e-mail] <mailto:[e-mail]> > wrote: 

  

Hi Krzysztof, 

  

Thanks for your reply. Please see some further inline with [Jie]: 

  

From:   Krzysztof Szarkowicz [ <mailto:[e-mail]> mailto:[e-mail]] 
Sent: Friday, April 15, 2022 3:01 PM
To: Dongjie (Jimmy) <[e-mail] <mailto:[e-mail]> > 
Cc:  John E Drake < [e-mail] <mailto:[e-mail]> >;   [e-mail] <mailto:[e-mail]> ; < [e-mail] <mailto:[e-mail]> > < [e-mail] <mailto:[e-mail]> >;   [e-mail] <mailto:[e-mail]>  
Subject:  Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization 

  

Hi Jie, 

  

Thank you for fast response. 

  

I fully agree with you, that the realization is the combination of various techniques, and in particular realization, there could be more focus on some technique ‘A’, while in some other realization there could be some more focus on technique ‘B’. And, the framework should be open for different realizations. 

  

[Jie] Agree the framework should be open to different realizations, and this is my understanding about the NRP description in the framework draft. 

  

I have re-read section 6.1, I am still confused with the first paragraph on page 30, which says: 

  

 An NRP is simply a collection of resources identified in the underlay 

 network.  Thus, the NRP is a scoped view of a topology and may be 

 considered as a topology in its own right.  The process of 

 determining the NRP may be made easier if the underlay network 

 topology is first filtered into a Filter Topology in order to be 

 aware of the subset of network resources that are suitable for 

 specific NRPs, but this is optional. 

  

It is very tight coupling between NRP and the topology. IMHO, is some realizations this tight coupling might be true, I’m some realizations it might not be true. This paragraph is most distracting for me. 

  

[Jie] My understanding about the topology here is that it is a generic term used to represent the set of network nodes and links that belong to the NRP, it does not constrain any mechanism to build or select the topology.   

  

But I agree the text could be improved. My suggestion is something like: 

  

     An NRP is simply a collection of resource identified in the underlay network. The set of nodes and links belonging to the NRP provide the scoped view of a topology, and the NRP may be considered as a topology in its own right. 

  

The rest text about filter topology (or call it sub-topology) is considered optional and I’m fine to either remove it or keep it. 

  

Best regards, 

Jie 

  

Best regards, 

Krzysztof 

  

 

On 2022 -Apr-15, at 07:00, Dongjie (Jimmy) <[e-mail] <mailto:[e-mail]> > wrote: 

  

Hi Krzysztof, 

  

Yes NRP is a concept introduced for the realization of IETF network slice, and it is the result of long time WG discussion about the terminology for the underlay network construct which is used to support the IETF network slice services. My personal understanding is that the NRP concept and definition belongs to the framework document, while the technologies used to instantiate NRP are out of its scope. For sure there can be multiple ways to build an NRP, as long as they comply to the NRP definition in the framework. 

  

I understand your concern is whether the framework mandates only one or two mechanisms to build NRP, I don’t think this is what the current framework indicates. Thus to me the examples about detailed realization mechanisms are not quite necessary for the framework document and may contradict with its role as a high-level framework. 

  

On the other hand, discussion about the possible mechanisms to build NRPs can continue in the WG. 

  

To me an NRP is usually realized with the combination of a set of data plane and control plane technologies. Constrained path computation or Flex-Algo can only be seen as a component rather than a complete solution. As you mentioned, one or multiple technologies such as admission control/advanced or basic QoS/capacity planning/resource reservation either on the edge nodes or the transit nodes would be needed, and the mechanisms can have specific applicability to different network applications. 

  

Best regards, 

Jie 

  

From:   Krzysztof Szarkowicz [ <mailto:[e-mail]> mailto:[e-mail]] 
Sent: Thursday, April 14, 2022 9:00 PM
To: Dongjie (Jimmy) <[e-mail] <mailto:[e-mail]> > 
Cc:  John E Drake < [e-mail] <mailto:[e-mail]> >;   [e-mail] <mailto:[e-mail]> ; < [e-mail] <mailto:[e-mail]> > < [e-mail] <mailto:[e-mail]> >;   [e-mail] <mailto:[e-mail]>  
Subject:  Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization 

  

Hi Jie, 

  

I agree, NRP is a realization, and a such, my initial comments (few weeks ago) was that it should not be mentioned at all in the framework document, but should be left to the documents describing the realization. 

  

If, however, NRP is mandated by the framework document for realization, the wording for NRP in the framework document should be wide enough, to allow different realization options (described in different realization documents). For example, realization option mentioned by Med: 

  

* admission control with advanced QoS (large number of edge QoS classes) at the transport edge 

-- 

 <http://www.verizon.com/> 

Gyan Mishra

Network Solutions Architect 

Email [e-mail] <mailto:[e-mail]> 

M 301 502-1347