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

From: John E Drake <[email-masked]>
Date: Thu, 9 Jan 2020 19:51:55 +0000

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

---

From: Xufeng Liu <[email-masked]>
Date: Mon, 13 Jan 2020 08:20:37 -0500

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

# Introduction

# Requirements

...

... [Xufeng] Transport Slice As a Service
        - Slice is configurable
        - Configurations can be negotiated
... [Xufeng] Elasticity
... [Xufeng] Survivability
... [Xufeng] Manageability

# 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

...  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

... data models ...

... SLOs as intents ...

## Mapping

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

## Controller

...

##  Underlying technology

# 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=
[email-masked]> wrote:

> 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.
>
> ... 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. ...
> ......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...
> ......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
>
>
> --
> Teas-ns-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 13 Jan 2020 13:59:20 +0000

All,

See my comment below

Reza

From: Teas-ns-dt <[email-masked]> on behalf of Xufeng Liu <[email-masked]>
Date: Monday, January 13, 2020 at 8:20 AM
To: John E Drake <jdrake=[email-masked]>
Cc: Stewart Bryant <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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

[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)

….[Reza] SLO/SLA discussion of transport slices

# Framework

... [Xufeng] Abstraction
….[Reza] discuss the transport slice controller

...  diagram ...

## Applications

... northbound interface ....

... data models ...

... SLOs as intents ...

## Mapping

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

## Controller

...

##  Underlying technology

# Considerations

## Monitoring

...

## Security model

Thanks,
- Xufeng

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

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

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