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

From: Ignas Bagdonas <[email-masked]>
Date: Tue, 03 Apr 2018 04:40:29 -0700

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?

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 3 Apr 2018 09:59:10 -0400

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:[email-masked]] 
Sent: Tuesday, April 3, 2018 7:40 AM
To: The IESG
Cc: [email-masked]; Susan Hares; [email-masked]; [email-masked]; [email-masked]
Subject: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

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

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

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?

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?

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 03 Apr 2018 22:29:33 +0200 (CEST)

Hi,

Just a quick comment on the YANG doctor's review.

"Susan Hares" <[email-masked]> wrote:
> Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested
> taking out the lengthy descriptions regarding logic and history.

It is very common that the YANG doctor review ask for *more* details
in the descriptions.  In general, we want the module to have as much
explanatory text as possible.  So was the case for the YD review for
this document as well; the YD wrote "The descriptions in all YANG
Modules are very short/terse."  That was for the -02 version, and even
the -00 version did not contain lengthy descriptions AFAICT.

/martin

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 3 Apr 2018 16:54:15 -0400

Martin:

Thank you for the comments on the Yang doctors.  The discussion reference
was in the introductory material and not in the descriptions in the YANG
text.  Do you also want additional comments in the introductory section?

Sue Hares 

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Tuesday, April 3, 2018 4:30 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked];
[email-masked]
Subject: Re: [i2rs] Ignas Bagdonas' Discuss on
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and
COMMENT)

Hi,

> taking out the lengthy descriptions regarding logic and history.

It is very common that the YANG doctor review ask for *more* details in the
descriptions.  In general, we want the module to have as much explanatory
text as possible.  So was the case for the YD review for this document as
well; the YD wrote "The descriptions in all YANG Modules are very
short/terse."  That was for the -02 version, and even the -00 version did
not contain lengthy descriptions AFAICT.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 03 Apr 2018 23:57:00 +0200 (CEST)

> text.  Do you also want additional comments in the introductory section?

No.  The comment was just about the YANG module.

You wrote:

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

My point is that I don't think we are changing the rules for the YANG
modules, which this reply seemed to indicate.

/martin

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 3 Apr 2018 18:21:53 -0400

Martin:

I apologize if my response seem to indicate the descriptions in the YANG
modules or the YANG module overall description.  My response was intended to
query if there were now rules on what needed to be in the introductory
material (non-YANG) in the RFC prior to the YANG module.  

AFAIK, the only formal definition for this portion of the YANG RFCs is
regarding the Yang diagram RFC. 
Therefore, I was asking Ignas to provide clarity on his DISCUSS to determine
references for his expectations for the introductory material.  A DISCUSS
should have some reference to a YANG web page, or an RFC or some written
context to help the shepherd.   As a shepherd unless I have a reference it
is hard to handle conflicting reviews (shorten the introduction vs. add the
introduction). 

If you know of such a web page or RFC, I would appreciate a reference. 

Thank you,
Susan Hares

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Tuesday, April 3, 2018 5:57 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Subject: Re: [i2rs] Ignas Bagdonas' Discuss on
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and
COMMENT)

"Susan Hares" <[email-masked]> wrote:
> Martin:
> 
> Thank you for the comments on the Yang doctors.  The discussion 
> reference was in the introductory material and not in the descriptions 
> in the YANG text.  Do you also want additional comments in the
introductory section?

You wrote:

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

/martin

> the -00 version did not contain lengthy descriptions AFAICT.

_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 4 Apr 2018 10:28:51 -0400

Martin: 

You are correct, this is not a concern about the rules for the Yang module
itself.   Hence, my questions to Ignas about why he placed a DISCUSS based
on "introduction material" that was not specified in any document. 

Thank you for your comments,
Susan Hares 

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Tuesday, April 3, 2018 5:57 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];

introductory section?

/martin

---

From: Ignas Bagdonas <[email-masked]>
Date: Wed, 4 Apr 2018 15:30:56 +0100

Hi Sue,

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

Why DISCUSS? DC fabric is a type of network topology, yes, it has some 
specifics, but nothing radically different than any purpose built 
network topology. Developing a separate model for a specific use case at 
the same time when there is generic and extensible TE model is 
questionable.

> Your question implies that only one yang model is appropriate for each type of fabric.

That is exactly opposite. What is special about DC fabric that it has to 
have a separate model? What is special about fabric type of topology 
that it has to have a separate model? Why is TE model not suitable?

>     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.
>
Excellent. Please get feedback from user community - even if it is not 
yet implemented and operations groups will not be able to provide 
feedback, architecture and engineering groups look into upcoming things 
and will have what to say.

Speaking of implementations, the ODL faas project (from where the 
majority of this model seems to be coming from) deals with an instance 
of overlay that is subsequently treated as an underlay, and that is 
different that the underlay on top of which that instance is being run. 
If the model focus is on the "fabric as a service" type of topologies 
then it explicitly needs to state that, and then justify why physical 
node properties exist together with logical instance properties in that 
case.

> 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 res…
The document as it is written now tries to cover every possible fabric. 
If the scope is intended to be narrower - it needs to be stated. 
Starting from bounded scope is certainly a right thing to do but that is 
not how the document reads now.

> 2nd - Multiple layers and multiple roles.
Why DISCUSS? Two stage fabrics and fabrics with a perfectly clean node 
role separation do indeed exist, but that is not necessary a common 
deployment model. The document assumes that those are the only possible 
options.

> 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 IE…
Would users of this model also be required to lookup proceedings of past 
IETF meetings in order to understand whether it may fit their use cases?

> 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 thi…
Why DISCUSS? The way how the model specifies port speeds is conflicting 
with common deployment practices.

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

Why DISCUSS? What kind of policy is being discussed here? The assumption 
of one single universal policy fitting all deployments and use cases 
contradicts to operational reality.

"Policy is simple" does not clarify what kind of policy it is.

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

Why DISCUSS? Model tries to prescribe a way how all DC networks should 
be built. It intermixes concepts of underlay and overlay. There are 
nodes in the model with unclear purpose and no documented details on 
what and how they are doing.

> 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 pl…

YANG models, and any other deliverables of the IETF, are targetted to 
the users of those deliverables and not necessary to the IETF itself. 
The situation with YANG models is that the main consumer of IETF YANG 
model for a noticeable period was  IETF itself - it was required to 
build the sufficient coverage of models for them to be practically 
useful. We as an industry start to see more practical use of YANG 
modules, and so far the main obstacle for YANG acceptance is the 
difficulty in trying to use it. It is incorrect to assume that outside 
of the IETF WGs that deal with developing the models there is enough of 
understanding of the reasoning behind modelling decisions made. It is 
incorrect to assume that potential users of such models would try to 
lookup proceedings of past IETF meeting trying to get answers - they 
will chose other manageability technologies instead. YANG models need to 
be self-contained from the practical usability perspective - the models 
themselves should contain enough and meaningful descriptions of the 
nodes that it would not raise questions for users trying to deploy those 
models. Descriptions equivalent to those found in command line 
interfaces - if YANG is expected to become a new command line interface, 
it should be no worse than the command line interface. The reasoning 
behind modelling decisions made also need to be documented - at least 
for allowing model users to see whether the model is suitable for 
deployment in the particular environment. As YANG is maturing and 
starting to be deployed, naturally the focus of reviews will change to 
reflect what is required for successful deployment of the technology.

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

RFC6087 and draft-ietf-netmod-rfc6087bis.

There are two parts that are important for reviews - the model itself, 
and how the model applies to the managed entities. And there is nothing 
new in the review criteria. The former is rather not that complex, and 
typically can be done within IETF itself. The latter is more complex and 
generally would require feedback from the target users of the model. 
There is a balance between a model being too generic to be practically 
usable and model being too prescriptive to be practically usable. If the 
model puts requirements and restrictions on the managed entities in a 
way that requires to build those managed entities in a specific way, 
predefined by the model authors, the value of such model is 
questionable. Speaking specifically about DC fabric model, it puts 
network design prescriptions that are significantly misaligned with how 
fabric based networks have been and are built. Yes, it is possible to 
find environments where the model would apply directly and with no 
impact, but one would need to look for such deployments quite hard, and 
with a high probability that would be proof of concept or technology 
demonstration type of environments.

IETF is good at developing technology components and fragments, IETF 
typically is not good at dealing with network design and how those 
fragments need to be bound together - that is the reality, and that is 
not necessarily wrong. IETF should be focusing on what it can do best - 
the fragments, and align with users of the fragments on how to improve 
the fragments but not try to direct how users should be building their 
networks. It is important for the reputation of IETF as a credible SDO - 
if IETF manageability mechanisms propose and enforce not necessarily 
right - or just plain broken - network designs, that is a reputation 
problem. This document tends to be proposed standard, and that sets a 
strong message.

Ignas

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 4 Apr 2018 11:03:05 -0400

Ignas: 

I am not trying to clarify the specifics.  This response (as I mentioned), will come from the authors.  As a shepherd/WG chair, I am asking for information regarding the basis of your DISCUSS models for specific points.    

The 2014 document on the IESG discuss criteria is at: 
https://www.ietf.org/blog/discuss-criteria-iesg-review/

What on this list does the following comment refer to: 
"Why DISCUSS? DC fabric is a type of network topology, yes, it has some specifics, but nothing radically different than any purpose built network topology. Developing a separate model for a specific use case at the same time when there is generic and extensible TE model is questionable." 

Perhaps you are not considering the fact this is an I2RS model.  Let me provide 3 comments regaring that point: 
 
1st - I2RS is focusing on models that are capable for the dynamic state and configuration state.  These models have qualitative differences.  The mechanisms of a model which does both dynamic state and configuration state is qualitative different that the basic TE models. This model extends the TE models toward this approach (see   module ietf-dc-fabric-topology reference import of ietf-network-topology).  
  
2nd - During the I2RS process we talked to the TE topology authors and the TE WG.  We agreed that this model has differences.  As a WG Co-chair, I spent time reviewing this interaction. 

3rd - How many of the user community have implemented I2RS dynamic models or the RFC version of the TE models?  

See the comments from Chris Hopps and others on slow pace of the netconf work.  If you are going to restrict to two deployed implementations, you will be joining the IDR camp of requirements and slowing the work further.  The only reason we require 2 implementations for IDR is for the fragile BGP environment and that operators request it due to the global consequences.  Network Management of these early yang models have a much more restricted case. 

Sue Hares 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Ignas Bagdonas
Sent: Wednesday, April 4, 2018 10:31 AM
To: Susan Hares; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

Hi Sue,

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

Why DISCUSS? DC fabric is a type of network topology, yes, it has some specifics, but nothing radically different than any purpose built network topology. Developing a separate model for a specific use case at the same time when there is generic and extensible TE model is questionable.

> Your question implies that only one yang model is appropriate for each type of fabric.

That is exactly opposite. What is special about DC fabric that it has to have a separate model? What is special about fabric type of topology that it has to have a separate model? Why is TE model not suitable?

> 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.
Excellent. Please get feedback from user community - even if it is not yet implemented and operations groups will not be able to provide feedback, architecture and engineering groups look into upcoming things and will have what to say.

Speaking of implementations, the ODL faas project (from where the majority of this model seems to be coming from) deals with an instance of overlay that is subsequently treated as an underlay, and that is different that the underlay on top of which that instance is being run. 
If the model focus is on the "fabric as a service" type of topologies then it explicitly needs to state that, and then justify why physical node properties exist together with logical instance properties in that case.

The document as it is written now tries to cover every possible fabric. 
If the scope is intended to be narrower - it needs to be stated. 
Starting from bounded scope is certainly a right thing to do but that is not how the document reads now.

Ignas

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 4 Apr 2018 11:22:13 -0400

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: 

I’m sure Yan will be glad to make adjustments in the draft (see below).  You will note that you are asking us to put back in RPCs that others had us take out.  

This leads me to back to my questions as a Shepherd. My concern is that many of your requested 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:[email-masked]] 
Sent: Tuesday, April 03, 2018 7:40 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; Susan Hares <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

 

Please refer to  <https://www.ietf.org/iesg/statement/discuss-criteria.html> https://www.ietf.org/iesg/statement/discuss-criteria.html

 

 <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topology/> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topology/

DISCUSS:

[Y] The intention of this model is to represent the entire topology of a data center fabric network. 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?

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

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

[Y] bandwidth is defined as identity-ref. Other speeds can be added by defining new identities.

[Y] The role for a device-node is defined as leaf-list to support a device with more than one roles. 

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

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

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

 

COMMENT:

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

[Y] It is used to say the range of the VNIs for a POD. We will update the description to clarify it.

[Y] Apologize for the inconsistent. It will be changed to ietf-dc-fabric-* in v09.

[Y] Since the port-type is identityref, new port types can be added by defining new identities.

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

---

From: Ignas Bagdonas <[email-masked]>
Date: Wed, 4 Apr 2018 19:37:50 +0100

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
>
> 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
>
> To: The IESG <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] 
> <mailto:[email-masked]>; 
> Susan Hares <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Subject: Ignas Bagdonas' Discuss on 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
>
> 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.
>
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?

> [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.
>
Needs to be documented.

> 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] rpcs were removed in previous version since people say it would 
> leave for vendor-specific implementation.
>
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.
>
> 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 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.

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

---

From: Ignas Bagdonas <[email-masked]>
Date: Wed, 4 Apr 2018 19:40:20 +0100

> "Why DISCUSS? DC fabric is a type of network topology, yes, it has some specifics, but nothing radically different than any purpose built network topology. Developing a separate model for a specifi…
The fact that for managing similar functionality there appears to be a 
need for different models that would as a result require different model 
lifecycle management clearly falls into the category of operational issues.

> Perhaps you are not considering the fact this is an I2RS model.  Let me provide 3 comments regaring that point:
I am considering the fact that this model defines configuration of 
something that is widely deployed in a way that is not compatible with 
how it is deployed. The fact that this may be I2RS model is not of the 
primary importance.

> 3rd - How many of the user community have implemented I2RS dynamic models or the RFC version of the TE models?
I am aware of 1 I2RS model family implementation. I am aware of 4 TE 
model implementations that I happen to use daily, and aware of several 
more that I do not deal with. And I am not certain what value such 
counting of implementations brings to this discussion.

> See the comments from Chris Hopps and others on slow pace of the netconf work.  If you are going to restrict to two deployed implementations, you will be joining the IDR camp of requirements and sl…

May I ask you to point to where I have said anything about two deployed 
implementations?

Ignas

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 4 Apr 2018 18:08:27 -0400

Ignas:

I'm not saying yes/no to change this model.  I've forwarded Yan's comments regarding changes to your specific issues.  Yan is very proactive.  It is likely that she will change most of the details if you respond to her. 

I am acting as a shepherd/WG chair.  I'm trying to determine  Discuss Criteria are you using from the following document are you using to restrict I2RS models (dynamic + configuration capable) because there are TE specific models in the same area:  
https://www.ietf.org/blog/discuss-criteria-iesg-review/

This goes against the design criteria I2RS has used. 

You asked for text sequences that lead me to this conclusion: 
(1st thread): 
 [Ignas] > Excellent. Please get feedback from user community - even if it is not yet implemented and operations groups will not be able to provide feedback, architecture and engineering groups look into upcoming things and will have what to say.

[Sue]: (Repeating earlier comments from email and shepherd's  )  We obtain a vendor (Huawei) and a target deployment situation (Data Centers) with two potential data centers in China who wanted to work with this type of logical deployment.   To this shepherd's eyes, this is the operational information.   

[Sue] (new clarifying comments): If you are still objecting, what else do you want as proof that the WG did due diligence on obtaining the operational feedback for deployment of a model which has I2RS capabilities (dynamic and configuration) must be judged against any TE (configuration only ) data models. 

(2) Further indication that you are comparing I2RS data models against the 4 TE models without a consideration to dynamic datastore design issues: 

[Sue's comment]:  3rd - How many of the user community have implemented I2RS dynamic models or the RFC version of the TE models?

[Ignas] I am aware of 1 I2RS model family implementation. I am aware of 4 TE model implementations that I happen to use daily, and aware of several more that I do not deal with. And I am not certain what value such counting of implementations brings to this discussion.

Summary of my question: 
I2RS models (configuration and dynamic) are different than regular TE models and you are lumping the I2RS models in with the configuration datastore TE models.  Please provide me with the DISCUSS criteria or RFCs you are using to make categorization.   

After we settle on these issues, we can go on to the other comments. 

Sue Hares 

-----Original Message-----
From: Ignas Bagdonas [mailto:[email-masked]] 
Sent: Wednesday, April 4, 2018 2:40 PM
To: Susan Hares; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

> "Why DISCUSS? DC fabric is a type of network topology, yes, it has some specifics, but nothing radically different than any purpose built network topology. Developing a separate model for a specifi…
The fact that for managing similar functionality there appears to be a need for different models that would as a result require different model lifecycle management clearly falls into the category of operational issues.

> Perhaps you are not considering the fact this is an I2RS model.  Let me provide 3 comments regaring that point:
I am considering the fact that this model defines configuration of something that is widely deployed in a way that is not compatible with how it is deployed. The fact that this may be I2RS model is not of the primary importance.

> 3rd - How many of the user community have implemented I2RS dynamic models or the RFC version of the TE models?
I am aware of 1 I2RS model family implementation. I am aware of 4 TE model implementations that I happen to use daily, and aware of several more that I do not deal with. And I am not certain what value such counting of implementations brings to this discussion.

> See the comments from Chris Hopps and others on slow pace of the netconf work.  If you are going to restrict to two deployed implementations, you will be joining the IDR camp of requirements and sl…

May I ask you to point to where I have said anything about two deployed implementations?

Ignas

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 Apr 2018 11:12:40 -0400

Ignas and Warren:

Your comments on the IESG telechat (4/5/2018) have two components: 
1) a DISCUSS based on direct comparison of the I2RS models (dynamic and configuration) with the TE models (configuration only), 2) "This will not work".  I need clarity to guide the WG/authors to a successful resolution of your DISCUSS/Abstain. 

1) a DISCUSS based on direct comparison of the I2RS models (dynamic and configuration) with the TE models (configuration only). 

The I2RS models are both available for the dynamic and configuration datastore.  The dynamic configuration models are for models that do not exactly align with perceptions of the configuration model.    These set of models are for situations that do not align with the configuration store only.   

As Martin indicated, trying these alternate  management Yang models in dynamic/configuration model configuration needs feedback based on deployment and interoperability issues. 

This does not align with RFC8342 (NMDA) or and I2RS requirement documents (RFC8242).    If this is your DISCUSS Criteria, then I have a strong objection to your DISCUSS based on these RFCs. 

If the Discuss/Abstain is based on one of the following discuss criteria, please state this clear in your emails so I can guide the authors and the WG. 

1) The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that the reader cannot understand it without ambiguity.
2) Widespread deployment would be damaging to the Internet or an enterprise network for reasons of congestion control, scalability, or the like.

These are objections I take seriously as a shepherd/WG chair.  However, I need you both to disambiguate between these two components.   I have been trying to get clarity on which DISCUSS criteria Ignas' comments indicate. 

I expect an IESG members to be able to inform a WG chair which the discuss criteria you are specifying. Please let me know if you have additional questions.  Your comments on the telechat did not indicate you understood my concerns. 

Cheerily, Susan Hares

-----Original Message-----
From: Susan Hares [mailto:[email-masked]] 
Sent: Wednesday, April 4, 2018 6:08 PM
To: 'Ignas Bagdonas'; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

Ignas:

[Sue]: (Repeating earlier comments from email and shepherd's  )  We obtain a vendor (Huawei) and a target deployment situation (Data Centers) with two potential data centers in China who wanted to work with this type of logical 
deployment.   To this shepherd's eyes, this is the operational information.

[Sue] (new clarifying comments): If you are still objecting, what else do you want as proof that the WG did due diligence on obtaining the operational feedback for deployment of a model which has I2RS capabilities (dynamic and
configuration) must be judged against any TE (configuration only ) data models.

Summary of my question:

Sue Hares

-----Original Message-----
From: Ignas Bagdonas [mailto:[email-masked]]
Sent: Wednesday, April 4, 2018 2:40 PM
To: Susan Hares; 'The IESG'
Cc: [email-masked]; [email-masked];
[email-masked]

On 04/04/2018 16:03, Susan Hares wrote:
> Ignas:
>
> I am not trying to clarify the specifics.  This response (as I 
> mentioned), will come from the authors.  As a shepherd/WG chair, I am 
> asking for information regarding the basis of your DISCUSS models for 
> specific points.
>
> "Why DISCUSS? DC fabric is a type of network topology, yes, it has 
> some specifics, but nothing radically different than any purpose built 
> network topology. Developing a separate model for a specific use case 
> at the same time when there is generic and extensible TE model is questionable."

> Perhaps you are not considering the fact this is an I2RS model.  Let 
> me provide 3 comments regaring that point:

>
> 1st - I2RS is focusing on models that are capable for the dynamic 
> state and configuration state.  These models have qualitative 
> differences.  The mechanisms of a model which does both dynamic state 
> and configuration state is qualitative different that the basic TE models. This model
> extends the TE models toward this approach (see   module 
> ietf-dc-fabric-topology reference import of ietf-network-topology).
>
> 2nd - During the I2RS process we talked to the TE topology authors and 
> the TE WG.  We agreed that this model has differences.  As a WG 
> Co-chair, I spent time reviewing this interaction.
>
> 3rd - How many of the user community have implemented I2RS dynamic 
> models or the RFC version of the TE models?

> See the comments from Chris Hopps and others on slow pace of the 
> netconf work.  If you are going to restrict to two deployed 
> implementations, you will be joining the IDR camp of requirements and slowing the work further.
> The only reason we require 2 implementations for IDR is for the 
> fragile BGP environment and that operators request it due to the 
> global consequences.  Network Management of these early yang models 
> have a much more restricted case.

Ignas

> Cc: [email-masked]; 
>> 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 
> specifics, but nothing radically different than any purpose built network 
> topology. Developing a separate model for a specific use case at the same 
> time when there is generic and extensible TE model is questionable.
>
>> This document was reviewed by authors with the TE topology models to make 
>> sure there was no conflict or duplication.
>>
> have a separate model? What is special about fabric type of topology that 
> it has to have a separate model? Why is TE model not suitable?
>
>>      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.
> Excellent. Please get feedback from user community - even if it is not yet 
> implemented and operations groups will not be able to provide feedback, 
> architecture and engineering groups look into upcoming things and will 
> have what to say.
>
> Speaking of implementations, the ODL faas project (from where the majority 
> of this model seems to be coming from) deals with an instance of overlay 
> that is subsequently treated as an underlay, and that is different that 
> the underlay on top of which that instance is being run.
> If the model focus is on the "fabric as a service" type of topologies then 
> it explicitly needs to state that, and then justify why physical node 
> properties exist together with logical instance properties in that case.
>
>
>> 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.
>> 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.
>> 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.
>> 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,
>> Cc: [email-masked]; Susan 
>> Hares; [email-masked]; [email-masked]; [email-masked]
>> overlay but that is not what the document seems to be focusing on. Fabric 
>> defines and implements the underlay, not the other way around.
>>
>> 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?
>>
>> 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?
>>
>> 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.
>>
>>
>> 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?
>>
>> 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

---

From: Warren Kumari <[email-masked]>
Date: Thu, 5 Apr 2018 13:52:11 -0400

On Thu, Apr 5, 2018 at 11:12 AM, Susan Hares <[email-masked]> wrote:
> I expect an IESG members to be able to inform a WG chair which the discuss criteria you are specifying.

I specifically did not ballot DISCUSS as there are no Discuss criteria
which I felt applied - Abstain is a non-blocking position (and so
practically indistinguishable from No Record, and fairly similar to No
Objection).

Much of my twitchiness with the document is that it feels like it is
trying to define what a datacenter fabric is (in an Introduction and a
single term - "Fabric: also known as a POD, is 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.").

There are a huge number of different data center "fabric" designs, and
I don't really think that the document goes into enough detail about
what exactly it is meaning when it says fabric. It also asserts:
"for a DC network, a fabric can be considered as an atomic structure
for management purposes." -- at some level this is probably true, but
at the level that I look at fabrics it definitely isn't -- a fabric is
a thingie made up of many devices and they all require management and
monitoring and care and feeding and love and attention.

A lot of the document seems to be written with a specific sets of
views and assumptions (yes, it is obviously extensible, but the base
selections reflect a certain understanding / world view):
the 'fabric-type' can be Vxlan, Vlan or Trill (most fabrics I've seen
are plain ethernet),
'port-types' are "Port type: ethernet or serial or others" (I've never
seen a serial fabric, and this leaves out InfiniBand),
'traffic-behavior' can be normal or policy-driven (with no description
of what the actual difference is, nor what 'policy-driven' means),
the 'fabric-options' are not really options I'd expect to be of primary import,
the 'gateway-mode' options of 'centralized' vs 'distributed' don't
really align with the descriptions (on spine vs leaf), nor do I
understand what that would be critical enough that it is given such
priority and things like the base protocol used isn't),
the descriptions for things like 'fabrictypes:node-ref' ("The device
the fabric includes.") are very unclear.

The document / model is at such an unusual level of abstraction
(simultaneously very high and low) that I simply don't understand how
this could usefully be used -- if I view a "fabric" as simply a
commodity thingie that I ride over, and the model is simply
informational, then it contains much which is not useful to me, and
leaves out things like cross sectional BW / locality hints, etc which
would be. If I instead view this as something that I might want to use
to administer / monitor / model a fabric then it is way too
simplistic.

But, again, I think that this is simply that my views / levels of
abstraction don't align with whatever the authors / WGs are -- and so
I'm not blocking the document, but rather "I oppose this document but
understand that others differ and am not going to stand in the way of
the others." - there is simply a large gulf between my worldview of
what a fabric is (and what levels of abstraction would be useful), and
what this document provides.

W

>  Please let me know if you have additional questions.  Your comments on the telechat did not indicate you understood my concerns.
>
> Cheerily, Susan Hares
>
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 Apr 2018 14:04:42 -0400

Warren:

Thank you for making clear your concerns.   I started with the same concerns and came to resolve these concerns. I will try to write up a clear summary of why I resolved it.  However, I do not have some of the same datacenter perspective you or Ignas has.  I would like your review on these concerns and the authors comments on these points.  

The delay until Friday is due to my day jobs (professor and other IETF hats).  I'm just out of time to do a proper job of this work. 

Sue Hares 

-----Original Message-----
From: Warren Kumari [mailto:[email-masked]] 
Sent: Thursday, April 5, 2018 1:52 PM
To: Susan Hares
Cc: Ignas Bagdonas; [email-masked]; [email-masked]; [email-masked]; [email-masked]; The IESG
Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

> I expect an IESG members to be able to inform a WG chair which the discuss criteria you are specifying.

I specifically did not ballot DISCUSS as there are no Discuss criteria which I felt applied - Abstain is a non-blocking position (and so practically indistinguishable from No Record, and fairly similar to No Objection).

Much of my twitchiness with the document is that it feels like it is trying to define what a datacenter fabric is (in an Introduction and a single term - "Fabric: also known as a POD, is 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.").

There are a huge number of different data center "fabric" designs, and I don't really think that the document goes into enough detail about what exactly it is meaning when it says fabric. It also asserts:
"for a DC network, a fabric can be considered as an atomic structure for management purposes." -- at some level this is probably true, but at the level that I look at fabrics it definitely isn't -- a fabric is a thingie made up of many devices and they all require management and monitoring and care and feeding and love and attention.

A lot of the document seems to be written with a specific sets of views and assumptions (yes, it is obviously extensible, but the base selections reflect a certain understanding / world view):
the 'fabric-type' can be Vxlan, Vlan or Trill (most fabrics I've seen are plain ethernet), 'port-types' are "Port type: ethernet or serial or others" (I've never seen a serial fabric, and this leaves out InfiniBand), 'traffic-behavior' can be normal or policy-driven (with no description of what the actual difference is, nor what 'policy-driven' means), the 'fabric-options' are not really options I'd expect to be of primary import, the 'gateway-mode' options of 'centralized' vs 'distributed' don't really align with the descriptions (on spine vs leaf), nor do I understand what that would be critical enough that it is given such priority and things like the base protocol used isn't), the descriptions for things like 'fabrictypes:node-ref' ("The device the fabric includes.") are very unclear.

The document / model is at such an unusual level of abstraction (simultaneously very high and low) that I simply don't understand how this could usefully be used -- if I view a "fabric" as simply a commodity thingie that I ride over, and the model is simply informational, then it contains much which is not useful to me, and leaves out things like cross sectional BW / locality hints, etc which would be. If I instead view this as something that I might want to use to administer / monitor / model a fabric then it is way too simplistic.

But, again, I think that this is simply that my views / levels of abstraction don't align with whatever the authors / WGs are -- and so I'm not blocking the document, but rather "I oppose this document but understand that others differ and am not going to stand in the way of the others." - there is simply a large gulf between my worldview of what a fabric is (and what levels of abstraction would be useful), and what this document provides.

W

> Subject: RE: [i2rs] Ignas Bagdonas' Discuss on 
> [Sue] (new clarifying comments): If you are still objecting, what else 
> do you want as proof that the WG did due diligence on obtaining the 
> operational feedback for deployment of a model which has I2RS 
> capabilities (dynamic and
>> some specifics, but nothing radically different than any purpose 
>> built network topology. Developing a separate model for a specific 
>> use case at the same time when there is generic and extensible TE model is questionable."
>> 2nd - During the I2RS process we talked to the TE topology authors 
>> and the TE WG.  We agreed that this model has differences.  As a WG 
>>> 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.
>>> representation of DC fabric? Why is DC fabric network topology 
>>> special compared to any generic fabric based topology?
>> Why DISCUSS? DC fabric is a type of network topology, yes, it has 
>> some specifics, but nothing radically different than any purpose 
>> built network topology. Developing a separate model for a specific 
>> use case at the same time when there is generic and extensible TE model is questionable.
>>
>>> This document was reviewed by authors with the TE topology models to 
>>> make sure there was no conflict or duplication.
>>>
>> That is exactly opposite. What is special about DC fabric that it has 
>> to have a separate model? What is special about fabric type of 
>> topology that it has to have a separate model? Why is TE model not suitable?
>>
>>> (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.
>> Excellent. Please get feedback from user community - even if it is 
>> not yet implemented and operations groups will not be able to provide 
>> feedback, architecture and engineering groups look into upcoming 
>> things and will have what to say.
>>
>> majority of this model seems to be coming from) deals with an 
>> instance of overlay that is subsequently treated as an underlay, and 
>> that is different that the underlay on top of which that instance is being run.
>> node properties exist together with logical instance properties in that case.
>>
>>
>>> 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.
>> Why DISCUSS? Two stage fabrics and fabrics with a perfectly clean 
>> node role separation do indeed exist, but that is not necessary a 
>> common deployment model. The document assumes that those are the only 
>> possible options.
>>
>>> 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.
>> Would users of this model also be required to lookup proceedings of 
>> past IETF meetings in order to understand whether it may fit their use cases?
>>
>>
>>> 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.
>> Why DISCUSS? The way how the model specifies port speeds is 
>> conflicting with common deployment practices.
>>
>>>    4 - policy is simple.
>>>
>> Why DISCUSS? What kind of policy is being discussed here? The 
>> assumption of one single universal policy fitting all deployments and 
>> use cases contradicts to operational reality.
>>
>> Why DISCUSS? Model tries to prescribe a way how all DC networks 
>> should be built. It intermixes concepts of underlay and overlay. 
>> There are nodes in the model with unclear purpose and no documented 
>> details on what and how they are doing.
>>
>>> rtg-dir, ops-dir, and yang-doctors can have rules for review clearly spelled out.
>> difficulty in trying to use it. It is incorrect to assume that 
>> outside of the IETF WGs that deal with developing the models there is 
>> enough of understanding of the reasoning behind modelling decisions 
>> made. It is incorrect to assume that potential users of such models 
>> would try to lookup proceedings of past IETF meeting trying to get 
>> answers - they will chose other manageability technologies instead. 
>> YANG models need to be self-contained from the practical usability 
>> perspective - the models themselves should contain enough and 
>> meaningful descriptions of the nodes that it would not raise 
>> questions for users trying to deploy those models. Descriptions 
>> equivalent to those found in command line interfaces - if YANG is 
>> expected to become a new command line interface, it should be no 
>> worse than the command line interface. The reasoning behind modelling 
>> decisions made also need to be documented - at least for allowing 
>> model users to see whether the model is suitable for deployment in 
>> the particular environment. As YANG is maturing and starting to be 
>> deployed, naturally the focus of reviews will change to reflect what is required for successful deployment of the technology.
>>
>>> 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,
>> There are two parts that are important for reviews - the model 
>> itself, and how the model applies to the managed entities. And there 
>> is nothing new in the review criteria. The former is rather not that 
>> complex, and typically can be done within IETF itself. The latter is 
>> more complex and generally would require feedback from the target users of the model.
>> There is a balance between a model being too generic to be 
>> practically usable and model being too prescriptive to be practically 
>> usable. If the model puts requirements and restrictions on the 
>> managed entities in a way that requires to build those managed 
>> entities in a specific way, predefined by the model authors, the 
>> value of such model is questionable. Speaking specifically about DC 
>> fabric model, it puts network design prescriptions that are 
>> significantly misaligned with how fabric based networks have been and 
>> are built. Yes, it is possible to find environments where the model 
>> would apply directly and with no impact, but one would need to look 
>> for such deployments quite hard, and with a high probability that 
>> would be proof of concept or technology demonstration type of environments.
>>
>> fragments need to be bound together - that is the reality, and that 
>> is not necessarily wrong. IETF should be focusing on what it can do 
>> best - the fragments, and align with users of the fragments on how to 
>> improve the fragments but not try to direct how users should be 
>> building their networks. It is important for the reputation of IETF 
>> as a credible SDO - if IETF manageability mechanisms propose and 
>> enforce not necessarily right - or just plain broken - network 
>> designs, that is a reputation problem. This document tends to be 
>> proposed standard, and that sets a strong message.
>>
>> Ignas
>>
>>
>>> 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
>>> 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.
>>>
>>> representation of DC fabric? Why is DC fabric network topology 
>>> special compared to any generic fabric based topology?
>>>
>>> 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.
>>>
>>> context while they are called device capabilities. Are those the 
>>> only possible service capabilities? What is the effect of 
>>> configuring those capabilities?
>>>
>>> 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.
>>>
>>>
>>> cases documents provide value beyond historic record. Is the 
>>> reference to I2RS use cases document really needed?
>>>
>>> What is atomic network?
>>>
>>> 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?
>>>
>>> project hasn't got much activity over last two years. Are you aware 
>>> of any other implementations or deployments?
>>>
>>>
>>>

--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf

---

From: Ignas Bagdonas <[email-masked]>
Date: Thu, 5 Apr 2018 21:35:37 +0100

Hi Sue,

I am responding as a DISCUSS holder. Warren may have different ABSTAIN 
views.

On 05/04/2018 16:12, Susan Hares wrote:
> 1) a DISCUSS based on direct comparison of the I2RS models (dynamic and configuration) with the TE models (configuration only),

This is incorrect. DISCUSS is based on very different background. I2RS 
and TE models are a small fragment in that background, and as I have 
mentioned in previous mails, it is not of primary importance.

> 2) "This will not work".

This is incorrect. DISCUSS is based on the impact of proposed mechanism 
to operations.

Please take a look at my DISCUSS notes again. And let's analyse them in 
detail then.

Network management mechanisms do not exist in vacuum, they are applied 
onto the entities being managed. Management mechanisms need to fit with 
the entities (in a broad sense of the word, including network elements 
and how those elements bind together - the network design) that they are 
trying to manage. Network design prescribes how the management mechanism 
will look and operate. DC fabric topology document appears to try to do 
the opposite - it provides assumptions and restrictions on how the 
network design that would be suitable for this model to be applied to 
has to look like. And that design appears to be substantially different 
than majority of practical deployments in DC network space. Given that 
this document is on standards track, it sends a strong message to the 
community saying that if one wants to use IETF approved DC network 
management mechanism, one needs to design a network based on the 
assumptions in this document. This is the core of my DISCUSS - the 
document as it is worded now prescribes network designs and 
manageability approaches that are disconnected from operational reality. 
If this was an informational document - likely I would not have much 
concerns on the same basis, but STD track document has a different impact.

Now onto the detailed parts of the DISCUSS. The scope of this model - 
where is it intended to be applied? Underlay? Overlay? Both at the same 
time? The text intermixes underlay and overlay scope, there are parts 
that seem to target one, the other, and both of them. The scope of ODL 
FAAS project does not help either - it intermixes the concepts even more 
freely. What might have been authors' intention - and I am not 
prescribing that, just guessing - was to take a single overlay instance 
and present it as an underlay, a "fabric as a service" in marketing 
terms, and to provide a model for managing the elements of that specific 
instance _ONLY_. I do not see problems with such approach, but the 
document needs to be very clear on the scope and the proposed 
mechanisms. If authors' scope intentions were different then it needs to 
be clarified in detail - the document, at least to me, does not provide 
clarity on the scope. This is a major part of DISCUSS.

The clarity of the model's logic. Model based network management is the 
new command line interface. It needs to be no worse than the industry 
norms for CLI. Having in a model leaf-this with a description of "this 
is leaf-this" does not seem to be sufficient. This is a minor part of 
DISCUSS.

TE topology - I fail to see anything resembling suggestions in the text 
of the DISCUSS. That is a question. It is a minor part of DISCUSS.

Stages, ports, roles, policies - those all are questions. All are minor 
parts of DISCUSS.

RPC - again, that was a question. I fail to see anything resembling a 
suggestion. That is a minor part of DISCUSS.

> I need clarity to guide the WG/authors to a successful resolution of your DISCUSS/Abstain.
>

The DISCUSS problem is above the specific details of specific models.

> 1) The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that the reader cannot understand it without ambiguity.

Yes. Model is not a protocol as such, and the flaws in model would 
impact not the model directly but the entities being managed by that 
model - it is a specifics of models vs protocols.

> 2) Widespread deployment would be damaging to the Internet or an enterprise network for reasons of congestion control, scalability, or the like.

Yes. Or the like - manageability practices.

> I expect an IESG members to be able to inform a WG chair which the discuss criteria you are specifying. Please let me know if you have additional questions.  Your comments on the telechat did not i…

What are your concerns?

Ignas

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 Apr 2018 16:58:15 -0400

Ignas: 

Thank you for the clarifying email.  I just wanted to understand the type of discuss.   This statement clarifies the discuss: 

  DISCUSS is based on the impact of proposed mechanism to operations

This matches the following category from DISCUSS:    "It would present serious operational issues in widespread deployment, by for example neglecting network management or configuration entirely." 
 
May I suggest if the TE is a minor issue, you move the TE comparison to comments so we can focus on the others?  You can always raise it to the DISCUSS level later after we solve the main issue.   

Do the suggestions that Yan start to address the problem? Is she heading in the right direction? If not, we may need to open up the discussion to a wider audience in the WG and the I2RS AD. 

Cheerily, Susan Hares 

========

When you say "not of primary importance", does this mean the I2RS/TE models are in the DISCUSS or out of it? 

-----Original Message-----
From: Ignas Bagdonas [mailto:[email-masked]] 
Sent: Thursday, April 5, 2018 4:36 PM
To: Susan Hares; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; 'The IESG'
Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

Hi Sue,

I am responding as a DISCUSS holder. Warren may have different ABSTAIN views.

On 05/04/2018 16:12, Susan Hares wrote:
> 1) a DISCUSS based on direct comparison of the I2RS models (dynamic 
> and configuration) with the TE models (configuration only),

This is incorrect. DISCUSS is based on very different background. I2RS and TE models are a small fragment in that background, and as I have mentioned in previous mails, it is not of primary importance.

> 2) "This will not work".

This is incorrect. DISCUSS is based on the impact of proposed mechanism to operations.

Please take a look at my DISCUSS notes again. And let's analyse them in detail then.

Network management mechanisms do not exist in vacuum, they are applied onto the entities being managed. Management mechanisms need to fit with the entities (in a broad sense of the word, including network elements and how those elements bind together - the network design) that they are trying to manage. Network design prescribes how the management mechanism will look and operate. DC fabric topology document appears to try to do the opposite - it provides assumptions and restrictions on how the network design that would be suitable for this model to be applied to has to look like. And that design appears to be substantially different than majority of practical deployments in DC network space. Given that this document is on standards track, it sends a strong message to the community saying that if one wants to use IETF approved DC network management mechanism, one needs to design a network based on the assumptions in this document. This is the core of my DISCUSS - the document as it is worded now prescribes network designs and manageability approaches that are disconnected from operational reality. 
If this was an informational document - likely I would not have much concerns on the same basis, but STD track document has a different impact.

Now onto the detailed parts of the DISCUSS. The scope of this model - where is it intended to be applied? Underlay? Overlay? Both at the same time? The text intermixes underlay and overlay scope, there are parts that seem to target one, the other, and both of them. The scope of ODL FAAS project does not help either - it intermixes the concepts even more freely. What might have been authors' intention - and I am not prescribing that, just guessing - was to take a single overlay instance and present it as an underlay, a "fabric as a service" in marketing terms, and to provide a model for managing the elements of that specific instance _ONLY_. I do not see problems with such approach, but the document needs to be very clear on the scope and the proposed mechanisms. If authors' scope intentions were different then it needs to be clarified in detail - the document, at least to me, does not provide clarity on the scope. This is a major part of DISCUSS.

The clarity of the model's logic. Model based network management is the new command line interface. It needs to be no worse than the industry norms for CLI. Having in a model leaf-this with a description of "this is leaf-this" does not seem to be sufficient. This is a minor part of DISCUSS.

TE topology - I fail to see anything resembling suggestions in the text of the DISCUSS. That is a question. It is a minor part of DISCUSS.

Stages, ports, roles, policies - those all are questions. All are minor parts of DISCUSS.

RPC - again, that was a question. I fail to see anything resembling a suggestion. That is a minor part of DISCUSS.

What are your concerns?

Ignas

---

From: "Zhuangyan (Yan)" <[email-masked]>
Date: Sun, 8 Apr 2018 09:37:09 +0000

Hi Ignas,

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

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

Ignas:

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

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.

Susan Hares

-----Original Message-----
From: Ignas Bagdonas [mailto:[email-masked]]
Sent: Tuesday, April 03, 2018 7:40 PM
To: The IESG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

DISCUSS:

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

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.

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.

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

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

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

    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.

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.

COMMENT:

What is atomic network?

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.

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

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

---

From: "Zhuangyan (Yan)" <[email-masked]>
Date: Wed, 18 Apr 2018 09:30:39 +0000

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' <[email-masked]>; Susan Hares <[email-masked]>; 'The IESG' <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: FW: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

Hi Ignas,

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

Ignas:

Susan Hares

-----Original Message-----
From: Ignas Bagdonas [mailto:[email-masked]]
Sent: Tuesday, April 03, 2018 7:40 PM
To: The IESG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

DISCUSS:

Does it make sense?

Needs to be documented.

    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;

        }

    }

COMMENT:

What is atomic network?

Thank you.

Ignas