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

"Adrian Farrel" <adrian@olddog.co.uk> Sun, 25 February 2018 09:11 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: l2sm@ietfa.amsl.com
Delivered-To: l2sm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7112126BFD; Sun, 25 Feb 2018 01:11:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwo-piS7Ew73; Sun, 25 Feb 2018 01:11:30 -0800 (PST)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D269126DFF; Sun, 25 Feb 2018 01:11:14 -0800 (PST)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id w1P9BBFN031900; Sun, 25 Feb 2018 09:11:11 GMT
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7A25122040; Sun, 25 Feb 2018 09:11:11 +0000 (GMT)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 648FE2203D; Sun, 25 Feb 2018 09:11:11 +0000 (GMT)
Received: from 950129200 ([193.57.121.27]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id w1P9B8NK005151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Feb 2018 09:11:10 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Joel Halpern'" <jmh@joelhalpern.com>, <gen-art@ietf.org>
Cc: <l2sm@ietf.org>, <ietf@ietf.org>, <draft-ietf-l2sm-l2vpn-service-model.all@ietf.org>
References: <151952041929.12995.5895779377191010604@ietfa.amsl.com>
In-Reply-To: <151952041929.12995.5895779377191010604@ietfa.amsl.com>
Date: Sun, 25 Feb 2018 09:11:09 -0000
Message-ID: <065401d3ae18$949f1ca0$bddd55e0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGVP3SqKJY89/RdTeyFQpQq0QAo9KQxscZQ
Content-Language: en-gb
X-Originating-IP: 193.57.121.27
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23684.006
X-TM-AS-Result: No--20.040-10.0-31-10
X-imss-scan-details: No--20.040-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23684.006
X-TMASE-Result: 10--20.040000-10.000000
X-TMASE-MatchedRID: yebcs53SkkCnykMun0J1wkhEDfw/93BuyeUl7aCTy8jjsTquy0JRiyA8 rnY0U1KzMKCFIoZOZBDxTwx4UJIMck5RCTiYesCKTIzrNCbT62obTwzYj2zQuuQydRUvl3QT+1y eRNwXFNzMjyttkaAdtLBMgJuhfWMi2rvYheZgBXtwUSK4/EeOxXJrB0Cu3DDnEd+K6O5Nt506wo IcQIJqTVWThGBLBxQbcw016UDmVKkNDmNqb6OmSq91/YHX0i1lzJmqByfAaS1Y/2pi7PK0EuD+b NUbvCNRlTJXKqh1ne3LJ3PSkfYjxkEzWu30xbMcJhb388hdoo9m43Ht6SePHu0lRPbZZsJJQfXe xN3meZCczXEIRLVzwev4h1UdnDHwpkkXpMSpG5wtR8fVMTBo3cBZPOJYZoM8SSUXkvSVAdzimg9 4X0eg/tuZalamwBXt7taqnOMBaKE9dF/Bzwh+4Az4VsCc1YW+ERzrQ87nh6pZps+y1VXzqXkDxC 8oBMkz1GEeRzIMZZOVku+AOFtK6teMRzCcJKBBbBu6+EIezdyEQiKo28GuYw2G3vz8l/IEsUxOW MsTCHLMU8uAdH6XmhiqtznBCN+1JTKg1fMqYHDDg+U1NSmcubnXAHYFSPMZyPRAwD/3abajkBpU 34bhn+26WDOAe8Sfr9dasV69MmyYWjOlAjIj68+ayFtEW0uYN/BTU5ZfZRK0Vg+MnSE2GPRm0km qtH+DezJybqTXDzLc8HL6slabEAQ4uF25dsUI3FqOVb7PDELEGBoHKd3a+bCXtJ14sCJ3fecMAQ BtYyTXgsFAU4DkYs0TtqW/TWarIWv+DotxFxueAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2sm/rUBQlM4r8aJogUt1pXAi2B8AE1A>
Subject: Re: [L2sm] Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08
X-BeenThere: l2sm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" <l2sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2sm>, <mailto:l2sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l2sm/>
List-Post: <mailto:l2sm@ietf.org>
List-Help: <mailto:l2sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2sm>, <mailto:l2sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Feb 2018 09:11:34 -0000

Thanks Joel,

There's a lot to digest here. The chairs will work with the authors on a response.

Adrian

> -----Original Message-----
> From: Joel Halpern [mailto:jmh@joelhalpern.com]
> Sent: 25 February 2018 01:00
> To: gen-art@ietf.org
> Cc: l2sm@ietf.org; ietf@ietf.org; draft-ietf-l2sm-l2vpn-service-model.all@ietf.org
> Subject: 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.
> 
>     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.
> 
> 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.
> 
>     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 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.
> 
>     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 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?
> 
>      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.
> 
>     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?
> 
> 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>"