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

Hi all,

The text proposed by Krzysztof looks good to me as well.

The text points to aspect of flexibility which I think is important for
operators as for as the degree of partitioning of the network where a
single NRP with the resources maybe the entire underlay network or it or
maybe a subset of underlay network resources where the QOS PHB
differentiated forwarding  aspects as Joel and Med reiterated fall under a
collection of resources in the proposed text.

With the text proposed I think resources and topology are still two
separate aspects of NRP even though the NRP may have the same topology as
the underlay network. The resources that make up the underlay topology
would be the sum total of all resources in the underlay topology in the
case where the single NRP with all resources is the entire underlay
network.  So we can still maintain the resources granularity aspect in the
underlay.

Cheers

Gyan

On Thu, May 19, 2022 at 9:06 AM <mohamed.boucadair@orange.com> wrote:

> Hi all,
>
>
>
> Fully agree with John.
>
>
>
> The text proposed by Krzysztof looks good to me.
>
>
>
> Queuing aspects mentioned by Joel fall under “a collection of resources”
> in the proposed text. More generally, queuing management falls under
> differentiated forwarding while topology customization is an aspect of
> differentiated routing that can be tweaked to put into effect an NRP. Other
> differentiated behaviors can be a result of traffic management
> considerations (admission control, ratio of reserved-provisioned/allowed
> traffic, etc.).
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* John E Drake <jdrake@juniper.net>
> *Envoyé :* jeudi 19 mai 2022 14:50
> *À :* Dongjie (Jimmy) <jie.dong@huawei.com>; Krzysztof Szarkowicz <
> kszarkowicz@gmail.com>; adrian <adrian@olddog.co.uk>; BOUCADAIR Mohamed
> INNOV/NET <mohamed.boucadair@orange.com>
> *Cc :* teas <teas@ietf.org>
> *Objet :* RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service !=
> Realization
>
>
>
> Hi,
>
>
>
> Comment inline.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Dongjie (Jimmy) <jie.dong@huawei.com>
> *Sent:* Wednesday, May 18, 2022 9:52 PM
> *To:* Krzysztof Szarkowicz <kszarkowicz@gmail.com>; John E Drake <
> jdrake@juniper.net>; adrian <adrian@olddog.co.uk>; mohamed.boucadair <
> mohamed.boucadair@orange.com>
> *Cc:* teas <teas@ietf.org>
> *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 *
>
>
>
> 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 <kszarkowicz@gmail.com>
>
> *收件人：*Dongjie (Jimmy) <jie.dong@huawei.com>;John E Drake <
> jdrake@juniper.net>;adrian <adrian@olddog.co.uk>;mohamed.boucadair <
> mohamed.boucadair@orange.com>
>
> *抄* *送：*teas <teas@ietf.org>
>
> *时* *间：*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
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*