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

Dan Romascanu <dromasca@gmail.com> Thu, 27 April 2023 07:24 UTC

Return-Path: <dromasca@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 6178FC1516E2; Thu, 27 Apr 2023 00:24:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.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_NONE=-0.0001, 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 JNtl-rBcTTpQ; Thu, 27 Apr 2023 00:24:29 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 AB226C15153F; Thu, 27 Apr 2023 00:24:29 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2ab3cff654dso907111fa.1; Thu, 27 Apr 2023 00:24:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682580267; x=1685172267; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Mi2BV8paBNhZ0k7tURTUanJJDGDytIzjPjDByeKTH7I=; b=c+jtSqnakxCBn595/RjpamYzIVt6rbrmXuaqProQuhJZQO3RkCz6NqZVMegF2Gj6Nd lyVCVIq0cPmsaZ8NV27WbCl3wzi+jQOgCmGqEhZyVQxYixGJpgCLje/o9f5tLxVfdNnV cGsGHcAzJyz+0SV2YHXIZz53J0mxv4vtSi849ZjwiS0xCyJMErcAnVrBKC1eulCMq8nn gEasH+RCBLypx4VKktjDQION4s8syAglHCZPwBeM8Cn4CZBzdafMoBERcB64M6sgN6LQ dMi8MsXE+h8iEjHtXumkD0NfbEZwBfb2BQHFhS2RBzzDkaV91XzWYPITgnHy0s0jmiH7 eeBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682580267; x=1685172267; 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=Mi2BV8paBNhZ0k7tURTUanJJDGDytIzjPjDByeKTH7I=; b=OvOhDtHrAc2k7OI2C1dOQmO2bXluHxuWBKxZ3ajP1j18DJ8sk7c21y1RdV/NIEljRZ gRvbu+zVk6GMJW4fFllbC3xl2Nl78+mbte5T47ahQCYkzoIe7lOxPmC3WkhyhPMBYIM+ 9n3k6ChKBXIrvXm6srGFJ6YLqqNk9OeRlYiUSqzcJTJwWINwT2Y+QlhiC5IIWAS1somY g8hzqwDpcrtPQUdJIHbxNXqnn1Y9ytsIeMRB6bSYBQc24gMjUbrzz/P1NURN8clR3NVk ye821mccyq5UAK7gIx5kUMpT6c+3Ejaa8fjBZBuRDi3EJh8BRFMgSOpePyWqCMINXwOl s/ng==
X-Gm-Message-State: AC+VfDzjl3jIvKlYp+vqCWz7Cabjsv2oWrclcyBRIgLDoUu62fSkQ88f iA8RaipopENXTQQ0KAS9KXfrAlpzbRY2U3g9ImWhGqjV
X-Google-Smtp-Source: ACHHUZ4DPEWzPFftBqSMc6SMOefjRc4VtOknC/y181kYSizFDjgDcocXAWUvrK7im3JBL9+QhnNm0xpB/h3WhZ7IGpE=
X-Received: by 2002:a2e:b890:0:b0:295:a08c:12a1 with SMTP id r16-20020a2eb890000000b00295a08c12a1mr330245ljp.0.1682580266784; Thu, 27 Apr 2023 00:24:26 -0700 (PDT)
MIME-Version: 1.0
References: <168206401546.30918.7998792221903169633@ietfa.amsl.com> <CAAbpuypG54s4JOo3irhYZ9VXTXpDAWxntWVdGORSW0RsTKbgJw@mail.gmail.com> <CAFgnS4W2jaSgk_U3rmSNSugqEwqTx2CZk1NESB2AfObTMSztsg@mail.gmail.com> <CAAbpuyqzB1TyRcEsKQSCS1HZNUs6FMz+ey9_++RARfwGYsynNA@mail.gmail.com>
In-Reply-To: <CAAbpuyqzB1TyRcEsKQSCS1HZNUs6FMz+ey9_++RARfwGYsynNA@mail.gmail.com>
From: Dan Romascanu <dromasca@gmail.com>
Date: Thu, 27 Apr 2023 10:24:15 +0300
Message-ID: <CAFgnS4VFRDoTbhm_GkDdx6uF8qfEL3w7fYB=dFg_SreP97_78A@mail.gmail.com>
To: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Cc: ops-dir@ietf.org, alto@ietf.org, draft-ietf-alto-oam-yang.all@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001b9e9405fa4c3fe9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/hC6MTXuM9FIq5fYBEQlpCPoz7LQ>
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: Thu, 27 Apr 2023 07:24:33 -0000

Thanks for the clarification and for addressing my comment. The proposed
change looks good to me.

Regards,

Dan


On Thu, Apr 27, 2023 at 2:29 AM Jensen Zhang <jingxuan.n.zhang@gmail.com>
wrote:

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