Re: [Teas] Benjamin Kaduk's Discuss on draft-ietf-teas-yang-te-types-12: (with DISCUSS and COMMENT)
Tarek Saad <tsaad.net@gmail.com> Wed, 13 November 2019 05:18 UTC
Return-Path: <tsaad.net@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBE81200FD; Tue, 12 Nov 2019 21:18:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIRglKs4UGdV; Tue, 12 Nov 2019 21:18:20 -0800 (PST)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 83A3D1200C4; Tue, 12 Nov 2019 21:18:20 -0800 (PST)
Received: by mail-yb1-xb2e.google.com with SMTP id h23so501151ybg.2; Tue, 12 Nov 2019 21:18:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=SZPyNxb5cqEGqXHFIZionntvOgwwRBzrAaurAjH0+1E=; b=IqAsVRrinz1VLUU9SXY2TC7Rz6L4TH937NNfC+3QztJ3oIz4m3zc/bWMzM8PUbcWz1 QS4s+9L/ZbFO/q7XYr2ceDIMiH5/Dd5RnMKjevHw/wP+7YpbgdXvW6u3hnchDzo+PNzG RyiknwYwasfFKs2ld+W86AnvOBGqTEf6xPXtlgTW0sAtXyXt9JKK2wUF6HvXO8dfX8lC DAg4OduECsbGQBsUAk3xpHhwCXbEI7UR+V3BE4AybE4aP260Dv1dTrCITstaNMmlGUiJ 10ZiZ4E6lV+13VoT61SQrDBY8KdMNKPvv5ReNpihHk13fKzEG7ZdsCbm8qFVaIKWIdBl xfOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=SZPyNxb5cqEGqXHFIZionntvOgwwRBzrAaurAjH0+1E=; b=ClCZb8gbqyekqkKnAaFdjnq/Pn0U95H7IaXNqBMxem3KFVQmNpC8IFOG85LdTr5TDs ofoBHevh0FHPWtNEHh5fjJ7Ipb3Iw+wZ/BhUYnEjm9FBg5SgguiNh750x6eyNT8LdtQF zAA+EYSGrWxZjb2Z5K2t873EO7KyWIzdHuY7qOQCyjcO2ZhMGXcTpm1FOdJRwJWDogVw jkL9k36cYRvcc31qPKeJ0YrfSNQ4/An5YOFEQ0QGVAE/9gSIJx6sXj0ZUU2Q7vg3xQoY jZ9ejSP94uGfJUYAfb7rLbOQiIYakQ69AnnkQymTZm2myMiLlPgTyP/Stik9KQsiWLtm lcfQ==
X-Gm-Message-State: APjAAAVqUUqRszxR4LqwZjbDRBmZuC+WRGzEYffjk5pxC9VOhND/hTi4 n5wrhNV5AXxRzgo/+gaWyrV4zP7c9qs=
X-Google-Smtp-Source: APXvYqxSlXeQpi9/uZsiyiKg6PecfkDUa+GLpEIs0bQCRhTDKejxqPogn1AX4a/W8cbLpShbbKQW2A==
X-Received: by 2002:a25:2548:: with SMTP id l69mr1162719ybl.441.1573622299212; Tue, 12 Nov 2019 21:18:19 -0800 (PST)
Received: from DM6PR19MB3689.namprd19.prod.outlook.com ([2603:1036:301:21db::5]) by smtp.gmail.com with ESMTPSA id b12sm352292ywb.35.2019.11.12.21.18.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Nov 2019 21:18:18 -0800 (PST)
From: Tarek Saad <tsaad.net@gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-teas-yang-te-types@ietf.org" <draft-ietf-teas-yang-te-types@ietf.org>, "lberger@labn.net" <lberger@labn.net>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] Benjamin Kaduk's Discuss on draft-ietf-teas-yang-te-types-12: (with DISCUSS and COMMENT)
Thread-Index: AXIuMzYz/5IoDQl6qU8x6w5jqmIVgMbXXRU+
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Wed, 13 Nov 2019 05:18:16 +0000
Message-ID: <DM6PR19MB368971197D840B2E1B8A4CCFFC760@DM6PR19MB3689.namprd19.prod.outlook.com>
References: <157360450753.31787.1635529063369317230.idtracker@ietfa.amsl.com>
In-Reply-To: <157360450753.31787.1635529063369317230.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/MucVsmojTPTjyGT2zo-qItfy6LA>
Subject: Re: [Teas] Benjamin Kaduk's Discuss on draft-ietf-teas-yang-te-types-12: (with DISCUSS and COMMENT)
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: Wed, 13 Nov 2019 05:18:24 -0000
Hi Benjamin, Thanks again. We are OK to make the suggested change to remove ambiguity as below. We are OK either uploading rev -13 (once tool reopens) or address it as an RFC-Editor note.. OLD: typedef admin-group { type yang:hex-string { /* 01:02:03:04 */ length "1..11"; } description "Administrative group/Resource class/Color representation in hex-string type. The Most Significant Byte (MSB) is the farthest to the left in the byte sequence."; NEW: typedef admin-group { type yang:hex-string { /* 01:02:03:04 */ length "1..11"; } description "Administrative group/Resource class/Color representation in hex-string type. The Most Significant Byte (MSB) is the farthest to the left in the byte sequence. Leading zero bytes in the configured value may be omitted for brevity. "; Regards, Tarek (for authors) On 11/12/19, 7:22 PM, "Teas on behalf of Benjamin Kaduk via Datatracker" <teas-bounces@ietf.org on behalf of noreply@ietf.org> wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-teas-yang-te-types-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-types/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the updates in the -12; they're some good improvements! I think I am still looking for a little more clarity on one point, though it can probably be addressed with an RFC-Editor note: (1) the semantics of admin-group hex strings of length smaller than 11 In the -12 we now have: typedef admin-group { type yang:hex-string { /* 01:02:03:04 */ length "1..11"; } description "Administrative group/Resource class/Color representation in hex-string type. The Most Significant Byte (MSB) is the farthest to the left in the byte sequence."; reference "RFC3630 and RFC5305"; } This description still feels potentially ambiguous as to how to interpret a byte sequence with fewer than four bytes -- does "MSB" mean "MSB of the input string" or "MSB of the full-width value"? I suggest adding "Leading zero bytes in the configured value may be omitted for brevity." (but anything with similar clarifying value would be fine). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [comment section from -10 preserved unchanged, for convenience] In general it's hard to examine many of these types and see whether they are fit for purpose without some sense of how they would be used, but of course following a chain of references for all of the types in question wouldu be tedious to the point of exhaustion. I'm reluctant to start getting into examples (since such a list would necessarily be incomplete), but if you want one, the 'suppression-interval' leaf has a very terse description, that will presumably be supplemented by some text in some other document about what exactly is getting suppressed and when, but if I were to try to implement from just this document I'd be doing a lot of guessing. Section 3 types for TE generic types and ietf-te-packet-types for packet specific types. Other technology specific TE types are outside the nits: "packet-specific" and "technology-specific" to hyphenate the compound adjectives. Section 3.1 te-node-id: A type representing the identifier for a node in a TE topology. The identifier is represented as 32-bit unsigned integer in the dotted-quad notation. This attribute MAY be mapped to the Router Why is te-node-id IPv4-centric? E.g., RFC 6119 describes an "IPv6 TE Router ID" TLV as well as the "TE Router ID" TLV that we reference here for the node ID. Furthermore, either it's a 32-bit unsigned integer or it's represented in the dotted-quad notation, but the dotted-quad notation doesn't really count as a 32-bit unsigned integer. te-metric: A type representing the TE link metric as defined in [RFC3785]. (editorial) the phrase "link metric" does not appear in RFC 3785. Section 3.2 The ietf-te-packet-types module covers the common types and groupings specific packet technology. nit: I think there's a word missing here. performance-metrics-attributes-packet: A YANG grouping for the augmentation of packet specific metrics to the generic performance metrics grouping parameters. nit(?) I can't tell which way the augmentation is supposed to go, just from this text. Section 4 typedef admin-group { type yang:hex-string { /* 01:02:03:04 */ length "1..11"; } description "Administrative group/Resource class/Color representation in hex-string type."; reference "RFC3630 and RFC5305"; RFC 5305 says to treat this as essentially a bitmask. What are the semantics when I only supply a string of (say) length 1 or 2? typedef performance-metrics-normality { [...] reference "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. RFC7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions"; None of these three references describes "normal" or "abnormal". typedef te-bandwidth { type string { pattern '0[xX](0((\.0?)?[pP](\+)?0?|(\.0?))|' + '1(\.([\da-fA-F]{0,5}[02468aAcCeE]?)?)?[pP](\+)?(12[0-7]|' + '1[01]\d|0?\d?\d)?)|0[xX][\da-fA-F]{1,8}|\d+' + '(,(0[xX](0((\.0?)?[pP](\+)?0?|(\.0?))|' + '1(\.([\da-fA-F]{0,5}[02468aAcCeE]?)?)?[pP](\+)?(12[0-7]|' + '1[01]\d|0?\d?\d)?)|0[xX][\da-fA-F]{1,8}|\d+))*'; } Can the document shepherd please report what validation has been done for this pattern? For packet switching type, a float number is used, such as 0x1p10. What kind of units are implied for this (and the other types)? typedef te-metric { type uint32; description "TE link metric"; reference "RFC3785"; [same comment about "link metric" and 3785] typedef te-node-id { type yang:dotted-quad; description "A type representing the identifier for a node in a TE topology. The identifier is represented as 32-bit unsigned integer in the dotted-quad notation. [same comment about uint32 vs. dotted-quad] typedef te-oper-status { [...] Is there some way (a grouping?) to deduplicate the admin and operational status enumerations? They seem to be nearly identical in terms of the range of possible values. identity se-style-desired { [...] (et seq) The rtgdir's comments about whether 'base' should be present seems relevant for these as well. identity oob-mapping-flag { [....] identity entropy-label-capability { Are all of the flags based on lsp-attributes-flags supposed to be "desired" in the description (these aren't)? identity oam-mep-entity-desired { base lsp-attributes-flags; description "OAM MEP entities desired"; We probably should expand Maintenance Entity Group End Point (and MIP, below). identity loopback-desired { base lsp-attributes-flags; description "This flag indicates a particular node on the LSP is required to enter loopback mode. This can also be Is there a mismatch between "desired" and "required"? identity rtm-set-desired { base lsp-attributes-flags; description "Residence Time Measurement (RTM) attribute flag"; Is there a mismatch regarding "desired" in the identity name vs. description? identity link-protection-type { description "Base identity for link protection type."; } identity link-protection-unprotected { base link-protection-type; [I assume the WG had some good discussion about identities vs. enumeration and don't want to second-guess that.] identity association-type-recovery { base association-type; description "Association Type Recovery used to association LSPs of same tunnel for recovery"; nit: the grammar seems weird, here; maybe a missing word? identity path-locally-computed { base path-computation-method; description "indicates a constrained-path LSP in which the path is computed by the local LER"; reference "RFC3209"; In line with the gen-art reviewer's comments, a section ref might be useful here. identity path-externally-queried { base path-computation-method; description [...] to the external source to aid computation); and the path that is returned by the external source is not required to provide a wholly resolved path back to the originating system - that is to say, some local computation may also be required"; nit: "provide a wholly resolved path back to the originating system" could potentially be read ambiguously about whether "back to the originating system refers to the path or where the (partial) result is returned to. identity te-tunnel-type { [...] There is no need for a mp2p or mp2mp tunnel type? identity tunnel-state-type { description "Base identity for TE tunnel states"; This is just "tunnel state" not "operational state"? identity lsp-state-type { description "Base identity for TE LSP states"; Is there a state machine for which transitions between states based on this identity are allowed, or is it basically just a full mesh? identity path-invalidation-action-drop-tear { base path-invalidation-action-type; description "TE path invalidation action tear"; Is there a reference for this (or the other path-invalidation-action-type)? My naive reading wants to complete it to "teardown" but I have low confidence that is correct. identity path-metric-optimize-includes { [...] identity path-metric-optimize-excludes { base path-metric-type; description "A metric that optimizes the number of excluded resources specified in a set"; optimizes to minimize or maximize it? grouping performance-metrics-one-way-bandwidth { [....] What are the units on the bandwidth values herein? bits per second? container threshold-accelerated-advertisement { description "When the difference between the last advertised value and current measured value exceed this threshold, anomalous announcement will be triggered."; uses performance-metrics-thresholds; Are we reusing the performance-metrics-threshold container, which up until now has been used for absolute measurements, to hold the corresponding relative values (differences)? grouping optimization-metric-entry { [...] leaf weight { Where is the sense of the 'weight' leaf defined? That is, to larger weight values get more traffic or less traffic? container path-srlgs-names { [...] leaf-list names { type string; description "List named SRLGs"; nit: missing "of"? grouping generic-path-disjointness { description "Path disjointness grouping"; leaf disjointness { type te-path-disjointness; description "The type of resource disjointness. Under primary path, disjointness level applies to all secondary LSPs. Under secondary, disjointness level overrides the one under primary"; What does "under" mean? It seems like it has something to do with the position in the hierarchy where this grouping gets instantiated, which is potentially subtle. container path-properties { config false; [...] container path-route-objects { description "Container for the list of route objects either returned by the computation engine or actually used by an LSP"; list path-route-object { key index; ordered-by user; (How do 'config false' and 'ordered-by user' interact?) Section 5 grouping performance-metrics-attributes-packet { [...] uses te-types:performance-metrics-attributes { augment performance-metrics-one-way { leaf one-way-min-delay { [...] leaf one-way-max-delay { What kind of sanity or error checking is there for the nodes in this model, e.g., if max delay is configured to be smaller than min delay? leaf one-way-delay-variation { type uint32 { range 0..16777215; } description "One-way delay variation in micro seconds."; What does "variation" mean? Deviation from mean? Variance? Mean absolute error? leaf one-way-packet-loss { type decimal64 { fraction-digits 6; range "0 .. 50.331642"; Is there a reason for the oddly specific upper limit? I also can't quite convince myself from the RFC 7950 grammar whether the quotes on the range are valid and/or needed. I also am unsure as to how useful the "normality" is for some of these, like the packet loss and delay-variation values. [same comments about two-way metrics as one-way metrics, I think. Also the -packet variants.] Section 7 We probably could say more here if we want, though I'm as-yet decided on whether we should. That is, things like editing the config could cause traffic to be disallowed, routed on suboptimal paths, routed through locations more easily targeted for other purposes, etc., and reading config/status could reveal information about network topology, which sites might be most sensitive as targets for subsequent attacks, etc.. It's less clear if there's much that would allow for identification of specific users/customers or their traffic, though. Maybe some of the DSCP stuff, in some cases. Section 10.2 A question for the responsible AD: do references that are used in "reference" statements need to be normative references? (E.g., RFC 3471.) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas
- [Teas] Benjamin Kaduk's Discuss on draft-ietf-tea… Benjamin Kaduk via Datatracker
- Re: [Teas] Benjamin Kaduk's Discuss on draft-ietf… Tarek Saad
- Re: [Teas] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk