Re: [mpls] [netmod] Use of schema mounts for common model

Robert Wilton <rwilton@cisco.com> Tue, 03 May 2016 14:34 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925E612D83B; Tue, 3 May 2016 07:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level:
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 gYEvxdn4l6Z7; Tue, 3 May 2016 07:34:50 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBEAC12D836; Tue, 3 May 2016 07:34:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18533; q=dns/txt; s=iport; t=1462286087; x=1463495687; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=6hapEK+4a5NqZEWnEcnwCcVDxluvGkBsuEWvYhVB5YY=; b=gMKK5CMKI/VhRpfuu3P9n9yWhPOF4kNfF8ROe7fbBv762fdU6gkfEqan wUT+rrldSLpB42Bh0G4MlPYYu7YVxZmN9c+udVUtRvZmihTFEeUxN1qho Ij+TaFRODtw4rmJBOVK2xXxtSX7eVPvBnRqeS1/EIQ1KIfOqyRTLWGfhi c=;
X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="scan'208,217";a="677025390"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2016 14:34:45 +0000
Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u43EYifm013526; Tue, 3 May 2016 14:34:44 GMT
To: "Tarek Saad (tsaad)" <tsaad@cisco.com>
References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> <20160429.122943.1926404425708749601.mbj@tail-f.com> <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <ae82ab7c-df1d-605e-9cf0-622818e9af2e@cisco.com>
Date: Tue, 03 May 2016 15:34:44 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com>
Content-Type: multipart/alternative; boundary="------------57E5E5B11600F1732E20E271"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/k1sJEVJj5SMhFzh2SbYU98lEsbU>
Cc: "mpls@ietf.org" <mpls@ietf.org>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>, "teas@ietf.org" <teas@ietf.org>, "draft-ietf-teas-yang-te@ietf.org" <draft-ietf-teas-yang-te@ietf.org>, "draft-ietf-netmod-schema-mount@ietf.org" <draft-ietf-netmod-schema-mount@ietf.org>
Subject: Re: [mpls] [netmod] Use of schema mounts for common model
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 May 2016 14:34:56 -0000

Hi Tarek,

I'm also wondering whether using schema mount in this way might be a bit 
like using a sledgehammer to crack a nut.

With interfaces, there is a per device global list of interfaces where 
each list entry can have a different type and different properties.  
Currently these are using the iana:iftype to differentiate their 
different schema modes, but there is an idea to use more abstract 
identities.

I'm not really familiar with the tunnel YANG models, but I was wondering 
whether the same approach has been considered for the TE tunnel YANG 
models at all?

I.e. rather than having a separate protocol instantiation for each 
different data plane technology, instead have a per device global list 
of tunnels that hold the configuration and operational state, making use 
of when statements and identities (if required) to manage dataplane 
specific leaves.  Each protocol specific data plane module could also 
maintain a protocol specific list containing leaf-refs back to the 
appropriate tunnels in the master list.

Thanks,
Rob


On 29/04/2016 17:17, Tarek Saad (tsaad) wrote:
> Thanks Martin, please see inline..
>
>
> On 2016-04-29, 6:29 AM, "Martin Bjorklund" <mbj@tail-f.com 
> <mailto:mbj@tail-f.com>> wrote:
>
>     "Tarek Saad (tsaad)" <tsaad@cisco.com <mailto:tsaad@cisco.com>> wrote:
>
>         Hi authors/WG,
>         In draft-ietf-teas-yang-te, we are driving the definition for a
>         generic TE YANG model that can/may be used (and extended when
>         necessary) for different data plane technologies (e.g. MPLS,
>         OTN, WDM,
>         etc.).
>         Reviewing the schema mount idea presented in
>         draft-ietf-netmod-schema-mount, we are thinking this proposal is
>         useful and can facilitate the reuse of the our model in multiple
>         places in the YANG tree (once per each technology), e.g.:
>         …/mpls/mount-points/mount-point/module=ietf-te.yang
>         …/otn/mount-points/mount-point/module=ietf-te.yang
>
>
>     Schema mount is probably not the right solution to your problem.  I
>     think a better solution in your case is to define groupings.
>     Groupings are designed to be re-used at different places in the
>     hierarchy.
>
>
> We thought of this earlier, and found groupings pose their own set of 
> challenges too.. Specifically:
> - a groupings with leafrefs could not reference data nodes that reside 
> in another grouping
> - a grouping with leafrefs of relative path were challenge when the 
> relative path references data nodes outside the grouping
> - the augmentation of the grouping by other modules is not as 
> straightforward
>
> That said, the grouping proposal seems to
>
> one could also think that with groupings one could address reuse of 
> the a model (e.g. Ietf-interfaces) for logical devices or VM (see 
> below). In fact, in your draft (section 2) you explicitly discourage 
> this approach as not scalable solution
>
>
>    With the "uses" approach, ietf-interfaces would have to define a
>    grouping with all its nodes, and the new model for logical devices
>    would have to use this grouping.  This is a not a scalable solution,
>    since every time there is a new model defined, we would have to
>    update our model for logical devices to use a grouping from the new
>    model.  Another problem is that this approach cannot handle vendor-
>
>
>
>         We have a comment/concern/suggestion and we value your feedback.
>         The generic TE model currently references data nodes in the global
>         tree (e.g. from the ietf-interfaces model to define additional TE
>         properties associated with a specific device interface). Our
>         understanding after reading section 3.1 of your draft is the
>         mounted
>         model can *not* reference any data nodes outside the scope of the
>         mount-point (e.g. global data nodes in the yang tree). This
>         poses a
>         limitation for us, do you have a suggestion for this problem?
>         One possible solution we thought of was to replace the leaf-refs
>         pointing to the global data nodes (e.g. Ietf-interfaces) with
>         context
>         names (e.g. the interface name).. This decouples the data-nodes
>         defined in the TE generic model from those in the global tree
>         (e.g. the actual interface ietf-interfaces model). Any feedback on
>         this or better suggestions?
>
>
>     If you use groupings instead, you can still use proper leafrefs.
>
>
> Not in all cases — as described above.
>
> Regards,
> Tarek
>
>
>
>     /martin
>
>
>
>         Regards,
>         Tarek
>         Excerpt from draft-ietf-netmod-schema-mount
>         3.1<https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-01#section-3.1>.
>         Augment and Validation in Mounted Data
>             All paths (in leafrefs, instance-identifiers, XPath
>         expressions, and
>             target nodes of augments) in the data models mounted at a
>         mount point
>             are interpreted with the mount point as the root node, and the
>             mounted data nodes as its children.  This means that data
>         within a
>             mounted subtree can never refer to data outside of this
>         subtree.
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod