Hi, what is needed is a clear and crisp description what terms such as "ethernet-like", "ethernet-mac-like", "ethernet-phy-like" really mean. Ideally, proposals for terms would include such descriptions, perhaps including examples where these terms apply and where they do not apply. The devil is in the details.
/js On Wed, Jul 26, 2017 at 11:17:16PM +0000, Alex Campbell wrote: > Hi, > > I would very much like to see this happen. > > However I recommend at least splitting up "ethernet-like" into > "ethernet-mac-like" and "ethernet-phy-like". At Aviat we have microwave radio > interfaces that behave like Ethernet at the MAC level but have totally > different PHYs. The distinction is also useful for virtual links, such as > link aggregations and tunnels. > > ________________________________________ > From: netmod <[email protected]> on behalf of Ladislav Lhotka > <[email protected]> > Sent: Wednesday, 26 July 2017 9:27 p.m. > To: Robert Wilton; [email protected] > Subject: Re: [netmod] draft-wilton-netmod-interface-properties-00 > > Hi Rob, > > I think this is a very useful work and we will probably implement it > soon. A few comments: > > - I support the proposed redesign of "iana-if-type" but I believe this > module should in fact be declared historic. For one, the name of the > most frequently used type, "ethernetCsmacd", is not only notoriously > hard to remember but it is also a misnomer: these days, almost no > Ethernet network uses CSMA/CD any more. Instead, "csma-cd" can be > another identity that could be added to the mix of bases where > necessary. > > - Interface type identities should be defined in a distributed way and > not in a single module as in "iana-if-type". A module defining > configuration and state data for a particular technology should also > define the corresponding identity or identities. This way, the choice > of interface types will always be limited to those supported by a > specific server. > > - In Appendix B I don't understand the comment in the definition of > container "encapsulation": what could be the abstract type and how > would it aid extensibility? > > Thanks, Lada > > Robert Wilton <[email protected]> writes: > > > Hi, > > > > In the NETMOD session on Wednesday I will spend 5 minutes speaking on > > draft-wilton-netmod-interface-properties-00, that has been created due > > to discussions with various folks to handle interface type specific > > configuration. > > > > The draft isn't particularly long, 21 pages, two thirds of that is just > > examples, and it is presenting a simple idea. > > > > In particular, it is aiming at solving the problem of when statements > > like this: > > > > augment "/if:interfaces/if:interface" { > > when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or > > derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or > > derived-from-or-self(if:type, 'ianaift:l2vlan') or > > derived-from-or-self(if:type, 'ianaift:ifPwType')" { > > description "Applies to all Ethernet-like interfaces"; > > } > > > > and instead proposes this: > > > > augment "/if:interfaces/if:interface" { > > when "derived-from(if:type, 'ianaifp:ethernet-like')" { > > description > > "Applies to all interfaces that derive from the Ethernet-like > > interface property."; > > } > > > > The core idea being that new identities are defined to represent > > interface properties (like ethernet-like) and the existing interface > > types iana-if-types.yang are updated to also derive from the new > > interface properties. > > > > This simplifies the YANG, should make interface based configuration more > > future proof, since new interface types can also derive from the > > appropriate interface properties. Of course additional interface > > properties could also be defined. > > > > I'm seeking input from the WG as to whether they like this approach, AND > > also whether the WG drafts: draft-ietf-netmod-intf-ext-yang-05 and > > draft-ietf-netmod-sub-intf-vlan-model-02 should be updated to make use > > of this approach (possibly in a future bis revision to avoid delaying > > publishing the models). > > > > Thanks, > > Rob > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
