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

[Ignas Bagdonas <[e-mail]>]

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.

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


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

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

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


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

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

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

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

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

> 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