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

Alexander Clemm <alexander.clemm@huawei.com> Wed, 01 February 2017 22:04 UTC

Return-Path: <alexander.clemm@huawei.com>
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 8F18F12955E; Wed, 1 Feb 2017 14:04:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.418
X-Spam-Level:
X-Spam-Status: No, score=-7.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 nErDRLowNR9Q; Wed, 1 Feb 2017 14:04:13 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCFBC12945C; Wed, 1 Feb 2017 14:04:11 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFQ14940; Wed, 01 Feb 2017 22:04:09 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 1 Feb 2017 22:04:07 +0000
Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML701-CHM.china.huawei.com ([169.254.3.132]) with mapi id 14.03.0235.001; Wed, 1 Feb 2017 14:04:01 -0800
From: Alexander Clemm <alexander.clemm@huawei.com>
To: Alia Atlas <akatlas@gmail.com>, Lou Berger <lberger@labn.net>
Thread-Topic: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
Thread-Index: AQHSdw/ybSgJ5VGI5EaXm4CY9Zw+S6FJzTqAgAAEUoCAAALgAIALPDiAgAALPACAABeFgIAABLgA//+CeZA=
Date: Wed, 01 Feb 2017 22:03:59 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D7EE@SJCEML703-CHM.china.huawei.com>
References: <CAG4d1rf+HNHfN0qNRpZKC2NZnj9gjKUdiHU9H-56J6-pefs3dA@mail.gmail.com> <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <CAG4d1rehjq327TTBk1n4gyRBL4yT97vnXN4sdjwYJp7aaT926g@mail.gmail.com> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> <c9f5d0e5-5cf0-9dbf-efb3-1111b0c92d9b@labn.net> <20170201193238.GA82029@elstar.local> <5204157b-1379-e217-5bcd-576ffeed6a91@labn.net> <CAG4d1rchU3uaSCo4GaE7VSg51Z087KHkEjj1bGDjiZt3BLdmig@mail.gmail.com>
In-Reply-To: <CAG4d1rchU3uaSCo4GaE7VSg51Z087KHkEjj1bGDjiZt3BLdmig@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.48.43]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D7EESJCEML703CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58925B59.034F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 6ff3d7af1302c2899e961bf42b5ae590
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/h90B5mi5Bzr-bhcmJu3TOz3u6nk>
Cc: "draft-ietf-i2rs-yang-l3-topology@ietf.org" <draft-ietf-i2rs-yang-l3-topology@ietf.org>, "i2rs@ietf.org" <i2rs@ietf.org>, "iesg@ietf.org" <iesg@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: Wed, 01 Feb 2017 22:04:15 -0000

We are working this separately and will articulate the different options and their respective issues.

The fundamental issue is still the fact that you may have dependencies in overlay topologies on underlay topologies that are discovered and represent “state”, and that in fact your underlay may be either.

RFC 7223, as far as I can tell, sidesteps this issue.  It does define a type “interface-ref” with a path to reference a configured interface, and it does define a type  “interface-state-ref” to reference an operationally present interface.  However, interface-state-ref is used only in read-only objects, whereas (to put the analogy) it is needed for configurable objects as well.  Likewise, there are two types; really we need a union which would allow either (or a leafref with alternate paths, which is not supported).  While there are some analogies with a preprovisioning scenario, there are also differences.

Anyway, Xufeng, Kent, Pavan and I are having offline discussions and will come back with further elaboration on this.

--- Alex

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Wednesday, February 01, 2017 1:14 PM
To: Lou Berger <lberger@labn.net>
Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; iesg@ietf.org
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

On Wed, Feb 1, 2017 at 3:56 PM, Lou Berger <lberger@labn.net<mailto:lberger@labn.net>> wrote:


On 2/1/2017 2:32 PM, Juergen Schoenwaelder wrote:
> On Wed, Feb 01, 2017 at 01:52:25PM -0500, Lou Berger wrote:
>> Juergen,
>>
>>     What precludes treating such dependencies in the same way
>> per-provisioning is handled by RFC7223?
>>
> This is fine. But having direct dependencies, e.g., leafrefs from
> config true leafs to config false leafs, is not.
>
> /js
>

Okay, then we're on the same page -- I think some may have missed the
possibility of handling references to dynamic topology information in
config using a 'pre-provisioning' approach.

I would be happy to see Alex, Xufeng, Kent & Pavan articulate what this would
look like and how it would work for the base topology model, so that the WG can
consider all potentially viable options.  I'm not certain how it would function for the
recursive nature and it does presume the separate /config and /oper-state trees in
the data-model that were a concern (though certainly the current recommended
approach for YANG models).

Regards,
Alia