Subject: Re: [Netslices] Input for problem statement

From: Liang GENG <[email-masked]>
Date: Tue, 9 Jan 2018 14:53:25 +0000

Hi Xavier,

Thanks for your very helpful suggestion.

As we discussed during IETF100, I believe the recursive nature of COMS is very important and it is sensible to make the terms aligned with NGMN definition. I will update the problem statement draft accordingly.

In additional, do you think we can take out the end-to-end slice manager for non-3GPP scenarios since the COMS may comes into the picture from the top-level slice manager/controller?

Best wishes

Liang

________________________________
From: Netslices <[email-masked]> on behalf of De Foy, Xavier <[email-masked]>
Sent: 06 December 2017 04:21:07
To: Geng, Liang
Cc: [email-masked]
Subject: [Netslices] Input for problem statement

Hi Liang,

   This is to follow-up our conversation at IETF 100 about draft-geng-coms-problem-statement, and share on the list. The goal would be to make a recursive use of the same (COMS) model, from top to bottom.

  A secondary point would be to align our use of the terms “slice segment” and “slice subnet” across drafts. Since “subnet” is defined by NGMN it could be simpler to use that term, as long as our definition is compatible with NGMN. There is a definition in the interconnection draft.

  Please consider the following figure as input for an update to figure 2: e.g. “cross-segment” could become “end-to-end”, “segment-specific” could become “technology specific”, etc.

  One additional thing we could consider is using a single term “manager” or “controller”. This would be better aligned with the recursive nature of COMS (e.g. an e2e slice manager may be used to manager/control a slice subnet for a larger slice).

  NSaaS and       +------------------------------------------+

  End-to-end      |   Network Slice Tenant                   |

  Network         +-+----------------------------------------+

  Slice             |   Requests a NSaaS Service

  Management        |

      ^           +-v----------------------------------------+

      |           | Network Slice Service Provider           |

      |           +-+----------------------------------------+

      |             |  Generates an end-to-end Slice Model

      |             |

      |           +-v----------------------------------------+   ^

      |           | E2e slice manager (COMS model)           |   |

      |           +-+----------------------------------------+   | NS

      |             | Decomposed by End-to-end                   | Layer

      |             |                    Network Slice Manager   |

      |           +-v----------------------------------------+   |

      ------------|Slice controllers (COMS model for subnets)|   |

      |           | (may include multiple controllers)       |   |

      v           +----+---------------+---------------+-----+   v

Tech-specific         |               |               |

Network Slice         |               |               |

Management     +------v------+ +------v------+ +------v------+

and            | Network     | | Network     | | Network     |

Implementation |Configuration| |Configuration| |Configuration|

                |  Model I    | |  Model II   | |  Model III  |

                +-------------+ +-------------+ +-------------+

And to match it, here is some input for figure 1:

+----------------------------------------------------------+

|                 Network Slice as a Service               |

| +-------------------------------------+ +--------------+ |

| |     Network Slice Template          | |              | |

| | +---------+ +---------+ +---------+ | | Customized   | |

| | |   5G    | | Internet| |Verticals| | | Network Slice| |

| | | centric | |   VPN   | |Industry | | |              | |

| | +---------+ +---------+ +---------+ | |              | |

| +-------------------------------------+ +----+---------+ |

|                 |                            |           |

|                 |                            |           |

|          +------v----------------------------v----+      |

|          | Network Slice Service Profile          |      |

|          +----------------+-----------------------+      |

|                           |                              |

+----------------------------------------------------------+

                            |

                  +---------v----------+

                  |   End-to-end       |

     +------------+   Slice Manager    +--------------+

     |            +---------+----------+              |

     |                      |                         |

     |                      |                         |

+----v----+  +--------------v-----------------+ +-----v----+

|  RAN    |  | Network Slice Controller       | |  CN      |

|  Slice  |  |                                | |  Slice   |

|  Ctrlr  |  +--------+----------+---------+-++ |  Ctrlr   |

+---------+  |        |          |         | |  +----------+

         +---+        |          |         | +----------+

         |            |          |         |            |

  +------+-----+ +----+----+ +---+----+ +--+--------+ +-+--------+

  |Connectivity| |Computing| | Storage| |Generalized| | Nw Slice |

  |            | |         | |        | |Functions  | | Ctrlr    |

  +------------+ +---------+ +--------+ +-----------+ +----------+

  Best Regards,

Xavier.

---

From: Xavier de Foy <[email-masked]>
Date: Tue, 9 Jan 2018 11:43:33 -0500

Hi Liang,

  Sure, it makes sense that in some cases, end-to-end slice management may
be realized by the service that sits above the COMS model. Actually we can
probably update the diagram to show both possibilities (and also remove
RAN/CN to be more general). For example:

+----------------------------------------------------------+
|                 Network Slice as a Service               |
| +-------------------------------------+ +--------------+ |
| |     Network Slice Template          | |              | |
| | +---------+ +---------+ +---------+ | | Customized   | |
| | |   5G    | | Internet| |Verticals| | | Network Slice| |
| | | centric | |   VPN   | |Industry | | |              | |
| | +---------+ +---------+ +---------+ | |              | |
| +-------------------------------------+ +----+---------+ |
|                 |                            |           |
|                 |                            |           |
|          +------v----------------------------v----+      |
|          | Network Slice Service Profile          |      |
|          +----------------+----------+------------+      |
|                           |          .                   |
+----------------------------------------------------------+
                            |          .
                            |          .
                            |          .
                            |          +..............+
                            |                         .
                            |                         .
                            |COMS                     .COMS
             +--------------v-----------------+ +-----v----+
             | Network Slice Controller       | | Nw Slice |
             |                                | | Ctrlr    |
             +--------+----------+---------+-++ +----------+
             |        |          |         | |
         +---+        |          |         | +----------+
         |            |          |         |            |COMS
  +------+-----+ +----+----+ +---+----+ +--+--------+ +-+--------+
  |Connectivity| |Computing| | Storage| |Generalized| | Nw Slice |
  |            | |         | |        | |Functions  | | Ctrlr    |
  +------------+ +---------+ +--------+ +-----------+ +----------+

  Regards,
Xavier

On Tue, Jan 9, 2018 at 9:53 AM, Liang GENG <[email-masked]> wrote:

> As we discussed during IETF100, I believe the recursive nature of COMS is
> very important and it is sensible to make the terms aligned with NGMN
> definition. I will update the problem statement draft accordingly.
>
>
> In additional, do you think we can take out the end-to-end slice manager
> for non-3GPP scenarios since the COMS may comes into the picture from the
> top-level slice manager/controller?
>
>
> Best wishes
>
> Liang
>
>
> ------------------------------
> *From:* Netslices <[email-masked]> on behalf of De Foy,
> Xavier <[email-masked]>
> *Sent:* 06 December 2017 04:21:07
> *To:* Geng, Liang
> *Cc:* [email-masked]
> *Subject:* [Netslices] Input for problem statement
>
>
> Hi Liang,
>
>
>
>    This is to follow-up our conversation at IETF 100 about
> draft-geng-coms-problem-statement, and share on the list. The goal would
> be to make a recursive use of the same (COMS) model, from top to bottom.
>
>
>
>   A secondary point would be to align our use of the terms “slice segment”
> and “slice subnet” across drafts. Since “subnet” is defined by NGMN it
> could be simpler to use that term, as long as our definition is compatible
> with NGMN. There is a definition in the interconnection draft.
>
>
>
>   Please consider the following figure as input for an update to figure 2:
> e.g. “cross-segment” could become “end-to-end”, “segment-specific” could
> become “technology specific”, etc.
>
>
>
>   One additional thing we could consider is using a single term “manager”
> or “controller”. This would be better aligned with the recursive nature of
> COMS (e.g. an e2e slice manager may be used to manager/control a slice
> subnet for a larger slice).
>
>
>
>
>
> _______________________________________________
> Netslices mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netslices
>
>