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/>