Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt
Igor Bryskin <Igor.Bryskin@huawei.com> Tue, 27 June 2017 01:59 UTC
Return-Path: <Igor.Bryskin@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 ABF291200FC for <i2rs@ietfa.amsl.com>; Mon, 26 Jun 2017 18:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 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=-0.001, 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 n_GHYXrfyNtx for <i2rs@ietfa.amsl.com>; Mon, 26 Jun 2017 18:59:52 -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 60F4E1286CA for <i2rs@ietf.org>; Mon, 26 Jun 2017 18:59:51 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJG08443; Tue, 27 Jun 2017 01:59:48 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 27 Jun 2017 02:59:46 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML701-CHM.china.huawei.com ([169.254.3.186]) with mapi id 14.03.0301.000; Mon, 26 Jun 2017 18:59:38 -0700
From: Igor Bryskin <Igor.Bryskin@huawei.com>
To: Alexander Clemm <alexander.clemm@huawei.com>, Igor Bryskin <Igor.Bryskin@huawei.com>, "j.schoenwaelder@jacobs-university.de" <j.schoenwaelder@jacobs-university.de>
CC: "rwilton@cisco.com" <rwilton@cisco.com>, "Xufeng_Liu@jabil.com" <Xufeng_Liu@jabil.com>, "i2rs@ietf.org" <i2rs@ietf.org>
Thread-Topic: RE: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt
Thread-Index: AQHS7ukIs+2h2WsHeE2z5D+Xxw2kLA==
Date: Tue, 27 Jun 2017 01:59:38 +0000
Message-ID: <etPan.5951bc33.40c8b4c4.3810@localhost>
References: <01a101d2eb18$8efea040$acfbe0c0$@clemm.org> <37626ce1-f10e-0357-e749-cfa9de40951a@cisco.com> <20170624131701.GC2187@elstar.local> <64c72fd5-8833-5d3c-afba-60402adf0882@cisco.com> <308C9498061C7E0D.327c7acb-aec9-4f08-b62c-980f928829ea@mail.outlook.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0E0BC826@SJCEML702-CHM.china.huawei.com> <20170626191238.GA3608@elstar.local> <etPan.59515f39.2efbe7f9.2309@localhost> <20170626192730.GB3608@elstar.local> <etPan.5951632c.fa8a1de.3810@localhost> <20170626204951.GE3608@elstar.local> <0C72C38E7EBC34499E8A9E7DD007863909B1A3B2@SJCEML702-CHM.china.huawei.com>, <644DA50AFA8C314EA9BDDAC83BD38A2E0E0BD3B1@SJCEML702-CHM.china.huawei.com>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0E0BD3B1@SJCEML702-CHM.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_etPan5951bc3340c8b4c43810localhost_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0206.5951BC15.007F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 0c20f3f718c95593b98f53812d64b4b6
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/xYgbjb071gfKxqh1T5Hhe5p0R88>
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 27 Jun 2017 01:59:55 -0000
Alex, I understand what you are saying, but are you aware of a use case in which a client of a network wouid configure topology of the network using I2RS network topology model? Igor From:Alexander Clemm To:Igor Bryskin,Juergen Schoenwaelder, Cc:rwilton@cisco.com,Xufeng_Liu@jabil.com,i2rs@ietf.org, Date:2017-06-26 20:00:50 Subject:RE: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt Igor, Juergen is correct in that the topology model clearly needs to support both configurable as well as discovered topologies. This is very clearly stated in the draft. We had this decision also earlier and the conclusion was always that a read-only model that is only applicable to discoverable topologies is too narrow in scope. So, the topology model clearly allows for topologies that discovered and for topologies that are configured, including overlay topologies put on top of discovered underlays. There are various use cases for that, including in the Open Daylight implementation. If we had wanted to do read-only, we would have been done a long time ago. Xufeng and I spoke earlier. If we should include a -state version of the model in the appendix, we will do that, even if it feels redundant. However, we are clearly not dropping support for configurable topology at this point. --- Alex -----Original Message----- From: Igor Bryskin Sent: Monday, June 26, 2017 3:51 PM To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Cc: Alexander Clemm <alexander.clemm@huawei.com>; rwilton@cisco.com; Xufeng_Liu@jabil.com; i2rs@ietf.org Subject: RE: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt Juergen, >> Perhaps you are right that I2RS never intends to configure topology, this is what RFC 7920 and 7921 talk about. That said, the base topology model clearly supports configured topologies (following the NMDA approach) but then it seems for TEAS this is not workable. Honestly, I don't even understand why I2RS topology model needs CONFIG=TRUE elements. Topology model is a network wide model. You do not configure physical topological elements (nodes and links) using topology model, they are discovered and passed to the client as data state. Abstract TE nodes and links are different. It is typical for a client to request a particular abstract node configured in a way the client prefers to see a network domain (partially or in entirety). Consequently, not only CONFIG=TRUE elements are needed, the deltas between intended and applied configurations are quite likely. Igor Note that RESTCONF and NETCONF protocol extension proposal I-Ds are in the making and the NETCONF charter is meanwhile in place with a target date for this work in Nov 2017. Sure, we all know that it is difficult to predict WG timing but creating a -state subtree may be something to regret in a year from now. /js On Mon, Jun 26, 2017 at 07:39:47PM +0000, Igor Bryskin wrote: > TE topology model client is a client application that talks netconf/restconf with the server application implemting one or more TE topologies. > In contrast to I2RS topology server, which only exposes topologies (learnt for example via IGP) as state information, TE topology model client can configure TE Topologies with all the implications, such as intended/applied, etc. > > Igor > From:Juergen Schoenwaelder > To:Igor Bryskin, > Cc:Alexander > Clemm,rwilton@cisco.com,Xufeng_Liu@jabil.com,i2rs@ietf.org, > Date:2017-06-26 15:27:49 > Subject:Re: [i2rs] I-D Action: > draft-ietf-i2rs-yang-network-topo-13.txt > > On Mon, Jun 26, 2017 at 07:22:57PM +0000, Igor Bryskin wrote: > > Hi Jorgen, > > The reason is that TE topologies (e.g. anstract TE topologies) could be (re-)configured by a client, while I2RS topologies could not. > > Igor > > What is 'client' and what is 'reconfigured' and why does that not > apply to i2rs topologies? > > /js > > -- > 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/> -- 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] I-D Action: draft-ietf-i2rs-yang-network-t… internet-drafts
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Alexander Clemm
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Robert Wilton
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Alexander Clemm
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Robert Wilton
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Alexander Clemm
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Juergen Schoenwaelder
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Igor Bryskin
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Juergen Schoenwaelder
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Igor Bryskin
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Juergen Schoenwaelder
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Igor Bryskin
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Alexander Clemm
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Kent Watsen
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Igor Bryskin
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Robert Wilton
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Xufeng Liu
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Robert Wilton
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Alexander Clemm
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Robert Wilton
- Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-netwo… Alexander Clemm