Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

[Kent Watsen <[e-mail]>]

Alex,

No one is asking you to drop support for configurable [overlay] topologies.  We all understand the need to be able to configure overlay topologies on top of discovered underlay topologies.

Kent

--


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 <[e-mail]>
Cc: Alexander Clemm <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
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,[e-mail],[e-mail],[e-mail],
> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>

_______________________________________________
i2rs mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2rs