Hi Med, see below...
On 29-Sep-20 18:40, [email protected] wrote:
> Hi Brian,
>
> Please see inline.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Brian E Carpenter [mailto:[email protected]]
>> Envoyé : mardi 29 septembre 2020 00:25
>> À : [email protected]
>> Cc : [email protected];
>> [email protected]
>> 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.
>
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
