Re: [i2rs] WG LC for Topology (10/1 to 10/14)

"Dongjie (Jimmy)" <jie.dong@huawei.com> Sat, 10 October 2015 01:44 UTC

Return-Path: <jie.dong@huawei.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45141B2EF5 for <i2rs@ietfa.amsl.com>; Fri, 9 Oct 2015 18:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 xqr5Z0Bw7CQs for <i2rs@ietfa.amsl.com>; Fri, 9 Oct 2015 18:44:34 -0700 (PDT)
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 EE1821B2EF8 for <i2rs@ietf.org>; Fri, 9 Oct 2015 18:44:33 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCJ02822; Sat, 10 Oct 2015 01:44:26 +0000 (GMT)
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 10 Oct 2015 02:44:25 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0235.001; Sat, 10 Oct 2015 09:44:16 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "Alexander Clemm (alex)" <alex@cisco.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Susan Hares <shares@ndzh.com>
Thread-Topic: [i2rs] WG LC for Topology (10/1 to 10/14)
Thread-Index: AdD8mZtMK+5wN+PKRMK6Tyi1tCuIrQFhoqyAAB5/BIAAF9VPcA==
Date: Sat, 10 Oct 2015 01:44:15 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927743B5722@nkgeml512-mbx.china.huawei.com>
References: <007701d0fc9a$537bcd90$fa7368b0$@ndzh.com> <20151009072207.GA56815@elstar.local> <DBC595ED2346914F9F81D17DD5C32B5728237026@xmb-rcd-x05.cisco.com>
In-Reply-To: <DBC595ED2346914F9F81D17DD5C32B5728237026@xmb-rcd-x05.cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.97.131]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/o1hRHbAAbQzbxpCuvmr1rRJcroE>
Cc: Ladislav Lhotka <lhotka@nic.cz>, "i2rs@ietf.org" <i2rs@ietf.org>, Martin Bjorklund <mbj@tail-f.com>, Andy Bierman <andy@yumaworks.com>, 'Alia Atlas' <akatlas@gmail.com>, 'Jeffrey Haas' <jhaas@pfrc.org>
Subject: Re: [i2rs] WG LC for Topology (10/1 to 10/14)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 10 Oct 2015 01:44:37 -0000

Hi Juergen, Alex,

Currently in the L2 topology model there is one leaf "tp-state" which is state data. We can remove it first before we reach some agreement on how to introduce operational/state information to topology models.

Besides the approach Juergen suggested, do we also need to consider the approach proposed by openconfig-opstate? 

Best regards,
Jie

> -----Original Message-----
> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alexander Clemm (alex)
> Sent: Saturday, October 10, 2015 5:55 AM
> To: Juergen Schoenwaelder; Susan Hares
> Cc: Andy Bierman; i2rs@ietf.org; Martin Bjorklund; Ladislav Lhotka; 'Alia Atlas';
> 'Jeffrey Haas'
> Subject: Re: [i2rs] WG LC for Topology (10/1 to 10/14)
> 
> Hi Juergen,
> 
> which specific objects/ subtrees are you referring to?
> 
> Essentially, in ietf-network and ietf-network-topology, we have all
> configuration information.  The same is true for the Layer 3 topology - all
> configuration information.  (I cannot comment on L2 topology as I am not
> involved there.)
> 
> Are you saying that we should add an additional branch as a placeholder (and
> perhaps an augmentation target) for operational data, even if we have not
> otherwise defined any operational data?
> 
> The only item in the topology that is read-only concerns the "server-provided"
> flag, but this concerns a separate issue that was also discussed (I am not sure if
> this is what you are referring to).  It is analogous to the other discussion
> concerning distinguishing configuration that has been intended, versus one that
> is in effect etc .  This concerns the issue that some topologies are populated by
> the server whereas some topologies can be populated by client applications.
> We have had discussions in the past whether to "split this up", having a (rw)
> branch to populate "intended" topologies and a (ro) branch for topologies "in
> effect".  We decided against it for various reasons - every piece of information
> would essentially be duplicated inside the model (this is not your normal config
> vs oper data distinction, but would essentially reflect a limitation of the
> framework), leading to unnecessary additional complexity in the model (every
> augmentation has to be conducted in two !
> places),
>  more complex validation rules, etc.
> 
> --- Alex
> 
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder
> Sent: Friday, October 09, 2015 12:22 AM
> To: Susan Hares <shares@ndzh.com>
> Cc: i2rs@ietf.org; Martin Bjorklund <mbj@tail-f.com>; Ladislav Lhotka
> <lhotka@nic.cz>; Andy Bierman <andy@yumaworks.com>; 'Jeffrey Haas'
> <jhaas@pfrc.org>; 'Alia Atlas' <akatlas@gmail.com>
> Subject: Re: [i2rs] WG LC for Topology (10/1 to 10/14)
> 
> Hi,
> 
> there is a discussion on the yang doctors mailing list about the data model
> design that mixes state data and configuration data into one subtree and that
> uses a data model specific runtime object to identify what is config data and
> what is state data. One of the main outcomes of the IAB workshop back in 2002
> was the need to clearly separate configuration from operational state and this
> has been driven the design of NETCONF and YANG. YANG data model validation
> rules, for example, make a distinction between config true and config false
> data.
> The config true or false property impacts what is returned by NETCONF's
> get-config operation. Also note that config data is not allowed to refer to
> config false data in constraints.
> 
> It is unclear why the document does not follow the typical design pattern,
> namely to have a config true subtree
> 
>   /networks/network*
> 
> and a config false subtree
> 
>   /networks-state/network*
> 
> Section 3.5 describes this approach in the 3rd paragraph and states "As most
> data is defined in those groupings, the amount of additional definitions required
> will be limited." and there are no strong reasons given why this approach has
> not been followed.
> 
> /js
> 
> On Thu, Oct 01, 2015 at 06:41:34PM -0400, Susan Hares wrote:
> > This begins a 2 week WG Last call (10/1 to 10/14)
> >
> >
> >
> > draft-ietf-yang-network-topo - modeling draft
> >
> > http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/
> >
> >
> >
> > draft-ietf-i2rs-yang-l3-topology - L3 topology
> >
> > http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/
> >
> >
> >
> > draft-ietf-i2rs-yang-l2-topology - L2 topology
> >
> > http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topolo
> > gy/
> >
> >
> >
> > Implementation status:
> >
> >
> >
> > This an OpenDaylight (ODL) implementation of the L3 topology and
> > general model.  It is likely the L2 topology model will be supported in future
> ODL
> > implementations.   Jeff and I would appreciate anyone who has
> > implementations of these topology models to provide details on list or
> > offlist to the chairs.
> >
> >
> >
> > Sue Hares
> >
> 
> > _______________________________________________
> > i2rs mailing list
> > i2rs@ietf.org
> > https://www.ietf.org/mailman/listinfo/i2rs
> 
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> 
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
> 
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs