I think there are major open issues in this I-D . As a result, IMHO further work would be needed prior to WG acceptance.
A summary of my comments are listed below. Sorry if I should have missed something. Michael General comments * To me the scope of the document is unclear. The abstract uses the term "composite layer", but that term is neither defined nor referenced. It is unclear what a "buttons-up" approach would imply, e.g., for a L3VPN, and the document also does not describe what "node", "link", and "termination points" actually shall refer to according to this I-D. Based on the current I-D, it is not clear to how this document relates e.g. to the L3SM WG. * At least one application example would be needed to actually understand the use of the proposed model. The document claims to be applicable to "L3VPN, L2VPN, EVPN, E-Tree, and others". I think the document should have examples that show how to apply the YANG model to one or more of those services. * The YANG model spec and documentation is inconsistent and partly confuses me. I struggle with understanding how key objects would actually have to be implemented. One key problem is that the high-level introduction in Section 2 is not consistent with the actual YANG data model. For instance, Section 2 introduces an object "flag" that is not used elsewhere. Also, the intended use of the object "composite-flags" is not consistently explained. Instead of just listing the YANG tree representation, I think this I-D would require a more comprehensive introduction of how "services" shall really be modeled according to this I-D. In addition, in several cases the specific YANG modeling design choices are not motivated. Examples: Why is "node-count" really needed? What is an "unnumbered link address"? Unfortunately, the actual descriptions of objects in the YANG data model often so not provide much further insight. Further examples for such issues can be found below. Selected comments on the YANG model - this list is not comprehensive, as I gave up at some point * Why do identifiers use the type "uint32"? draft-ietf-i2rs-yang-network-topo-02 uses type "inet:uri", and it includes a discussion that "string" might also be appropriate. draft-ietf-l3sm-l3vpn-service-model-02 uses "string". I really wonder why yet another ID type is needed. * Page 6: It is unclear how existing VPN technologies would be mapped to the currently defined identities in "l3vpn-svc-topo". For instance, are E-LAN or E-Pipe mapped to L2VPN? And is E-Tree not a L2VPN? Other identities are not rigorously defined, e.g., "I2rs-svc-topo". * Page 7: There is both an "identity service-topology-types" and a "grouping service-topology-types", even with exactly the same description. This is really confusing. * Page 8: What is the purpose of "domain-name" in a node? How would this e.g. be set in a L2VPN? * Page 9: What is the intended semantics of "metric" in links? Would it not make sense to refer e.g. to draft-ietf-teas-yang-te-topo? * Page 11: What is the purpose of augmenting node by a "leaf-list next-hop"? * Page 11/12: "/nw:networks/nw:network/nw:node" is apparently augmented two times. This is confusing as the two augmentations even seem to overlap, e.g., by a leaf "name" and a leaf "domain-name" both of type "inet:domain-name". * etc. Selected editorial nits * Section 1: I cannot parse "The virtual service topology is a composite summary of the services available services gathered from the lower layer indications of ..." * There are numerous indention issues in YANG figures, also in Section 2.1 and Section 2.2. * There seem to be various spellings for the same concept: "composite-flag", "composite_flag", "composite-flags" * Page 6: The identity "Etee-svc-topo" is described as "Seamless MPLS service type" * Page 7: "leaf service-type" is described as "list of..." * Page 9: s/currewntly/currently/ From: i2rs [mailto:[email protected]] On Behalf Of EXT Susan Hares Sent: Tuesday, January 26, 2016 3:58 PM To: [email protected] Cc: 'Jeffrey Haas'; 'Alia Atlas' Subject: [i2rs] WG Adoption call for draft-hares-i2rs-service-topo-dm-04 (1/26 to 2/9/2015) This begins a 2 week WG adoption call for draft-hares-i2rs-service-topo-04.txt. https://datatracker.ietf.org/doc/draft-hares-i2rs-service-topo-dm/ The service topology model is a bottoms-up protocol independent model model that combines protocol-dependent service layers. Protocol-dependent services layers include: L3VPN, L2VPN, EVPN, E-Tree, and others. Please indicate in your response if you feel this direction "bottoms-up" is a good way to approach the service layer rather than the top-down of attaching this layer to service models (E.g. the L3SM model). As always, indicate if this draft is a good start for the service topology yang model. Sue Hares and Jeff Haas
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
