Hi Adrian,
> 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.
ok.
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, thatis 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>
Fine with me.
> - 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 understand the difficulty and the conscious decision.
This is however the first question readers will ask themselves, and the
conclusion that the experts could find the answer is not a good sign.
Anyway, let's move on.
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.
Fair enough.
Regards, Benoit
> - 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
