Skip to main content

Early Review of draft-ietf-teas-yang-sr-te-topo-04

Request Review of draft-ietf-teas-yang-sr-te-topo-04
Requested revision 04 (document currently at 18)
Type Early Review
Team YANG Doctors (yangdoctors)
Deadline 2019-06-24
Requested 2019-05-31
Requested by Lou Berger
Authors Xufeng Liu , Igor Bryskin , Vishnu Pavan Beeram , Tarek Saad , Himanshu C. Shah , Stephane Litkowski
I-D last updated 2019-06-10
Completed reviews Yangdoctors Early review of -04 by Ladislav Lhotka (diff)
Review in preparation for WG LC
Assignment Reviewer Ladislav Lhotka
State Completed
Request Early review on draft-ietf-teas-yang-sr-te-topo by YANG Doctors Assigned
Posted at
Reviewed revision 04 (document currently at 18)
Result Ready w/issues
Completed 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

**** 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

3. Typos in the module text:

   - description of grouping "sr-topology-type":

   - description of container "sr-mpls":