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

[[e-mail]]

Hi Joel, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Joel Halpern <[e-mail]>
> Envoyé : mardi 27 septembre 2022 17:26
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> [e-mail]
> Cc : TEAS WG <[e-mail]>
> Objet : Re: [Teas] NRP definition [Was: Repeated call for last
> call on draft-ietf-teas-ietf-network-slices]
> 
> 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?
> 

[Med] If NRPs are used, then the NSC maintains a mapping between a slice service and an NRP. Classification/steering policies will also need to be provisioned on ingresses to make sure the  appropriate NRP-related resources are invoked. A concrete example is, when we use L3NM (RFC9182) or L2NM (RFC9291) to implement slices, the NSC can bind a VPN with an NRP by setting the following parameter in the LxNM: 

              +--rw underlay-transport
              |  +-- (type)?
              |     +--:(abstract)
              |     |  +--rw transport-instance-id?   string
              |     |  +--rw instance-type?           identityref
              |     +--:(protocol)
              |        +--rw protocol*                identityref 


         +------------------------------------------+
         |                 Customer                 |
         |                                          |
         +------------------------------------------+
                              A
                              | IETF Network Slice service interface
                              V
         +------------------------------------------+
         |        Network Slice Controller (NSC)    |
         +------------------------------------------+
                              A
                     L3NM     | Network Configuration Interface
                    NRP Model V
         +------------------------------------------+
         |           Network Controller(s)          |
         +------------------------------------------+
                              A
                              |    Device model
                              V
      +------------------------------------------------+
                            Network

Of course, the use of NRPs is not mandatory to offer slice services. Relying upon such yet-another abstraction is deployment-specific. For example, manipulating customized sets of resources from the underly network (i.e., NRPs) might be a useful in networks to reason about slice aggregates.


> 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.

[Med] Sure. It would be helpful if you can provide text from draft-ietf-teas-ietf-network-slices which you think is confusing so that it can be fixed. 

For example, I would not be against simplifying Section 6.1 among these lines: 
* Change the title from "Architecture to Realize IETF Network Slices" to "An Architecture to Realize IETF Network Slices" to further insist this is just an example, not a recommended arch.
* Avoid introducing new terms when not justified. For example, I would avoid having the "Filtered Topology" concept as this is redundant with NRPs.
* Reorder the text to first introduce NRPs, and then focus on the customized topology as an approach to build NRPs. 

_________________________________________________________________________________________________________________________

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.