[Teas] Comments on draft-ietf-teas-yang-te-types

Matt Hartley <mhartley.ietf@gmail.com> Mon, 15 October 2018 19:28 UTC

Return-Path: <mhartley.ietf@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7B43A130DDA; Mon, 15 Oct 2018 12:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ylaEXoWJzFhR; Mon, 15 Oct 2018 12:28:57 -0700 (PDT)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636F8124C04; Mon, 15 Oct 2018 12:28:57 -0700 (PDT)
Received: by mail-pf1-x431.google.com with SMTP id m77-v6so10179372pfi.8; Mon, 15 Oct 2018 12:28:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=8uWq18aWSF7XtSzgRaMHn/EHpA+NdJDJqjDRCjP3OWw=; b=Vt+K+EY9Sc3t/HN5Lfuebo+BMjGgZvaHdbkE3S+Zg/O17OlhbY7XEO8naiseViy1ob 0tr6w7UTs6gzwRK4SKQ1xSD840KKFQ/+yc/V8dCAJolkgZkSo9VlMrBmtV0YAASEmEfg SvLJwtjnmc9EwYlt0PjJ4xmbyfIsVW13q8tPt0vDBimtm5MDgiPjxAwm1uzKtc2ySEgP V0088yqNMZSW+wLYuDzUr8Yr4C9NcnfQzHFYZHVia8m627MLEf+DJI0s6TWqLkj26y36 tBkj4K3m4TZySaAuZs1RvjOPK8wOnTV06gJcNpBDxnodMsH8dMkd5cqOw1ZNsF1AB6/9 OuJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=8uWq18aWSF7XtSzgRaMHn/EHpA+NdJDJqjDRCjP3OWw=; b=H0QgOQa4J59Iy03b1fcr8rnDUxH8+wqDeblJv2sn08AfuzpisMbO5c8r9pQ2QH9z5U rIAbxMQIP96COdYHE7KRNABgZP4kBmBCQbtXt2rO/vIXvJE+R/v2iNcLsSFnUFxIOnlL L6J+K+YCGWwUiEA97aVI0OgUjINFEBNn5F/D4j76YyJa/cRDkviz/zTRwYKGJQyUJmJ4 kWmsqA3scVXLOBGlMNA/YlkZQmrbnMgggu3CuLoKxVtAcF728O1qOT/IJPylRVYirIcH CQbCuxW8eTLmnueCy0TsuJEkkgfufdcByW7LiEDRiqn0EgvtngfDTgoicfgmE+EOBqiO UOtg==
X-Gm-Message-State: ABuFfog71oxb6yIm3t0CYlUVL+D95EW6fDy/3SkabQyX/BMhMdrjacB/ M9QnRO559kLk0ppkEqwrXDFK2NGpzriH3ieQnRXrCAt2
X-Google-Smtp-Source: ACcGV60BTsfHMY+SV5HFRZrQqjXuzrRZ6i7QAot+wO++N0ZI8145iChoh9xwFULVeqZFgRmrPmfhPJQfUqyYyAGmfSA=
X-Received: by 2002:a63:86c8:: with SMTP id x191-v6mr17453708pgd.39.1539631736703; Mon, 15 Oct 2018 12:28:56 -0700 (PDT)
MIME-Version: 1.0
From: Matt Hartley <mhartley.ietf@gmail.com>
Date: Mon, 15 Oct 2018 15:28:45 -0400
Message-ID: <CAKfnWBhTrSZyfhpUZdBbyZWei_+grj7iGs3MP10mvryGCZ2XfQ@mail.gmail.com>
To: draft-ietf-teas-yang-te-types@ietf.org
Cc: teas@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c050fd057849725f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/XWp3weWOrpcesY8zJ8BjkhJDN3A>
Subject: [Teas] Comments on draft-ietf-teas-yang-te-types
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Oct 2018 19:28:59 -0000


Some LC comments on this. Please note that I haven't really been all that
involved in the discussions and I'm coming to it fairly cold... which may
or may not be a good thing :)

p26: identity lsp-protection-unidir-1-to-1: description is "LSP protection
'1+1 Unidirectional Protection'", but that's inconsisent with the name. I'd
expect this to be for 1:1 protection, not 1+1. Or if it is for 1+1, the
name should be ...1-plus-1, shouldn't it? Same for the bidir one below.

p32: identity lsp-encoding-optical-channel: this has the same description
as the next one. One of these needs fixing.

p33: identity route-usage-type has route-exclude-ero as an option. Is that
intended to cover XROs too? Or do we need another identity for XROs?

p34: identity te-optimization-criterion: Can't an optimization criterion be
anything that can be used as a metric? Do we actually need a separate type
here? If we do, what does 'cost' refer to? And is the delay the average or
minimum (as for the metrics)? the model seems inconsitent with itself here.

p37: identity oduc: description is "ODUCn bit rate." For all the other
elements here the ODU type is the same in the description as in the
identity name (barring capitalization) but here it's different. Is there a
reason for that or does something need to be fixed?

p39: grouping te-topology-identifier: leaf provider-id: how do we ensure
uniqueness here? Is this something that will need to be managed in the same
way as IP addresses and AS numbers? Or should we recommend that something
like an AS number or IP address owned by the provider be used here?

p39: grouping te-topology-identifier: leaf topology-id: should we put some
RFC 2119 language in there, if things MUST be unique? And what's the scope
of that uniqueness? Within the provider/client pair? Globally? Something
else? It's unclear.

10.1: You've got the other yang models we're working on as normative
references. Isn't the idea that this document stands alone, and those
documents can reference it? Why do we need them as normative references

Note: Everything after here is nits...

p5, admin-groups: "A union type for TE link's" -> "A union type for a TE

p5, srlg: "representing the Shared" -> "representing a Shared"

p6, protection-external-commands: "trouble shooting" -> "troubleshooting"

p7: te-class-type, bc-type, bc-model-type: "Diffserv-TE" -> "DS-TE" (since
you went to the trouble of defining this up front...)

p12: typedef te-link-access-type, enum multi-access: is NBMA something that
we can assume is generally understood, or does it need to be expanded?

p13: typedef te-oper-status, enum unknown: I think just "Status cannot be
determined" would do for the description. The rest is redundant.

p13: typedef te-oper-status, enum maintenance: the description here doesn't
reference the control plane (contrast preparing-maintenance above). Would
it be worth specifying that the resource is disabled in both planes?

p17: typedef srlg: I think having the description as "SRLG type" is
confusing (my initial reaction was 'hang on, SRLGs don't have types...').
Maybe just "SRLG"?

p19: identity of-minimize-cost-path: That's a really confusing name. I
thought it was a mangled version of minimize-cost-of-path until I figured
out that the 'of' is just a prefix for objective-function. Maybe
of-minimize-path-cost would be better? Similarly for the next one... maybe

p20: identity path-externally-queried: The description is awkward. Maybe:
"Constrained-path LSP in which the path is obtained by querying an external
source, such as a PCE server. In the case that an LSP is defined to be
externally queried, it may also have associated explicit definitions
provided to the external source to aid computation. The path that is
returned by the external source need not be a wholly resolved path back to
the originating system; some additional local computation may also be

p28: identity protection-external-commands: "trouble shooting" ->

p32: identity path-signaling-type: please put a blank line before this so
it's more obvious it's a new base type when reading it.

p36: identity srlg-preferred: is this best-effort? If so, could we have
that in the description?

p37: identity otn-rate-type: description could just be "Base type to
identify OTN bit rates." The rest is redundant.