Re: [alto] Opsdir early review of draft-ietf-alto-oam-yang-06

Jensen Zhang <jingxuan.n.zhang@gmail.com> Wed, 26 April 2023 23:29 UTC

Return-Path: <jingxuan.n.zhang@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057F2C1519BF; Wed, 26 Apr 2023 16:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.094
X-Spam-Level:
X-Spam-Status: No, score=-7.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqO1ddDrm-2g; Wed, 26 Apr 2023 16:29:19 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB46C1519BA; Wed, 26 Apr 2023 16:29:19 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-3f09b4a1584so53579075e9.2; Wed, 26 Apr 2023 16:29:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682551758; x=1685143758; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MIQGRDWh9eDG9LvCfM0qC9wgG8OR/hqrUHd/mxcsPag=; b=bp7cAYeXsmQlCBLeKs4rGVNhMWLCxCxqmWlJM9XPZE6wWyweIY0XMO/4Qf5yUxYbbh aaUzqHpY2/J1cexa6Q8kayjzhXABmlayNTJTt/zxWXJiUmhBZPPvQjmaQlTgZT+iSFgT yh1lxUo0jVSYWoCQXjcAwuNmZjrMLY3kMIns2yaIJXjwz6Qa0jfvML8dAtrnitAtw/x5 DSjlBv9X0OqW7bFDmhjFhqGG85PBET5d5afa3CWcnSg0j/lwvSLr+GuyW1aE354YHEP+ VaLuwwh4S4qC4scMkimD0cz36hg8FL1J20uhZI+K4r6i1OOUJOT1fu2DglT9uiooUwvA xSlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682551758; x=1685143758; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MIQGRDWh9eDG9LvCfM0qC9wgG8OR/hqrUHd/mxcsPag=; b=B7LeykUcJ/rm1WGI2V/j0zYtjQ355bx7b+zjfSMmQ1TnLbl9IJt/JEkOm4l67fwhVJ 43jvK6gmn27iA2AmmKE7NOawd/Ro6NevSuUuYep5Od4jEROVJ04Ll4r+Ztya02/sOThP ceNZ8Ptc7iY9F1kzmhfzBDDuMnFWap+5EIV3gvue499SVCRMRT6jU15vzZ5Eq0VmgRZ4 jtXuRXt3zXv6Sx5cpIHBzLnL2f4mwrgjwDfbMZEHzXIuxuZRVihnso0eQycGIXQLi8gZ iR2D2Mnog4fQNaA8Ui66oqx95FWcXTdk4apR9UlSbnOVbNcwH3cL5OGdI9hKrKB1eDyY oQ5w==
X-Gm-Message-State: AAQBX9d4a6Mp8FNKGzitoCUvMRRB1n/ZkW502RCuDiGNs5r6nhUX8VeX BivVT4XtGQOD+yImoEb5VbJopLnGBLLdeT3ynX5nxIrgdww=
X-Google-Smtp-Source: AKy350aOswW2iLsPXJzGH9v9Z8cZVNJC5u/ty7CLpjTgZvjUx6lrXHfQVHp9MdyNta/BN4+gYgwt/1e6wFPDm1mBzxE=
X-Received: by 2002:a7b:c7cd:0:b0:3f2:549b:3ede with SMTP id z13-20020a7bc7cd000000b003f2549b3edemr6446107wmk.5.1682551757424; Wed, 26 Apr 2023 16:29:17 -0700 (PDT)
MIME-Version: 1.0
References: <168206401546.30918.7998792221903169633@ietfa.amsl.com> <CAAbpuypG54s4JOo3irhYZ9VXTXpDAWxntWVdGORSW0RsTKbgJw@mail.gmail.com> <CAFgnS4W2jaSgk_U3rmSNSugqEwqTx2CZk1NESB2AfObTMSztsg@mail.gmail.com>
In-Reply-To: <CAFgnS4W2jaSgk_U3rmSNSugqEwqTx2CZk1NESB2AfObTMSztsg@mail.gmail.com>
From: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Date: Thu, 27 Apr 2023 07:29:05 +0800
Message-ID: <CAAbpuyqzB1TyRcEsKQSCS1HZNUs6FMz+ey9_++RARfwGYsynNA@mail.gmail.com>
To: Dan Romascanu <dromasca@gmail.com>
Cc: ops-dir@ietf.org, alto@ietf.org, draft-ietf-alto-oam-yang.all@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d14ce005fa459b7a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/VL3eI8vGRDgy2kyjM8PLZL4qZN0>
Subject: Re: [alto] Opsdir early review of draft-ietf-alto-oam-yang-06
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Apr 2023 23:29:23 -0000

Hi Dan,

Thanks for your feedback. See my response inline.

On Wed, Apr 26, 2023 at 3:25 PM Dan Romascanu <dromasca@gmail.com> wrote:

> Hi Jensen,
>
> Thank you for your email and for addressing my comments.
>
> See in-line.
>
> Regards,
>
> Dan
>
>
>
>
> On Tue, Apr 25, 2023 at 4:01 PM Jensen Zhang <jingxuan.n.zhang@gmail.com>
> wrote:
>
>> Hi Dan,
>>
>> Sorry for the delay. Many thanks for your review. Please see our response
>> inline below.
>>
>> On Fri, Apr 21, 2023 at 4:00 PM Dan Romascanu via Datatracker <
>> noreply@ietf.org> wrote:
>>
>>> Reviewer: Dan Romascanu
>>> Review result: Has Nits
>>>
>>> Ready with Nits
>>>
>>> This document defines YANG data models for Operations, Administration,
>>> and
>>> Maintenance (OAM) & Management of ALTO. The operator can use these data
>>> models
>>> to set up an ALTO server, create, update and remove ALTO information
>>> resources,
>>> manage the access control, configure server discovery, and collect
>>> statistical
>>> data.
>>>
>>> I like this document. It is clearly written and very well structured. I
>>> liked
>>> the description of requirements, the information model corresponding to
>>> the
>>> requirements, and the extension example modules in the Appendices. These
>>> are
>>> all very useful for operators who need to understand and use the YANG
>>> modules.
>>>
>>> Understanding and using this document requires a good knowledge of ALTO.
>>>
>>> My review is focused on the design and data modelling issues relevant for
>>> operations and manageability. I did not perform a YANG review, I assume
>>> that
>>> YANG Doctors review is performed separately.
>>>
>>> This document is Ready with a couple of editorial comments.
>>>
>>> Editorial & Nits:
>>>
>>> 1. There are many more acronyms not included in Section 3 or expanded at
>>> first
>>> occurrence. Maybe the respective acronyms sections in the ALTO documents
>>> should
>>> be mentioned / referred
>>>
>>
>> Thanks for pointing out this issue. We have included all the acronyms
>> that occur in the document in Sec 3. You can check the changes in our early
>> edit [1].
>>
>> [1]:
>> https://ietf-wg-alto.github.io/draft-ietf-alto-oam-yang/draft-ietf-alto-oam-yang.html#name-acronyms-and-abbreviations
>>
>> But we are not sure if the acronyms that only occur in the YANG modules
>> should also be included.
>>
>
> I believe that the answer is yes. There is no other separate abbreviations
> section for the YANG modules.
>
>
>
>>
>>
>>>
>>> 2. In Section 5.3.1.2
>>>
>>> > In practice, multiple ALTO servers can be deployed for scalability.
>>>    That may require communication among different ALTO servers.
>>>
>>>    The "ietf-alto" module does not contain any configuration for the
>>>    communication between peer ALTO servers.  Instead, it provides the
>>>    configuration for how an ALTO server can be discovered by another
>>>    ALTO server on demand (Figure 6).
>>>
>>> I understand that the communication between ALTO servers is out of scope.
>>> However, I do not understand how is the scalability requirement met. Is
>>> there /
>>> Will there be another YANG module to define this data model? Something
>>> else
>>> than YANG? Maybe this is described in another ALTO document that I did
>>> not find.
>>>
>>
>> The scalability requirement is not explicitly defined in this document.
>> It looks like a part of R1 but is not mandatory.
>>
>> And I am not quite sure what is the scalability requirement that you
>> mentioned here. There can be two kinds of scalability issues:
>>
>> 1. The scalability of a large number of network domains and elements.
>> This issue requires the deployment of multiple ALTO server instances in
>> different domains and communications among different ALTO servers in
>> different domains. WG is still discussing the related topic [2]. The
>> solution is not mature. So we consider it to be out of the scope of this
>> document.
>>
>> [2]:
>> https://mailarchive.ietf.org/arch/msg/alto/Hpay0QShfob_3LR7ERfpIjXvGI0/
>>
>> 2. The scalability of a large number of client connections. i.e., the
>> load balance issue. This may need some autoscaling or load-balancing
>> configuration parameters. Is this what you want to add?
>>
>
> I was referring to the scalability issue mentioned in the document in the
> sentence 'In practice, multiple ALTO servers can be deployed for
> scalability.'. This seems to be related to issue #1 in your answer. If the
> solution is considered not mature at this stage, maybe you should mention
> just that in the document, to explain why it is out of scope.
>

Thanks for your clarification. I think the "scalability" in the original
text may be ambiguous. We made the following change:

OLD:

   In practice, multiple ALTO servers can be deployed for scalability.
   That may require communication among different ALTO servers.

   The "ietf-alto" module does not contain any configuration for the
   communication between peer ALTO servers.  Instead, it provides the
   configuration for how an ALTO server can be discovered by another
   ALTO server on demand (Figure 6).

NEW:

   In practice, for a large-scale network consisting of multiple
   administrative domains, the information about the network may be
   partitioned and distributed over multiple ALTO servers.  That may
   require discovery and communication among different ALTO servers.

   The "ietf-alto" module provides the configuration for how an ALTO
   server can be discovered by another ALTO server or client on demand
   (Figure 6).  But it does not contain any configuration for the
   communication among ALTO servers because the related solution has not
   become a standard.  Future documents may extend it to fully support
   multi-domain scenarios.

Does the changed text address your concern?

Thanks,
Jensen

>