Re: [alto] New Version Notification for draft-lachosrothenberg-alto-brokermdo-01.txt

["Y. Richard Yang" <[e-mail]>]

Dear Danny, Christian,

I started to read this draft. It addresses an important, timely issue.
Below is the first part (on Sections 1-6) of my review, and I will send the
second part on Sections 7-9 by tomorrow.

Great work!
Richard

====
Existing proposals for the network service orchestration are
   intrinsically conceived for single administrative domain scenarios.

     [yry] Add citations right after existing proposals?

   For example, in the standard service orchestration model described in
   ETSI NFV MANO framework [ETSI-NFV-MANO], one orchestrator is supposed to
work within one administrative domain.  The analysis of
   orchestration and management of network Services over multiple

     [yry] case, network vs Services

   administrative domains have begun to be addressed by ETSI
   in [ETSI-NFV-MANO-MDO].

     [yry] The last sentence gives a related work. To make reading easier,
     it may help to differentiate between proposals (first sentence) and
analysis (this sentence).

   All such proposals described above envision the potential
   introduction of new business model approaches, including federation
   models [PPP-5:2013] among administrative domains.  In this context,
   this document considers each network operator involved in the
   community advertises its abstracted capabilities (e.g., software/
   hardware resources, physical/virtual network functions, etc.) to a
   broker (i.e., 3rd party).  This latter, in its turn, provides or

     [yry] latter -> broker

   assists coordinate E2E network services spanning multi-domain
   networks.

5.  Problem Statement and Challenges

   The provision of a complete E2E network service requires chaining
   services provided by multiple network operator with multiple

     [yry] operator -> operators

   technologies.  In this multi-domain environment, the orchestration
   process will require an advertise mechanism through which single

     [yry] advertise -> advertisement, single -> individual

   domains can describe their capabilities, resources, and VNFs in an
   interoperable manner.  Moreover, a discovery mechanism is also
   necessary so that source domains can obtain candidate domains (with

     [yry] Although one can infer what source/candidate domains mean,
     it can help if you define them.

   the corresponding connectivity information) which can provide a part
   of the service and/or slide in an E2ENS requirement.

     [yry] slide -> slice?

   In order to the advertising and discovery process works in a proper
   way, a number of challenges can be identified:

     [yry] "In order to" -> "In order that"

   Lack of Abstractions:  Multiple vendors with heterogeneous
        technologies need an information model to adequately represent
        in confidentiality-preserving fashion the resource and topology
        information.

   Scalability:  Involves the distribution of topology and resource
        information in a peer-to-peer fashion (MdO-to-MdO).  Multi-

     [yry] Note that the previous item mentions generic information model
     but here mentions only topology and resource information. It can help
if
     the scoping is clarified up front: only topology/resource.

        operator multi-domain environments where the information
        distribution is advertised in a peer-to-peer model scales
        linearly.  It means more MdO interconnections one has, the more

      [yry] Why linearly? There can be ambiguity. Assume the total
      transmission load of one domain grows linearly with n, which is
      the number of domains. Total system scales w/ n^2. But there can be
other peer-to-peer systems such as CHORD which publish
(advertises) with a constant cost. It helps to specify some more details.

        it "costs" to distribute.

   Flexibility:  Considers that a distributed approach does not allow
        domains without physical infrastructure (e.g., without BGP or
        BGP-LS) to advertise resource capabilities and networking
        resources.  Such procedures consist in deploying and configuring
        physical peering points for these domains.

     [yry] The description above is not clear to me yet. One can run BGP
w/o a physical infrastructure. It helps if you can clarify this challenge.

   Complexity:  Refers to the discovery mechanism to pre-select
        candidate domains, accounting for resources and capabilities,
        necessary for an E2E network service deployment.  An intrinsic
        complexity exists in the process of assembling, logically
        organizing, and enabling abstraction views of different
        resources and capabilities in multi-domain scenarios.

    [yry] A summary comment on the 4 items. Are they challenges, issues
    or requirements? The wording appears to have multiple aspects: lacking
    of abstractions seems to imply issues; flexibility seems to imply
    requirements... Is the set complete, for example how about security,
autonomy, privacy ...---some you touch right below?  One more comment is
that the terms used (e.g., flexibility) can be too generic. If you go a bit
more specific, for example, Discovery Flexibility, it may help.

====

On Mon, Jul 2, 2018 at 8:25 PM Danny Alex Lachos Perez <[e-mail]>
wrote:

> Dear WG members
>
> This new version (-01) considers a section on benefits and open questions
> (section 7) where we analyze the advantages and open issues in the
> broker-assisted architecture. Moreover, we removed the Property Map
> Extension section because the current Property Map draft [0] already
> supports property values encoded as JSONArray.
>
> Other changes include (i) update the Problem Statement and Challenges
> section and (ii) many minor style and grammar edits.
>
> Comments and feedback will be highly appreciated.
>
> Thank you very much
>
> [0]
> https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-04#section-4.6
>
> Ss
>
> Danny Lachos
>
> On Mon, Jul 2, 2018 at 4:18 PM <[e-mail]> wrote:
>
>>
>> A new version of I-D, draft-lachosrothenberg-alto-brokermdo-01.txt
>> has been successfully submitted by Danny Alex Lachos Perez and posted to
>> the
>> IETF repository.
>>
>> Name:           draft-lachosrothenberg-alto-brokermdo
>> Revision:       01
>> Title:          ALTO-based Broker-assisted Multi-domain Orchestration
>> Document date:  2018-07-02
>> Group:          Individual Submission
>> Pages:          22
>> URL:
>> https://www.ietf.org/internet-drafts/draft-lachosrothenberg-alto-brokermdo-01.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-lachosrothenberg-alto-brokermdo/
>> Htmlized:
>> https://tools.ietf.org/html/draft-lachosrothenberg-alto-brokermdo-01
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-lachosrothenberg-alto-brokermdo
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-lachosrothenberg-alto-brokermdo-01
>>
>> Abstract:
>>    Evolving networking scenarios (e.g., 5G) demand new multiple
>>    administrative domain (aka multi-domain) orchestration models.  This
>>    document proposes the use of Application-Layer Traffic Optimization
>>    (ALTO) services to offer topology and resources addressing network
>>    service discovery and provisioning by multi-domain orchestrators.
>>    The ALTO services with the proposed protocol extension offer
>>    aggregated views on various types of resources contributing to a more
>>    simple and scalable solution for resource and service discovery in
>>    multi-domain, multi-technology environments.
>>
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>


-- 
-- 
 =====================================
| Y. Richard Yang <[e-mail]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================