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

# Requirements

...

... clarify scoping is only networking ...

... add some discussion of scalability ...

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

... 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=
40juniper.net@dmarc.ietf.org> 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
> Teas-ns-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>