Hi Lada, I looked at this and I like this simple association. I think we should go with this - there is one point for discussion.
All, In routing design team discussions we had augmented “if:interfaces/if:interface/ip:ipv4” and “if:interface/if:interface/ip:ipv6” so an interface could be mapped to different routing-instances for IPv4 and IPv6. Do we really see associating the same interface with different routing-instances for IPv4 and IPv6? I can seem to remember the use case and it does add complexity forever. Thanks, Acee On 10/15/15, 7:25 AM, "Ladislav Lhotka" <[email protected]> wrote: >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
