Apologies for the lengthy delay in performing the AD review.
I found that this document to be well written so I would like to thank the
authors, WG, and doc shepherd for that. My more significant comments relate to
questions on the scope of this architecture.
More significant comments:
1. By "Data Model" does this document mean "YANG data model"? And if so, does
it take this meaning all through this document, or only some of the time?
2. Generically, service data models are not necessarily written in YANG (e.g.,
I think that MEF are defining them using OpenAPI). So, related to (1), is this
architecture intended to be tied to only service models defined in YANG, or be
more broadly applicable?
3. This architecture seems to quite strictly represent 3 layers (service,
network, device). Does it envisage that these layers may themselves be
deconstructed? E.g. a customer service can be constructed from underlying
services (e.g., as discussed in section 3.1, but more as an East-West
relationship). Similarly, device models could also be deconstructed, e.g., if
the dataplane is decoupled from the control plane, or if a device itself acts
as a controller managing other devices.
4. My minimal understanding of the MEF LSO architecture was that they put quite
a lot of emphasis on East-West models, probably at the service layer. Is this
effectively the same as what is described in Figure 1 in section 3.1? Does the
potential existence of these East-West APIs need to be described in any more
detail?
Minor comments/clarifications:
Section 3.1: Data Models: Layering and Representation
5. Network Models are mainly network resource-facing modules; they
describe various aspects of a network infrastructure, including
devices and their subsystems, and relevant protocols operating at the
link and network layers across multiple devices (e.g., network
topology and traffic-engineering tunnel modules).
Would it be fair to say that Network Models might be protocol specific, or
might be generalized? If so, is that worth mentioning?
6. Re: DOTS & RFC 8783, I'm not sure how well the YANG model defined in that
drafts fits into the category of Service YANG model.
7. Pipe vs hose vs funnel. Are these terms, or do they need to be, defined
somewhere? In particular it is not obvious to me what the distinction is
between pipe vs hose.
In Appendix A:
8. Would it be useful to discuss or reference YANG Catalog (as a source of
querying YANG models), the public YANG github repository, or YANG module tags
as a method of organizing YANG models?
9.
o Tunnel identities to ease manipulating extensions to specific
tunnels [RFC8675].
I found this sentence slightly unclear. Perhaps it could be reworded?
10.
o Generic Policy Model:
The Simplified Use of Policy Abstractions (SUPA) policy-based ...
It does not like this draft is going anywhere, and I'm not convinced that it
is really helpful to reference it here. Or, if it must be referenced, it
should be caveated accordingly.
11.
A.3. Device Models: Samples
I think that it would be helpful if this diagram, and the list in section A3.2,
had references to the interface YANG module.
12.
A.3.1. Model Composition
o Device Model
[I-D.ietf-rtgwg-device-model] presents ...
Again, I'm not sure that this is a helpful reference, given that the approach
defined in this draft did not gain traction, and instead, a more loosely
coupled structure was preferred. E.g., I see that tags (and arguably schema
mount) solve this organizational problem in a more flexible way.
13.
A.3.1.1. Schema Mount
That capability does not cover design time.
This sentence is unclear on its own. Perhaps either expand it or remove it.
Also, I wouldn't regard schema mount as necessarily being specific to device
models, and could be used for network and service YANG models as well.
Although there may not be a good place to put it.
14.
A.3.2. Device Models: Samples
As above, having a section for interfaces/interface management would be useful.
I also think think it would be good to have a section for device management
(e.g. system, nacm)
I would potentially reorder the list of modules:
- Move Core Routing up, near the top of the list (above BGP)
- L2VPN (next to) but before EVPN
- Perhaps move BGP down, and having routing policy next to it might be
helpful
- NAT and Stateless Address Sharing could perhaps move down.
Editorial nits to check:
1. Network Operator -> network operator?
2. Perhaps "it can accommodate modules" -> "it can also accommodate modules"?
3. "follow top-down approach" -> "follow a top-down approach"
4. "validated during the implementation time" -> "validated during
implementation"
5. For Diagram A2, possibly could have just used the full names and not
requried the legend.
6. "[RFC8345] with TE topologies specifics." -> "[RFC8345] with TE topology
related content."
7. "Network Topology Models" -> Network Topologies Model"?
8. "TE Topology Models" => "TE Topology Model"?
9. "Layer 3 Topology Models:" -> "Layer 3 Topology Model:"
10. "Layer 3 topologies specifics" -> "Layer 3 topology specifics"
11. "Layer 2 Topology Models:" -> "Layer 2 Topology Model:"
12. "Layer 2 topologies specifics" -> "Layer 2 topology specifics"
13. Figure 4: "Config Validate" -> "Config Validation", and realign "Monitoring"
Regards,
Rob
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
