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 <[email protected]>
> Sent: 28 September 2020 23:25
> To: [email protected]
> Cc: [email protected]; [email protected]
> 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
>
>
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
