[L2sm] FW: YANG + XML review of draft-ietf-l2sm-l2vpn-service-model-05

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 31 January 2018 14:32 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: l2sm@ietfa.amsl.com
Delivered-To: l2sm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7E41A12EB8A; Wed, 31 Jan 2018 06:32:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DYwg_xf1EBT5; Wed, 31 Jan 2018 06:32:53 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9355F1317F2; Wed, 31 Jan 2018 06:31:08 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain []) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id w0VEV6EN003904; Wed, 31 Jan 2018 14:31:06 GMT
Received: from 950129200 ([]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id w0VEV1xh003825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Jan 2018 14:31:03 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <draft-ietf-l2sm-l2vpn-service-model@ietf.org>
Cc: <l2sm@ietf.org>, "'Jan Lindblad'" <janl@tail-f.com>
References: <058801d38f72$7526d800$5f748800$@olddog.co.uk> <16F8CDDD-6FB9-4C29-BE19-31C398540303@tail-f.com> <05c101d38f88$482eb0a0$d88c11e0$@olddog.co.uk> <D5DFD8FF-40F6-4F4B-8F27-6BA625BD5925@tail-f.com>
In-Reply-To: <D5DFD8FF-40F6-4F4B-8F27-6BA625BD5925@tail-f.com>
Date: Wed, 31 Jan 2018 14:31:02 -0000
Message-ID: <0b4b01d39aa0$1f91f3a0$5eb5dae0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B4C_01D39AA0.1FBA8A40"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGbYYMLnOH+20pqSyT8FxtWyiFAXQLBgAiWAcQeilMCRvT87aPIFyEQ
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--18.034-10.0-31-10
X-imss-scan-details: No--18.034-10.0-31-10
X-TMASE-MatchedRID: AXqs4r+tk3JHdhuYYkLbTLdQIb8hCnY+rHCvytg5b4495QkkroABJbT1 PfFb2aa8SREnFCYlEy37J7KZNCMUZiP0K6pQJfW4b/5HBZ6dvRgS12tj9Zvd8xKIr6MHZFJ1r3A g3zt3L14i4bZCUUt3BoEN02vEC7aDo4XUuMvTVpQjK+nUBBcfy5ACgmEvxn6vYIPlIzxi9UUrjL 21lsVzzlUJN3KkiTtdrouWMPKBA/FnEZWl/y7mGc5Scd0yVs+bCQ3xS+zL6e34JyR+b5tvoPRm0 kmqtH+D3pye3Whh2REEyKTjjDAwEK2QcrcGaiYgliwpJdZauweZf5btvM85AXX+rbovv1tMzw+o FzYqJkf+f0nlDYjAjtlYmtBNW3IbrCSDvRpy10RsG7r4Qh7N3BU5qsA/dJ7CDpCUEeEFm7B8rwA wWerBmDEkM/dhR7QFk2JnmeZE9gi1Ha+bMGdk0xIRh9wkXSlFdwX/SSKrKHizXLgm/AgMbgfoRw TLQ8VIci6AUyYpyt+U9QSsHUHEBsfeJfU5DGcLCFaAixm5eU8UkWvaqUqLH7iBTLMkgNsWJUgu5 qZIX1dILvrkd8n3SjNcGg4YDGurs9gvQBjr0DSRGzV8Bxg0cUCrr/LkAQ46LcVjbs+keawgkXq/ YVYC+O8BtdISrVH6q7Fs15iXQ7Wjb+Fpw9wtLtjDJsU1r62bojQrbrPpzzpcKZwALwMGs8it/eC fvDyiFcQoBygS/73+yOWquOWfJMJHVFWeMALEjtK7dC6UBnlcSMp/1+EppyfO9H6Y/dy+rBS6zb NxgL6yypnor4OCPqyDYF/RX6N8jBOuHzVSbRGeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDOG2o4D tJIL5vLE5hS3p8W33fj+sMArfOEbaqKQSlAZRow8Kyk3tsB57ywFN4XkPWNg+0X1d6KF8O5kKaV eETKm9JyYX76gYc=
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2sm/Lss9stotaXF_sAhoyb_M0bE41JY>
Subject: [L2sm] FW: YANG + XML review of draft-ietf-l2sm-l2vpn-service-model-05
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: Wed, 31 Jan 2018 14:32:57 -0000

Hi authors,
Jan Lindblad has done a great review for us.
On the positive side he thinks you have done a really good job with the module,
but he has nevertheless found a pile of small issues.
It looks to me (what do I know ;-) that the majority of these should be really
easy to fix, so I'd like to lean on you a bit to get a revision "soon." Can you
let us know what the plan is?
At the same time, I will do an English language review.
From: Jan Lindblad [mailto:janl@tail-f.com] 
Sent: 31 January 2018 13:48
To: Adrian Farrel
Cc: bclaise@cisco.com; Qin Wu
Subject: YANG + XML review of draft-ietf-l2sm-l2vpn-service-model-05
Adrian, shepherds,
I've now made a YANG review of the l2vpn YANG model and examples. Since I'm not
listed as the formal reviewer, I'll just write it in a mail like this. Let me
know how you'd like me to post this if this mail to you is not what you had in
That's fabulous!
We are looking to do WG last call in early February. Of course, incorporating
your comments before then would be best, but that would mean completing your
review by the end of January.
The back-up plan would be to do your review before the end of last call so
targeting 20th Feb.
So I read the first 35 pages of the RFC before I realized I'm not going to
understand this well enough to have any use of the plaintext when looking at the
YANG anyway. So then I jumped right at the YANG and examples instead. I must say
it's a clean and simple approach and one of the more well written YANGs I have
seen; I could not find any serious issues with it. Since it's written in a very
down to earth fashion without much in terms of fancy constructs, it stays clear
of some of the pitfalls we've seen in the past. When it comes to the examples,
they all omit things (which may or may not be acceptable, you decide) and almost
all the examples are broken. In other words, business as usual.
On the detailed level I have a long list of comments. Mostly the usual stuff. So
here goes:
-- indentation is broken
  feature dot1q{
-- missing space between name and open brace in lots of places
  identity opaque {
    base bw-type;
-- descriptions like this have negative value, no information but take up space.
I would have hoped to understand how/when to use "opaque", etc.
46:  feature L2CP-control { 
443:  identity all2one-Bundling {
-- should be all lowercase
80:  feature signaling-options {
      "Enable the support of signalling option.";
3001:      leaf signalling-type {
-- make spelling consistent; either "signaling" or "signalling". Our own XML
examples below stumble over this as well
365:  identity site-vpn-flavor-single {
371:  identity site-vpn-flavor-multi {
381:  identity site-vpn-flavor-nni {
601:  identity co-managed {
606:  identity customer-managed {
611:  identity provider-managed {
616:  identity address-family {
-- remove the word "Base" in the description, these are identities, but not base
454:  identity color-id--cvlan { 
468:  identity cos-id--dscp {
-- use single dash
906:  identity bidirection {
-- should be "bidirectional" ?
1024:        choice list-flavor {
1064:    leaf site-vpn-flavor {
1252:        leaf delivery-mode {
1452:    leaf bundling-type {
1459:    leaf default-ce-vlan-id {
1469:   grouping cfm-802-grouping { (one leaf has a default)
1538:  grouping y-1731 {
1650:   grouping lacp-grouping {
1672:       leaf system-priority {
1830:        leaf enable {
1838:      leaf uni-loop-prevention {
1888:        leaf tag-type {
1895:        leaf cvlan-id {
1909:         leaf tag-type {
1925:        leaf tag-type {
1932:        leaf svlan-id {
1937:        leaf cvlan-id {
1951:        leaf tag-type {
1958:        leaf svlan-id {
1972:        leaf vni-id {
1977:        leaf peer-mode {
2005:      leaf encapsulation-type {
2012:      leaf eth-inf-type {
2049:  grouping svc-preservation-grouping {
2073: grouping site-mac-addr-limit {
2105:      leaf access-priority {
2139:  grouping l2cp-grouping {
2199:  grouping site-bum {
2275:  grouping site-mac-loop-prevention {
2301:  grouping ethernet-svc-oam-grouping {
2327:  grouping fate-sharing-group {
2452:      choice request-type-choice {
2542:      leaf attachment-device-id {
2577:          leaf vpn-id {
2648:        leaf vpn-id {
2653:        leaf cir {
2661:        leaf cbs {
2855:                leaf direction {
2863:                leaf policing {
2879:                  choice flavor {
2907:                  choice flavor {
3001:      leaf signalling-type {
3135:        leaf svc-type {
3147:        leaf svc-topo {
3203:            leaf remote-carrier-name {
-- no default, no mandatory, no description what happens if not set. Groupings
included above when every leaf inside is lacking default/mandatory/description
1171:             list filter {
-- only one filter of each type (and only one standard type). Will there ever be
a filter that you'd want to have several of?
1211:               mandatory true;
-- redundant, this is already a key, hence mandatory
1349:          leaf group-id {
1718:            leaf profile-name {
1779:      leaf flow-control {
1818:      leaf flow-control {
2334:      leaf group-color {
2341:        leaf group-id {
2362:        leaf group-id {
2399:                  leaf group-id {
2455:            leaf physical-if {
2472:          leaf physical-if {
2477:          leaf circuit-id {
2499:        leaf requested-type {
2542:      leaf attachment-device-id {
3203:            leaf remote-carrier-name {
-- These use type string, is that really the right type? How about leafref,
enumeration, ...? What are the valid values here? What happens if an "incorrect"
value is given?
1563:       leaf message-period {
1569:      leaf measurement-interval {
1662:      leaf lacp-speed {
1667:      leaf mini-link {
1695:        leaf bfd-interval {
1700:        leaf bfd-hold-timer {
1748:          leaf port-speed {
1803:      leaf port-speed {
2245:      leaf bum-overall-rate {
2259:        leaf rate {
2277:      leaf frequency {
2935:                  leaf fr-loss-rate {
-- add units. In some cases unit is specified in the description, but better in
units stmt.
1107:          leaf management-transport {
1650:   grouping lacp-grouping {
1652:      leaf lacp-state {
1657:      leaf lacp-mode {
1662:      leaf lacp-speed {
1681:        leaf micro-bfd-on-off {
1695:        leaf bfd-interval {
1700:        leaf bfd-hold-timer {
1710:        leaf bfd-hold-timer {
1857:        leaf lag-ifindex {
1875:      leaf tagged-inf-type {
2075:      leaf mac-num-limit {
2776:      container qos-classification-policy {
2824:      container qos-profile {
2935:                  leaf fr-loss-rate {
3060:    leaf site-network-access-type {
-- remove redundant part of the name. Inside container bfd, leaf:s should not be
called bfd-foo, but just foo
1652:      leaf lacp-state {
-- wouldn't "enable" be a better name than "state" for an on/off switch?
1657:      leaf lacp-mode {
-- what does values true and false mean here? How is this different from leaf
1740:      container member-link-list {
-- should probably be "member-links"
1798:      leaf ifindex {
-- how do I know what ifindex value to use? Is this the same ifIndex as in snmp?
1853:    container lag-interface {
-- should probably be lag-interfaces
2112:          leaf single-active {
2121:          leaf all-active {
-- I think you mean type empty?
2308:      leaf md-level {
2792:               leaf match-phy-port {
-- how do I know what is a good value for this leaf?
2460:            leaf vlan-id {
-- add a range?
2499:        leaf requested-type {
-- same name as parent container, confusing
Finally, there are seven leafrefs with absolute paths. In the past reviews there
have been issues when an absolute path was used but only a relative path had the
right semantics. In this case, I don't understand well enough what the author's
intent is, so let me verify for each one that the YANG matches the author's
1015:         leaf cloud-identifier {
-- points to ANY cloud, regardless of profile
1033:            leaf-list permit-site {
1042:            leaf-list deny-site {
-- points to ANY site, regardless of which customer
1206:            leaf vpn-id {
1273:      leaf svc-id {
2577:          leaf vpn-id {
-- points to ANY vpn, regardless of which customer
2832:            leaf profile {
-- points to ANY qos-profile
Then we have the XML examples. I refer to them by page number in the spec, with
"a" and "b" suffix when there is more than one on a single page.
p24a, p24b, p25:
t-mapping is mandatory and not set by the example. After working a bit with the
model, I'd suggest removing mandatory here and add a default instead. It's
really a bit annoying to have to care about multicast properties as soon as I
define a vpn-service.
Example broken in a couple of places:
Example broken in a couple of places:

And a few things are omitted:

/l2vpn-svc/sites/site["SITE1"]/service/svc-mtu is mandatory and not included in
the example. I'd suggest adding a default instead, the MTU is perhaps not the
first thing you think about when defining a new service. Now it has to be given
/l2vpn-svc/sites/site["SITE1"]/management/type is mandatory and not included in
the example. As soon as a type is set, a number of other things become mandatory
too. Which ones depends on what type you select.
vpn-attachment/vpn-id refers to a VPN that is not defined, but I guess that's
Example broken:
Same things omitted as on p39.
Example broken in a couple of places:
Omits service/svc-mtu and management/type like on p39.
Example broken in a number of places:
Need to move <service> out of <site-network-accesses/>
Missing end tag
Not making up our mind on how to spell signaling/signalling bites us:
Same omissions as on p39.
Example broken:
Some unwanted whitespace crept in:
                     <svc-type>vpws</svc -type >
/l2vpn-svc/vpn-services/vpn-service["12456487" and
"12456488"]/frame-delivery/multicast-gp-port-mapping is mandatory and not
Example broken in a number of places:
Double start tags
I'm guessing the author means "vlan" when saying "dot1q" ?
Wrong end tag
Needs to be lowercase
Need to move <service> out of <site-network-accesses/>
Same omissions as on p39.
Obviously, these XML fixes assume an unchanged YANG model. As they YANG is
fixed/changed, the examples should follow suit.
That's all I found.
From: Jan Lindblad [mailto:janl@tail-f.com] 
Sent: 17 January 2018 11:29
To: Adrian Farrel
Cc: bclaise@cisco.com; Qin Wu
Subject: Re: Cheeky request
You did such a good job with the L3SMbis draft that it should come as no
surprise that we are all queueing up to have you as a reviewer.

https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ is now
very close to WG last call and we just made a request for "early" YANG Doctor

But if you were able to look at it as well, that would be rather good. Of
course, you are allowed to be tired/bored/busy :-)
Flattery is often effective ;-) Thank you for asking. I would certainly be
interested to have a good look at all IETF service models, and perhaps better to
get into the habit of doing that before the publication rather than after :-/ I
guess it's primarily going to be a question of when you need the answer. By when
would you need it?
Best Regards,
Jan Lindblad,  <mailto:janl@tail-f.com> janl@tail-f.com, +46 702855728
Solutions Architect, Business Development, Tail-f
Tail-f is now a part of Cisco