-- Carl Moberg Technology Director, CVG [email protected] > On Apr 7, 2016, at 2:40 AM, Doolan, Paul (Coriant - US/Irving) > <[email protected]> wrote: > > Hello Carl, > > Interesting comment. > > Would you agree with me that in principle a topology is a topology is a > topology and, therefore, that we should strive for a model that can be > employed recursively at any level in such a (implied) hierarchy ?
I don’t know :-) On a more serious note, I would suggest it is likely to depend on the intent of the model and all the common tradeoffs between trying to be general yet useful. > When I look at topology, i.e fundamentally at a graph, I wish to manipulate > or exploit aspects of the properties represented by it. In principle it > doesn't matter to me what it represents. I have the same primitives at my > disposal to manipulate it regardless of what it represents . Obviously in > practice I might want to check some identifier in/of the topology to ensure > that it's not a national backbone I'm messing with when I intended to change > an access link in my metro ;-) > > Do you think that's a reasonable perspective from which to continue this > discussion ? I come at this from the classification angle, so my interest is if the assumption that a YANG model can only be classified as a network service model XOR a network device model according to the definitions in draft-ietf-netmod-yang-model-classification (sections 2.1 and 2.2). Based on this discussion I take it that some models are intended to be able to serve in both roles. And we should make sure that it’s supported in our catalog structure. > pd > > On Apr 6, 2016, at 5:41 PM, "Carl Moberg (camoberg)" <[email protected]> > wrote: > >> >> There is a case that can be made for topology models capable of exposing >> topologies both from the view of a participant node as well as an all-seeing >> orchestrator/controller. >> >> -- >> Carl Moberg >> Technology Director, CVG >> [email protected] >> >>> On Apr 6, 2016, at 11:33 PM, Sterne, Jason (Nokia - CA) >>> <[email protected]> wrote: >>> >>> Exposing a model of a *network* seems like something more appropriate on a >>> controller that sits above individual NEs and aggregates network wide >>> information no ? >>> Jason >>> >>> -----Original Message----- >>> From: netmod [mailto:[email protected]] On Behalf Of EXT Doolan, Paul >>> (Coriant - US/Irving) >>> Sent: Wednesday, April 06, 2016 17:33 >>> To: Lou Berger >>> Cc: [email protected] >>> Subject: Re: [netmod] YANG model classification? >>> >>> Not sure either captures the case where, in the same network, there are >>> instances of the model on NEs and on the management systems. >>> >>> Does "both" cover that case ? >>> >>> pd >>> >>> There has already been discussion of the concept of a switch matrix (inside >>> an NE) which can On Apr 6, 2016, at 3:31 PM, Lou Berger <[email protected]> >>> wrote: >>> >>>> My personal view is either. .. >>>> >>>> >>>> On April 6, 2016 4:15:08 PM "Carl Moberg (camoberg)" <[email protected]> >>>> wrote: >>>> >>>>> >>>>> Is the YANG model in draft-ietf-teas-yang-te-topo expected to be >>>>> implemented in a network element, on a management system or perhaps >>>>> either? >>>>> >>>>> -- >>>>> Carl Moberg >>>>> Technology Director, CVG >>>>> [email protected] >>>>> >>>>>> On Apr 6, 2016, at 8:09 PM, Scharf, Michael (Nokia - DE) >>>>>> <[email protected]> wrote: >>>>>> >>>>>> draft-ietf-netmod-yang-model-classification suggests that a YANG model >>>>>> is either a "Network Element YANG Model" or a "Network Service YANG >>>>>> Model". >>>>>> >>>>>> How would draft-ietf-teas-yang-te-topo be classified according to that? >>>>>> Thoughts? >>>>>> >>>>>> Thanks >>>>>> >>>>>> Michael >>>>>> >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
