Re: [Rtg-yang-coord] [netmod] draft-ietf-netmod-routing-cfg

Ladislav Lhotka <lhotka@nic.cz> Wed, 25 November 2015 08:26 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 EF0121A8AC8; Wed, 25 Nov 2015 00:26:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 voh5LcxZOiZG; Wed, 25 Nov 2015 00:26:40 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B31911A8AC6; Wed, 25 Nov 2015 00:26:39 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 0F83C1CC0187; Wed, 25 Nov 2015 09:26:39 +0100 (CET)
From: Ladislav Lhotka <lhotka@nic.cz>
To: "Acee Lindem (acee)" <acee@cisco.com>, Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <D27A2EC8.3F0A6%acee@cisco.com>
References: <D278C312.3EDF3%acee@cisco.com> <20151124.102441.1278595679799542000.mbj@tail-f.com> <D27A2EC8.3F0A6%acee@cisco.com>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Wed, 25 Nov 2015 09:26:36 +0100
Message-ID: <m28u5mjxhf.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/gAJL0eSZ4OUYWswy9I6TjlEktUY>
Cc: "rtg-yang-coord@ietf.org" <rtg-yang-coord@ietf.org>, "rtg-dt-yang-arch@ietf.org" <rtg-dt-yang-arch@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [Rtg-yang-coord] [netmod] draft-ietf-netmod-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: Wed, 25 Nov 2015 08:26:44 -0000

"Acee Lindem (acee)" <acee@cisco.com> writes:

> Hi Martin,
>  
> I think using the more generic term, “networking”, at the top would be
> preferable. What we need is an instance abstraction that covers L3

Hmm, shall we also rename "routing-protocol" to "networking-protocol"?
Seriously, I am concerned that we are drifting away from the original
focus of the data model. We should keep in mind it needs to remain
usable by hosts (even constrained ones) and simple routers because there
is no other model such devices could use.

> (e.g., virtual router or VRF), L2 (e.g., Virtual Switch Instance), or
> a combination (some EVPN, TRILL, etc). This could be used in lieu of
> each L2 model creating their own top separate list of instances. For
> example, the networking-instance could be augmented with both the VPLS
> and VPWS instances in
> https://tools.ietf.org/html/draft-shah-bess-l2vpn-yang-00.
>
> Some YANG models ascribe greatness from the start, others achieve
> greatness through refinement, while still others have greatness thrust
> upon them. routing-cfg would fall into the last category…

If it ever gets finished.

Lada

>
> Thanks,
> Acee 
>
> On 11/24/15, 4:24 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote:
>
>>Hi,
>>
>>"Acee Lindem (acee)" <acee@cisco.com> wrote:
>>> We had a lot of good discussions at IETF 94 with respect to the
>>> ietf-routing and how it could be augmented in the future to support
>>>I2RS.
>>> These discussions are ongoing.
>>> 
>>> One current change that I would like to propose is to change the base
>>> instance container from routing-instance to networking-instance.
>>
>>Is the idea to simply rename the "routing-instance" container to
>>"networking-instance"?
>>
>>Then we would have:
>>
>>   +--rw routing
>>      +--rw networking-instance
>>
>>Would you keep the top-level name "routing"?
>>
>>
>>
>>
>>/martin
>>
>>
>>
>>
>>> This
>>> would provide an instance definition that could be augmented for L2
>>> protocols and service functionality as well as L3. It is also consistent
>>> with the term used in both
>>> https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-01.txt and
>>> https://www.ietf.org/id/draft-openconfig-rtgwg-network-instance-01.txt.
>>> 
>>> Thanks,
>>> Acee 
>>> 
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> 
>
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C