Hi,
I've reviewed this document in working group last call and support its
publication. I found the Appendix particularly helpful.
I have some minor thoughts that the authors may want to consider as the
document moves forward.
Thanks,
Adrian
==
idits says that draft-ietf-dots-data-channel has been published as
RFC 8783
---
The Abstract is a little longer than the recommended maximum length of
20 lines. Maybe reduce the first paragraph to:
Data models provide a programmatic approach to represent services and
networks. They can be used to derive configuration information for
network and service components, and state information that will be
monitored and tracked. Data models can be used during the service
and network management life cycle, such as service instantiation,
provisioning, optimization, monitoring, diagnostic, and assurance.
Data models are also instrumental in the automation of network
management, and they can provide closed-loop control for adaptive and
deterministic service creation, delivery, and maintenance.
---
Section 1
s/requirements and order/requirements and orders,/
s/operating in a silo/operate in a silo/
s/providers'savoir-faire/providers' savoir-faire,/
s/first tentative/first tentative attempt/
YANG [RFC7950] module developers have taken both top-down and bottom-
up approaches to develop modules [RFC8199] and to establish a mapping
between a network technology and customer requirements on the top or
abstracting common construct from various network technologies on the
bottom.
s/construct/constructs/
s/on the/at the/ (twice)
---
Section 1
other Standards Developing
Organizations (SDOs) (e.g., MEF)
It's not clear to me why you cite MEF as an example of another SDO. I
don't think you mean to be judgemental (i.e., saying that you would have
expected MEF to have done this) so it is probably best to leave that out
---
Section 2
I don't object to your definitions of Network Model and Device Model,
but I wondered why you chose not to use or reference Network
Configuration Model and Device Configuration Model from RFC 8309.
---
Section 3.1
Figure 1 depicts the example of a VoIP service provider that relies
upon connectivity services offered by a Network Operator.
But Figure 1 actually uses the terms "Provider" and "SP". It might be
helpful to clarify in the text (the paragraph before the figure) whether
the two "SP sites" and the "Provider" are all under the control of the
"Network Operator" while the "Internet" is of broader scope.
---
Section 3.3
To operate a service, Device Models derived from Service Models and/
or Network Models can be used to provision each involved network
function/device with the proper configuration information, and
operate the network based on service requirements as described in the
Service Model(s) and local operational guidelines.
It seems to me that you are describing a top-down approach to the
construction of data models. But, in practice, isn't it the case that
Device Models are derived from the nature of the devices being managed
in a bottom-up approach. Thus there is a challenge of "meeting in the
middle" as the top-down service models meet the bottom-up device models.
Perhaps this issue is resolved by...
To operate a service, the settings of the parameters in the Device
Models are derived from Service Models and/or Network Models and are
used to provision each involved network function/device...
---
Section 4
s/led to the/lead to the/
---
Can I be so bold as to suggest some changes to Figure 4?
Changes include:
- Minor updates to spacing to make arrows clearer
- Arrow end where path joins E2E Service Assurance to E2E Service
Diagnostics
- Remove path cross-over in paths from Specific Service Assurance
- Arrow end where path joins Specific Service Assurance to Specific
Service Optimization
- Dotted lines to separate the different levels and moved the names of
the levels inside the boundaries.
+------------------+
................. | |
Service level | |
V |
E2E E2E E2E E2E
Service --> Service ---------> Service -----> Service -----+
Exposure Creation ^ Optimization ^ Diagnosis |
/Modification | | |
| |Diff | V
Multi-layer | | E2E | E2E
Multi-domain | | Service | Service
Service Mapping| +------ Assurance --+ Decommission
| ^
................ |<-----------------+ |
Network level | | +-------+
V | |
Specific Specific |
Service --------> Service <--+ |
Creation ^ Optimization | |
/Modification | | |
| |Diff | |
| | Specific --+ |
Service | | Service |
Decomposing | +----- Assurance ----+
| ^
................ | | Aggregation
Device level | +------------+
V |
Service Intent |
Fullfillment Config -----> Config -----> Performance ---> Fault
Provision Validate Monitoring Diagnostic
---
Section 4.1.2
Upon receiving a service request, the service orchestrator/management
system should first verify whether the service requirements in the
service request can be met (i.e., whether there is sufficient
resources that can be allocated with the requested guarantees).
It may sound "obvious" but I think there is an authentication and
authorisation step first. Is the user who they say they are? Are they
allowed to request the service they are asking for?
It would be worth mentioning this in Section 6 as well.
---
Section 4.1.3
s/feed/fed/
---
Section 4.3
in Traffic Engineering Architecture and Signaling
(TEAS) VN model [I-D.ietf-teas-actn-vn-yang]
I think you should use the name of the model as given in the referenced
document.
---
Section 5.1
You use L3NM without expansion or a reference
I think it might be helpful to know where the model in [I-D.ogondio-
opsawg-uni-topology] fits in the context of Figure 5.
---
Figure 5
OLD
| +-----V- -------+ |
NEW
| +-----V---------+ |
OLD
+-------------++---------- ++--------------------+
NEW
+-------------++------------++--------------------+
OLD
+--+--+ +++---+ --+---+ +--+--+
NEW
+--+--+ +-+---+ +-+---+ +--+--+
OLD
| CE1 -------| PE1 | | PE2 | ---------+ CE2 |
NEW
| CE1 +------+ PE1 | | PE2 +-----------+ CE2 |
---
Figure 6
OLD
+-------------++---------- ++--------------------+
NEW
+-------------++------------++--------------------+
OLD
+--+--+ +++---+ --+---+ +--+--+
NEW
+--+--+ +-+---+ +-+---+ +--+--+
OLD
| CE1 |------| PE1 | | PE2 | ---------+ CE2 |
NEW
| CE1 +------+ PE1 | | PE2 +-----------+ CE2 |
---
Figure 7
OLD
+----------------------V--------------------+----+
NEW
+----------------------V--------------------+-----+
OLD
| CE1 |------| PE1 | | PE2 |---------+ CE2 |
NEW
| CE1 +------+ PE1 | | PE2 +---------+ CE2 |
---
Appendix A
It is not the intent of this appendix to provide an inventory of
tools and mechanisms used in specific network and service management
domains; such inventory can be found in documents such as [RFC7276].
It is OK to say what this appendix is not, but it might be useful to
also say what it is. Also to note that the appendix is non-normative.
From: OPSAWG <[email protected]> On Behalf Of Tianran Zhou
Sent: 01 June 2020 03:25
To: [email protected]
Cc: OpsAWG-Chairs <[email protected]>
Subject: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03
Hi WG,
The authors requested the WG last call. And we think this draft is mature
and stable. We start a two week last call for this draft.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framewor
k/
Please send your comments stating whether you believe the document is ready
for publication.
If not, please explain why not and provide comments to improve this
document.
Thanks,
Tianran and Joe
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
