Re: [Teas-ns-dt] Pull-request #7: Xufeng’s proposed textual additions.

[Eric Gray <[e-mail]>]

Added Xufeng’s text as modified and suggested by Jari by E-Mail prior to the meeting this week.

From: Teas-ns-dt <[e-mail]> On Behalf Of Jari Arkko
Sent: Sunday, February 23, 2020 2:34 PM
To: Xufeng Liu <[e-mail]>om>; [e-mail]
Subject: [Teas-ns-dt] Pull-request #7: Xufeng’s proposed textual additions.


I promised to review the contributions to the framework
documement. This is a my personal review, without any hats.  Looking
at the pull requests from https://github.com/teas-wg/teas-ns-dt/pulls,
we have:

Pull-request #7: Xufeng’s proposed textual additions
Pull-request #8: Reza’s proposed text addition to the controller section
Pull-request #9: Reza’s proposed text for Transport Slice Controller (TSC) Northbound Interface (NBI)
Pull-request #10: Reza’s proposed text for additions to the Framework section
Pull-request #11: Reza’s proposed text for addition to the Mapping section

I'm going through each of them, one by one. This email concerns
Pull-request #7: Xufeng’s proposed textual additions.

Thanks for this proposal, Xufeng! It contains useful material that we
can integrate to the draft. Below you'll find what I'd propose to be
included. (I can make another pull request if the editors so desire --
but I should note that I have not reviewed in detail the other pull
requests so maybe there are conflicts or similar text between them).

The pull request is a set of separate subsections.

----

The first subsection is on abstraction. The concept is useful,
although I feel one could have explained it more briefly,
particularly given the context of network slicing. The last paragraph
discusses negotiation where a client requests specific
implementation. This may be needed in some cases, but I think we
should start from a simpler approach of keeping the requirement
separate from the implementation. Where needed, requirements can of
course including things like "must provide to physically independent
paths and not share components", which does force some of the
implementation choices, but does it at the level of a requirement
rather than specific implementation constraint.

I think what should put to the document is this (adapted from Xufeng's
text):

    A consumer expresses requirements for a particular slice by
    specifying what is required rather than how that is achieved. That
    is, the consumer's view of a slice is an abstract one.  Consumers
    normally have no visibility into the provider network’s actual
    topology and resource availability information.'

    The benefits can be:

    1. Security: network operators do not need to expose the network’s
    actual topology to its consumers;

    2. Layered implementation: Transport network is comprised of network
    elements that belong to a different layer network that the consumer
    devices. Also, the internal network connectivity advertisements usually
    contain proprietary information, which the consumers cannot interpret,
    but discarding of which would lead to incorrect assumptions and
    decisions. This means that the consumers cannot use actual network
    topology and traffic engineering information even if said information
    is available;

    3. Scalability: consumers do not want to know any transport network
    information that is not related to the services provided to the
    consumers.

    The general issue of abstraction in TE network is described more
    fully in [RFC7926].

This text should go into Section "Expressing connectivity intents" of
the Framework.  Also, in the current introduction section of the
framework draft, we should make this change:

OLD:
    Network abstraction is a technique that can be applied to a network
    domain to select network resources by policy to obtain a view of
    potential connectivity and a set of service functions.
NEW:
    The consumer expresses requirements for a particular slice by
    specifying what is required rather than how that is achieved. That
    is, the consumer's view of a slice is an abstract one.

----

The second subsection is on layering.

It is a useful topic, but needs to be connected somehow to this
specific work on network slicing.

I'd propose the following, using again Xufeng's references and points
but with a much shortened text. It should go again to the Section
"Expressing connectivity intents" of the Framework, right after the
abstraction text above.

    This framework does not mandate a particular layer at which
    network slices operate, as theoretically anything from virtual L2
    connections to Ethernet or IP connectivity could be provided. Data
    models and interface are of course needed to set up network
    slices, and specific interfaces may have capabilities that allow
    the creation of specific layers.

    Layered virtual connections are comprehensively discussed in IETF
    documents and widely supported. See, for instance, GMPLS-based
    networks [RFC5212] [RFC4397] or ACTN [RFC8353] [RFC8345]. The
    principles and mechanisms are also applicable to the transport
    slice architecture.

----

The third subsection is on "System Management and Control
Interfaces". There may be some material here to be used in the
management sections. I feel that the desire to cover everything is
taking a bit off from focus. I'd propose the following text, again
adapted from Xufeng's text and going to the "Expressing connectivity
intents" section:

    There are several IETF-defined mechanisms for expressing the need
    for a desired virtual network. The northbound interface carries
    data either in a protocol-defined format or expressed in a
    formalism defined by a modeling language. For instance:

    o  Path Computation Element (PCE) Communication Protocol (PCEP)
        [RFC5440] and GMPLS User-Network Interface (UNI) using RSVP-TE
        [RFC4208] do not use a modeling language to define the
        interface data. The data is transmitted as TLV-based, binary
        format.

    o  Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF
        Protocol [RFC8040] use XML and JSON encoded interfaces;
        gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses encoded,
        binary formatted, programmable interface; SNMP [RFC3417]
        [RFC3412] [RFC3414] has a binary formatted interface.

    o  For data modelling, YANG [RFC6020] [RFC7950] is used to model
        configuration and other data for NETCONF, RESTCONF, and GNMI
        among others. ProtoBufs are used to model gRPC data and GNMI
        data.  Structure of Management Information (SMI) [RFC2578]:
        Used to define the Management Information Base (MIB) modules
        for the SNMP protocol.  Its syntax is an adapted subset of
        OSI's Abstract Syntax Notation One, ASN.1 (1988).

    While several generic formats and data models for specific
    purposes exist, it is also expected that network slice creation
    may require augmentation of some of the existing data models.