Subject: Re: [Teas] Network slicing framework : Issue #4: Describing the network slice service

From: Xufeng Liu <[email-masked]>
Date: Thu, 7 Oct 2021 12:24:26 -0400

I would hope the service could support topology-as-a-server, beyond
connectivity-as-a-service, or provide the capability to specify an explicit
path for connectivity.

Thanks,
- Xufeng

On Wed, Sep 29, 2021 at 6:53 AM <[email-masked]> wrote:

> Hi Adrian, all,
>
> That minimal scope is a good starting point.
>
> I had a proposal to get us out of SLO/SLE taxonomy, though.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Teas <[email-masked]> De la part de Adrian Farrel
> > Envoyé : lundi 27 septembre 2021 18:49
> > À : 'TEAS WG' <[email-masked]>; 'Vishnu Pavan Beeram' <
> [email-masked]>
> > Objet : [Teas] Network slicing framework : Issue #4: Describing the
> > network slice service
> >
> > Hi,
> >
> > The current document describes the service in terms of:
> > - endpoints
> > - connectivity matrices
> > - SLOs/SLE
> >
> > I believe that today's meeting had no objection to keeping this minimal
> > definition, and specifically that it would not be appropriate to put an
> > Information Model into the document.
> >
> > Opinions are wanted to confirm this view (silence is consent!).
> >
> > Pavan suggested that "a little more text may be needed" and I took this
> as
> > him volunteering to draft that text.
> >
> > Thanks,
> > Adrian
> >
> > _______________________________________________
> > Teas mailing list
> > [email-masked]
> > 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: <[email-masked]>
Date: Fri, 8 Oct 2021 05:45:15 +0000

Hi Xufeng,

I support that as well … but this can be expressed as part of service requirements (SLO/SLE).

As already mentioned during the call for adoption of the slice definition I-D, the authors can pick from RFC7297 at wish, where we have the following:

=========================================
3.10<https://datatracker.ietf.org/doc/html/rfc7297#section-3.10>.  Routing and Forwarding

   This clause is used to specify outsourced routing actions, such as
   installing dedicated routes to convey the traffic to its (service)
   destination.  These dedicated routes may be computed, selected, and
   installed for Traffic Engineering or resilience purposes.  For
   Traffic Engineering, these paths can be used to intelligently divert
   traffic away from some nodes/links that may potentially suffer from
   congestion or avoid crossing competitors' networks.  For resilience,
   backup paths are typically pre-installed in order to bypass nodes/
   links under protection.

   This clause is also used to specify intermediate functions that must
   be invoked in the forwarding path (e.g., redirect the traffic to a
   firewall, invoke topology hiding features, etc.) or specify
   geographic routing restrictions.

   A requirement for setting up a logical routing topology [RFC4915<https://datatracker.ietf.org/doc/html/rfc4915>]
   [RFC5120<https://datatracker.ietf.org/doc/html/rfc5120>] may also be considered, e.g., to facilitate the management
   of the nodes that are involved in the forwarding of the traffic as
   defined in the CPP.

   …

   For illustration purposes, a routing policy would avoid satellite
   links for Voice over IP (VoIP) deployments since this may degrade the
   offered service.
===========================================

Thank you.

Cheers,
Med

De : Teas <[email-masked]> De la part de Xufeng Liu
Envoyé : jeudi 7 octobre 2021 18:24
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]; TEAS WG <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>
Objet : Re: [Teas] Network slicing framework : Issue #4: Describing the network slice service

I would hope the service could support topology-as-a-server, beyond connectivity-as-a-service, or provide the capability to specify an explicit path for connectivity.

Thanks,
- Xufeng

On Wed, Sep 29, 2021 at 6:53 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Adrian, all,

Cheers,
Med

> De : Teas <[email-masked]<mailto:[email-masked]>> De la part de Adrian Farrel
> À : 'TEAS WG' <[email-masked]<mailto:[email-masked]>>; 'Vishnu Pavan Beeram' <[email-masked]<mailto:[email-masked]>>
> Pavan suggested that "a little more text may be needed" and I took this as
> [email-masked]<mailto:[email-masked]>

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
[email-masked]<mailto:[email-masked]>
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.