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

"Adrian Farrel" <> Sun, 25 February 2018 09:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7112126BFD; Sun, 25 Feb 2018 01:11:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rwo-piS7Ew73; Sun, 25 Feb 2018 01:11:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D269126DFF; Sun, 25 Feb 2018 01:11:14 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id w1P9BBFN031900; Sun, 25 Feb 2018 09:11:11 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 7A25122040; Sun, 25 Feb 2018 09:11:11 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 648FE2203D; Sun, 25 Feb 2018 09:11:11 +0000 (GMT)
Received: from 950129200 ([]) (authenticated bits=0) by (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: <>
From: "Adrian Farrel" <>
To: "'Joel Halpern'" <>, <>
Cc: <>, <>, <>
References: <>
In-Reply-To: <>
Date: Sun, 25 Feb 2018 09:11:09 -0000
Message-ID: <065401d3ae18$949f1ca0$bddd55e0$>
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-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--20.040-10.0-31-10
X-imss-scan-details: No--20.040-10.0-31-10
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: <>
Subject: Re: [L2sm] Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


> -----Original Message-----
> From: Joel Halpern []
> Sent: 25 February 2018 01:00
> To:
> Cc:;;
> 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
> <>.
> 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 (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 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 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 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 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 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>"