Mohamed Boucadair's Discuss on draft-ietf-teas-yang-te-41

[italobusi]

Mohamed Boucadair has entered the following ballot position for
draft-ietf-teas-yang-te-41: 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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle 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/

---

DISCUSS:

Hi Tarek, Rakesh, Xufeng, Pavan, and Igor,

Thank you for the effort put into this effort. I’m always impressed by the
perseverance of authors who carry a specification for more than a decade.

Thanks to Gyan Mishra for the OPSDIR review and to Tarek for engaging and
clarifying the scope. The changes made in -41 are direct to the point, IMO.

Please find below some few DISCUSS points:

Defaults in reusable groupings are problematic

The generic module includes a set of reusable groupings that can be used by
modules other than those defined in this document. Many of these groupings has
default values that are problematic when used for example in templates/profiles
or in various levels of a given structure. Even a precedence is given to some
layer, the default values will override those and then nullifies the effect of
the precedence.

FWIW, the guidance in RFC8407bis is as follows:

• Do not include a "default" substatement on a leaf or choice unless
  the value applies on all possible contexts.

• Do not include a "config" substatement on a data node unless the
  value applies on all possible contexts.

I think that you can get rid of most of these statements. Anyway, please check
and, for those that you decide to keep, consider adding some motivation text.

Anchoring TE/tunnels in a device

TE structure is designed as a standalone component to which interfaces are then
grafted. I’m puzzled by that part as a natural approach would be to proceed in
the other way around.

I’m not requesting to change the design you had so far. Adding some text about
your design reasoning and why your current design is superior compared to
augmenting the interface module. Thanks.

Unicity scope

CURRENT:
- name: A YANG leaf that holds the named path constraint entry.
This is unique in the list and used as a key.

There are several keys that are used to uniquely identify “something”. Given
the scope of the first model, the unicity scope of these is not clear. Please
consider updating the description of these to make that clear (controller
context, network, else).

---

COMMENT:

No need to motivate the use of YANG

CURRENT:
YANG [RFC6020] and [RFC7950] is a data modeling language that was
introduced to define the contents of a conceptual data store that
allows networked devices to be managed using NETCONF [RFC6241]. YANG
has proved relevant beyond its initial confines, as bindings to other
interfaces (e.g. RESTCONF [RFC8040]) and encoding other than XML
(e.g. JSON) are being defined. Furthermore, YANG data models can be
used as the basis of implementation for other interfaces, such as CLI
and programmatic APIs.

I don’t think this is needed. I would delete this text.

It would be helpful for readers to have early in the document a discussion

about the various concepts (tunnel, lsp, path) and how they relate to each
other.

NMDA Mention

CURRENT:
The Network Management Datastore Architecture (NMDA) [RFC8342]
addresses modeling state data for ephemeral objects. This document
adopts the NMDA model for configuration and state data representation
as per IETF guidelines for new IETF YANG data models.

This statement is not needed anymore per the new guidance in RFC8407bis. You
can delete that part (and also the mention in the modules themselves).

RFC8407bis:
If the document contains major Network Management Datastore
Architecture (NMDA) exceptions or include a temporary non-NMDA module
[RFC8342], then the Introduction section SHOULD mention this fact
with the reasoning that motivated that design. Refer to Section 4.23
for more NMDA-related guidance. Specifically, Section 4.23.2
includes a recommendation for designers to describe and justify any
NMDA exceptions in detail as part of the module itself.

One Data Model:One Module or Multiple DMs

The use in the document is inconsistent. For example,

Section 1:
The data model described herein is divided into two YANG modules.

Section 4.1:
The generic TE YANG data model, defined in the 'ietf-te' YANG module,

I think the text in Section is correct. Please update other parts to be
consistent with that design.

No need to repeat the parent node names

This is a common pattern in the module. For example:

OLD:
+--rw globals
| +--rw named-admin-groups
| | +--rw named-admin-group* [name]
| | ...
| +--rw named-srlgs
| | +--rw named-srlg* [name]
| | ...
| +--rw named-path-constraints
| +--rw named-path-constraint* [name]

NEW:

    +--rw globals
    |  +--rw named-admin-groups
    |  |  +--rw group* [name]
    |  |        ...
    |  +--rw named-srlgs
    |  |  +--rw srlg* [name]
    |  |        ...
    |  +--rw named-path-constraints
    |     +--rw constraint* [name]

(and idem for similar part)

Alias

CURRENT:
alias:

  A YANG leaf that holds an alternate name to the TE tunnel.  Unlike
  the TE tunnel name, the alias can be modified at any time during
  the lifetime of the TE tunnel.

What is the expected usage of the alias?

Name and Identifier

CURRENT:
identifier:

  A YANG leaf that holds an identifier of the tunnel.  This
  identifier is unique among tunnels originated from the same
  ingress device.

You may clarify why/how this is needed vs. using the name as identifier?

IETF Module Template

For both modules, update to align with the template in RFC8407bis:

OLD:
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.";

NEW:
All revisions of IETF and IANA published modules can be found
at the YANG Parameters registry group
(https://www.iana.org/assignments/yang-parameters).

 This version of this YANG module is part of RFC XXXX; see
 the RFC itself for full legal notices.";

Which constraints are supported by a device/controller

Several parameters can be included in a constrained path. However, it was not
clear to me how a device can expose the constrainsts it supports.

Missing references

CURRENT:
reference
"RFC8231, section-7.3.2";
}
..

reference
  "RFC 4655: A Path Computation Element (PCE)-Based

I tagged at least these ones not called out in the narrative text. Please check
all references cited in the module and cite them in the narrative text.

Comments

CURRENT:
/* This grouping is re-used in path-computation YANG model

• defined in [I-D.ietf-teas-yang-path-computation] */

This is repeated several times in the module. I don’t think this is needed for
the published module.

Meaningful description

Many description clauses are too short, while some can be easily digested. An
example is provided below:

CURRENT:
description
"The time between the declaration of an SF or SD condition

These conditions are not described.

Section 8

Please update to follow the template in
https://wiki.ietf.org/group/ops/yang-security-guidelines

Check the classification of your references

For example, the following one are listed as normative while they shouldn’t.
Please fix.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
https://www.rfc-editor.org/rfc/rfc6241.

[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
https://www.rfc-editor.org/rfc/rfc6242.

[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
https://www.rfc-editor.org/rfc/rfc8340.

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
https://www.rfc-editor.org/rfc/rfc8446.

Figure

CURRENT:
192.0.2.1 192.0.2.2 192.0.2.4
+-------+ +-------+ +-------+
| | | | | |
| A +--------+ B +------+ D |
+---+---+ +-------+ +---+---+
| |
| +-------+ |
| | | |
+------------+ C +----------+
| |
+-------+
192.0.2.3

          Figure 10: TE network used in data tree examples

Please indicate how to interpret the addresses listed in the figure.

The example also cite some IPv6 addresses, but these are not shown in the

figure. Please update.

Cheers,
Med

See: https://mailarchive.ietf.org/arch/msg/teas/a03uQ_rHYVS3qTuCRYXPnOWDaWk/