Re: [netmod] LL review of draft-ietf-netmod-intf-ext-yang-03

Robert Wilton <rwilton@cisco.com> Mon, 20 March 2017 13:55 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CDE127011 for <netmod@ietfa.amsl.com>; Mon, 20 Mar 2017 06:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0-rHhOi-Ti3 for <netmod@ietfa.amsl.com>; Mon, 20 Mar 2017 06:55:10 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD05F12785F for <netmod@ietf.org>; Mon, 20 Mar 2017 06:55:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15107; q=dns/txt; s=iport; t=1490018109; x=1491227709; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=9AMswnjeKx+F24Rkt92BxePuSMiWOFX40feW1RhCHzM=; b=CXgN7IUnmqFtuEcdN6GLispqo2cPmAZs5vsZ4OVgGGd9ftyeiNzIzjxU TVGAn1djcRFnAaMwWsx+PaeEcJ0sY4je0IeDz6SfXShoNklUdXWgaGIKu 6JA/CT1Jqoy8GZiIw2j29GWHNpDIqNyfLfuz5E2PEdAxZVL17BIJ4eM+O w=;
X-IronPort-AV: E=Sophos;i="5.36,194,1486425600"; d="scan'208";a="693116380"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Mar 2017 13:55:08 +0000
Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2KDt7wJ012894; Mon, 20 Mar 2017 13:55:08 GMT
To: "Acee Lindem (acee)" <acee@cisco.com>, Ladislav Lhotka <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org>
References: <m2h95xxwee.fsf@birdie.labs.nic.cz> <33d0132e-750b-97ed-8bdb-0befeb1b81c3@cisco.com> <0400d1cb-30ce-e074-b707-202026161ebb@cisco.com> <m24lz1z0im.fsf@birdie.labs.nic.cz> <12f97503-9801-56f5-650f-8accdab68e4c@cisco.com> <D4E9E60B.A1304%acee@cisco.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <f4d12afb-623a-44a7-c37e-92d3d11f5065@cisco.com>
Date: Mon, 20 Mar 2017 13:55:07 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <D4E9E60B.A1304%acee@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/yA5LrXKUX3rdlSmwnkShs4iyDfo>
Subject: Re: [netmod] LL review of draft-ietf-netmod-intf-ext-yang-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Mar 2017 13:55:14 -0000

Hi Acee,

On 17/03/2017 17:18, Acee Lindem (acee) wrote:
> Hi Rob,
>
> On 3/10/17, 9:46 AM, "netmod on behalf of Robert Wilton -X (rwilton -
> ENSOFT LIMITED at Cisco)" <netmod-bounces@ietf.org on behalf of
> rwilton@cisco.com> wrote:
>
>> Lada,
>>
>> Thanks for the comments, some further comments inline ...
>>
>>
>> On 10/03/2017 14:09, Ladislav Lhotka wrote:
>>> Hi Rob,
>>>
>>> please see inline.
>>>
>>> Robert Wilton <rwilton@cisco.com> writes:
>>>
>>>> Hi Lada,
>>>>
>>>> To pick up an old thread, I'm updating the interface model per your
>>>> comments below, and I had a few questions that you might have an
>>>> opinion on.
>>>>
>>>> On 22/12/2016 14:32, Robert Wilton wrote:
>>>>> Hi Lada,
>>>>>
>>>>> Thanks for the review and comments.
>>>>>
>>>>>
>>>>> On 21/12/2016 13:08, Ladislav Lhotka wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I think this is a very useful addition to ietf-interfaces. In
>>>>>> general,
>>>>>> the document is clearly written and YANG modules nicely designed.
>>>>>> Here
>>>>>> are my comments:
>>>>>>
>>>>>> *** Sec. 1
>>>>>>        - "This document defines two YANG RFC 7950 [RFC7950] modules Š"
>>>>>>          looks weird. I'd suggest "Š YANG 1.1 [RFC7950] Š" instead.
>>>>> OK.
>>>> Fixed.
>>>>>> *** Sec. 2
>>>>>>        - first line: s/of of/of/
>>>> Fixed.
>>>>
>>>>>> *** Sec. 3.1
>>>>>>        - If the "bandwidth" parameter is only used for tuning routing
>>>>>>          algorithms and has nothing to do with real bandwidth on the
>>>>>>          interface, I would suggest to use a different name
>>>>>>          (metric?). Perhaps it may indeed be better to leave this to
>>>>>>          routing protocol modules because they can also specify how
>>>>>>          exactly such a parameter is used.
>>>>> Yes, possibility it would be better to define this as part of the
>>>>> routing models.  The idea here is that the bandwidth would span across
>>>>> the routing protocols rather than be tied to a specific protocol.
>>>> I think that we need a better name than just "bandwidth" since this
>>>> leaf
>>>> doesn't affect the actual bandwidth on the of the link, just the
>>>> bandwidth that is reported to routing protocols to implicitly adjust
>>>> their link metrics.  Hence, I was considering renaming this to
>>>> "reported-bandwidth"?
>>> This looks like something for routing people to decide.
> I believe this is referred to as maximum-reservable-bandwidth in RFC 3630.
>
>
> 2.5.7.  Maximum Reservable Bandwidth
>
>     The Maximum Reservable Bandwidth sub-TLV specifies the maximum
>     bandwidth that may be reserved on this link, in this direction, in
>     IEEE floating point format.  Note that this may be greater than the
>     maximum bandwidth (in which case the link may be oversubscribed).
>     This SHOULD be user-configurable; the default value should be the
>     Maximum Bandwidth.  The units are bytes per second.
>
> Perhaps, reservable-bandwidth would suffice.
I like that suggestion.

I'll raise this on the rtgwg alias as well.


>
>
>
>>>> I also think that it would be good to follow up with the routing folks
>>>> to see if this leaf would be better covered in a general routing model.
>>>> Where do you think is the best place that I raise this, the routing
>>>> area
>>>> yang design team?
>>> Maybe, or RTGWG?
>> OK.  I'll send an email that way, after I've published this next revision.
>>
>>>>>> *** Sec. 3.6
>>>>>>        - The "l3-mtu" parameter is probably the same as "mtu" defined
>>>>>> in
>>>>>>          ietf-ip. Again, I would suggest to leave the definition of
>>>>>> MTU
>>>>>>          to each L3 protocol because there may be specific aspects and
>>>>>>          constraints.
>>>>> The MTU being defined here is an "l2-mtu" parameter.  I.e. the maximum
>>>>> size of the L2 frames that can be sent/received.  For some devices
>>>>> this value is independent of a protocol specific L3 MTU that only
>>>>> affects that particular protocol instance.
>>>> I've updated the text to make it clear that it is only a L2 MTU
>>>> configuration leaf, and if not configured, the system will
>>>> automatically
>>>> decide on the L2 MTU.
>>> Shouldn't it have a "when" substatement to make it available only for
>>> "layer-2" interfaces?
>> It can apply to all interfaces that use a layer 2 encapsulation, i.e.
>> most interfaces.
> It seems that an L3 interface could still have an L2 MTU? Of course, the
> IP or IPv6 MTU could not exceed the L2 MTU.
Yes, an L3 interface still has a L2 MTU, and on some systems this 
configuration item can be used to indirectly control the IP/IPv6 
protocol MTUs on the interface, or the MTUs of any sub-interfaces.

Some network OSes control their MTU from an L2 perspective, i.e. you 
normally configure the L2 MTU, and the system works out what L2 payload 
size is available to the L3 protocols.

Other network OSes control them MTU from an L3 perspective, i.e. you 
configure the L3 MTU, and the system calculates the L2 overhead, 
possibly with some extra slop space, to program into the Ethernet MAC 
chip to police the maximum size of frame that can be sent or received.


Perhaps it would be beneficial to add some text to explain the 
relationships between the MTUs values for L2 and the protocols to the 
draft?  Actually, it may be beneficial to cover the MTU relationship to 
sub-interfaces as well.






>
>
>
>
>> The only interfaces that it wouldn't apply to are:
>>   - interfaces that are performing optical switching - but then I think
>> that they are probably not really interfaces at all.
>>   - software interfaces that represent a tunnel endpoint that carriers
>> L3 frames with no L2 encapsulation.  Although in this case you could
>> just regard them as having a 0 byte layer 2 overhead.
>>
>>
>>
>>>>>> *** Sec. 3.8
>>>>>>        - I think that "transport-layer" is not a good name because in
>>>>>> the
>>>>>>          ISO OSI model it denotes a particular layer (L4). How about
>>>>>>          "iso-osi-layer"?
>>>> I agree that "transport-layer" is somewhat ambiguous.
>>>>
>>>> I was wondering whether "service-layer" or "service-type" would work?
>>> This looks more like a business term, "iso-osi-layer" or just
>>> "osi-layer" seems better to me, even if you include only layers
>>> 1-3. Actually, the OSI model calls these three "media layers", but this
>>> term isn't commonly used.
>> The problem with osi-layer is that I don't think that the name really
>> indicates what it means.
> If we have trouble deciding on the semantics, perhaps the data node isn¹t
> useful.
Possibly, that may be the conclusion.  In which case I think that this 
would end up being a vendor augmentation leaf that ends up being defined 
in similar ways for different vendors, reducing commonality of 
configuration.

Some of our implementations, that I believe applies to other vendors as 
well, need to know what mode an interface or sub-interface is running in 
to optimize the forwarding resources.  E.g. perhaps different microcode, 
or hardware path data structures.

The other perceived benefit of this leaf is as a way of trying to ensure 
that features and the forwarding mode are consistently configured.  E.g. 
the hardware may not be able to handle an L2 ACL applied to an 
interface/sub-interface that is forwarding at L3. This forwarding layer 
leaf would potentially offer a common way to police this via a MUST 
statement in the ACL module.  The MUST statement could say, if this is 
an L2 ACL and the forwarding mode leaf exists then it must be in L2 mode.

Thanks,
Rob


>   
>
> Thanks,
> Acee
>
>
>
>>>> Or perhaps it could be called "forwarding-mode"?
>>> IMO, the layers are not only about forwarding.
>> Agreed, but this configuration is to provide a constraint as to what
>> services and forwarding paradigm can be enabled.
>>
>> E.g. an "l2 transport/service" would be connected to an L2VPN instance
>> but not IP.
>> An ACL applied to a "L2 transport/service" would filter on MAC
>> addresses/VLAN Ids rather than IP header fields.
>>
>>>>>>        - The type of "transport-layer" has three enums, namely
>>>>>>          "layer-[123]". I would suggest to use descriptive names
>>>>>>          ("physical-layer" etc.), include the remaining layers of the
>>>>>> ISO
>>>>>>          OSI model, and maybe also define it as a typedef - or does
>>>>>> this
>>>>>>          belong to ietf-inet-types?
>>>> I'm not sure that defining the higher layers of the OSI model helps.
>>>> Perhaps using identities would be a better choice?
>>>>
>>>> Perhaps:
>>>>     "physical-layer"
>>>>     "data-link-layer"
>>>>     "network-layer"
>>>>
>>>> But I prefer "layer-2" over "data-link-layer" since I think that term
>>>> is much more widespread.  I'm also not quite sure whether
>>> OK.
>>>
>>>> "physical-layer" is actually the right term, I think that is probably
>>>> really "below-layer-2"
>>>>
>>> In terms of the OSI model, there is only layer 1 (physical) below layer
>>> 2. Or do you mean things like Ethernet-over-MPLS? I don't know how the
>>> layer classification works in such convoluted cases.
>> For layer-2, I think of carrying L2 frames over another service (e.g.
>> IP, MPLS, or MAC-in-MAC).
>> For layer-1, I was thinking of things like optical switching or OTN
>> switching.  But again it does come back to whether those are represented
>> as interfaces.  Although, even in the optical switching cases, I think
>> that devices sometimes snoop the layer 2 frame statistics.
>>
>>>>>>        - Is a leaf sufficient? I think some interfaces can be in
>>>>>> multiple
>>>>>>          layers at the same time (e.g. an ATM interface is L3 but can
>>>>>>          also be L2 for Classical IP over ATM). Or is the idea that
>>>>>> such
>>>>>>          an interface will be split into two entries of the
>>>>>> "interface"
>>>>>>          list?
>>>>> This needs some further thought/work.
>>>> I think that using sub-interfaces is the cleanest way of doing this, so
>>>> each sub-interface can be offering a service at a different layer.
>>>>
>>>>
>>>>> The main idea here was to be able to label sub-interfaces as
>>>>> supporting only L2 services or L3 services, since on some platforms
>>>>> different types of interfaces get instantiated internally.
>>> OK, I don't dare to give any suggestions here.
>>>
>>>>>> *** YANG modules
>>>>>>        - Descriptions are not consistently formatted. I think that the
>>>>>>          current BCP is to start description text on the same line as
>>>>>> the
>>>>>>          "description" keyword only if it all fits on one line.
>>>>>>        - I don't have a strong opinion on this but it might increase
>>>>>>          readability if the number of augments is reduced. Perhaps at
>>>>>>          least augments that contain only one node could be made into
>>>>>> one
>>>>>>          (and the "feature" and "when" statements moved to the nodes'
>>>>>>          definitions.
>>>>> Yes, I'll fix these, probably using Martin's suggested approach.
>>>> I've fixed the descriptions, and merged all the augments except for the
>>>> sub-interface one (which is an if-feature conditional augment of a
>>>> mandatory node).
>>> Good.
>>>
>>>> I also have a question about the "encapsulation" container that is
>>>> currently defined as:
>>>>
>>>>        /*
>>>>         * Various types of interfaces support a configurable layer 2
>>>>         * encapsulation, any that are supported by YANG should be
>>>>         * listed here.
>>>>         *
>>>>         * Different encapsulations can hook into the common encaps-type
>>>>         * choice statement.
>>>>         */
>>>>        container encapsulation {
>>>>          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:pos') or
>>>>             derived-from-or-self(if:type, 'ianaift:atmSubInterface') or
>>>>             derived-from-or-self(if:type, 'ethSubInterface')" {
>>>>
>>>>            description
>>>>              "All interface types that can have a configurable L2
>>>>               encapsulation";
>>>>            /*
>>>>             * TODO - Should we introduce an abstract type to make this
>>>>             *        extensible to new interface types, or vendor
>>>>             *        specific interface types?
>>>>             */
>>>>          }
>>>>
>>>>          description
>>>>            "Holds the OSI layer 2 encapsulation associated with an
>>>>             interface";
>>>>          choice encaps-type {
>>>>            description "Extensible choice of L2 encapsulations";
>>>>          }
>>>>        }
>>>>
>>>> I was considering removing the when statement to generalize this, since
>>>> the case statements can be constricted to suitable interface types
>>>> using
>>>> when statements anyway.  E.g. I'm proposing to changing it to something
>>>> like this:
>>>>
>>>>        /*
>>>>         * Various types of interfaces support a configurable
>>>>         * encapsulation.
>>>>         *
>>>>         * Different encapsulations (often layer 2) can hook into the
>>>>         * common encaps-type choice statement.
>>>>         */
>>>>        container encapsulation {
>>>>          description
>>>>            "Holds the encapsulation (often layer 2) associated with an
>>>>             interface";
>>>>          choice encaps-type {
>>>>            description
>>>>              "Extensible choice of encapsulations";
>>>>          }
>>>>        }
>>>>
>>>> Do you have a view on this?
>>> This demonstrates that the IANA interface types are not very useful for
>>> restricting the data model. As you indicate, multiple levels of the
>>> interface hierarchy (abstract interface types) might be better, perhaps
>>> you could also make use of multiple inheritance of identities, hence
>>> allowing for arbitrary mixes of interface properties encoded in the
>>> type.
>> Yes, I think that the IANA interface types are a problem.
>>
>> Previously I was planning on writing up a draft with abstract types
>> deriving from the IANA types, but I'm not sure whether this helps in the
>> general case.
>>
>> It might be that we need to define a set of abstract types (e.g.
>> physical interfaces, ethernet-like, sub-interface, logical interface,
>> etc) and then update the type identities in iana-if-type.yang to derive
> >from those base types (which I believe would be an allowed backwards
>> compatible change).
>>
>> Thanks,
>> Rob
>>
>>
>>> Cheers, Lada
>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>>> Thanks again,
>>>>> Rob
>>>>>
>>>>>> Lada
>>>>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> .
>