[i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

[Ignas Bagdonas <[e-mail]>]

Ignas Bagdonas has entered the following ballot position for
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topology/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?