Re: [Teas-ns-dt] Network Slicing and Enhanced VPN Drafts

["Rokui, Reza (Nokia - CA/Ottawa)" <[e-mail]>]

All,

See my comment below

Reza

From: Teas-ns-dt <[e-mail]> on behalf of Xufeng Liu <[e-mail]>
Date: Monday, January 13, 2020 at 8:20 AM
To: John E Drake <jdrake=[e-mail]>
Cc: Stewart Bryant <[e-mail]>om>, "[e-mail]" <[e-mail]>rg>, "[e-mail]" <[e-mail]>
Subject: Re: [Teas-ns-dt] Network Slicing and Enhanced VPN Drafts

While I feel that the text VPN+ document is too technology specific, I'd like to propose the following annotations:

# Introduction

.. Refer to [definitions] ...

... Relation to existing IETF technologies ...

[Reza] Discuss how the transport slot relates to e2e network slice (and mention that the focus of IETF is transport slice)
[Reza] include a couple of diagram to clarify this


# Requirements

...

... clarify scoping is only networking ...
[Reza] one scope is NBI to transport slice controller to address creation, monitoring and optimization of the transport slices
[Reza] Other scope is to define the NBI data model
[Reza] other scope is the guideline for mapping the NBI to SBI (with a few use-case for clarity)


... add some discussion of scalability ...

... [Xufeng] Transport Slice As a Service
        - Slice is configurable
        - Configurations can be negotiated
... [Xufeng] Elasticity
... [Xufeng] Survivability
... [Xufeng] Manageability
….[Reza] SLO/SLA discussion of transport slices



# Framework

... [Xufeng] Abstraction
... [Xufeng] Network layers (Layer hierarchy)
... [Xufeng] Overlay and underlay (Abstraction hierarchy)
... [Xufeng] Network domains
... [Xufeng] Control mechanisms and interfaces
... [Xufeng] Measurement, monitoring, and recovery systems
….[Reza] discuss the transport slice controller


...  diagram ...

## Applications

... the transport slice system is used by an application. in most likely, that application is just another level slice orchestrator, e.g., the end-to-end slice orchestrator. but in theory it could also be an actual application that wants to manage some specific connectivity through the transport slice system. ...

## Expressing connectivity intents

... northbound interface ....

... data models ...

... SLOs as intents ...

... (most of this comes from the definitions draft) ...

## Mapping

.... the requirements get mapped by a piece of software, the controller, to concrete technologies and the connectivity is set up ...

## Controller

...

##  Underlying technology

... such as MPLS or VPNs or even physical cables ...

# Considerations

## Monitoring

... we need to instrument the slice realisation to know how it is doing + update the slice as situation changes + dynamic reconfig...

## How to deal with hierarchy

...

## Security model

... accidental or malicous interaction between slices raises new security concerns ...

Thanks,
- Xufeng


On Thu, Jan 9, 2020 at 2:52 PM John E Drake <jdrake=[e-mail]<mailto:[e-mail]>> wrote:
Dear Network Slicing Design Team, Stewart, and Adrian,

The current definition of a network slice is, I think, an underlay network MP2MP connection between a set of endpoints with an SLO which is met between any pair of endpoints.  What I think we can then say is that a variety of services are provided to those endpoints.  I.e., a network slice is strictly an underlay network construct over which a variety of overlay network services are offered to individual tenants.  Currently, the IETF defines overlay network services such as EVPN, L3VPN, and SFC (either separately or in combination), but this underlay/overlay separation would allow us to easily incorporate other services including those that are 5G specific.

So, what we might want to consider is moving the material which is underlay network specific from the VPN+ draft to the network slicing framework draft and recasting the VPN+ draft as defining how VPN overlay services use network slices.

Annotations are preceded w/ .....JD

Introduction

.... Refer to [definitions] ...

..... Relation to existing IETF technologies ...

.......JD  https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-03#section-1

Requirements

.....

..... clarify scoping is only networking ...

..... add some discussion of scalability ...

.......JD  https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-03#section-2,  https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-03#section-5

Framework

.......JD  https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-03#section-3

..... diagram ...
Applications

..... the transport slice system is used by an application. in most likely, that application is just another level slice orchestrator, e.g., the end-to-end slice orchestrator. but in theory it could also be an actual application that wants to manage some specific connectivity through the transport slice system. ...
Expressing connectivity intents

.......JD  I would replace the term 'applications' w/ 'overlay services'

..... northbound interface ...

..... data models ...

..... SLOs as intents ...

..... (most of this comes from the definitions draft) ...
Mapping

..... the requirements get mapped by a piece of software, the controller, to concrete technologies and the connectivity is set up ...
Controller

.....
Underlying technology

..... such as MPLS or VPNs or even physical cables ...

.......JD  https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-03#section-4

Considerations
Monitoring

..... we need to instrument the slice realisation to know how it is doing + update the slice as situation changes + dynamic reconfig...
How to deal with hierarchy

.......JD  https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-03#section-6,  https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-03#section-7,  https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-03#section-8

.....
Security model

..... accidental or malicous interaction between slices raises new security concerns ...

.......JD  https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-03#section-10


Yours Irrespectively,

John


Juniper Business Use Only

--
Teas-ns-dt mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt