Hi Martin, I think using the more generic term, “networking”, at the top would be preferable. What we need is an instance abstraction that covers L3 (e.g., virtual router or VRF), L2 (e.g., Virtual Switch Instance), or a combination (some EVPN, TRILL, etc). This could be used in lieu of each L2 model creating their own top separate list of instances. For example, the networking-instance could be augmented with both the VPLS and VPWS instances in https://tools.ietf.org/html/draft-shah-bess-l2vpn-yang-00.
Some YANG models ascribe greatness from the start, others achieve greatness through refinement, while still others have greatness thrust upon them. routing-cfg would fall into the last category… Thanks, Acee On 11/24/15, 4:24 AM, "Martin Bjorklund" <[email protected]> wrote: >Hi, > >"Acee Lindem (acee)" <[email protected]> wrote: >> We had a lot of good discussions at IETF 94 with respect to the >> ietf-routing and how it could be augmented in the future to support >>I2RS. >> These discussions are ongoing. >> >> One current change that I would like to propose is to change the base >> instance container from routing-instance to networking-instance. > >Is the idea to simply rename the "routing-instance" container to >"networking-instance"? > >Then we would have: > > +--rw routing > +--rw networking-instance > >Would you keep the top-level name "routing"? > > > > >/martin > > > > >> This >> would provide an instance definition that could be augmented for L2 >> protocols and service functionality as well as L3. It is also consistent >> with the term used in both >> https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-01.txt and >> https://www.ietf.org/id/draft-openconfig-rtgwg-network-instance-01.txt. >> >> Thanks, >> Acee >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
