Re: [Rtg-yang-coord] [netmod] rib-data-model and routing-cfg
Ladislav Lhotka <lhotka@nic.cz> Thu, 15 October 2015 11:25 UTC
Return-Path: <lhotka@nic.cz>
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC751B2B65; Thu, 15 Oct 2015 04:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.7
X-Spam-Level: *
X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_210=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6] autolearn=no
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 XNRjwnDZoiOT; Thu, 15 Oct 2015 04:25:23 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A40301B2B61; Thu, 15 Oct 2015 04:25:22 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id C0E691CC0183; Thu, 15 Oct 2015 13:25:25 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: "Acee Lindem (acee)" <acee@cisco.com>
In-Reply-To: <D242C30E.34C2A%acee@cisco.com>
References: <7E24547E-B42B-46E2-AF76-F7639D61963F@nic.cz> <D23D3103.34500%acee@cisco.com> <D2429721.34A0E%acee@cisco.com> <DBF22257-A7A2-4679-927A-EBCC1022FE13@nic.cz> <D242C30E.34C2A%acee@cisco.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Thu, 15 Oct 2015 13:25:21 +0200
Message-ID: <m27fmowezi.fsf@birdie.labs.nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/mCSj7ciD4yEYJhZjACBu3OnOjVM>
Cc: Routing YANG <rtg-yang-coord@ietf.org>, "i2rs@ietf.org" <i2rs@ietf.org>, NETMOD WG <netmod@ietf.org>, Routing WG <rtgwg@ietf.org>
Subject: Re: [Rtg-yang-coord] [netmod] rib-data-model and routing-cfg
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" <rtg-yang-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-yang-coord/>
List-Post: <mailto:rtg-yang-coord@ietf.org>
List-Help: <mailto:rtg-yang-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2015 11:25:26 -0000
Hi Acee, I made the necessary changes in ietf-routing, please see the GitHub repo: https://github.com/netmod-wg/routing-cfg A new leaf "rt:routing-instance" was augmented into interface configuration, and "rt:interfaces" container in configuration is gone. Below is the complete new tree. Will this work? Lada module: ietf-interfaces +--rw interfaces | +--rw interface* [name] | +--rw name string | +--rw description? string | +--rw type identityref | +--rw enabled? boolean | +--rw ip:ipv4! | | +--rw ip:enabled? boolean | | +--rw ip:forwarding? boolean | | +--rw ip:mtu? uint16 | | +--rw ip:address* [ip] | | | +--rw ip:ip inet:ipv4-address-no-zone | | | +--rw (subnet) | | | +--:(prefix-length) | | | +--rw ip:prefix-length? uint8 | | +--rw ip:neighbor* [ip] | | +--rw ip:ip inet:ipv4-address-no-zone | | +--rw ip:link-layer-address yang:phys-address | +--rw ip:ipv6! | | +--rw ip:enabled? boolean | | +--rw ip:forwarding? boolean | | +--rw ip:mtu? uint32 | | +--rw ip:address* [ip] | | | +--rw ip:ip inet:ipv6-address-no-zone | | | +--rw ip:prefix-length uint8 | | +--rw ip:neighbor* [ip] | | | +--rw ip:ip inet:ipv6-address-no-zone | | | +--rw ip:link-layer-address yang:phys-address | | +--rw ip:dup-addr-detect-transmits? uint32 | | +--rw ip:autoconf | | | +--rw ip:create-global-addresses? boolean | | +--rw v6ur:ipv6-router-advertisements | | +--rw v6ur:send-advertisements? boolean | | +--rw v6ur:max-rtr-adv-interval? uint16 | | +--rw v6ur:min-rtr-adv-interval? uint16 | | +--rw v6ur:managed-flag? boolean | | +--rw v6ur:other-config-flag? boolean | | +--rw v6ur:link-mtu? uint32 | | +--rw v6ur:reachable-time? uint32 | | +--rw v6ur:retrans-timer? uint32 | | +--rw v6ur:cur-hop-limit? uint8 | | +--rw v6ur:default-lifetime? uint16 | | +--rw v6ur:prefix-list | | +--rw v6ur:prefix* [prefix-spec] | | +--rw v6ur:prefix-spec inet:ipv6-prefix | | +--rw (control-adv-prefixes)? | | +--:(no-advertise) | | | +--rw v6ur:no-advertise? empty | | +--:(advertise) | | +--rw v6ur:valid-lifetime? uint32 | | +--rw v6ur:on-link-flag? boolean | | +--rw v6ur:preferred-lifetime? uint32 | | +--rw v6ur:autonomous-flag? boolean | +--rw rt:routing-instance? routing-instance-ref +--ro interfaces-state +--ro interface* [name] +--ro name string +--ro type identityref +--ro oper-status enumeration +--ro last-change? yang:date-and-time +--ro phys-address? yang:phys-address +--ro higher-layer-if* interface-state-ref +--ro lower-layer-if* interface-state-ref +--ro speed? yang:gauge64 +--ro statistics | +--ro discontinuity-time yang:date-and-time | +--ro in-octets? yang:counter64 | +--ro in-unicast-pkts? yang:counter64 | +--ro in-broadcast-pkts? yang:counter64 | +--ro in-multicast-pkts? yang:counter64 | +--ro in-discards? yang:counter32 | +--ro in-errors? yang:counter32 | +--ro in-unknown-protos? yang:counter32 | +--ro out-octets? yang:counter64 | +--ro out-unicast-pkts? yang:counter64 | +--ro out-broadcast-pkts? yang:counter64 | +--ro out-multicast-pkts? yang:counter64 | +--ro out-discards? yang:counter32 | +--ro out-errors? yang:counter32 +--ro ip:ipv4! | +--ro ip:forwarding? boolean | +--ro ip:mtu? uint16 | +--ro ip:address* [ip] | | +--ro ip:ip inet:ipv4-address-no-zone | | +--ro (subnet)? | | | +--:(prefix-length) | | | +--ro ip:prefix-length? uint8 | | +--ro ip:origin? ip-address-origin | +--ro ip:neighbor* [ip] | +--ro ip:ip inet:ipv4-address-no-zone | +--ro ip:link-layer-address? yang:phys-address | +--ro ip:origin? neighbor-origin +--ro ip:ipv6! | +--ro ip:forwarding? boolean | +--ro ip:mtu? uint32 | +--ro ip:address* [ip] | | +--ro ip:ip inet:ipv6-address-no-zone | | +--ro ip:prefix-length uint8 | | +--ro ip:origin? ip-address-origin | | +--ro ip:status? enumeration | +--ro ip:neighbor* [ip] | | +--ro ip:ip inet:ipv6-address-no-zone | | +--ro ip:link-layer-address? yang:phys-address | | +--ro ip:origin? neighbor-origin | | +--ro ip:is-router? empty | | +--ro ip:state? enumeration | +--ro v6ur:ipv6-router-advertisements | +--ro v6ur:send-advertisements? boolean | +--ro v6ur:max-rtr-adv-interval? uint16 | +--ro v6ur:min-rtr-adv-interval? uint16 | +--ro v6ur:managed-flag? boolean | +--ro v6ur:other-config-flag? boolean | +--ro v6ur:link-mtu? uint32 | +--ro v6ur:reachable-time? uint32 | +--ro v6ur:retrans-timer? uint32 | +--ro v6ur:cur-hop-limit? uint8 | +--ro v6ur:default-lifetime? uint16 | +--ro v6ur:prefix-list | +--ro v6ur:prefix* [prefix-spec] | +--ro v6ur:prefix-spec inet:ipv6-prefix | +--ro v6ur:valid-lifetime? uint32 | +--ro v6ur:on-link-flag? boolean | +--ro v6ur:preferred-lifetime? uint32 | +--ro v6ur:autonomous-flag? boolean +--ro rt:routing-instance? routing-instance-state-ref module: ietf-routing +--ro routing-state | +--ro routing-instance* [name] | +--ro name string | +--ro type? identityref | +--ro router-id? yang:dotted-quad | +--ro interfaces | | +--ro interface* if:interface-state-ref | +--ro routing-protocols | | +--ro routing-protocol* [type name] | | +--ro type identityref | | +--ro name string | +--ro ribs | +--ro rib* [name] | +--ro name string | +--ro address-family identityref | +--ro default-rib? boolean {multiple-ribs}? | +--ro routes | +--ro route* | +--ro route-preference? route-preference | +--ro next-hop | | +--ro (next-hop-options) | | +--:(outgoing-interface) | | | +--ro outgoing-interface? if:interface-state-ref | | +--:(special-next-hop) | | | +--ro special-next-hop? enumeration | | +--:(next-hop-address) | | | +--ro v6ur:next-hop-address? inet:ipv6-address | | +--:(next-hop-address) | | +--ro v4ur:next-hop-address? inet:ipv4-address | +--ro source-protocol identityref | +--ro active? empty | +--ro last-updated? yang:date-and-time | +--ro v6ur:destination-prefix? inet:ipv6-prefix | +--ro v4ur:destination-prefix? inet:ipv4-prefix +--rw routing +--rw routing-instance* [name] +--rw name string +--rw type? identityref +--rw enabled? boolean +--rw router-id? yang:dotted-quad +--rw description? string +--rw routing-protocols | +--rw routing-protocol* [type name] | +--rw type identityref | +--rw name string | +--rw description? string | +--rw static-routes | +--rw v6ur:ipv6 | | +--rw v6ur:route* [destination-prefix] | | +--rw v6ur:destination-prefix inet:ipv6-prefix | | +--rw v6ur:description? string | | +--rw v6ur:next-hop | | +--rw (next-hop-options) | | +--:(outgoing-interface) | | | +--rw v6ur:outgoing-interface? if:interface-ref | | +--:(special-next-hop) | | | +--rw v6ur:special-next-hop? enumeration | | +--:(next-hop-address) | | +--rw v6ur:next-hop-address? inet:ipv6-address | +--rw v4ur:ipv4 | +--rw v4ur:route* [destination-prefix] | +--rw v4ur:destination-prefix inet:ipv4-prefix | +--rw v4ur:description? string | +--rw v4ur:next-hop | +--rw (next-hop-options) | +--:(outgoing-interface) | | +--rw v4ur:outgoing-interface? if:interface-ref | +--:(special-next-hop) | | +--rw v4ur:special-next-hop? enumeration | +--:(next-hop-address) | +--rw v4ur:next-hop-address? inet:ipv4-address +--rw ribs +--rw rib* [name] +--rw name string +--rw address-family? identityref +--rw description? string "Acee Lindem (acee)" <acee@cisco.com> writes: > On 10/13/15, 12:30 PM, "Ladislav Lhotka" <lhotka@nic.cz> wrote: > >> >>> On 13 Oct 2015, at 17:20, Acee Lindem (acee) <acee@cisco.com> wrote: >>> >>> Hi Lada, NETMOD, >>> >>> So I think we should move forward this ietf-rtg-cfg so that it can be >>> augmented and other work can move forward. We are still in disagreement >>> with respect to routing-instance/interface configuration. >>> >>> - We feel the IPv4/IPv6 interfaces should reference the >>> routing-instance in their config state. This is consistent with >>> draft-rtgyangdt-rtgwg-device-model-01.txt. >>> - You feel that the routing-instance should have a list of leaf-ref’s >>> to the interface. You believe the leaf-ref provides a level of >>>validation >>> due to the fact that references can be confined to routing-instance >>> references. However, heretofore, no models are referencing the interface >>> leaf-refs in the list. >> >>True, these models (ietf-isis, for instance) use leafrefs with >>"if:interface-ref" type. However, such leafrefs are under-constrained >>because they can be configured to refer to: >> >>- interfaces of any layer, including physical interfaces, VLAN trunks etc. > > Actually, putting the routing-instance reference in the IPv4 and IPv6 > interface models (i.e., RFC 7277) constrains the reference to layer 3 more > effectively than the list of leaf-refs. > >> >>- interfaces assigned to any routing instance. > > But the list of leaf-refs doesn’t insure an IPv4 interface or IPv6 > interface isn’t included by a single routing-instance. > >> >>I believe in all these cases the choice has to be limited to (1) L3 >>interfaces, and (2) belonging to "own" routing instance. These >>constraints will have to be checked in server code somehow - I would >>prefer to have them represented in the data model. >> >>But if nobody shares this concern with me, I am not going to block the >>document on this issue. > > I’d also be interested if anyone shares this concern. > > Thanks, > Acee > > >> >>Lada >> >>> >>> Other than the Routing YANG Design Team having chosen the first option - >>> are there any other opinions? >>> >>> Thanks, >>> Acee >>> >>> On 10/9/15, 9:00 AM, "netmod on behalf of Acee Lindem (acee)" >>> <netmod-bounces@ietf.org on behalf of acee@cisco.com> wrote: >>> >>>> Hi Lada, >>>> I2RS is not chartered to do the base models. There are other routing >>>> models that reference routing-cfg and even in-progress implementations. >>>> >>>> On 10/9/15, 4:13 AM, "netmod on behalf of Ladislav Lhotka" >>>> <netmod-bounces@ietf.org on behalf of lhotka@nic.cz> wrote: >>>> >>>>> Hi, >>>>> >>>>> I am sorry for cross-posting but I think it is high time to decide the >>>>> relationship between the data models in i2rs-rib-data-model and >>>>> netmod-routing-cfg I-Ds because they clearly target the same >>>>>management >>>>> data in a router. I can see three possible scenarios: >>>>> >>>>> 1. The i2rs-rib module will be modified to augment >>>>> ietf-routing/ietf-ipv[46]-unicast-routing. >>>> >>>> This would seem to be the obvious choice. >>>> >>>>> >>>>> 2. The scope of ietf-routing will be changed so that it would address >>>>> only host routing and simple routers. The modelling work for advanced >>>>> routers will be done elsewhere. >>>>> >>>>> 3. The work on netmod-routing-cfg will be stopped. >>>> >>>> A fourth option would be for me to take over ownership, move the work >>>>to >>>> the RTG WG, and we’d recruit some strong authors/reviewers from >>>>operators >>>> and other vendors (involving the ADs in selection). >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>>>> >>>>> Opinions? >>>>> >>>>> Thanks, Lada >>>>> >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >>-- >>Ladislav Lhotka, CZ.NIC Labs >>PGP Key ID: E74E8C0C >> >> >> >> > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
- Re: [Rtg-yang-coord] [netmod] rib-data-model and … Acee Lindem (acee)
- Re: [Rtg-yang-coord] [netmod] rib-data-model and … Ladislav Lhotka
- Re: [Rtg-yang-coord] [netmod] rib-data-model and … Acee Lindem (acee)
- Re: [Rtg-yang-coord] [netmod] rib-data-model and … Ladislav Lhotka
- Re: [Rtg-yang-coord] [netmod] rib-data-model and … Acee Lindem (acee)
- Re: [Rtg-yang-coord] [netmod] rib-data-model and … Rob Shakir
- Re: [Rtg-yang-coord] [netmod] rib-data-model and … Ladislav Lhotka
- Re: [Rtg-yang-coord] [netmod] rib-data-model and … Rob Shakir
- Re: [Rtg-yang-coord] [netmod] rib-data-model and … Acee Lindem (acee)