Joel, thanks for your in-depth review. Giuseppe, thanks for your responses. I have raised a DISCUSS point around the cloud-access identifier issue and included some other suggestions in my ballot.
Alissa > On Mar 1, 2018, at 5:59 AM, Fioccola Giuseppe > <[email protected]> wrote: > > Hi Joel, > Thanks for your suggestions! > Answers inline tagged as [GF]. > For now we are working on a new local revision and will see when to submit > changes according to chairs and AD. > > Best Regards, > > Giuseppe > > -----Messaggio originale----- > Da: Joel M. Halpern [mailto:[email protected]] > Inviato: mercoledì 28 febbraio 2018 19:08 > A: Fioccola Giuseppe; [email protected] > Cc: [email protected]; [email protected]; > [email protected] > Oggetto: Re: R: Genart telechat review of > draft-ietf-l2sm-l2vpn-service-model-08 > > Further comments in line, marked <jmh> ... </jmh> as some mail readers mangle > the inclusion marking. > As a reminder, please work with your chair and sponsoring AD to determine > when to submit changes. > > Yours, > Joel > > On 2/28/18 6:22 AM, Fioccola Giuseppe wrote: >> 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:[email protected]] >> Inviato: domenica 25 febbraio 2018 02:00 >> A: [email protected] >> Cc: [email protected]; [email protected]; >> [email protected] >> 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. > > <jmh>Thank you. I think clarifying this will help the reader. </jmh> > > [GF]: Ok > >> >> 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. > > <jmh> I did see the indirect references, that basically make these name lists > a constraint on what values can be used in the other parts of the model. > That is effective. What is unclear is why you have the different kinds of > identifiers, as the distinctions are not very clear. > </jmh> > > [GF]: Will clarify better this point. > >> >> 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. > > <jmh>The point I was trying to get at, and probably muddled, is that the > name a customer uses for some third party may not be the same as the > name the service providers uses (although they will be similar. Is > Ericsson A.B. the same or different from Ericsson Inc. or just Ericsson. > So these need to be coordinated. > > Writing this, it also seems that there needs to be an additional > clarification. Suppose that as a customer I want an L2VPN that reachs > third party. But that third party is not directly reachable by the > service provider. I as the customer probably do not specify what > transit provider the service provider should use to get connectivity to > the far end. But the far end may not even be directly known to the > service provider. This leads to a lack of clarity as to what names or > types should be used. (And what if I need a third party to reach some > of my own sites?) </jmh> > > [GF]: Will clarify better this point. I think your example can be addressed > by optionally using remote-carrier-name: > leaf remote-carrier-name { > ... > description > "Remote carrier name. The remote-carrier-name > must be configured only when site-vpn-flavor > is set to site vpn-flavor-nni. If it is not > set,it indicates customer does not know remote > carrier name beforehand."; > } > >> >> 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 > <jmh> ack </jmh> > >> >> 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. > <jmh>The same names are used for different things. Pleaes give them > different names. </jmh> > > [GF]: Ok > >> >> 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. > <jmh>The document describes the purpose of cloud access as a means to > define a constraint on authorization. Given that there are means to > define the authorization model, this "short-cut" seems > counter-productive. </jmh> > > [GF]: Ok understand, it is a good point but it could be also open to future > extensions. > >> >> 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: > <jmh>The text in 5.2 says that svc-type is a string. Apparently I had > missed that the YANG defined it as an identity. Which is what I ould > prefer. Please tune the text in 5.2 to reflect the fact that there are > some defined values, that it uses the identity mechanism, and that thus > service providers can extend the available values. </jmh> > > [GF]: Ok. Will fix it. > >> “ >> >> 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. > <jmh>I wasn't asking where the customer name lived. I was asking what > security assumption was being made about how the model behavior is > restricted so taht a given customer can only modify his own services. I > am not sure whether that is a new section or a subsection in security > considerations. </jmh> > > [GF]: Ok, probably we could add some text on this. > >> >> 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. > <jmh>As far as I know, the IETF does not have an SDN architecture. Even > if this model needs to be different from the MEF work, it would be good > to relate this even if by highlighting the differences. Also, I was not > asking for alignment with LSO, even if I would like that. I understood > that was a step too far. I am concerned about the service definitions > and descriptions themselves. The MEF service descriptions are what most > Ethernet service providers use. </jmh> > > [GF]: Will clarify this. Anyway I mean the examples of architecture described > in RFC 8309 and RFC 8199, a little bit different from LSO scheme. > [GF]: Both RFC 8309 and RFC 8199 are references for L2SM. > >> >> 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. > <jmh>The way it is currently used does not seem to make it likely that > additional parameters are going to be useful. Is there some practical > expectation of that? The structure would be simpler if you did not use > separate lists.</jmh> > > [GF]: Ok > >> >> 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. > <jmh>Yes, the leafs are under different paths. This is a minor comment > because it is driven by personal observation of effectiveness, rather > than an agreed IETF rule. </jmh> > > [GF]: Ok > >> >> 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. > <jmh>Okay. I will get off this point. I can live with what you have.</jmh> > >> >> 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. > <jmh>Yes, it is "relevant", but it is not itself a property of the > topology. So the placement seemed very odd. </jmh> > > [GF]: Will check. > >> >> 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 > <jmh> ack </jmh> > >> >> 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. > <jmh>Then please put words to that effect in that place in the document. > </jmh> > > [GF]: Ok > >> >> 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. > <jmh>I think the text needs to be explicit about what is assumed about > internal connectivity of a mult-homed site. </jmh> > > [GF]: Ok, will clarify. > >> >> 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. > <jmh>Please add explanatory text and a forward reference to 5.10.2.1.</jmh> > > [GF]: Ok, a reference can be added. > >> >> 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. > <jmh>If 5.10.2.1 answers the question, then what is 5.5.1.2 doing> </jmh> > >> >> 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 > <jmh>Not sure what "no" means. On the one hand, the early text seems to > say they are different. On the other hand, later things are listed as > constraint / parameter. If they are the same, then is it a hint or a > requirement? If they are a different, how can something be both. "No" > does not answer the question. </jmh> > > [GF]: No in the sense that hint and requirement cannot be both. > [GF]: So we could specify better which are parameters and constraints. > >> >> 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. > <jmh>ack</jmh> > >> >> 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. > <jmh>Then please remove the qoa-profile-identifiers.</jmh> > > [GF]: Ok > >> >> 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. > <jmh>ack.</jmh> > > > 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. > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
