Sorry for the delayed response - I am travelling. And many thanks for your feedback.
I believe that my comments are not sufficiently addressed in -06, apart from the small nits and low hanging fruits. Given that all the major issues are still all unsolved, I continue to object to a WG adoption of the draft. I am familiar with actual implementations of related systems and it is not possible for me to understand how this YANG model should be implemented, i.e., an interoperable implementation of this specification is not possible as far as I can tell. Significant additional explanation + examples and a much more consistent and precise definition of the YANG model would be required to allow understanding how an implementation of this specification should look like. I believe this work has to happen prior to WG adoption. I also suspect that this exercise could affect significant parts of the YANG model as well, but this is difficult to know as the scope of the YANG model is fuzzy to me. For more details, see below [MS]. I have briefly read version -06 as well and version -06 does not address my main concerns. From: EXT Susan Hares [mailto:[email protected]] Sent: Friday, February 12, 2016 5:46 PM To: Scharf, Michael (Nokia - DE); [email protected] Cc: 'Jeffrey Haas'; 'Alia Atlas' Subject: RE: [i2rs] WG Adoption call for draft-hares-i2rs-service-topo-dm-04 (1/26 to 2/9/2015) Michael: Thank you for your patience in responding. Your comments were very helpful. I have responded inline, and revised the draft. I would appreciate your comments on the draft. In future drafts, may I acknowledge your helpful comments by including you in the "acknowledgement" section. The new draft is at: https://datatracker.ietf.org/doc/draft-hares-i2rs-service-topo-dm/ Sue From: i2rs [mailto:[email protected]] On Behalf Of Scharf, Michael (Nokia - DE) Sent: Monday, February 01, 2016 7:30 AM To: EXT Susan Hares; [email protected]<mailto:[email protected]> Cc: 'Jeffrey Haas'; 'Alia Atlas' Subject: Re: [i2rs] WG Adoption call for draft-hares-i2rs-service-topo-dm-04 (1/26 to 2/9/2015) 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. ============== Sue's Response: Scope: The scope of this document is a "bottoms-up" composite of several L3VPN, L2VPN, EVPNs, and other IP-VPNs. Each of these will eventually have other service modules: L2SM, EVPN-SM, and SFC service models. [MS] I think what is first lacking is a rigorous definition of the terms "buttoms-up" and "composite". Maybe the draft should have a terminology section explaining those terms, or reference to existing definitions. And, for what it is worth, the draft -06 still states: "The virtual service topology is a composite summary of the services available services gathered from the lower layer indications of L3VPN, L2VPN, and EVPN services, E-TREE services, Seamless MPLS topologies within an As and others." I cannot parse this sentence, as noted below in my original review. [MS] Without clear definition of these terms it is unclear to me what this draft actually wants to achieve and how I could map this to implementations actually realizing such services. You need the bottom up topology parts (links, support) in order to combine the topologies which can then support indicates of: a) L3SM topology type (any-to-any, hub-spoke, hub-spoke disjoint) that overlay on the topology link b) Cloud ID + Sites* [id] within Clouds: specific topologies and access points. c) Multicast trees d) Transport [MS] I cannot parse this. I am not a native speaker, but the way how the L3SM service model is defined "needs" IMHO no "buttom up" topology, as it focuses on the service view only. An NMS or EMS may obviously map this to actual MPLS/IP topologies but I don't see how this model would address this. If you look at the L3SM, it has at the top levels, it does not have a level which easily fits on top of L1, L2, and L3 levels to support combining L3 Topology levels: [MS] I know how to implement L3SM models on top of L1, L2, and L3 networks. But I do not understand what actual technology should here standardized in this document. Maybe this is a terminology issue but this is why this draft has to formally and rigorously introduce the terms "buttom-up", "composite", "combining", ... and exactly explain what the YANG model actually wants to achieve, and what value that YANG model actually has. [MS] It may also be possible to explain on which interface such a YANG model would actually be used. This is also not clear at all from the draft. The L3SM high level yang is: +--rw vpn-svc* [vpn-id] | +--rw customer-name? | +--rw topology identityref [any-to-any, hub-spoke, hub-spoke-disjoint] | +--rw cloud-access | | +--rw sites | | ... | +--rw multicast | | ... | +--rw mpls | +--rw transport-constraints +--rw sites | +-- +--rw site-templates The vpn-svc, cloud-access and sites provide topology at a high layer. [MS] Cloud-access, sites, etc. are also an ACL abstraction. Specifically, if we dig deeper into "sites" (e.g., vpn-policy - currently discussed in L3SM). I do not understand how you plan to map the ACLs in sites into a "topology" data structure with nodes and links and termination points. But I guess a discussion whether the L3SM policies represent a "topology" with nodes, links, and termination points, or not, belongs to the L3SM mailing list, and a corresponding topology model should be discussed there, not here. This topology will have attributes of: topology (any-to-any, hub-spoke, hub-spoke disjoint), multicast, mpls, and transport constraints as a service topology attribute, you can create a high-level service. It's nodes (sites) will link to the bottoms-up composite service topology nodes (overlapping on the L3VPN topology). Therefore, using the generic model - you can link the higher level service topology (L3SM) to the composite bottoms up service topology by considering the composite service topology as supporting links. [MS] If "composite buttoms up service topology" is a set of VRFs or RT/RD policies than this terminology is not intuitive to me, and if you are not referring to VRFs here then I don't understand these sentences at all. Again, please add a longer terminology introduction to the draft, possibly with examples how to map this e.g. to existing VPNs, so that implementers can understand what you mean. It is not possibly to understand the YANG model if the concepts are not explained. You can link these to a composite bottoms-up service topology (e.g. L3VPN topology) by understanding which of the bottoms-up topology can support the attributes required. I added attributes that will help the upper L3SM topology know which parts of the composite "bottoms up" service topology can support the L3SM topology. L3SM-topology | (not there) ========= [socket] I2RS Bottoms up Service Topology To make this clearly, I've released -06. [MS] -06 is not clear to me on any of these concepts. Also, I do not understand the term "socket" in this picture - where is this term defined in -06? [MS] In summary, based on the text in -06 and this e-mail it is not clear to me what problem this draft is actually trying to solve, and why an IETF specification were needed needed. ======================= * 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. Good point. I've added the L3SM and the L3VPN example. [MS] I have suggest to add an example how the *YANG* model is used for an existing example. Figure 2 shows some L3VPNs but it does not show the YANG model would realize this. An example would e.g. have XML or JSON representation of the objects in the data store. Personally, I would start with a simpler example than the one used in this case, but this is clearly left to the authors. As a side node, Figure 2 is very hard to parse as labels overlap; this is an editorial issue but does not help at all. I I believe it is not reasonable to ask for implementer feedback on a YANG model of this complexity without one or more actual examples how the YANG model would be used. * 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. In previous versions, I describe these features with SFC, but people felt the level of details was not appropriate. I've check all the flags to see these are used by compiling the service-topology. I've also removed node-count, unnumbered link, and anything other than identifying attributes. [MS] Section 2 has not significantly improved in -06. There is still a lack of explanation of "composite-flag" (as well as the different spellings of that attribute in the model). For instance, the text mentions a "bit mask" and this continues to be inconsistent. And Section 2 now introduces quite a set of new attributes not used in previous versions, again with unclear scope, no clear motivation, and lack of examples. As a first step, Section 2 should have a comprehensive motivation for each attribute, i.e., why it is required, and at least one example use case for each one. Thanks Michael 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. I've removed any identifiers with type uint32. I've used "strings" to be generic. Upon review we can move some of these to inet:uri if it is appropriate. * 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". Yes - I agree that the link downward is vague. I had linked it to specific XXVPNs, but people wanted me to stay at the high level until these other yang modules were firmed up. We can then pick whether L2VPN contains EVPN and E-LAN and E-PIPE, or if there is a different break-out. I welcome the discussion. The current mechanism were left vague to allow alignment with the moving MPLS and BESS specification. If we can agree we will align with this drafts, I am willing to go on. * 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. Please see the netmod yang 1.1 identity and grouping mechanisms. These are means to provide essentially "enums" that support this topology. I've added description in the XML draft. Please let me know if this helps the confusion. * Page 8: What is the purpose of "domain-name" in a node? How would this e.g. be set in a L2VPN? This has been removed. * 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? Yes. I've included text to indicate this is the "metric" at the service level. It is not clear if the teas-yang-te-topo really deals with above L3VPNs and L2VPNs. I've not included it in -06, but I will ask the TEAS DT. * Page 11: What is the purpose of augmenting node by a "leaf-list next-hop"? This has been removed. Other people mentioned this issue. * 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". Yes, this was in error. Selected editorial nits (Thank you for the nits. I will revise these in the next version. * 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/ Hopefull, I've caught all these spelling issues. Thank you for all the comments. From: i2rs [mailto:[email protected]] On Behalf Of EXT Susan Hares Sent: Tuesday, January 26, 2016 3:58 PM To: [email protected]<mailto:[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
