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)" <[email protected]> writes: > On 10/13/15, 12:30 PM, "Ladislav Lhotka" <[email protected]> wrote: > >> >>> On 13 Oct 2015, at 17:20, Acee Lindem (acee) <[email protected]> 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)" >>> <[email protected] on behalf of [email protected]> 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" >>>> <[email protected] on behalf of [email protected]> 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 >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> [email protected] >>>> 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
