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

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

Ignas:

Yan will answer for the authors but I would like to share some information related to the I2RS working group reviews.  In your response, please specify why each question is a "DISCUSS" quality question rather than a "Comment" question.  The authors and I (as the shepherd) will work to resolve both DISCUSS and comment issues.  

Let me review only 5 of your many points because they are pointing in a direction which is different from earlier QA reviews of this document (rtg-dir, ops-dir, yang-doctors) in the 2017-2018 timeframe.  

1st - 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?

This document was reviewed by authors with the TE topology models to make sure there was no conflict or duplication.    

Your question implies that only one yang model is appropriate for each type of fabric.   This theory of one yang mode per fabric does not apply to dynamic (ephemeral) datastore versus configuration datastore models.  It is also not true of all models even within the configuration datastore. Since there is a yang catalog and selection of yang models is specific to a implemented, there has been no early winnowing of the yang models per type.  If you are insisting on this theory of "one yang model" per fabric type, please provide an RFC reference so that I can help review this DISCUSS criteria with the authors. 

This yang model has been implemented by 1 vendor, and there was interest by other vendors.  A deployment target has been identified for this model, and feedback is expected from the users. 

If you are asking this model to cover three-four layer datacenters, this approach is opposite some of the initial feedback to the group to keep the initial model - that is to keep it simple and restricted to 2 layers in order to test the concepts.  If you are asking to provide text (in introduction or appendix) that indicates the initial focus, this can be added. 

2nd - Multiple layers and multiple roles.  

 The authors provide slides in several meetings I2RS meeting repository regarding this point. 
The initial feedback suggested reducing the "why" text within the draft.   Again, the initial feedback was to reduce the initial model's text to 2 layers and simple "whys".  See proceedings from IETF 95 forward on I2RS on fabric data model for discussions. 

3rd - The authors will comment on the port restrictions.  Early feedback during the I2RS meetings from vendors may have taken the authors down this path.  In my review, I expect major issues in this area - but I will let the authors comment. 

 4 - policy is simple. 

Again, the initial feedback was to keep initial policies simple and gain feedback from the deployments. 

5 - You indicate that the document requires a "major" rewrite clarifying the logic. 

Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested taking out the lengthy descriptions regarding logic and history.  If we are switching the rules for the YANG models, would you please update the requirements for the YANG models so that shepherds, rtg-dir, ops-dir, and yang-doctors can have rules for review clearly spelled out. 

Summary on Shepherd's comment:  

The authors will respond to others specifics, but in order to guide these diligent authors - I need to know what rules you are setting for the 2018 IESG approval of YANG models.  If you are placing a DISCUSS on a YANG model based on a set criteria, the criteria needs to be published on a web page or in an RFC. If I've missed this criteria that the OPS Area has specified, 

Thank you for your review, 
Susan Hares 

-----Original Message-----
From: Ignas Bagdonas [mailto:[e-mail]] 
Sent: Tuesday, April 3, 2018 7:40 AM
To: The IESG
Cc: [e-mail]; Susan Hares; [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
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?