Chassis based systems have line cards that support particular interface types.
What happens to the output when a line card is plugged in or out of the system?
In other words, is this a static or a dynamic list?
> On Apr 6, 2018, at 9:03 AM, Andy Bierman <a...@yumaworks.com> wrote:
>
> Hi,
>
> All of these suggested solutions seem OK if one were looking for the most
> disruptive
> way to solve the problem. Tossing iana-if-types and starting over would
> achieve that result.
>
> First, this is a server capabilities problem, so it is related to the
> implementation, not the schema.
>
> Second, the if-types that are allowed at any given moment can be specific to
> the implementation
> and the interface name.
>
> I think this is the 3rd time I have suggested an RPC to solve the actual
> probem:
>
> rpc get-allowed-if-types {
> description
> "Retrieve the interface types allowed by the server.";
> input {
> leaf name {
> type if:interface-ref;
> description
> "If present, the server will return allowed interface types for
> this interface name only.
> If not present, then the server will return all supported
> interface types.";
> }
> }
> output {
> leaf-list type {
> type identityref {
> base interface-type;
> }
> description
> "Specifies a supported interface type";
> }
> }
> }
>
>
> Andy
>
>
> On Fri, Apr 6, 2018 at 6:55 AM, Robert Wilton <rwil...@cisco.com
> <mailto:rwil...@cisco.com>> wrote:
> At the moment, I would say that the vast majority of the definitions in
> IANA.yang are just noise because they refer to definitions that are obsolete.
> Our OS seems to use only 10% of the 287+ defined IANA types, and that 10%
> includes technologies such as frame relay, serial, atm, that very much seem
> to be on their way out.
>
> Using hierarchical identities and interface properties seems like a
> reasonable solution to me (e.g. as described in
> draft-wilton-netmod-interface-properties-00). E.g. so rather than having
> configuration with a direct when statement on a specific list of interface
> types, instead the when statement can depend on the appropriate interface
> properties.
>
> I also like Lada's suggestion of trying to spread out the IANA definitions to
> the modules that are defining the technology. So, if a device implements
> support for PPP configuration/operational state then it would also naturally
> define any PPP related interface identities at the same time.
>
> If a vendor wants to define their own flavour of Ethernet interface then they
> can do so in their vendor specific module without requiring all tooling to
> become aware of it, and allowing the existing Ethernet configuration to work
> as normal.
>
>
>
> On 06/04/2018 13:01, Ladislav Lhotka wrote:
> On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote:
> On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de
> <mailto:j.schoenwael...@jacobs-university.de>> writes:
>
> If we would have a mechanism to deviate an identityref to a subset of
> identity values supported by an implementation, we would have solved a
> more generic problem. Yes, the IANA list could be 'nicer' but it will
> never be 'nice'.
> Three mechanisms can be used for this:
>
> - splitting the identities into separate modules
> Whatever module organization you come up with, it won't work for all
> implementations.
> Yes, getting the root of this structure right is perhaps somewhat tricky, but
> I don't think that it needs to be all encompassing, or perfect.
>
> - using features
> Making every identity a feature will turn the feature system upside
> down. This is similar to making every leaf a feature.
>
> - using deviations (even though vendors frown on them)
> If my implementation only supports A and B and C, then a deviation may
> state exactly that and the problem is solved. Hoping that my specific
> In fact, deviations cannot delete identity values because they aren't schema
> nodes, so they are of no use.
>
> combination of A and B and C matches a set of modules or some set of
> features is in my view an illusion.
> An implementation that supports, say, a given type of tunnel interface will
> implement the module that covers this tunnel type. If the identity for this
> tunnel interface type is defined in the same module, then all is good. I don't
> get why this should be an illusion. On the contrary, I think it is the
> cleanest
> available solution to this conformance specification problem.
>
> Vendors not shipping proper deviations are essentially telling their
> customers that they have not yet understood model driven management.
> We need to change the mindset here instead of polluting our data
> models with hundreds or thousands of fine grained 'features'.
> I agree that zillions of features aren't nice but it seems to be the only
> solution that we currently have for modules of the iana-if-type style.
>
> Having an bulky set of identity values, most of which are of no interest, is
> IMO
> much worse and could also be a security issue if implementors aren't careful
> enough.
> I'm not sure there is a security concern here, but a long list where most of
> the values are cruft doesn't really seem to help anyone. It also makes it
> harder to know which is the right type to use. E.g. will everyone know that
> they should use "ethernetCsmacd" rather than "gigabitEthernet" for an optical
> GE interface that doesn't actually use CSMA/CD ...
>
> Thanks,
> Rob
>
>
>
> Lada
>
> /js
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod
> <https://www.ietf.org/mailman/listinfo/netmod>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.com
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
