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

[Qin Wu <[e-mail]>]

Hi,
-----邮件原件-----
发件人: Brian E Carpenter [mailto:[e-mail]] 
发送时间: 2020年9月30日 3:55
收件人: [e-mail]; [e-mail]
抄送: [e-mail]; [e-mail]
主题: 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 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.)

[Qin]: Thanks Brian for heads up. I think what Med mean is YANG doesn't need to tie with NETCONF, or RESTCONF, it could be also work with gRPC.
YANG is transport independent data modeling language.
One motivation to write this draft is to focus on management plane approach and build fully automated YANG based system. I am not sure grasp can be used to distribute YANG.
My impression of information distribution is used to distribute information between autonomic nodes in the data plane, that is not in the scope of this document,
If my understanding is correct. But I agree with you we could investigate how YANG, ANINMA, NETCONF work together. That's a very interesting topic.

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