[L2sm] R: Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08

[Fioccola Giuseppe <[e-mail]>]

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:[e-mail]] 
Inviato: domenica 25 febbraio 2018 02:00
A: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
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.