Re: [netmod] draft-wilton-netmod-interface-properties-00

[Ladislav Lhotka <[e-mail]>]

> On 27 Jul 2017, at 09:31, Juergen Schoenwaelder <[e-mail]> wrote:
> 
> 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.

Even better, these identities could be defined along with the corresponding configuration and state data. From the viewpoint of data modelling, everything would then be absolutely clear.

Lada

> 
> /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 <[e-mail]> on behalf of Ladislav Lhotka <[e-mail]>
>> Sent: Wednesday, 26 July 2017 9:27 p.m.
>> To: Robert Wilton; [e-mail]
>> 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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>> 
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67