"Acee Lindem (acee)" <[email protected]> writes: > On 2/24/15, 1:28 PM, "Jeffrey Haas" <[email protected]> wrote: > >>[I'm behind as usual and this may have been discussed already.] >> >>On Fri, Feb 13, 2015 at 06:07:11PM +0000, Acee Lindem (acee) wrote: >>> Independent of the hierarchy, I think an interface should be associated >>> with one and only routing-instance. I know of no implementation that >>> allows this (including the use case of separate instances for IPv4 and >>> IPv6). >> >>While junos does have the interface as part of the routing instance >>interface hierarchy, you're also correct in that junos enforces that the >>interface is only associated with one instance. >> >>The question is with regard to generic modeling: Should a single unified >>interface model with the ability to associate the interface with the >>instance? Should the instance refer to interfaces? >> >>My concern with making the interface model point to associated instances >>is >>how we handle versioning for unknown things that we may want to associate >>that interface with. The interface model is something we want to be rock >>solid stable, not something that needs to be revised each time some new >>instancing mechanism is created. > > Since what I¹m suggesting is having rtg-cfg augment the interface model, I > don¹t understand your concern. Why is the new model having a separate list > of interfaces any more ³rock solid² than the existing interface to > reference the associated routing instance?
Acee is right - it is an augment and its data belong to a different namespace, so it really doesn't affect the interface model. Actually, I think it would be done the same way (via an augment from another module) even if we envisioned from the start that the assignment of interfaces to routing instances will be done inside the interface hierarchy.. My concern regarding the change that Acee proposes is that this schema extension cannot be made specific so that only a subset of interfaces (L3) can be assigned to routing instances - at least I don't know how to do it formally in the data model. The problem has to do with the fact that interfaces of all layers and types are kept in the same flat list. > > My concern is much easier to understand - with existing configuration > information augmenting the RFC 7223 model and some new subset of > configuration information augmenting the interface list, we have a > bifurcated extension model. Independent of which way we decide to If it is the other way around, one could then argue that the routing-instance configuration is bifurcated. I think both ways are possible in principle, and are just a matter of taste, or perhaps legacy CLI considerations. > proceed,this issue needs to be addressed lest we have confusion every > time a new model needs to augment interface configuration. I agree, we have to make a choice. Lada > > Acee > > > > >> >>-- Jeff > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
