Re: [OPSAWG] Last Call: <draft-ietf-opsawg-model-automation-framework-06.txt> (A Framework for Automating Service and Network Management with YANG) to Informational RFC

[Brian E Carpenter <[e-mail]>]

Hi Med, see below...
On 29-Sep-20 18:40, [e-mail] wrote:
> Hi Brian, 
> 
> Please see inline.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Brian E Carpenter [mailto:[e-mail]]
>> Envoyé : mardi 29 septembre 2020 00:25
>> À : [e-mail]
>> Cc : [e-mail];
>> [e-mail]
>> Objet : Re: Last Call: <draft-ietf-opsawg-model-automation-
>> framework-06.txt> (A Framework for Automating Service and Network
>> Management with YANG) to Informational RFC
>>
>> Hi,
>>
>> I have a question for clarification, and then a comment.
>>
>> First, consider these extracts:
>>
>>> 5.1.  L2VPN/L3VPN Service Delivery
>>>
>>>    In reference to Figure 5, the following steps are performed to
>>>    deliver the L3VPN service within the network management
>> automation
>>>    architecture defined in this document:
>>>
>>>    1.  The Customer requests to create two sites (as per service
>>>        creation operation in Section 4.2.1)...
>> ...
>>> 5.2.  VN Lifecycle Management
>>>
>>>    In reference to Figure 7, the following steps are performed to
>>>    deliver the VN service within the network management automation
>>>    architecture defined in this document:
>>>
>>>    1.  Customer requests (service exposure operation in Section
>> 4.1.1)
>>>        to create 'VN' based on Access point...
>> ...
>>>    3.  The Customer exchanges connectivity-matrix on abstract node
>> and
>>>        explicit path using TE topology model with the
>> orchestrator...
>>
>> In those examples, how does the customer "request" or "exchange"
>> data? I assume this is intended to happen by software, rather than
>> by telefax. 
> 
> [Med] We hope this can be by software if we want to benefit from the automation in the full cycle but the approach still apply independently how a service request is captured. 
> 
> We don't zoom that much on that interface because the document is more on the provider's side.
> 
>> So what protocol is involved, and which entity on the
>> customer side is doing it?
> 
> [Med] The component at the client side are generally represented as service ordering (see RFC 4176). That component may interact with the Order Handling at the provider side using a variety of means such as https://www.rfc-editor.org/authors/rfc8921.txt (Section 5) or by offering a management interface to the customer, etc. 

Well, I'd rather see a standardised and generic solution to that problem, as noted in my reply to Adrian. But indeed, that is the requirement.
 
> Please let us know if you think that we need to add some text on this part.

I think it needs just a few words in section 3 or 4, even just to say that the mechanism is out of scope for this document.

> 
>>
>>> 5.3.  Event-based Telemetry in the Device Self Management
>>>
>>>    In reference to Figure 8, the following steps are performed to
>>>    monitor state changes of managed objects or resources in a
>> network
>>>    device and provide device self-management within the network
>>>    management automation architecture defined in this document:
>>>
>>>    1.  To control which state a network device should be in or is
>>>        allowed to be in at any given time, a set of conditions and
>>>        actions are defined and correlated with network events
>> (e.g.,
>>>        allow the NETCONF server to send updates...
>>
>> Second, this is the first mention of NETCONF in the document, and
>> the only other mention is in the Security Considerations. I suggest
>> that there should be a short description of the role of NETCONF (and
>> RESTCONF) earlier in the document, either in section 3 or more
>> likely in section 4 (Functional Blocks and Interactions).
> 
> [Med] Point taken. We will also clarify that in some cases the use of YANG does not require NETCONF/RESTCONF. 

Thanks. (For example, draft-ietf-anima-grasp-distribution can serve for distributing YANG.)

    Brian
> 
>>
>> Regards
>>    Brian Carpenter
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>