IETF Logo Mail Archive

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

Dean Bogdanovic <ivandean@gmail.com> Tue, 24 November 2015 20:11 UTC

Return-Path: <ivandean@gmail.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 008AB1A8937; Tue, 24 Nov 2015 12:11:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 LkkETnYru6K8; Tue, 24 Nov 2015 12:11:24 -0800 (PST)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81FA71A8902; Tue, 24 Nov 2015 12:11:24 -0800 (PST)
Received: by qgcc31 with SMTP id c31so18539943qgc.3; Tue, 24 Nov 2015 12:11:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LpqWjsJwOp4p2G2jFZCAa9epE5Vy0yZ5bzDZkOnQHDw=; b=DOiCSD9hyU9OIKqSSnlejkLiYgJPTLmRxNvj5nvdxYXVIt+jbYRe5YzIZSV0tw7FU8 J6Wlw6mGnMx4QvjSMB53gglR2k6bkyio3eKIg8IdKBJc5fJ6EEV2/lFCL2JJkYq6GGyq chOR3Z9n31HBpu3thuekR8Phzs/KNMZMgyx+5XSsAew0SzgLhFVd7r6CwK+TJBM9uf4z PFp62WRaZZH2ouP06TcOcoWgVt7hqGj+umxoWMjlHIrH5uRaLddte98YxTFhMQnU7pIy uSxQ1LgPq0/M3uyJxqwG6F+L5ZpjFe3u8aMJ2pKNC8hUgVuT6H6cBwU2yp0B3EcB8OQh w0Mw==
X-Received: by 10.140.155.75 with SMTP id b72mr35455364qhb.29.1448395883698; Tue, 24 Nov 2015 12:11:23 -0800 (PST)
Received: from [192.168.128.73] ([192.64.64.178]) by smtp.gmail.com with ESMTPSA id w10sm4561052qhc.16.2015.11.24.12.11.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 24 Nov 2015 12:11:23 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Dean Bogdanovic <ivandean@gmail.com>
In-Reply-To: <20151124.102441.1278595679799542000.mbj@tail-f.com>
Date: Tue, 24 Nov 2015 15:11:22 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <A9DE6AFB-14DC-46FB-B2EE-C993BEEC67E2@gmail.com>
References: <D278C312.3EDF3%acee@cisco.com> <20151124.102441.1278595679799542000.mbj@tail-f.com>
To: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/vJTpZTWnOp7WxFEUVu-ziyimd_o>
X-Mailman-Approved-At: Mon, 30 Nov 2015 08:58:57 -0800
Cc: rtg-yang-coord@ietf.org, rtg-dt-yang-arch@ietf.org, acee@cisco.com, netmod@ietf.org
Subject: Re: [Rtg-yang-coord] [Rtg-dt-yang-arch] [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: Tue, 24 Nov 2015 20:11:26 -0000

Martin,
> n Nov 24, 2015, at 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”?

Yes, routing is not confined to IP only. TRILL and PBB do routing at MAC layer, so routing as top level domain can stay. OTH, routing instance is well defined term in the industry, so there is a need to have a term that can encompass L2 and L3.

Dean

> 
> 
> 
> 
> /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-dt-yang-arch mailing list
> Rtg-dt-yang-arch@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch

v2.23.0 | Report a Bug | By Email