Hi Joel, Thanks for your detailed review! It is very useful. My answers inline tagged as [GF] Best Regards, Giuseppe -----Messaggio originale----- Da: Joel Halpern [mailto:jmh@xxxxxxxxxxxxxxx] Inviato: domenica 25 febbraio 2018 02:00 A: gen-art@xxxxxxxx Cc: l2sm@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-l2sm-l2vpn-service-model.all@xxxxxxxx Oggetto: Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08 Reviewer: Joel Halpern Review result: On the Right Track 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 <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-l2sm-l2vpn-service-model-08 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. Major: 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. [GF]: Ok I understand and we can clarify this point in a new revision. This model is used to describe service intent or service requirements and characteristic associated with connectivity service. Consider that also in RFC 8299 (L3SM) there is the same phrasing. 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. [GF]: Remote-carrrier-identifier is used in the NNI case, see the code within YANG module: “ leaf remote-carrier-name { when "derived-from-or-self(../../../site-vpn-flavor,"+ "'l2vpn-svc:site-vpn-flavor-nni')" { description "Relevant when Site vpn flavor is site-vpn-flavor-nni."; } ” [GF]: In the NNI case, the current VPN Service provider can connect to another L2VPN or Data Center network or Cloud Provider’s network. Please also see section 5.16 for NNI support details. You are right, the VPN service provider doesn’t care whether the remote provider is a cloud provider or L2VPN service provider. So remote carrier-name doesn’t need to distinguish cloud provider or L2VPN service provider, if you believe we should distinguish we can remove remote carrier name, we think it add complexity and note that remote carrier name is an optional parameter. Regarding cloud-identifier defined within “valid-provider-identifiers”, cloud-identifier is only applied to public cloud or internet access, while remote-carrier-name can be referred to private cloud/data center or another L2VPN. That’s why we use cloud-identifier within cloud-access. 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. [GF]: We think one is name of the public cloud or internet access, the other is carrier name, they are different. We assume in this model to use “cloud access” to get access to public cloud or internet, we use “NNI” to get access to private cloud, data center or another L2VPN, therefore Cloud identifier should be known by both the current L2VPN Service provider and the customer. Remote Carrier name in NNI case should be known by the current L2VPN service provider it is connecting. 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. [GF]: Ok 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.) [GF]: No, the service-type is only referred to L2VPN service types. 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. [GF]: It is intended to list “Cloud-Access” in VPN service Overview, since “Cloud-Access” is applicable to all the sites rather than site-level parameter. Note that this model is a VPN model, so public Cloud and private cloud, datacenter are not part of VPN therefore we separate Cloud Access from Network Access within VPN. VPN service topology describe how site within VPN are connected to each other rather than describe how VPN is connecting to public Cloud. 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.) [GF]: Two level identity has already been achieved by using identity data type in this model, Since we have defined base identity in the model, other identity can be extension of the base identity. See the code in the module: “ identity service-type { description "Base Identity of service type."; } leaf svc-type { type identityref { base service-type; } default "vpws"; ” 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. [GF]: Similar to L3SM (RFC 8299), under VPN-services, the customer-name is defined and associated with each VPN-service. Under Sites, VPN-attachment is defined to describe which site is attached to which VPN. Then we can have Site A, Site B, Site C, Site D, Site A, Site B, Site C are attached to VPN-A, Site B, Site C and Site D are attached to VPN B (i.e., vpn-id is set to VPN-B), VPN A and VPN B belong to the same provider, then one provider end can talks to two customers. Minor: 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. [GF]: We tried to cooperate and we participate also to some MEF conference calls but we noticed that there are some differences in particular between the MEF LSO (Lifecycle Service Orchestration) architecture and the IETF SDN architecture. 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? [GF]: Yes, it allows augmentation, you may add some new parameters under each list. 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, ...) [GF]: We could, but these leaf are located in different paths, therefore unique leaf name under different parent node doesn’t matter. 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. [GF]: To get consistent with RFC8299, we prefer to keep as it does. The placement of section 5.2.2.1 (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. [GF]: Route Target Allocation section is VPN service topology relevant since Route Target is allocated based on the requested VPN service topology. See Section 5.2.2.1 for more details. 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. [GF]: Ok 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.) [GF]: Define the model of management for the site means: who has ownership of CE device, who manage CE device; this will decide the boundary between service provider and customer. 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. [GF]: The site may support single-homed or multi-homed. In case of multi-homed, the site can support multiple site-network-accesses, under each site-network-access, vpn-attachment is defined and it will describe which site-network-access associated with which site will connect to which vpn. In section 5.5.1.2 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? [GF]: The user can use a target-sites to identify the destination of a flow rather than using destination addresses. In some other case, the user can use VPN-id combining with MAC address to identify the destination of a flow. This has been specified in section 5.10.2.1. In section 5.5.2.2 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 5.5.1.2 that selection is on the basis of destination address. [GF]: Section 5.10.2.1 instead of section 5.5.1.2 answer your question. Site policy just describe which site is attached to which vpn, in more granularity case, it describe which lan from which site is attached to which VPN. 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? [GF]: No Section 5.17 has a short paragraph in the middle that uses the term OVC that is not otherwise used in this document. [GF]: Good catch, Thanks! we will fix this. 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? [GF]: Note that QoS parameter defined under site is an optional parameter. For simplicity, QoS behaviors are not included in the Example. Editorial: 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 5.3.2.1 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 5.5.2.1 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 "<bandwidth>" [GF]: Will fix them, thanks. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non è necessario.
