On 29-Sep-20 22:22, Adrian Farrel wrote:
> Hi Brian,
>
> I'll let the authors answer in more detail, but when we started the L3SM work we were by no means certain that an automated software approach would be adopted to requests by customers for service provision. The intent, therefore, was to represent the service via a data model that would be equally clear to the customer and the service provider. Communication could be on paper, via email, on a web form, or using Netconf (or, as you say, using telefax).
>
> But this document is about the automation of network management, so we should assume that there is a protocol-based solution to the question. I think the authors will respond "Netconf" and that will mean that your second point is right - there should be a little bit more about the use of Net/Restconf in the document.
I'm not completely sure Netconf is the right answer, but then, I'm a protagonist of ANIMA, which would certainly be another possible answer in the long term. Once we get the base ANIMA documents out I think there needs to be a conversation about exactly how ANIMA, NETCONF and YANG interact. (I'm thinking that an autonomic service agent on the customer side would negotiate with one on the provider side, and that would trigger the requisite actions as defined in the present document.)
Regards,
Brian
>
> Best,
> Adrian
>
> -----Original Message-----
> From: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>
> Sent: 28 September 2020 23:25
> To: last-call@xxxxxxxx
> Cc: draft-ietf-opsawg-model-automation-framework.all@xxxxxxxx; opsawg@xxxxxxxx
> Subject: 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. So what protocol is involved, and which entity on the customer side is doing it?
>
>> 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).
>
> Regards
> Brian Carpenter
>
>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
