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

[Dan Romascanu <[e-mail]>]

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 <[e-mail]>
wrote:

> Hi Dan,
>
> Thanks for your feedback. See my response inline.
>
> On Wed, Apr 26, 2023 at 3:25 PM Dan Romascanu <[e-mail]> 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 <[e-mail]>
>> 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 <
>>> [e-mail]> 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
>
>>