Subject: [Actn] ACTN Requirements

From: Leeyoung <[email-masked]>
Date: Wed, 13 Aug 2014 19:44:10 +0000

Hi,

I'd like to trigger a new thread of discussions on ACTN requirements.  There are some service requirements identified by KDDI and China Mobile use-case presentations on the need for network slicing by different internal services. If we were to work on this service interface between "customer" and VNC, this might constitute a separate work on this interface. However, as a starting point, we can begin with a VNC-PNC interface as this is a common thread in all use-cases.

Here's a list of areas for VNC-PNC interface requirements collected from use-cases.

1.       VN Information Query /Response

a.       Abstraction level negotiation

b.      Constraints Filtering (B/W, latency, etc.)

c.       Abstracted Topology (VNs/VLs)

                                                               i.      Type:  TED like

                                                             ii.      Including border VNs/VLs

d.      End-point information

2.       VN Path Computation Request / Reply

a.       Path level abstraction - LSP DB like

b.      Diversity calculation

c.       Border/gateway nodes/links

3.       VN Path Request Signaling (Setup) / Reply

a.       Per domain path request

                                                               i.      Single request

                                                             ii.      Multiple requests - diversity path request, etc.

b.      Domain sequence kept at VNC

c.       Coordination of signaling (multi-domain)

4.       VN Path Modification/Rerouting/re-grooming

5.       VN Performance Monitoring

a.       VN Connection Failure and other degradation report

b.      Pull/Push Models
Thanks,
Young

---

From: Nico Wauters <[email-masked]>
Date: Mon, 18 Aug 2014 12:08:01 +0200

Lee,

On your proposal,

I assume that some use cases require a good understanding of diversity or
risk sharing.

Can we include in Abstracted topology (section 1.c) also publishing of
shared risk information (e.g. by listing SRGID’s)?

In case links (of the abstracted topology) have common SPOF’s, the VNC
should be informed about this.

Regards

Nico

*From:* Leeyoung [mailto:[email-masked]]
*Sent:* woensdag 13 augustus 2014 21:44
*To:* [email-masked]
*Subject:* [Actn] ACTN Requirements

I’d like to trigger a new thread of discussions on ACTN requirements.
There are some service requirements identified by KDDI and China Mobile
use-case presentations on the need for network slicing by different
internal services. If we were to work on this service interface between
“customer” and VNC, this might constitute a separate work on this
interface. However, as a starting point, we can begin with a VNC-PNC
interface as this is a common thread in all use-cases.

Here’s a list of areas for VNC-PNC interface requirements collected from
use-cases.

                                                               i.      Type:
TED like

                                                             ii.      Including
border VNs/VLs

d.      End-point information

a.       Path level abstraction – LSP DB like

b.      Diversity calculation

                                                               i.      Single
request

                                                             ii.      Multiple
requests – diversity path request, etc.

b.      Pull/Push Models

Thanks,

Young

---

From: Leeyoung <[email-masked]>
Date: Mon, 18 Aug 2014 15:35:11 +0000

Hi Nico,

Yes, this is addressed by some use-cases. In the initial VN abstracted topology should indicate single point of failure (SPOF). One way to do it for links is as you said SRLG ID.  For some application, I can think that VN Node level SPOF indicator may be needed.

In all case, I agree with you that VNC needs to be informed of that.

Thanks,
Young

From: Nico Wauters [mailto:[email-masked]]
Sent: Monday, August 18, 2014 5:08 AM
To: Leeyoung; [email-masked]
Subject: RE: [Actn] ACTN Requirements

Lee,

On your proposal,

I assume that some use cases require a good understanding of diversity or risk sharing.

Can we include in Abstracted topology (section 1.c) also publishing of shared risk information (e.g. by listing SRGID’s)?

In case links (of the abstracted topology) have common SPOF’s, the VNC should be informed about this.

Regards
Nico

From: Leeyoung [mailto:[email-masked]<mailto:[email-masked]>]
Sent: woensdag 13 augustus 2014 21:44
To: [email-masked]<mailto:[email-masked]>
Subject: [Actn] ACTN Requirements

I’d like to trigger a new thread of discussions on ACTN requirements.  There are some service requirements identified by KDDI and China Mobile use-case presentations on the need for network slicing by different internal services. If we were to work on this service interface between “customer” and VNC, this might constitute a separate work on this interface. However, as a starting point, we can begin with a VNC-PNC interface as this is a common thread in all use-cases.

Here’s a list of areas for VNC-PNC interface requirements collected from use-cases.

                                                               i.      Type:  TED like

d.      End-point information

b.      Diversity calculation

                                                               i.      Single request

                                                             ii.      Multiple requests – diversity path request, etc.

b.      Pull/Push Models
Thanks,
Young