Hey Benoit,
Thanks for the review.
> Figure 3: Network configuration model is a brand new term that is only
> mentioned
> in the figure, and not explained.
OMG! That is a good catch.
> In the same figure, could the "Device Configuration Model" be renamed to RFC
> 8199
> "Network Element YANG module" (this is what you did in figure 4 anyway)
I believe we are separating the "device configuration model" that is used to
talk to an NE, and a "network configuration model" used to talk to a controller
that is responsible for a set of NEs. I think the correct thing is to add
exactly that statement (i.e., a definition of the terms alongside figure 3).
Then the mapping of these terms should show up alongside Figure 4.
But, you know what?
Looking at this made me go back to Figure 1 of RFC8199 again. And finally I
understood it. That is probably a bit sad.
I had been misled (no blame associated) by the OSS/BSS box in the figure
because that is an entity not a module. That made me read the horizontal lines
as interfaces (over which the named module types are used) and the boxes as
functional units that consume the modules.
Now, that is a *horrible* misreading, but there we go! And RFC8199 has already
been published, so adding clarification so that fools like me are not confused
is not possible.
I believe the intention is to only show modules and not things that consume or
use modules.
So I wonder whether we should make some clarification in our Figure 4. Possibly
it should look like...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Operations Support and Business Support YANG Modules
+-----------------------+ +-----------------------+
| | | |
| Customer Service | | Other |
| YANG Modules | | Operations Support |
| | | and |
| +------+ +------+ | | Business Support |
| | | | | | | YANG Modules |
| | L2SM | | L3SM | | | |
| | | | | | | |
| +------+ +------+ | | |
| | | |
+-----------------------+ +-----------------------+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Service YANG Modules
+------------+ +-------------+ +-------------+ +-------------+
| | | | | | | |
| - L2VPN | | - L2VPN | | EVPN | | L3VPN |
| - VPWS | | - VPLS | | | | |
| | | | | | | |
+------------+ +-------------+ +-------------+ +-------------+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Element YANG Modules
+------------+ +------------+ +-------------+ +------------+
| | | | | | | |
| MPLS | | BGP | | IPv4 / IPv6 | | Ethernet |
| | | | | | | |
+------------+ +------------+ +-------------+ +------------+
The text in that section becomes...
<t>As previously noted, <xref target="RFC8199" /> provides a
classification
of YANG data modules. It introduces the term "Network Service YANG
Module" to
identify the type of module used to "describe the configuration,
state data,
operations and notifications of abstract representations of services
implemented
on one or multiple network elements." These modules are used to
construct the
service delivery models as described in this document; that is, they
are the
modules used on the interface between the Service Orchestrator or
OSS/BSS and
the Network Orchestrator as shown in <xref target="svc_arch" />.</t>
<t>Figure 1 of <xref target="RFC8199" /> can be modified to make
this more clear
and to add an additional example of a Network Service YANG module as
shown in
<xref target="modfig" />. As can be seen, the highest
classification of modules
collects those that are used to deliver operations support and
business support.
These might be consumed by an Operations Support System (OSS) or a
Business Support
System (BSS), and a Service Orchestrator may form part of an OSS/BSS
or may be a
separate component. This highest layer in the figure is divided
into the Customer
Service Modules that are used to describe services to a customer as
discussed in
this document, and other modules that describe further OSS/BSS
function such as
billing and SLAs.</t>
> - section 6.2 "service delivery and network element model work"
>
> Some
> of these models are classified as service delivery models, while
> others have details that are related to specific element
> configuration and so are classed as network element models (also
> called device models).
>
> Next to each model description, that would help the audience to clarify what
> the correct term is:
> customer service model, service delivery model, network service YANG modules
> [RFC8199]
I agree, but we have made a conscious decision to not do that
*in*this*document*. None of the models in 6.2 is a customer service model (so
that part is easy), but beyond that we could not get coherent advice from the
authors of the listed documents. Most were pretty certain that their work was
"mainly network element model" although some thought that they were dealing
with "network wide configuration" and a few thought they were "delivering
services".
While it would be good to get more clarity on this, it looks like we are trying
to retrofit an architecture on an organically evolved set of modules and
perhaps we shouldn't push too hard. What is important in this document is to
get the "Customer Service Model" piece more clearly explained.
> In RFC 8199, we made a distinction between model and YANG modules. This is
> why we defined
> the terms "Network Service YANG modules" and "Network Element YANG modules"
> and not models.
> You should follow this convention. After all, from the abstract, this
> document focuses on YANG.
> Ex: should "model" be replaced by "YANG module"?
The definition imported from 7950 by 8199 looks like a reasonable distinction
and we will attempt to apply it here. I hope I am not importing too much
thought from SMI but isn't a "model" built from one or modules? A model is used
to "model" some larger entity or function, while a module is used to describe a
component of an entity or a granular function.
Probably just some cleanup needed through this document. I'll have a go.
> - section 6.4 "The MEF architecture".
> Do we want to mention that MEF currently focuses on the customer service
> model?
We could do this, but...
Not so happy to use "currently" in an archival document.
Also not comfortable about asserting in an IETF document what another body is
doing.
And not convince that the MANO architecture is focused in the way you describe.
So I prefer no change for this.
> - I'm glad you cleverly avoided the term "intend"
That was intentional :-)
Thanks,
Adrian
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
