Re: [Teas] Network slicing framework : Issue #7: Workflow

["Luis M. Contreras" <[e-mail]>]

Hi all,

two additional aspects that could be considered:

.- feedback to the customer in case the slice can be realized following
different technology-specific alternatives.

.- something related with previous comments: reservation and later
activation of the slice (even parts of it).

Best regards,

Luis


El jue, 30 sept 2021 a las 23:11, Xufeng Liu (<[e-mail]>)
escribió:

> As Med mentioned, a state report would be an expected step:
>
> - The NSC reports back to the customer as a function of the previous step
>
> Also, should this report include all allocated resources and maps? Or
> partial allocations with follow-up updates?
>
> Thanks,
> - Xufeng
>
> On Thu, Sep 30, 2021 at 6:33 AM Ogaki, Kenichi <[e-mail]> wrote:
>
>> Hi Med,
>>
>> In the other SDOs, the reservation step may be introduced after a
>> successful feasibility check.
>> Clause 7.3.3. of ETSI NFV IFA 013 V4.2.1 is easy to understand.
>>
>> https://www.etsi.org/deliver/etsi_gs/nfv-ifa/001_099/013/04.02.01_60/gs_nfv-ifa013v040201p.pdf
>>
>> When we assume TE technology, the reservation, LSP setup, is almost same
>> as the creation, but the reservation may be necessary for SFC case.
>>
>> Thanks,
>> Kenichi
>>
>> -----Original Message-----
>> From: [e-mail] <[e-mail]>
>> Sent: Thursday, September 30, 2021 6:11 PM
>> To: 大垣 健一 <[e-mail]>; [e-mail]; [e-mail]
>> Subject: RE: [Teas] Network slicing framework : Issue #7: Workflow
>>
>> Hi Kenichi,
>>
>> I agree this makes sense even if I think that this can be handled by the
>> protocol used to place a request (confirmed commit in netconf, for
>> example).
>>
>> A successful feasibility check does not guarantee that a subsequent
>> request will be accepted unless some resource preservations are made,
>> though.
>>
>> Cheers,
>> Med
>>
>> > -----Message d'origine-----
>> > De : Teas <[e-mail]> De la part de Ogaki, Kenichi Envoyé
>> > : jeudi 30 septembre 2021 10:39 À : BOUCADAIR Mohamed INNOV/NET
>> > <[e-mail]>; [e-mail]; [e-mail]
>> > Objet : Re: [Teas] Network slicing framework : Issue #7: Workflow
>> >
>> > Hi Adrian and Med,
>> >
>> > As I wrote below before, a feasibility check request step may be
>> > introduced before the creation request.
>> > A feasibility check has a broad sense, but we can limit the scope to
>> > the available resource check to create a slice.
>> > This may be not used by an end user(consumer), but a Customer higher
>> > level operations system* may require to avoid the creation failure or
>> > suspended state.
>> > It corresponds to VN compute of Sec. 4.3.1 of actn-vn-yang model.
>> >
>> > https://mailarchive.ietf.org/arch/msg/teas/WZKp2PHrPqH5J5_km8Mz8P2pSVU
>> > /
>> >
>> > *Figure 1 in draft-ietf-teas-ietf-network-slices-04
>> >
>> > Thanks,
>> > Kenichi
>> >
>> > -----Original Message-----
>> > From: Teas <[e-mail]> On Behalf Of
>> > [e-mail]
>> > Sent: Thursday, September 30, 2021 12:45 AM
>> > To: [e-mail]; [e-mail]
>> > Subject: Re: [Teas] Network slicing framework : Issue #7: Workflow
>> >
>> > Hi Adrian,
>> >
>> > > For that reason, I think it would be wrong to document a workflow.
>> > > (This is a change to my original opinion!)
>> > >
>> > > Maybe add a sentence to explain that the order that the
>> > > architectural networks are constructed is open for operational choice.
>> >
>> > Seems reasonable. Internals to the NSC should be kep as such
>> > (especially, the second and third bullets of your list).
>> >
>> > Another approach would be to focus only on the visible external
>> > behavior,
>> > e.g.,:
>> >
>> > - The network exposes its (slice) capabilities
>> > - The customer requests a slice
>> > - The NSC maps the requests to the capabilities while applies provider
>> > policies (if any) and then creates the resource partition
>> > - The NSC reports back to the customer as a function of the previous
>> > step
>> >
>> > Cheers,
>> > Med
>> >
>> > > -----Message d'origine-----
>> > > De : Teas <[e-mail]> De la part de Adrian Farrel
>> Envoyé :
>> > > lundi 27 septembre 2021 20:25 À : [e-mail] Objet : [Teas]
>> > > Network slicing framework : Issue #7: Workflow
>> > >
>> > > Dependent slightly on the resolution of issue #6 (architecture and
>> > > terminology), we could document a workflow.
>> > >
>> > > For example,:
>> > > - customer requests a slice
>> > > - NSC maps slice to a slice group
>> > > - NSC maps slice group to a resource partition
>> > > - NSC allocates resources to the resource partition
>> > >
>> > > But it seems to me that these steps could happen in pretty much any
>> > > order depending to operational preferences and possibly the
>> > > technology of the network.
>> > >
>> > > For that reason, I think it would be wrong to document a workflow.
>> > > (This is a change to my original opinion!)
>> > >
>> > > Maybe add a sentence to explain that the order that the
>> > > architectural networks are constructed is open for operational choice.
>> > >
>> > > 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.
>> >
>> > _______________________________________________
>> > Teas mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/teas
>> > _______________________________________________
>> > 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.
>>
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
>>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>


-- 
___________________________________________
Luis M. Contreras
[e-mail]
[e-mail]
Global CTIO unit / Telefonica