[Teas] IETF TE Topology YANG Model Design Meeting Notes - 2017-05-17

Xufeng Liu <Xufeng_Liu@jabil.com> Tue, 23 May 2017 14:18 UTC

Return-Path: <Xufeng_Liu@jabil.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B3D129A8F for <teas@ietfa.amsl.com>; Tue, 23 May 2017 07:18:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.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 ZyZ5jJsXTtVU for <teas@ietfa.amsl.com>; Tue, 23 May 2017 07:18:51 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0117.outbound.protection.outlook.com [104.47.37.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A559E129576 for <teas@ietf.org>; Tue, 23 May 2017 07:18:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2FWwcPROxLZgAMJhRjS0YkG2eYjcAqoPuL2oE+jL3zw=; b=hV+uFf1j+ITdDT3xp5uOsclnouEfPsUA1qbjgmGipXezmSp9lW7ALl4PfgB/IigLilder4l2J98Zgxq+b2Ewhk/GzT/oEMp/He7PsgF9Lo+eaDWvQORv9w/5Rj1oQEJ7YWKyZLQj0/idjTCeha6s5juInu8jdaHdtIld8OTc0yE=
Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.14; Tue, 23 May 2017 14:18:44 +0000
Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1101.019; Tue, 23 May 2017 14:18:44 +0000
From: Xufeng Liu <Xufeng_Liu@jabil.com>
To: Vishnu Pavan Beeram <vbeeram@juniper.net>, Igor Bryskin <Igor.Bryskin@huawei.com>, Oscar Gonzalez De Dios <oscar.gonzalezdedios@telefonica.com>, Tarek Saad <tsaad@cisco.com>, Himanshu Shah <hshah@ciena.com>, Lou Berger <lberger@labn.net>, "BRUNGARD, DEBORAH A (ATTLABS)" <db3546@att.com>, Susan Hares <shares@ndzh.com>, "Zafar Ali (zali)" <zali@cisco.com>, "Khaddam, Mazen (CCI-Atlanta)" <Mazen.Khaddam@cox.com>, "BELOTTI, SERGIO (SERGIO)" <sergio.belotti@alcatel-lucent.com>, "Beller, Dieter (Dieter)" <dieter.beller@alcatel-lucent.com>, Rajan Rao <rrao@infinera.com>, "Zhangxian (Xian)" <zhang.xian@huawei.com>, "xufeng.liu.ietf@gmail.com" <xufeng.liu.ietf@gmail.com>, "Belotti, Sergio (Nokia - IT)" <sergio.belotti@nokia.com>, Anurag Sharma <AnSharma@infinera.com>, Mateusz Waldman <MWaldman@advaoptical.com>, Paweł Kaczmarek <PKaczmarek@advaoptical.com>, Monali Chakrabarty <MChakrabarty@advaoptical.com>, Italo Busi <Italo.Busi@huawei.com>, Carlo Perocchio <carlo.perocchio@ericsson.com>, "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>, "Giles Heron (giheron)" <giheron@cisco.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Leeyoung <leeyoung@huawei.com>
CC: "teas@ietf.org" <teas@ietf.org>
Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2017-05-17
Thread-Index: AdLTzilgf34qHZ4uQTyDeiWz/rQNnw==
Date: Tue, 23 May 2017 14:18:44 +0000
Message-ID: <BN3PR0201MB0867C2204958BA8F25C334F0F1F90@BN3PR0201MB0867.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=jabil.com;
x-originating-ip: [98.191.72.170]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0201MB0867; 7:E+96Rry98RhRLSYcs6RfXi1p6sI0JBIF6T3ys0lMj84N6R7C51JiY2o/1GWMbS3jTQcpqrcShhxzBFPukLKvDI50DA1nR0B/4GwGaF2C57htWnOfUeu46kYfT/hE0C00t+VjMZ1OdaAhb7qGFm8I6fERlpXx30vDc+wXGP5/Lwbq5mn+d7DVV4d3RQ50Yaq5KW2ng1TtjYhzV5ArOkHagO6s5p4xB0273PabjVA0Lzd9OI0rVjhNIjXfqkO1xt7Jtc/ltyrdWZcAj+tDVRPdgl9En9jXVMoWT5xqcPUSWGQfvvYSIOfqBbTP2BVv5duFIsz4rBnhJ49akISMpLxfqg==
x-ms-traffictypediagnostic: BN3PR0201MB0867:
x-ms-office365-filtering-correlation-id: 7b2defa9-1079-424c-b715-08d4a1e69f0e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR0201MB0867;
x-microsoft-antispam-prvs: <BN3PR0201MB086711D785ACB3D6F8037C2CF1F90@BN3PR0201MB0867.namprd02.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123558100)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR0201MB0867; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0201MB0867;
x-forefront-prvs: 0316567485
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39400400002)(39450400003)(39410400002)(39860400002)(39840400002)(37854004)(5423002)(2900100001)(80792005)(1941001)(81166006)(7696004)(7736002)(4326008)(6116002)(2501003)(25786009)(5890100001)(790700001)(3846002)(966005)(72206003)(39060400002)(102836003)(66066001)(9686003)(99286003)(8936002)(122556002)(55016002)(50986999)(6306002)(77096006)(54896002)(53936002)(8676002)(236005)(606005)(6436002)(86362001)(54356999)(6506006)(230783001)(189998001)(7906003)(508600001)(33656002)(7416002)(5660300001)(3660700001)(8666007)(38730400002)(8656002)(3280700002)(2906002)(74316002)(921003)(1121003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB0867; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0201MB0867C2204958BA8F25C334F0F1F90BN3PR0201MB0867_"
MIME-Version: 1.0
X-OriginatorOrg: jabil.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2017 14:18:44.8153 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0867
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/fzuiDM5RohxsOJbDGw_qxh7jyDY>
Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2017-05-17
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 May 2017 14:18:55 -0000

Attendees: Igor, Xufeng, Carlo, Dieter, Sergio, Rakesh, Young, Tarek

- NMDA discussion (https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01) for three options:
1) Compromised position: Publish with the current model, and start an NMDA compliant revision in TEAS WG.
   > Proposed by Kent:
     "Perhaps, in the spirit of doing the right thing, the TEAS WG can commit to adopting a draft to publish the NMDA-compatible model ASAP?"

2) NMDA module in main body, and current module in a non-normative appendix.
   > Comment from Lou:
     "Keep in mind that the non-nmda modules will still be in a Standards Track RFC,  just in an appendix.  I suspect those that would be discouraged by a non-PS document will miss the subtly of the implications of being in an appendix..."

3) NMDA module in main body, a new state model in appendix, and current model in another appendix with a new name space.
   > Proposed by Rob Wilton:
     https://github.com/rgwilton/ietf-models-to-combined
   "I've just generated the necessary "-state" modules as well, and committed them to the same github repository above.

    I've also checked that that the modules compile cleanly by confdc (to check the xpaths) as well as pyang.

    It is worth noting the the changeset to convert the "ietf-te-topology" from the current draft to NMDA style is only about 175 lines.  I had another 24 line diff to the te-types.yang as well.  I.e. we are really not talking about a big change here (diffs attached, and combined generated trees attached).

    Given that the modules haven't even been through YANG doctor review yet (which could easily change the structure of the modules), and given that removing the "config/state" containers is a formulaic change (which I believe I've already done) then I guess that I don't really see why they don't now follow the agreed guidance that they were previously waiting for.

    I.e.
    - Publish the NMDA style modules in the body of the draft.
    - Publish the extra -state modules in the appendix.
    - Publish the current draft modules in another appendix (in a separate namespace).

    It feels that adding in the NMDA shouldn't really significantly slow the document progress down, and choosing to publish the current model as the main standard seems like a strange choice for IETF to take when we know that the module has the wrong structure to the future direction in IETF, and that fixing the draft now to comply seems to be of relatively cheap cost (compared to the overhead of the YANG doctor review, WG last call, and IESG publication process).

    Perhaps this draft would be a good test to ensure that the datastore guidelines process works well."

-----
Attendees discussed the three options above, and agreed that:
Option 1) is preferred.
  > The solution fits our situation best.
  > Publish the current version with the current structure ASAP.
  > The current on-going implementations can continue without restructuring.
  > The NMDA compatible model will be the next version, with a new document, incorcorporating furthur experiences from implementations.
  > NMDA compatible implementation can start in a year or so with planned structure upgrades, when updated protocol specifications and implementations are available.

- Discussed some type sharing with TE tunnel model
  > disjointness
   o Xufeng will move this type to te-types.

  typedef te-path-disjointness {
    type bits {
      bit node {
        position 0;
        description "Node disjoint.";
      }
      bit link {
        position 1;
        description "Link disjoint.";
      }
      bit srlg {
        position 2;
        description "SRLG (Shared Risk Link Group) disjoint.";
      }
    }
    description
      "Type of the resource disjointness for a TE tunnel path.";
    reference
      "RFC4872: RSVP-TE Extensions in Support of End-to-End
       Generalized Multi-Protocol Label Switching (GMPLS)
       Recovery";
  } // te-path-disjointness

  > path-properties
   o Tarek will move the grouping to te-types

Thanks,

- Xufeng

Note: Please drop me an email if you need an invite for joining the weekly call.