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

["Susan Hares" <[e-mail]>]

Ignas:

 

I’m forwarding Yan’s specific answers to each of your questions. I had held this response back until I tried to learn more about what specific questions were tag with specific DISCUSS quality comments 

per the IESG 2014 DISCUSS criteria comments: 

https://www.ietf.org/blog/discuss-criteria-iesg-review/

 

I’m sure Yan will be glad to make adjustments in the draft (see below).  You will note that you are asking us to put back in RPCs that others had us take out.  

 

This leads me to back to my questions as a Shepherd. My concern is that many of your requested changes are counter to agreements in discussions with WG, TE WG, NETCONF/NETMOD, and previous ADS (OPS, RTG) regarding I2RS drafts.   Since these drafts were delayed due to the reading load of the IESG, it seems we are working under different rules.  So, please specify how your comments match the DISCUSS criteria.  If you are setting new rules for I2RS documents, please detail the new rules of review.   

 

It is too bad that we could not have reviewed these documents during their originally scheduled telechat with previous  ADs.  

 

Susan Hares 

 

-----Original Message-----
From: Ignas Bagdonas [mailto:[e-mail]] 
Sent: Tuesday, April 03, 2018 7:40 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; Susan Hares <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

 

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> 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/> 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.

[Y] The intention of this model is to represent the entire topology of a data center fabric network. The whole network can be considered as a single fabric network which is composed by several PODs defined as “node” in this module. Under these “nodes”, there are supporting-nodes (reference to device-nodes belonged to the POD) and connections. 

 

The term of POD/fabric is a bit confusing in the draft. How about we updating the Terminology section as below?

POD: a module of network, compute, storage, and application components that work together to deliver networking services. It represents a repeatable design pattern. Its components maximize the modularity, scalability, and manageability of data centers.

Fabric: composed of several PODs to form a data center network.

 

Does it make sense?

 

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?

[Y] We discussed with TE topology model authors about this question. For TE, it is more focused on connections for TE and statics for their performance, while this model is to present how a data center network look like with its specific nodes(leaf/spine). 

 

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

[Y] In that case, more roles for interlayer devices can be added. The “role” for device is defined as identity-ref. New roles can be added by defining new identities.

 

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.

[Y] bandwidth is defined as identity-ref. Other speeds can be added by defining new identities.

 

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

[Y] The role for a device-node is defined as leaf-list to support a device with more than one roles. 

 

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?

[Y] Service capabilities is for a fabric not a device. The description for the service capabilities will be corrected. For better extension for other services, we will change current enumeration type to identity-ref. More service identities can be defined in the future by vendors.

 

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

[Y] rpcs were removed in previous version since people say it would leave for vendor-specific implementation.

The rpcs to compose a fabric is as:

    rpc compose-fabric {

        input {

            uses fabric-attributes;

        }

        output {

            leaf fabric-id {

                type fabric-id;

            }

        }

}

To add a node to fabric:

 

    rpc add-node-to-fabric {

        input {

            leaf fabric-id {

                type fabric-id;

            }

            uses device-attributes;

        }

    }

Do you suggest we bring it back to the draft?

 

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

[Y] Policy is needed for the traffic otherwise the traffic will be discard. There can also be normal, which means no policy is needed for all traffic. 

 

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?

[Y] The reference will be removed in v09.

 

What is atomic network?

[Y] The original sentence might be confusing. How about we changing it to “a POD can be considered as a basic structure for management purposes.”?

 

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?

[Y] It is used to say the range of the VNIs for a POD. We will update the description to clarify it.

 

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

[Y] Apologize for the inconsistent. It will be changed to ietf-dc-fabric-* in v09.

 

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?

[Y] Since the port-type is identityref, new port types can be added by defining new identities.

 

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?

[Y] Yes, the implementation is in ODL FAAS. Current module is a part of fass project. It has been done over two years and only maintenance is needed. And we think it is stable.