Early Review of draft-ietf-teas-yang-sr-te-topo-04
review-ietf-teas-yang-sr-te-topo-04-yangdoctors-early-lhotka-2019-06-10-00
Review
review-ietf-teas-yang-sr-te-topo-04-yangdoctors-early-lhotka-2019-06-10
This document and YANG module "ietf-sr-topology" contained therein
contribute two new types to the family of network topology data
models: segment routing and segment routing traffic engineering
topologies. The document also provides a companion module
"ietf-sr-topology-state" intended for non-NMDA implementations.
From the YANG point of view, both modules are in a relatively good
shape. Also, as far as I can tell, they satisfy the requirements
specified in RFC 8345.
The example instance data contained in Appendix B successfully passes
formal validation against the date model, which is far from
commonplace for early versions of documents. See however comment #1
below.
**** Comments
1. I have argued several times that using URIs as identifiers of all
network topology objects in RFC 8345 is an overkill. Now, the
present draft demonstrates the consequences: id values used in
many places of the example data (Appendix B) are not valid URIs!
For example, "link-id" leaves have values like
"D1,1-2-1,D2,2-1-1", which is not a URI.
This type violation isn't caught by validating tools because the
"ietf-inet-types:uri" type doesn't specify a regular expession
pattern. However, its description states clearly that the type
represents URI as defined by STD 66.
2. The module uses (indirectly) the grouping "srlr" from the
"ietf-segment-routing-common" module. This grouping defines two
leaves, "lower-bound" and "upper-bound". I assume it is expected
that the former must not be greater than the latter. This is
however not enforced by the data model. My suggestion is to add a
"must" statement to the "srlr" grouping corresponding to this
constraint.
3. Typos in the module text:
- description of grouping "sr-topology-type":
s/toplogies/topologies/
- description of container "sr-mpls":
s/Indiates/Indicates/