Subject: Re: [Teas] Benjamin Kaduk's Discuss on draft-ietf-teas-yang-te-types-10: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 1 Nov 2019 13:58:40 -0700

Hi Tarek,

Thanks for asking netmod and passing on the answer -- that's quite helpful
for me to know.

Unfortunately, I've forgotten where we are on the rest of the document --
is there a -12 forthcoming or should I go back and look at the -11?

Thanks,

Ben

On Thu, Oct 31, 2019 at 05:29:26AM +0000, Tarek Saad wrote:
> Hi Benjamin,
> 
> Thanks again for your comments. We poked netmod WG about the point you raised on "ordered by user" for state list.
> The response we got (see attached), is for state lists, it's all about what the system orders.
> 
> For NMDA (intended/applied), the rw list will be marked with "ordered by user" and applied/state returns the items as ordered by system - they are supposed to match the user input in this case.
> 
> With this, I believe the order as we have is ok.
> 
> Regards,
> Tarek
> 
> 
> 
> On 10/4/19, 5:02 PM, "Benjamin Kaduk" <[email-masked]> wrote:
> 
>     On Tue, Oct 01, 2019 at 05:41:37PM +0000, Tarek Saad wrote:
>     > Hi Benjamin,
>     > 
>     > Thank you very much for the thorough review and for the valuable comments. We have uploaded revision -11 that attempts to address those comments. Please see inline for detailed responses. Let us know if there are further outstanding comments.
>     > 
>     > On 8/20/19, 1:27 PM, "Benjamin Kaduk via Datatracker" <[email-masked]> wrote:
>     > 
>     >     Benjamin Kaduk has entered the following ballot position for
>     >     draft-ietf-teas-yang-te-types-10: 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Kd6NW5ctLWr7GB646PVmMByvi8wQxPILpKhHvGQeRHY&m=hnPuRIqXqStfK232Nk2hmq9WsTD2edVNgVLywB7I9S8&s=-tmE5kZMwh42TgMAaC3M4xeGTxYdYNt5fZ7gnVI59m0&e=
>     >  
>     >     for more information about IESG DISCUSS and COMMENT positions.
>     >     
>     >     
>     >     The document, along with other ballot positions, can be found here:
>     >     https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dteas-2Dyang-2Dte-2Dtypes_&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Kd6NW5ctLWr7GB646PVmMByvi8wQxPILpKhHvGQeRHY&m=hnPuRIqXqStfK232Nk2hmq9WsTD2edVNgVLywB7I9S8&s=RkaTEY5gt6bhkr_3YkKb0CkmkQyY4-GYjfuvWkkKVaQ&e= 
>     >     
>     >     
>     >     
>     >     ----------------------------------------------------------------------
>     >     DISCUSS:
>     >     ----------------------------------------------------------------------
>     >     
>     >     There's a couple points (describe further in the comment section) that
>     >     I'd like to get a bit more clarity on:
>     >     
>     >     (1) the semantics of admin-group hex strings of length smaller than 11
>     > [TS]: RFC6991 defines the hex-string as stream of octets - separated by colon. The below are acceptable representations that result in same value (bit-position 0 is set).
>     > 01
>     > 00:01
>     > 00:00:00:01
>     
>     I'm not coming to the conclusion just based on what's written in this
>     document and RFC 6991.  You seem to be assuming that the hex string is
>     mapped to the four-octet bitmask using a little-endian representation of
>     the bitmask with zero padding, but I can't find where that's stated.
> [TS]: Yes, our assumption was it's HBO representation of octets for the hex-string type. Since hex-string type seems to allow for both endianness (seems to be the case from RFC 6991), we are OK to add text to dictate little endian/HBO in our model for this.
> 
> 
>     
>     >      (2) the units for the te-bandwidth numerical values (and in what cases
>     >     no units are needed), and for performance-metrics-*-way-bandwidth values
>     > [TS]: The unit is technology dependent. For example for packet, the example we give in the description is inline with the type bandwidth-ieee-float32 defined in RFC8294. We can clarify this further in description if needed.
>     
>     I was most concerned about the "packet switching type" since my cursory
>     look at OTN and/or DWDM indicated that the listed parameters do imply an
>     absolute bandwidth.  Please do further clarify what the units are for the
>     float32 value used for packet-switching types.
> [TS]: Yes, it is bytes per second as per bandwidth-ieee-float32 (RFC8294) -also inline with rfc3630 and rfc5305#section-3.6. We can add the (not bits!) as per your suggestion to highlight this.
> NEW:
> "units are bytes (not bits!) per second"
> 
>     >     (3) whether threshold-accelerated-advertisement's use of relative vs.
>     >     absolute values requires any special handling
>     > [TS]: these are absolute values and inline with the rfc7810#section-5 and rfc7471#section-5
>     [comments below]
>     
>     >     (4) whether we want to specify any requirements/error-handling/etc. when
>     >     there is potential for "nonsense" configuration, such as a
>     >     max-constraint being configured as numerically smaller than a
>     >     min-constraint
>     > [TS]: We have some checks where it was needed. Implementations can also make additional restrictive checks with a deviations if needed.
>     
>     Okay.
>     
>     >     (5) what the "variation" in the te-packet-types module's leafs is
>     >     intending to measure.
>     > [TS]: the per link delay variation as defined in RFC7823.    
>     
>     I looked at RFC 7823 and it doesn't help me very much.  Is there a
>     mathematical formula for what it measures?
> 
> [TS]: I think RFC3393 further clarifies the definition of PDV.
> 1.2. Definition
> 
>    A definition of the IP Packet Delay Variation (ipdv) can be given for
>    packets inside a stream of packets.
> 
>    The ipdv of a pair of packets within a stream of packets is defined
>    for a selected pair of packets in the stream going from measurement
>    point MP1 to measurement point MP2.
> 
>    The ipdv is the difference between the one-way-delay of the selected
>    packets.    
> 
>     
>     >     ----------------------------------------------------------------------
>     >     COMMENT:
>     >     ----------------------------------------------------------------------
>     >     
>     >     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.
>     >     
>     > [TS]: Agreed. For 'suppression-interval', it is detailed in rfc7810#section-6. We will update the description/reference for this.
>     > 
>     >     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.
>     > [TS]: updated.
>     >     
>     >     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.
>     > [TS]: this was discussed on the WG mail list, and agreement was to keep TE node ID as dotted-quad 4 octets. We updated the description as below.. https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/teas/bP5VurFZKQVx3hNWxUVz6alRIGg__;!8WoA6RjC81c!QzYpTPxbg-aKPGhbRPxgYU7B7c_NlriZzhfN9Ji4A_HgoQ5ByOIHiqBtYB9JKQ$ 
>     > We can update description to:
>     > OLD:
>     >        The identifier is represented as 32-bit unsigned integer in
>     >        the dotted-quad notation.
>     > NEW:
>     >        The identifier is represented as 4 octets in dotted-quad notation.    
>     >        te-metric:
>     >     
>     >           A type representing the TE link metric as defined in [RFC3785].
>     >     
>     >     (editorial) the phrase "link metric" does not appear in RFC 3785.
>     > [TS]: Sure. 
>     > OLD:
>     > A type representing the TE <link> metric as defined in [RFC3785].
>     >  
>     > NEW:
>     > A type representing the TE metric as defined in [RFC3785].
>     >     
>     >     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.
>     > [TS]: update to: 
>     > NEW:
>     >        The ietf-te-packet-types module covers the common types and groupings
>     >        that are specific to packet technology.
>     >     
>     >        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.
>     > [TS]: update text to:
>     > NEW: A YANG grouping that contains the generic performance metrics and additional packet specific metrics.
>     >     
>     >     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?
>     > 
>     > [TS]: number is stored as 32-bits. As indicated earlier:
>     > 01
>     > 00:01
>     > 00:00:00:01 all indicate bit-position 0 is set and can internally be represented as 0x00000001
>     > 
>     >     
>     >       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".
>     > [TS]: The RFCs refer to it as "anomaly or anomalous". We updated the description to indicate this.
>     >     
>     >       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)?
>     > [TS]: An answer was given earlier, let us know if that clarifies.
>     >     
>     >       typedef te-metric {
>     >         type uint32;
>     >         description "TE link metric";
>     >         reference "RFC3785";
>     >     
>     >     [same comment about "link metric" and 3785]
>     > [TS]: Addressed.
>     >     
>     >       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]
>     > [TS]: Addressed.
>     >     
>     >       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.
>     > [TS]: Yes, created a common type and referenced it the respective typedefs.
>     >     
>     >       identity se-style-desired {
>     >         [...]
>     >     
>     >     (et seq) The rtgdir's comments about whether 'base' should be present
>     >     seems relevant for these as well.
>     > [TS]: thanks for pointing it out, added the missing base.
>     >     
>     >       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)?
>     > [TS]: These identities simply indicate the LSP attributes. Every flag has its own semantics. The respective RFCs describe whether any action is to be taken by nodes along the LSP path.
>     > 
>     >       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).
>     > [TS]: expanded.
>     >     
>     >       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"?
>     > [TS]: yes, RFC7571 uses the term "required" (as we have in description). We renamed the identity to be in sync with the RFC.
>     > OLD:
>     > identity loopback-desired {
>     > NEW:
>     > identity loopback-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?
>     > [TS]: RFC 8169 section 4.4 uses "requested" - we think this can be equated to desired.
>     > <snip>
>     > .. indicates to the egress node that RTM is requested
>     > </snip>
>     > 
>     > updated:
>     > NEW:
>     >       identity rtm-set-desired {
>     >         description
>     >           "Residence Time Measurement (RTM) attribute flag requested";
>     > 
>     > 
>     >     
>     >       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.]
>     > [TS]: yes, this was discussed and the choice was to pick identities over enums for extensibility. We used enums in places where extensions were not expected.
>     >     
>     >       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?
>     > [TS]: NEW:
>     >           "Association Type Recovery used to associate LSPs of
>     >            same tunnel for recovery";
>     >     
>     >       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.
>     > [TS]: Added references.
>     >     
>     >       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.
>     > [TS]: reworded:
>     > NEW:
>     > ..................................................................................... The path that is
>     > returned by the external source may require further local
>     > computation on the device.";
>     >     
>     > 
>     >       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";
>     > [TS]: no, none standardized for TE exists as of yet.
>     >     
>     >     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?
>     > [TS]: we've only modelled possible state outputs. There is no standard state-machine. Implementations may execute a state-machine for transitions, but we did not think it needs to be covered by the model.
>     >     
>     >       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.
>     > [TS]: renamed identity 'teardown' and added reference to RFC3209 section 2.5 talks about these general principles.
>     >     
>     >       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?
>     > [TS]: Update to:
>     > NEW:
>     >           "A metric that optimizes to a maximum the number of excluded resources
>     >            specified in a set";
>     >     
>     >       grouping performance-metrics-one-way-bandwidth {
>     >         [....]
>     >     
>     >     What are the units on the bandwidth values herein?  bits per second?
>     > [TS]: The type bandwidth-ieee-float32 is defined in RFC8294. The expected units are bytes per second (this is also inline with rfc3630 and rfc5305#section-3.6).
>     
>     I note that RFC 5305 even feels a need for a parenthetical: "units are
>     bytes (not bits!) per second".  To me, the risk/reward is clearly in favor
>     of being explicit.
> [TS]: addressed earlier.
>     
>     >           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)?
>     > [TS]: yes, but these are currently defined as absolute threshold values - not differences/relative.
>     
>     The "difference between the last advertised value and current measured
>     value" is a difference with respect to a baseline, which, while still
>     measured in the same units, is qualitatively different than an absolute
>     value (i.e., against zero baseline).  The difference is much smaller than
>     when we go to a percentage difference, where the units change, but the
>     semantics are slightly different.  Anyway, it sounds like you don't think
>     there is a problem here, so I can accpet that.
>     
>     >       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?
>     > [TS]: this weight is input to optimization function when trying to optimize for multiple metrics. A higher weight signifies a more important metric when trying to find optimal path. 
>     
>     What reference chain can the reader follow to learn this fact?
> [TS]: several references for multiple metric optimization can be found in literature.. The closest in IETF I found was in rfc8189. We can add it to the reference/description.
>     
>     >         container path-srlgs-names {
>     >             [...]
>     >             leaf-list names {
>     >               type string;
>     >               description "List named SRLGs";
>     >     
>     >     nit: missing "of"?
>     > [TS]: updated.
>     >     
>     >       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.
>     > [TS]: Reworded to clarify.
>     > NEW:
>     >             "The type of resource disjointness.
>     >              When configured for a primary path, the disjointness level applies to
>     >              all secondary LSPs. When configured for a secondary path, disjointness
>     >              level overrides the one configured for the primary path";
>     >     
>     >         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?)
>     > [TS]: We discussed this within the authors. We think ‘ordered-by user’ for config false leafs will be ignored -- and hence would fallback to the default (‘ordered-by system’) as per RFC6020. Note, we think this is a common behavior that affect NMDA model(s) when extracting applied configuration. Please correct our thinking if this is not true and we’ll try to address it.
>     
>     I have essentially no domain knowledge on this point; we'd need to call in
>     some outside expert if we feel an authoritative answer is important.
> [TS]: emailed to netmod and response stated earlier.
> 
> Regards,
> Tarek
> 
>     Thanks for the updates,
>     
>     Ben
>     
>     > 
>     >     
>     >     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?
>     > [TS]: these are measured values over a time period and maintained as state. The minimum/maximum being over the last period.
>     >     
>     >              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?
>     > [TS]: This attempts to model the parameters as described in RFC7823 (including delay variation/jitter).
>     >     
>     >              leaf one-way-packet-loss {
>     >                type decimal64 {
>     >                  fraction-digits 6;
>     >                  range "0 .. 50.331642";
>     >     
>     >     Is there a reason for the oddly specific upper limit?
>     > [TS]: this is described in https://urldefense.com/v3/__https://tools.ietf.org/html/rfc7810*section-4.4__;Iw!8WoA6RjC81c!QzYpTPxbg-aKPGhbRPxgYU7B7c_NlriZzhfN9Ji4A_HgoQ5ByOIHiqAcSkO6tw$  . Updated the description and reference to indicate this.
>     >    “Link Loss: This 24-bit field carries link packet loss as a percentage
>     >    of the total traffic sent over a configurable interval.  The basic
>     >    unit is 0.000003%, where (2^24 - 2) is 50.331642%. “
>     > 
>     > 
>     >     I also can't quite convince myself from the RFC 7950 grammar whether the
>     >     quotes on the range are valid and/or needed.
>     > [TS]: RF7950 expects a string for the range argument - so it's OK. Also, made it consistent across the modules
>     >     
>     >     I also am unsure as to how useful the "normality" is for some of these,
>     >     like the packet loss and delay-variation values.
>     > [TS]: RFC7823 suggests possible utility of those values.
>     > 
>     > Regards,
>     > Tarek
>     >     
>     >     [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.)
>     >     
>     >     
>     >     
>     > 
>     
> 

> Date: Mon, 28 Oct 2019 08:42:57 +0100 (CET)
> From: Martin Bjorklund <[email-masked]>
> To: [email-masked]
> Cc: [email-masked], [email-masked],
>  [email-masked]
> Subject: Re: [netmod] Effect of ordered by user on state(config false) list
> X-Mailer: Mew version 6.8 on Emacs 25.2
> 
> Hi,
> 
> Tarek Saad <tsaad=[email-masked]> wrote:
> > Hi,
> > 
> > We are wondering if “ordered by user” has any effect on a (config
> > false)/state list?
> > Given RFC6020 specifies “ordered by system” as the default order, does
> > this mean it is the order assumed for a state list with “ordered by
> > user”?
> 
> There is no effect "on the wire"; the entries are sent in the order
> determined by the server in both cases.  But it informs to the
> consumer of the data model that the order of the list entries carries
> some meaning.
> 
> 
> /martin
> 
> 

> Date: Mon, 28 Oct 2019 08:47:53 +0000
> From: "Schönwälder, Jürgen" <[email-masked]>
> To: Martin Bjorklund <[email-masked]>
> CC: "tsaad=[email-masked]" <[email-masked]>,
>  "[email-masked]"
>  <[email-masked]>, "[email-masked]"
>  <[email-masked]>
> Subject: Re: [netmod] Effect of ordered by user on state(config false) list
> 
> On Mon, Oct 28, 2019 at 08:42:57AM +0100, Martin Bjorklund wrote:
> > Hi,
> > 
> > Tarek Saad <tsaad=[email-masked]> wrote:
> > > Hi,
> > > 
> > > We are wondering if “ordered by user” has any effect on a (config
> > > false)/state list?
> > > Given RFC6020 specifies “ordered by system” as the default order, does
> > > this mean it is the order assumed for a state list with “ordered by
> > > user”?
> > 
> > There is no effect "on the wire"; the entries are sent in the order
> > determined by the server in both cases.  But it informs to the
> > consumer of the data model that the order of the list entries carries
> > some meaning.
> >
> 
> For operational is always about what the system actually does.
> 
> For ordered by user entries configured by intended, the order of
> entries used by the system should be the order defined by the users
> but ultimately operational needs to report what is actually used. (If
> a system fails to honor ordered by user, this should be visible from
> comparing operational and intended. This is essential for debugging.)
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://urldefense.com/v3/__https://www.jacobs-university.de/__;!8WoA6RjC81c!Q1j8Eo7gWrzRD2s-zQP9mzf1CEc2Apf6phYBzgFGry5SdHbe1fXOKi13j0aTUw$ >
>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 1 Nov 2019 20:44:33 -0500

Benjamin, Hi!

There is another version coming up -- will be published before the deadline
on Monday. The new version addresses the last set of nits from you (adding
more text to the description of a couple of leafs).

Please wait for the new version to come out and then revisit your comments.

Regards,
-Pavan (on behalf of the authors)

On Fri, Nov 1, 2019 at 3:58 PM Benjamin Kaduk <[email-masked]> wrote:

> > Thanks again for your comments. We poked netmod WG about the point you
> raised on "ordered by user" for state list.
> > For NMDA (intended/applied), the rw list will be marked with "ordered by
> user" and applied/state returns the items as ordered by system - they are
> supposed to match the user input in this case.
> >
> >     > Thank you very much for the thorough review and for the valuable
> comments. We have uploaded revision -11 that attempts to address those
> comments. Please see inline for detailed responses. Let us know if there
> are further outstanding comments.
> >     >
> >     >     Please refer to
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Kd6NW5ctLWr7GB646PVmMByvi8wQxPILpKhHvGQeRHY&m=hnPuRIqXqStfK232Nk2hmq9WsTD2edVNgVLywB7I9S8&s=-tmE5kZMwh42TgMAaC3M4xeGTxYdYNt5fZ7gnVI59m0&e=
> >     >
> >     > [TS]: RFC6991 defines the hex-string as stream of octets -
> separated by colon. The below are acceptable representations that result in
> same value (bit-position 0 is set).
> >     > 01
> >     > 00:01
> >     > 00:00:00:01
> >
> > [TS]: Yes, our assumption was it's HBO representation of octets for the
> hex-string type. Since hex-string type seems to allow for both endianness
> (seems to be the case from RFC 6991), we are OK to add text to dictate
> little endian/HBO in our model for this.
> >
> >
> >
> >     >     no units are needed), and for
> performance-metrics-*-way-bandwidth values
> >     > [TS]: The unit is technology dependent. For example for packet,
> the example we give in the description is inline with the type
> bandwidth-ieee-float32 defined in RFC8294. We can clarify this further in
> description if needed.
> >
> > [TS]: Yes, it is bytes per second as per bandwidth-ieee-float32
> (RFC8294) -also inline with rfc3630 and rfc5305#section-3.6. We can add the
> (not bits!) as per your suggestion to highlight this.
> > NEW:
> >     > [TS]: We have some checks where it was needed. Implementations can
> also make additional restrictive checks with a deviations if needed.
> >
> >     Okay.
> >
> >     > [TS]: Agreed. For 'suppression-interval', it is detailed in
> rfc7810#section-6. We will update the description/reference for this.
> >     >
> >     >     Section 3
> >     >
> >     > [TS]: this was discussed on the WG mail list, and agreement was to
> keep TE node ID as dotted-quad 4 octets. We updated the description as
> below..
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/teas/bP5VurFZKQVx3hNWxUVz6alRIGg__;!8WoA6RjC81c!QzYpTPxbg-aKPGhbRPxgYU7B7c_NlriZzhfN9Ji4A_HgoQ5ByOIHiqBtYB9JKQ$
> >     >           +
> '1(\.([\da-fA-F]{0,5}[02468aAcCeE]?)?)?[pP](\+)?(12[0-7]|'
> >     >           +
> '1(\.([\da-fA-F]{0,5}[02468aAcCeE]?)?)?[pP](\+)?(12[0-7]|'
> >     > [TS]: These identities simply indicate the LSP attributes. Every
> flag has its own semantics. The respective RFCs describe whether any action
> is to be taken by nodes along the LSP path.
> >     >
> >     > [TS]: yes, RFC7571 uses the term "required" (as we have in
> description). We renamed the identity to be in sync with the RFC.
> >     > OLD:
> >     > [TS]: yes, this was discussed and the choice was to pick
> identities over enums for extensibility. We used enums in places where
> extensions were not expected.
> >     >
> >     > [TS]: we've only modelled possible state outputs. There is no
> standard state-machine. Implementations may execute a state-machine for
> transitions, but we did not think it needs to be covered by the model.
> >     >
> >     > [TS]: renamed identity 'teardown' and added reference to RFC3209
> section 2.5 talks about these general principles.
> >     >
> >     > [TS]: The type bandwidth-ieee-float32 is defined in RFC8294. The
> expected units are bytes per second (this is also inline with rfc3630 and
> rfc5305#section-3.6).
> >
> >     > [TS]: this weight is input to optimization function when trying to
> optimize for multiple metrics. A higher weight signifies a more important
> metric when trying to find optimal path.
> >
> > [TS]: several references for multiple metric optimization can be found
> in literature.. The closest in IETF I found was in rfc8189. We can add it
> to the reference/description.
> >
> >     > [TS]: We discussed this within the authors. We think ‘ordered-by
> user’ for config false leafs will be ignored -- and hence would fallback to
> the default (‘ordered-by system’) as per RFC6020. Note, we think this is a
> common behavior that affect NMDA model(s) when extracting applied
> configuration. Please correct our thinking if this is not true and we’ll
> try to address it.
> >
> >     > [TS]: these are measured values over a time period and maintained
> as state. The minimum/maximum being over the last period.
> >     >
> >     > [TS]: This attempts to model the parameters as described in
> RFC7823 (including delay variation/jitter).
> >     >
> >     > [TS]: this is described in
> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc7810*section-4.4__;Iw!8WoA6RjC81c!QzYpTPxbg-aKPGhbRPxgYU7B7c_NlriZzhfN9Ji4A_HgoQ5ByOIHiqAcSkO6tw$
> . Updated the description and reference to indicate this.
> >     > [TS]: RF7950 expects a string for the range argument - so it's OK.
> Also, made it consistent across the modules
> >     >
> > Fax:   +49 421 200 3103         <
> https://urldefense.com/v3/__https://www.jacobs-university.de/__;!8WoA6RjC81c!Q1j8Eo7gWrzRD2s-zQP9mzf1CEc2Apf6phYBzgFGry5SdHbe1fXOKi13j0aTUw$
> >
> >
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: Tarek Saad <[email-masked]>
Date: Sat, 2 Nov 2019 18:49:33 +0000

Hi Benjamin,

I’ve just uploaded version 12 of the draft @ https://tools.ietf.org/html/draft-ietf-teas-yang-te-types-12
Please let us know if that addresses all your comments.

Regards,
Tarek

From: Teas <[email-masked]> on behalf of Vishnu Pavan Beeram <[email-masked]>
Date: Friday, November 1, 2019 at 9:45 PM
To: Benjamin Kaduk <[email-masked]>
Cc: Lou Berger <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, Tarek Saad <tsaad=[email-masked]>
Subject: Re: [Teas] Benjamin Kaduk's Discuss on draft-ietf-teas-yang-te-types-10: (with DISCUSS and COMMENT)

Benjamin, Hi!

There is another version coming up -- will be published before the deadline on Monday. The new version addresses the last set of nits from you (adding more text to the description of a couple of leafs).

Regards,

On Fri, Nov 1, 2019 at 3:58 PM Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tarek,

Thanks,

Ben

On Thu, Oct 31, 2019 at 05:29:26AM +0000, Tarek Saad wrote:
> On 10/4/19, 5:02 PM, "Benjamin Kaduk" <[email-masked]<mailto:[email-masked]>> wrote:
>
>     > On 8/20/19, 1:27 PM, "Benjamin Kaduk via Datatracker" <[email-masked]<mailto:[email-masked]>> wrote:
>     >
>     > [TS]: this was discussed on the WG mail list, and agreement was to keep TE node ID as dotted-quad 4 octets. We updated the description as below.. https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/teas/bP5VurFZKQVx3hNWxUVz6alRIGg__;!8WoA6RjC81c!QzYpTPxbg-aKPGhbRPxgYU7B7c_NlriZzhfN9Ji4A_HgoQ5ByOIHiqBtYB9JKQ$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/teas/bP5VurFZKQVx3hNWxUVz6alRIGg__;!8WoA6RjC81c!QzYpTPxbg-aKPGhbRPxgYU7B7c_NlriZzhfN9Ji4A_HgoQ5ByOIHiqBtYB9JKQ$>
>     > ...................................................................................... The path that is
>     > [TS]: renamed identity 'teardown' and added reference to RFC3209 section 2.5 talks about these general principles..
>     >
>     > [TS]: this is described in https://urldefense.com/v3/__https://tools.ietf.org/html/rfc7810*section-4.4__;Iw!8WoA6RjC81c!QzYpTPxbg-aKPGhbRPxgYU7B7c_NlriZzhfN9Ji4A_HgoQ5ByOIHiqAcSkO6tw$<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7810*section-4.4__;Iw!8WoA6RjC81c!QzYpTPxbg-aKPGhbRPxgYU7B7c_NlriZzhfN9Ji4A_HgoQ5ByOIHiqAcSkO6tw$>  . Updated the description and reference to indicate this.

> From: Martin Bjorklund <[email-masked]<mailto:[email-masked]>>
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>,
>  [email-masked]<mailto:[email-masked]>
> Tarek Saad <tsaad=[email-masked]<mailto:[email-masked]>> wrote:
> > Hi,
> >

> From: "Schönwälder, Jürgen" <[email-masked]<mailto:[email-masked]>>
> To: Martin Bjorklund <[email-masked]<mailto:[email-masked]>>
> CC: "tsaad=[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,
>  "[email-masked]<mailto:[email-masked]>"
>  <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
>  <[email-masked]<mailto:[email-masked]>>
> > Tarek Saad <tsaad=[email-masked]<mailto:[email-masked]..org>> wrote:
> > > Hi,
> > >
> Fax:   +49 421 200 3103         <https://urldefense.com/v3/__https://www.jacobs-university.de/__;!8WoA6RjC81c!Q1j8Eo7gWrzRD2s-zQP9mzf1CEc2Apf6phYBzgFGry5SdHbe1fXOKi13j0aTUw$<https://urldefense.com/v3/__https:/www.jacobs-university.de/__;!8WoA6RjC81c!Q1j8Eo7gWrzRD2s-zQP9mzf1CEc2Apf6phYBzgFGry5SdHbe1fXOKi13j0aTUw$> >
>

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas