Re: [Rtg-yang-coord] [netmod] rib-data-model and routing-cfg
"Acee Lindem (acee)" <acee@cisco.com> Thu, 15 October 2015 21:12 UTC
Return-Path: <acee@cisco.com>
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 CB0521A1BC8; Thu, 15 Oct 2015 14:12:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.911
X-Spam-Level:
X-Spam-Status: No, score=-10.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 JY5NAUvXS907; Thu, 15 Oct 2015 14:12:33 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF001A1BBE; Thu, 15 Oct 2015 14:12:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22542; q=dns/txt; s=iport; t=1444943552; x=1446153152; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uScMXPNjLMqGClxGrDWEtbR+1TgEYksHmClbMMnwuZU=; b=hNYWXySKtnLKjSI3H18S29i9YhLx8uFXylfq602wmlPNq6ERlODt7JoS MUQlsRa94X2I+G7XczQmllUxtGTiteGEfyJwCbuLfILN/n4ySzhSavLaF AGBGeFwsRjhnjlHdIjrEz8TnZ+d82+6Bllkefu3qYLJe+6LwcdytunamL I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AFAgDsFSBW/5ldJa1egyZUbga9NwENgVkXCoUzSgIcgSA4FAEBAQEBAQGBCoQnAQEEAQEBIBE6BAcQAgEIGAICJgICAiULFRACBA4FiC4NsCeTPAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKKUoQ0AQ0YGBsHgmmBRQWND4kOAYUYiAKBWIQ6lX0BHwEBQoQDcYQeAQEeBxyBBgEBAQ
X-IronPort-AV: E=Sophos;i="5.17,687,1437436800"; d="scan'208";a="197321908"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 15 Oct 2015 21:12:31 +0000
Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9FLCVIq032246 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2015 21:12:31 GMT
Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Oct 2015 16:12:16 -0500
Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.000; Thu, 15 Oct 2015 16:12:16 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Thread-Topic: [netmod] rib-data-model and routing-cfg
Thread-Index: AQHRAmpn2WDjXB7SH0yyXI3vdDB1jJ5jMMMAgAZwt4CAAFZcgP//3TyAgALyRYCAAGEWAA==
Date: Thu, 15 Oct 2015 21:12:16 +0000
Message-ID: <D2458D0F.36813%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> <m27fmowezi.fsf@birdie.labs.nic.cz>
In-Reply-To: <m27fmowezi.fsf@birdie.labs.nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.199]
Content-Type: text/plain; charset="utf-8"
Content-ID: <831E8953BAB4F14782F0EA1A175A966A@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/gydZ84yuwirEDjGYIhlD84YBSEo>
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 21:12:36 -0000
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" <lhotka@nic.cz> 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)" <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)