Telechat Review of draft-ietf-l2sm-l2vpn-service-model-08
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.
For more information, please see the FAQ at
Reviewer: Joel Halpern
Review Date: 2018-02-24
IETF LC End Date: 2018-03-26
IESG Telechat date: 2018-04-05
Summary: Given the number of Major and minor issues, this document is not yet ready for publication as a Proposed Standard RFC.
Introduction: The phrasing of "an abstract model", "this model is not a configuration model..." creates some confusion in the reader as to whether this model represent the current state of service deliveyr, the desired state of service delivery (which would drive configuration) or both. Please clarify.
The "valid-provider-identifiers' distinguish between cloud-identifier and remote-carrier-identifier. It i unclear why the VPN service provider should know or care whether the remote provider he is connecting with is a cloud provider, and another L2 service provider, or both. And if it is both, which identifier should be used.
Also, it is very unclear how these identifiers will be used. They presumably are names of something. But of what? As known to whom? Derived from where? I do not see how a provider / customer pair using this model will know what values to use for this. Even if the intention is that these be names made available by the provider by external means, the YANG model needs to say that if it is to be usable.
I did eventually find some explanation in section 5.15. At the very least a forward reference is needed. I think more explanation of what these things names would also help.
The use of different sets of what read like service types (is cloud access a service type? Is remote-access a service type?) and the use of similar but not the same terminology between provider descriptions, service types, and service topologies, leaves the reader VERY confused. Please, do not use the same term for kinds of providers, kinds of services, and kinds of topologies unless the names are fully congruent (which they currently are not.)
It is unclear why "Cloud-Access" is listed in the VPN Service Overview (section 5.2), or even why Cloud Access is any different from any other access. Presumably, the customer can configure authorization for the sites to meet his needs. Any topological effect would be capture in 5.2.2 on VPN Service Topology, not as a different kind of VPN Service.
Regarding VPN Service Type (svc-type) the text in section 5.2 says that this is explicitly for the local administrator to use to flexibly define the CPN service type. Section 5.2.1 then says that it has one of six values, implying that if other values are needed they will need to be defined in an extension to the model. If they are for model use, and for model extension, then they should be using a two-level identity (where the second level provides the possible values.)
Given taht this is a model for providers and customers to use to collaborate on the configuration of VPNs, I would expect to see some discussion of how this is used on the provider end so as to collaborate with multiple customers, working with each only about their VPNs. I missed any such description.
I would have expected some reference to the MEF Ethernet service definitions and MEF defined parameters of interest, as industry usage seems to reflect those as the common basis for L2 services. I udnerstand that this model is not mandated to conform to the MEF Forum work. I would expect some discussion of the relationship. This may be a deliberate working group choice, as I see in teh change log that there were references to EVC and OVC. It still seems that it would help readers to have something.
The structure of the vpn-profile-cfg grouping seems very strange. It is a series of 4 lists, each of which only contains an id leaf. First, and less important, that makes them leaf-lists, doesn't it? Or is it structured this way with no explanation to allow for unexplained type specific augmentation?
If no Augmentation is needed, it would seem more general to use a two level identity (identity based enumeration) for the type of VPNs, use a single list containing an id and a type field, where both are keys and the type field uses the enumeration. This would still easily allow for adding new types, and would avoid using the same leaf name in different lists (which while legal often leads to errors.)
If we really need four distinct lists, then I would recommend changing the names of the id field so each one has a unique leaf name (cloud-id, qos-id, bfd-id, ...)
It appears that the purpose of this list is to be used as targets for leafrefs. As such, it does not seem that distinct lists are needed.
The placement of section 22.214.171.124 (and the resulting YANG objects) seems odd. "Route Target Allocation" is a mechanism, not a topology. It is not even listed in the options mentioned in 5.2.2.
Section 5.2.3 on Cloud Access uses a variant on the unfortunate "MUST ... except ... MAY" construction. As far as I can tell, that is a very nice SHOULD, with an explanation of when the SHOULD does not apply. Even if this is not fixed, the inconsistency between having an exception here, and the strict requirement (upper case MUST with no exception) in section 5.2 needs to be fixed.
Section 5.3 on a Site Overview has an item for "Management" which "Defines the model of management for the site". It is completely unclear from this text what it is intended to mean, and the example does not help. (5.11 is better, but still vague.)
When I reached the note in section 5.3.1 that a site may have multiple locations, I realized that I did not see anything explicit as to whether a site is assumed to have full internal connectivity (so that from the point of view of the VPN any of the access links to the site are interchangeable, or if it is fully meshed but there may be preferences for entrance for different distinations, or whether sites may actually be partitioned, where one part of a site is only reachable from another part of a site fia the VPN (the usual assumption when told that there are multiple locations in a site). I think this should be clarified.
In section 126.96.36.199 on MultiVPN attachment, the text says "Reaching VPN A or VPN from the New York office will be done via destination-based routing." Routing usually refers to the handling of IP packets. Is the intention that this distinction is based on IP destination even though we are providing an L2 service? Is the intention that MAC addresses are unique across the two VPNs, and the bridging tables will know which VPN contains which destinations? If the later is the intention, how does that interact with B/U/M frames?
In section 188.8.131.52 on site policy, the text appears to be attempting to answer the question of which destinations in a site should be reachable over (possibly should have reachability to) which VPNs. It does this via a "lan" tag. The meaning of this tag is unclear. Reading between the lines, this appears to be intended to say that the segregation is on the basis vlan tag (although the string is "lan" not "vlan" much less "vlan tag".) if the intention is that policy is on the basis of vlan, it is unclear how this relates to the assert in 184.108.40.206 that selection is on the basis of destination address.
Section 5.6 seems to indicate that parameters and constraints are different things. Several of the subsections of 5.6 such as access-type seem to indicate that information may be either a parameter or a constraint. Given that the difference seems to be between a customer hint and a customer requirement, how can something be both?
Section 5.17 has a short paragraph in the middle that uses the term OVC that is not otherwise used in this document.
Why do the examples in section 7 include qos-profile-identifiers when the description does not include any reference to multiple QoS behaviors, and nothing in the example makes use of the defined identifiers?
The wording at the front of section 5.2.5 could use tuning. It currently says "If Frame Delivery Service support is required..." It seems to me that by definition all L2VPNs require support for delivery of L2 frames. This seems instead to be about parameters for handling BUM (Broadcast / Unkown / Multicast) delivery. If so, this should be named suitably. It would also be helpful if this were explicitly related to the support parameter in 5.10.3.
Section 5.3.2 refers to the "bearer" parameters as "below layer 2". Section 220.127.116.11 on Bearer refers to it as "below layer 3". I presume that should be "below layer 2"?
In Section 5.5.1 the text states that "There are three possible types of .. Therefore the model supports three flavors:" Which is then followed by a list of four bullets.
The indenting of the XML in section 18.104.22.168 should be repaired. All of the XML examples should have their indenting checked.
The text in section 5.6 says "The management system MUST honor all customer constraints...". Then it says "Parameters such as site location ... are just hints." I think that the intention is that "parameters" and "constraints" are different things. If so, the paragraph above where those terms are introduced should at least indicate something about the diffence. Maybe "parameters (hints) and constraints (customer requirements)"?
It seems surprising in 5.6.4 on Access Diversity for a customer to be able to talk about whether things are premitted to be on the same line card. That seems a level that an operator is unlikely to expose.
It is surprising that committed vs excess bandwidth is treated as a QoS parameter, with no mention of it in 5.10.1 "Bandwidth". Particularly since these are actually parameters of ""