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

["Zhuangyan (Yan)" <[e-mail]>]

Hi Ignas,

Thanks for your responses and sorry for the delay due to a local holiday. Please see replies inline.

From: Ignas Bagdonas [mailto:[e-mail]]
Sent: Thursday, April 05, 2018 2:38 AM
To: Susan Hares <[e-mail]>; 'The IESG' <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: FW: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)




On 04/04/2018 16:22, Susan Hares wrote:

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

Thank you Yan, this seems to be a practical way forward in bringing clarity to the scope of the document.





You will note that you are asking us to put back in RPCs that others had us take out.

I will note that I am not asking for anything like that. Please re-read my DISCUSS notes.





This leads me to back to my questions as a Shepherd. My concern is that many of your requested changes

I recall raising questions, not requesting 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]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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

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.

[Y] The intention of this model is to represent the entire topology of a data center fabric network.

Yan, can you be specific here - the topology of what? Are we talking about the underlay topology, or an overlay instance topology? That is a major difference and many other comments will depend on this answer. The terminology does not help here too much - data center fabric network may mean many different things if viewed from different contexts.


[Y] We provide an entire topology for a dc fabric. This fabric contains several PODs as its “node”, each of which is composed of a set of underlay nodes (which are device nodes) and their interconnection links, and may implement different overlays. The links of this fabric can be connections between PODs, interconnections within a POD or connections to WANs.


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?


It is closer to both the terminology and design used in actual deployments.
[Y] Thanks. We will add these to the terminology part.



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

Leaf/spine is a node, nodes are interconnected by links. Depends on the context of the earlier question about the underlay and overlay. Links and nodes can definitely be represented by TE model. What is a leaf/spine node in the overlay context?
[Y] Leaf/spine is the role of a device node within a pod. It indicates its functions. Such as, for distributed GW, it will be deployed on LEAF node.




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.
This needs to be documented. Or, if you intend to limit the scope to two stages (as it is implied at the moment) - this also needs to be explicitly stated in the document. What is an interlayer device?
[Y] Ok, it will be added to the definition of role. Err…an interlayer device is for other layers besides SPINE/LEAF.




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.


Needs to be documented.
[Y] Ok, it will be added to the definition of bandwidth.



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.
The extensibility mechanism needs to be documented.
[Y] Ok, it will be added to the definition of the service capability.




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?
I am not suggesting anything, I was asking about the compose-fabric RPC that was mentioned in the document.
[Y] We will clarify it in v-09.






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.


It needs to be documented on what is meant by policy - what is the purpose of that policy, where and how it should be instantiated.
[Y]It will be clarified in v-09.


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.”?


What is a basic structure then? If this is in overlay context then it is not obvious what POD means there. If this is in underlay context then conceptually it is clear but quite far away from operational reality.
[Y] It is a set of nodes and links which composes a POD and also supports an overlay instance.


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.
Please document the extensibility.
[Y] Ok, we will document it in the definition of port-type.




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.

Good. So this in fact is closer to FAAS and therefore the context of the document is the overlay. The document needs to state that clearly.

Overall it seems that what is missing in the document is the context clarification. Once the context of this model is clearly defined the rest of comments will be easier to address.

Thank you.

Ignas