Hi Ignas,

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

From: Ignas Bagdonas [mailto:ibagd...@gmail.com]
Sent: Thursday, April 05, 2018 2:38 AM
To: Susan Hares <sha...@ndzh.com>; 'The IESG' <i...@ietf.org>
Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org; 
i2rs-cha...@ietf.org
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:ibagd...@gmail.com]
Sent: Tuesday, April 03, 2018 7:40 PM
To: The IESG <i...@ietf.org<mailto:i...@ietf.org>>
Cc: 
draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org<mailto:draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org>;
 Susan Hares <sha...@ndzh.com<mailto:sha...@ndzh.com>>; 
i2rs-cha...@ietf.org<mailto:i2rs-cha...@ietf.org>; 
sha...@ndzh.com<mailto:sha...@ndzh.com>; i2rs@ietf.org<mailto:i2rs@ietf.org>
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

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to