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

2018-04-18 Thread Zhuangyan (Yan)
Hi Ignas,

The version-09 incorporated the responses below has been uploaded. Could you 
check if it can resolve your comments?

Thank you very much.

Best Regards,

Yan (on behalf of co-authors)

From: Zhuangyan (Yan)
Sent: Sunday, April 08, 2018 5:37 PM
To: 'Ignas Bagdonas' <ibagd...@gmail.com>; 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)

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<mailto:sha...@ndzh.com>>; 'The IESG' 
<i...@ietf.org<mailto:i...@ietf.org>>
Cc: i2rs@ietf.org<mailto:i2rs@ietf.org>; 
draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org<mailto:draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org>;
 i2rs-cha...@ietf.org<mailto: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 terminol

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

2018-04-08 Thread Zhuangyan (Yan)
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

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

2018-04-04 Thread Ignas Bagdonas



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 >
Cc: draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org 
; 
Susan Hares >; 
i2rs-cha...@ietf.org ; sha...@ndzh.com 
; 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.


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