In general, I do think there are use cases for writeable topology information, for example in the case of service and application layer topologies (which may be provisionable). Not sure whether it needs to be included in the charter, but in general I think it would be good to allow for this possibility. --- Alex
From: i2rs [mailto:[email protected]] On Behalf Of Alia Atlas Sent: Wednesday, March 11, 2015 1:03 AM To: Juergen Schoenwaelder; Alia Atlas; [email protected] Subject: Re: [i2rs] simple rechartering underway On Wed, Mar 11, 2015 at 3:55 AM, Juergen Schoenwaelder <[email protected]<mailto:[email protected]>> wrote: On Wed, Mar 11, 2015 at 03:33:14AM -0400, Alia Atlas wrote: > Juergen, > > On Wed, Mar 11, 2015 at 3:24 AM, Juergen Schoenwaelder < > [email protected]<mailto:[email protected]>> > wrote: > > > On Fri, Mar 06, 2015 at 06:06:44PM -0500, Alia Atlas wrote: > > > Given the excellent progress that the WG has been making - due to your > > work > > > and interest, I have been working on a simple rechartering with Sue and > > > > Here is the diff related to topology: > > > > - o The ability to extract information about topology from the network. > > - Injection and creation of topology will not be considered as an > > initial work item. > > + o The ability to extract information about topology from the network. > > + These models will be based on a generic topology model to support > > + multiple uses. Injection and creation of topology will not be > > considered > > + as a work item. > > > > The first and third sentences are both about 'reading topology'. Does > > this imply that the generic model will also be limited to 'reading > > topology'? Or will the generic model also allow create topology? > > It's an interesting question. What use-cases do you see where > writing the topology is appropriate? If you want to do service management, you need to describe (configure) the desired service topology. This is largely an interface to the network manager (called a controller these days). True - I see that as needing significantly more information, but having a generic topology model to build upon would be useful. > If one thinks of reading the topology as reading operational state, > aren't read-write config and read-only operational recommended to be > separated in YANG models (at least for now)? Yes, we love to separate config state from operational state. But this has nothing to do with the scope of the work item added to the I2RS charter. It is relevant if I2RS defines the operational topology for reading and there isn't an active need for writing the topology. If there is an active need - presumably because of interest in modeling interfaces to a network manager - then I can massage the text. I don't see a reason to have separate drafts. Alia /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587<tel:%2B49%20421%20200%203587> Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103<tel:%2B49%20421%20200%203103> <http://www.jacobs-university.de/>
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
