Sue Hares
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Ignas Bagdonas
Sent: Wednesday, April 4, 2018 10:31 AM
To: Susan Hares; 'The IESG'
Cc: [email protected];
[email protected];
[email protected]
Subject: Re: [i2rs] Ignas Bagdonas' Discuss on
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and
COMMENT)
Hi Sue,
On 03/04/2018 14:59, Susan Hares wrote:
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?
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.
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.
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 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 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.
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.
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 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.
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.
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,
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
Thank you for your review,
Susan Hares
-----Original Message-----
From: Ignas Bagdonas [mailto:[email protected]]
Sent: Tuesday, April 3, 2018 7:40 AM
To: The IESG
Cc: [email protected]; Susan
Hares; [email protected]; [email protected]; [email protected]
Subject: Ignas Bagdonas' Discuss on
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and
COMMENT)
Ignas Bagdonas has entered the following ballot position for
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topology/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
I have concerns about the practical usability of this proposed model as
it is specified now.
The intended decoupling of fabric implementation properties (what is
termed as "underlay network infrastructure" in the document) and its
topology seems to be contradicting to general operational practices of
fabric based networks. It is generally true for the context of the
overlay but that is not what the document seems to be focusing on. Fabric
defines and implements the underlay, not the other way around.
The document does not contain a sufficient description of the logic of
the model itself, the reasons for choices made for representation of
types and attributes, and at the same time descriptions in modules are
single lines that do not add clarification beyond being copies of leaf
names. Either there needs to be a section that describes the logic of the
model and how it relates to other models, also including examples, or
module description fields need to have enough content to be able to have
equivalent understanding of model intent and operation. Both are strongly
encouraged, as descriptions have value of itself for being a reference
for use, and model description is needed for understanding how this
particular model fits into the larger hierarchy. Network management does
not end at the boundary of the single domain-specific model, it is
important to build it into a whole system.
Why TE topology model is not sufficient for modelling the representation
of DC fabric? Why is DC fabric network topology special compared to any
generic fabric based topology?
How this model could be used for representing more than two stage fabrics
that are in wide deployment?
Limiting port bandwidth to a fixed rate is too restrictive. The model as
specified already does not cover a set of port speeds that are in
deployment.
How would a device that has more than a single role in the fabric be
represented?
Service capabilities as they are described belong to the overlay context
while they are called device capabilities. Are those the only possible
service capabilities? What is the effect of configuring those
capabilities?
What is compose-fabric RPC? The document does not define any RPCs.
What is policy driven traffic behavior? Is there the only one policy that
fits all possible deployment scenarios?
Looking at the history of the document from the individual submission
time and the comments received, it seems that the point fixes to the text
went in to cover the specific comments but not to address the broader
scope of comments.
The document would definitely benefit from a major rewrite clarifying the
logic behind the decisions made, aligning more with the operational
practice of fabric based network design and deployment, and bringing the
content in YANG modules to be self-describing.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Fabric and POD are not equivalent terms.
I2RS use case requirements document has expired 11 months ago. Use cases
documents are good for tracking the work progress of specification
documents, it is questionable whether standalone use cases documents
provide value beyond historic record. Is the reference to I2RS use cases
document really needed?
What is atomic network?
VLAN is not a fabric building technology as such, while Ethernet is.
What is the need for VNI capacity leaves? What is their effect if
configured?
The document intermixes ietf-fabric-* and ietf-dc-fabric-* namespaces.
Serial port-type is present while Infiniband is not - Infiniband based
fabrics are widely deployed. What is the extensibility mechanism for
adding in new port types?
Is there any deployment experience with this model? The ODL faas project
hasn't got much activity over last two years. Are you aware of any other
implementations or deployments?
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
