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

Warren Kumari <warren@kumari.net> Thu, 05 April 2018 17:53 UTC

Return-Path: <warren@kumari.net>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1659612E038 for <i2rs@ietfa.amsl.com>; Thu, 5 Apr 2018 10:53:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfK9AZH7o3Iq for <i2rs@ietfa.amsl.com>; Thu, 5 Apr 2018 10:52:56 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0127412DFE0 for <i2rs@ietf.org>; Thu, 5 Apr 2018 10:52:54 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id g8so7852980wmd.2 for <i2rs@ietf.org>; Thu, 05 Apr 2018 10:52:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3kZq8sipbjPhhfMj1qZTc82pNJ8zsnw1haJy4OEfz6o=; b=dIum+6eeLl4dE3CrxnCvJi8lRNvz5vbuEB05hLTy6cOF3Vj2OdFztFZqaLYEP4DLC3 3Zi2BiRLRQkh1/29OvAZ3mkPOdi/fMSa2yX4R+B5dj+e7H3P2gY+d8Yj2EBs1wHY1XuR rP3eWrhhEXiBZqJ3wtQFtmC8psYzc+i0OJ3sFV0uoHiUfezN4eXQ9tzz7sUSfwXRrTG/ /NTeOnR6v/MSTnf4vVYTy6OfUGX1rQP2BGZZsNvry0ZZdSGao+DUdn1GMNtzukRAr8sk R3hqIGNjlklXPKAtn92fB/rQdJLDgjCY4VFtxapeK+JriDIdNeQr4TxTFsBDxylgg3YT IEfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3kZq8sipbjPhhfMj1qZTc82pNJ8zsnw1haJy4OEfz6o=; b=bl79fUvXpyU6X9TkkgYHUSd5J2efTl+b6X+ho/vugunuNkbrWKYBxO2Eiy7NzmA8jz PSzowi+JwsuzADo8en1eX1MeXEgJ1RuEHdQSUs+RdGPV7MPi8w1xFoC/jgUZrHfRd7zz BL6soSXOubwWXZNX19SCYzc3GlAk7t26JEx5USaxGXIDP24hDt9rSNJ+H19C5qgKZSqJ qqhqQVPWWSevDHNAaCyQ5VI/8cjiEnA7m3nB/1q44Q+ve/TXlEtDBW/JP7lJAI/9M8Cw uWfVY93CrfgpJiC+EEOtsfRLzvRZMsaAMH+4kZxBM1ukFsL61gJoWhCWG9+XP65I+hxd AiOg==
X-Gm-Message-State: AElRT7F/3euRgB2MOIDZMbFyEBUfZtaqfDlRjrVuys+sr1R1dFRA5imC PM3xgc6Sbl2A0ADRuftyw2VGfaPgsYapqm/UpootI0U3S0c=
X-Google-Smtp-Source: AIpwx48BQEBNqO8ovr3mRvT7V2hM1Gb1RaBZDjgziom2f5Wec/W4AX7tYDH5A4Q5ZCOifM9US1ctFUzoJWxL8E7D25M=
X-Received: by 10.28.139.18 with SMTP id n18mr10576634wmd.26.1522950772712; Thu, 05 Apr 2018 10:52:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.226.76 with HTTP; Thu, 5 Apr 2018 10:52:11 -0700 (PDT)
In-Reply-To: <04bb01d3ccf0$8a9e64d0$9fdb2e70$@ndzh.com>
References: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> <006401d3cb53$f17c36d0$d474a470$@ndzh.com> <b6d55ad0-6bca-68a7-6374-1693c6c10f10@gmail.com> <01c701d3cc26$09865b20$1c931160$@ndzh.com> <d7f30e3a-4597-a763-e848-4735558cf280@gmail.com> <02d001d3cc61$768db9d0$63a92d70$@ndzh.com> <04bb01d3ccf0$8a9e64d0$9fdb2e70$@ndzh.com>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 05 Apr 2018 13:52:11 -0400
Message-ID: <CAHw9_iJ_1V8CWYhU1cVvTx5Wd4b6iPofcf4No9r8Pc+6_jFM1w@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Cc: Ignas Bagdonas <ibagdona@gmail.com>, martin.vigoureux@nokia.com, i2rs@ietf.org, draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org, i2rs-chairs@ietf.org, The IESG <iesg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/vSjAclGI7oUxvmauEz3wnFJdEzI>
Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2018 17:53:01 -0000

On Thu, Apr 5, 2018 at 11:12 AM, Susan Hares <shares@ndzh.com> wrote:
> 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.

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
>
>
> -----Original Message-----
> From: Susan Hares [mailto:shares@ndzh.com]
> Sent: Wednesday, April 4, 2018 6:08 PM
> To: 'Ignas Bagdonas'; 'The IESG'
> Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; i2rs-chairs@ietf.org
> Subject: RE: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)
>
> 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:ibagdona@gmail.com]
> Sent: Wednesday, April 4, 2018 2:40 PM
> To: Susan Hares; 'The IESG'
> Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org;
> i2rs-chairs@ietf.org
> Subject: Re: [i2rs] Ignas Bagdonas' Discuss on
> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and
> COMMENT)
>
>
>
> 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.
>>
>> 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."
> 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.
>
>>
>> 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?
> 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 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.
>
> May I ask you to point to where I have said anything about two deployed implementations?
>
>
> Ignas
>
>> Sue Hares
>>
>>
>> -----Original Message-----
>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Ignas Bagdonas
>> Sent: Wednesday, April 4, 2018 10:31 AM
>> To: Susan Hares; 'The IESG'
>> Cc: i2rs@ietf.org;
>> draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org;
>> i2rs-chairs@ietf.org
>> 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:ibagdona@gmail.com]
>>> Sent: Tuesday, April 3, 2018 7:40 AM
>>> To: The IESG
>>> Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan
>>> Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org
>>> Subject: Ignas Bagdonas' Discuss on
>>> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and
>>> COMMENT)
>>>
>>> Ignas Bagdonas has entered the following ballot position for
>>> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: Discuss
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topology/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> I have concerns about the practical usability of this proposed model as
>>> it is specified now.
>>>
>>> The intended decoupling of fabric implementation properties (what is
>>> termed as "underlay network infrastructure" in the document) and its
>>> topology seems to be contradicting to general operational practices of
>>> fabric based networks. It is generally true for the context of the
>>> overlay but that is not what the document seems to be focusing on. Fabric
>>> defines and implements the underlay, not the other way around.
>>>
>>> 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
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>
>



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