A YANG Data Model for Fabric Topology in Data-Center Networks
draft-ietf-i2rs-yang-dc-fabric-network-topology-12

Nit:

1.  Introduction

   These fabrics may be heterogeneous due to implementation of different
   technologies when a DC network is upgraded or new techniques and
   features are enrolled.

enrolled --> rolled out?

I share Ignas's concern about the definition of "fabric". Otherwise, I have a couple of nits:

Abstract: Missing article before "Data Center Network".

§2: Please use the boilerplate from RFC 8174 rather than rolling your own text to constrain the keywords to their all-caps forms.

=== DISCUSS text saved for archiving ===

Discuss (2018-04-03 for -08)
I have concerns about the practical usability of this proposed model as it is specified now. 

The intended decoupling of fabric implementation properties (what is termed as "underlay network infrastructure" in the document) and its topology seems to be contradicting to general operational practices of fabric based networks. It is generally true for the context of the overlay but that is not what the document seems to be focusing on. Fabric defines and implements the underlay, not the other way around. 

The document does not contain a sufficient description of the logic of the model itself, the reasons for choices made for representation of types and attributes, and at the same time descriptions in modules are single lines that do not add clarification beyond being copies of leaf names. Either there needs to be a section that describes the logic of the model and how it relates to other models, also including examples, or module description fields need to have enough content to be able to have equivalent understanding of model intent and operation. Both are strongly encouraged, as descriptions have value of itself for being a reference for use, and model description is needed for understanding how this particular model fits into the larger hierarchy. Network management does not end at the boundary of the single domain-specific model, it is important to build it into a whole system. 

Why TE topology model is not sufficient for modelling the representation of DC fabric? Why is DC fabric network topology special compared to any generic fabric based topology?

How this model could be used for representing more than two stage fabrics that are in wide deployment? 

Limiting port bandwidth to a fixed rate is too restrictive. The model as specified already does not cover a set of port speeds that are in deployment.

How would a device that has more than a single role in the fabric be represented? 

Service capabilities as they are described belong to the overlay context while they are called device capabilities. Are those the only possible service capabilities? What is the effect of configuring those capabilities? 

What is compose-fabric RPC? The document does not define any RPCs. 

What is policy driven traffic behavior? Is there the only one policy that fits all possible deployment scenarios? 

Looking at the history of the document from the individual submission time and the comments received, it seems that the point fixes to the text went in to cover the specific comments but not to address the broader scope of comments. The document would definitely benefit from a major rewrite clarifying the logic behind the decisions made, aligning more with the operational practice of fabric based network design and deployment, and bringing the content in YANG modules to be self-describing.

===

Fabric and POD are not equivalent terms.

I2RS use case requirements document has expired 11 months ago. Use cases documents are good for tracking the work progress of specification documents, it is questionable whether standalone use cases documents provide value beyond historic record. Is the reference to I2RS use cases document really needed? 

What is atomic network?

VLAN is not a fabric building technology as such, while Ethernet is. 

What is the need for VNI capacity leaves? What is their effect if configured?

The document intermixes ietf-fabric-* and ietf-dc-fabric-* namespaces.

Serial port-type is present while Infiniband is not - Infiniband based fabrics are widely deployed. What is the extensibility mechanism for adding in new port types?
 
Is there any deployment experience with this model? The ODL faas project hasn't got much activity over last two years. Are you aware of any other implementations or deployments?

Please use RFC 8174 boilerplate!

I support Ignas's DISCUSS.