IETF Logo Mail Archive

Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

Kent Watsen <kwatsen@juniper.net> Fri, 03 February 2017 18:11 UTC

Return-Path: <kwatsen@juniper.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 9AEE31293FB; Fri, 3 Feb 2017 10:11:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level:
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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=junipernetworks.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 dyylEAJXWbmf; Fri, 3 Feb 2017 10:11:31 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0121.outbound.protection.outlook.com [104.47.42.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85E0412948B; Fri, 3 Feb 2017 10:11:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=T6AKuowYQvRv5XgaKKT6rOmkiIKdlYsy2643IuigwzY=; b=TGBNDPa3KPSrY/ldg6JuH1QmdPAWEhm/qNw8oUC2SYDCXN+T3KPBdMRuwtLCUC3ocG1DLOcaluY1wOAk6zNK9POpr7AFZXMUQV1IeHa6Tejqwqz96r+3DjnEI3GL1CRjpvONftzE92Yxo4keonpsRCGLFvU/NpWe1GQIZerRuqs=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Fri, 3 Feb 2017 18:11:30 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0888.018; Fri, 3 Feb 2017 18:11:30 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Xufeng Liu <Xufeng_Liu@jabil.com>, Martin Bjorklund <mbj@tail-f.com>
Thread-Topic: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
Thread-Index: AQHSdw/yqRSiXVe4g0u0BDQlaxXyX6FJRx6AgAAEUoCAAALgAIALPDeAgAALPQCAABeFgIAABLgAgAAODICAAJ8egIAAbOUAgAAlhgCAAA+qAIAAOUOAgAEq7wCAABHTAIAABTiAgAAExACAAAJvgP//zECA
Date: Fri, 03 Feb 2017 18:11:30 +0000
Message-ID: <030B0A7E-5238-4D78-BC97-2140B269D82A@juniper.net>
References: <BN3PR02MB1141BE8B907D10AAFAA6BDA7F14F0@BN3PR02MB1141.namprd02.prod.outlook.com> <20170203.163216.1400419881696462638.mbj@tail-f.com> <BN3PR02MB11416DD67AB92C6620CEF7E4F14F0@BN3PR02MB1141.namprd02.prod.outlook.com> <20170203.170800.1259525494650193374.mbj@tail-f.com> <BN3PR02MB114192FEEF7116B20D314658F14F0@BN3PR02MB1141.namprd02.prod.outlook.com>
In-Reply-To: <BN3PR02MB114192FEEF7116B20D314658F14F0@BN3PR02MB1141.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1e.0.170107
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-ms-office365-filtering-correlation-id: 92b5a182-cae0-4144-c180-08d44c60144d
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1443;
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:1oiGmJ6eqc3h9HZlAjgbFZ2gY3cZQUpU0b2QIcD9WTqf7NISHeoyq1uYir/JRBZhbIck2pf7BGlBJ+wcUr/rwOLWv3gSoGEL6hvc+1PV8R9NaeH7oTXfKyAQpmySiTyKLXzgF7QORcAUe+ZtoO5PA0rKS0uOa9pfKBdo4AmzUP4Qiatjjog5yrkaKqtLctOUKAuTTLxqMem1g7Qv5Xh+q/25cBKW+CX20gBcJ+fPHijN2qZrguqkGuJeRxyK7nVfdivU4UgUxg2VSRourDf2kkoM28KX8+2uG2jV8WAR63v3bWFZAt92DezE42SeAj5JGMfnZP32um65cGSrX5H6pjKfh5tSL5bkuaTNpnlqcGaFf5szGGxg/wCzs4JbVfDiY51wqjwcYCIbUjBeyECDVuyFQFLEu4Nf0+Sn/vjSswmvJ/K9mBNhHnX7Fcd5roxtbkArwVymgNFU0ldsKIn2GgDz2Q0SiK4Ewae2S21wjFHg54RPIioQw+aeAVfh3MGlUYruUI5EXHbIqT8kazVLVA==
x-microsoft-antispam-prvs: <BN3PR0501MB144391EBD7B2D62139BE2CFAA54F0@BN3PR0501MB1443.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123558025)(20161123555025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443;
x-forefront-prvs: 02070414A1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39410400002)(39860400002)(39450400003)(39850400002)(189002)(199003)(52314003)(189998001)(2906002)(4001350100001)(4326007)(97736004)(66066001)(6116002)(2900100001)(5001770100001)(93886004)(36756003)(561944003)(230783001)(92566002)(3846002)(229853002)(6506006)(102836003)(38730400001)(33656002)(54906002)(86362001)(6512007)(3280700002)(25786008)(6486002)(68736007)(3660700001)(82746002)(83716003)(77096006)(83506001)(6436002)(99286003)(122556002)(81166006)(50986999)(76176999)(53936002)(305945005)(7736002)(8676002)(81156014)(54356999)(5660300001)(101416001)(2950100002)(105586002)(8936002)(106116001)(6246003)(106356001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <C4A58534E57BB64AAE7A6DFB04215EC6@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2017 18:11:30.6433 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/smqImkkXIMgcErVmt528VcA-5G4>
Cc: "draft-ietf-i2rs-yang-l3-topology@ietf.org" <draft-ietf-i2rs-yang-l3-topology@ietf.org>, "i2rs@ietf.org" <i2rs@ietf.org>
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 03 Feb 2017 18:11:33 -0000

[Xufeng] Right. If we do so, the approach will be different from RFC7223, and requires the capability that a "config true" leafref references a "config false" leaf.


I think my proposal was misunderstood, so here's a more complete example:

Assume the following schema is used by client/servers that implement the long-term
opstate solution presented in the revised-datastores draft:

   module foo {
      container nodes {
         config true;
         list node {
            key "name";
            leaf name { type string; }
            leaf dependency {
               type leafref {
                 path "../node/name"
                 require-instance false;
                 description
                   "In the case when a configured node (i.e. in the running DS)
                    has a dependency on a node that is not configured, the system
                    may try to resolve the dependency as operational state data
                    (i.e. in the operational-state DS).  As operational state 
                    data may have a lifecycle independent of configuration, there
                    is no guarantee that the opstate data will exist.  Therefore,
                    application of the configuration node is conditional, resulting
                    in an effect much like pre-provisioning interfaces in RFC 7223.";
               }
            }
         }
     }
   }


Specifically, note that the leafref is from one config true node to another config
true node.  I understand that the semantics are almost as if it were like a config
true node were pointing to a config false node, but I believe that this should be
okay, that is, that we should specifically define this convention as okay.


Assuming that we're okay with the above, we proposal for a near-term solution, that
does NOT utilize the opstate solution, follows:

   module foo {
      container nodes {
         config true;
         list node {
            key "name";
            leaf name { type string; }
            leaf dependency {
               type leafref {
                 path "../node/name"
                 require-instance false;
                 description
                   "In the case when a configured node (i.e. in the running DS)
                    has a dependency on a node that is not configured, the system
                    may try to resolve the dependency as operational state data
                    (i.e. under the /nodes-state tree).  As operational state 
                    data may have a lifecycle independent of configuration, there
                    is no guarantee that the opstate data will exist.  Therefore,
                    application of the configuration node is conditional, resulting
                    in an effect much like pre-provisioning interfaces in RFC 7223.";
               }
            }
         }
      }
      container nodes-state {
         config false;
         list node {
            key "name";
            leaf name { type string; }
            leaf dependency {
               type leafref {
                 path "../node/name"
                 require-instance false;
               }
            }
         }
      }
   }


This module is semantically identical to the first, but now, in additional
to the leafref potentially hopping datastores, it also needs to hop paths 
(i.e. s/nodes/nodes-state/). Note the minute change in the first sentence
of the description statement.  Yes, it's a hack, but since the hopping is
implemented internally anyway, maybe it's okay as a stop-gap short-term
solution?


Kent

v2.23.0 | Report a Bug | By Email