Re: [netmod] [Rtg-yang-coord] High Level Comments on draft-ietf-netmod-rtg-cfg-16.txt
Ladislav Lhotka <lhotka@nic.cz> Wed, 19 November 2014 13:46 UTC
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BAA1A037C; Wed, 19 Nov 2014 05:46:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.645
X-Spam-Level:
X-Spam-Status: No, score=-0.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_29=0.6, RP_MATCHES_RCVD=-0.594] autolearn=no
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 KbsY579F-xRu; Wed, 19 Nov 2014 05:46:02 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A52B81A037B; Wed, 19 Nov 2014 05:46:01 -0800 (PST)
Received: from [192.168.1.108] (unknown [195.113.220.254]) by mail.nic.cz (Postfix) with ESMTPSA id F035D13F853; Wed, 19 Nov 2014 14:45:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1416404760; bh=86tPHpbrs4oVbcT46euonJTXRLGYM/BjtE+HgL1Lrs4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=niktppy+xwzqCUwm61ZIMjhFh6bP6RLSF4pMuFJTEl/RhI6ej1KlGN28lpycfSfUU 8PRz/Q25fIJCODxUbLbX7TYtv+tbhkZ7BvSObArKUH23UDC0ruU6MEkvpoJfbiKVhg jQqyPgYCZyi/DlIxD+erRRoS86QEbhYZs1RVUlV4=
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <D0920478.93BC%acee@cisco.com>
Date: Wed, 19 Nov 2014 14:45:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <00447907-9E3C-408C-BFDC-8BABE0254869@nic.cz>
References: <D09109E6.930E%acee@cisco.com> <m261ebfkxu.fsf@nic.cz> <20141119.134003.1741683880484092511.mbj@tail-f.com> <D0920478.93BC%acee@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GmHlUDmdByc4xZBlwsK0PWyiJzU
Cc: "rtg-yang-coord@ietf.org" <rtg-yang-coord@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Re: [netmod] [Rtg-yang-coord] High Level Comments on draft-ietf-netmod-rtg-cfg-16.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Nov 2014 13:46:04 -0000
On 19 Nov 2014, at 14:35, Acee Lindem (acee) <acee@cisco.com> wrote: > Re-adding netmod@ietf.org due to popular request. > > On 11/19/14, 7:40 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote: > >> Ladislav Lhotka <lhotka@nic.cz> wrote: >>> Hi Acee, >>> >>> please see my comments inline. >>> >>> "Acee Lindem (acee)" <acee@cisco.com> writes: >>> >>>> First, let me explain why I requested that the route-filters be >>>> removed from the model. What I don't like about the route-filters is >>>> that they are merely place-holders placed at a point-of-attachment >>>> which I don't necessarily agree with. Although we may end up with >>>> something similar, these definitions should be in a more complete >>>> routing policy model. Additionally, I believe it is obvious that there >>>> will >>> >>> I don't think the ietf-routing module preempts any further work on a >>> policy model. And if the points-of-attachment turn out to be wrong, we >>> can write a new module - nothing is cast in stone and I expect the >>> module will have to be redone anyway after some experience will have >>> been collected. >> >> But then it doesn't hurt to wait with these "attachment points" until >> at least the first policy model is being written, right? They can >> then either be defined in an update to this model, or in a separate >> model that augments this one. > > My point is that this may set us off in the wrong direction and be a > source of future confusion and debate. If others believe the existing stub > policies are a good start, they should speak up. > > +1 > > >> >> [...] >> >>>> As for the interface list in the routing-instance, I think it is >>>> obvious that one should not define the address space for interface >>>> disjointly from the IPv4/IPv6 interface addresses. That is why I >>>> would recommend augmenting the RFC 7273 objects with a reference >>>> to the routing instance rather having a disjoint interface >>>> list in routing-instance as proposed. >>> >>> It is IMO subjective whether the assignment of interfaces to routing >>> instances should be done in interface configuration or in routing >>> instance configuration. As it is now, the following procedure could work >>> fine: >>> >>> 1. Define routing instances (this has to be done in any case). >>> 2. Assign interfaces to routing instances in routing instance >>> configuration via references to interfaces in the main interface >>> list. >>> 3. Assign addresses to interfaces in main interface configuration. >>> >>> The system then has all information to be able to resolve potential >>> conflicts in IP addresses belonging to different routing instances. >> >> To be very clear, is this what you propose: >> >> augement /if:interfaces/if:interface { >> leaf routing-instance { >> type routing-instance-ref; >> } >> } >> >> ... and remove /routing/routing-instance/interfaces? > > Either here or augment ietf-ip (RFC 7277) in a similar manner. I also > think the definition of the ipv6-router-advertisements should augment the > ipv6 container in ietf-ip rather than on this misplaced list of > interfaces. An advantage of this misplaced list of interfaces is that it is supposed to contain only network layer interfaces whereas if:interface is a flat list that contains interfaces of all layers including those where RAs don’t make sense at all. Lada > > Thanks, > Acee > >> >> I think this would be equivalent to your current model, in the sense >> of *what* you can express. >> >>> Maybe there are some implementation-related issues that I am missing, >>> so I am not against the change you propose but I'd like to know sound >>> reasons before applying it. >> >> I think Acee provided a good reason: >> >>>> one should not define the address space for interface >>>> disjointly from the IPv4/IPv6 interface addresses >> >> >> >> >> /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
- [netmod] High Level Comments on draft-ietf-netmod… Acee Lindem (acee)
- Re: [netmod] High Level Comments on draft-ietf-ne… Acee Lindem (acee)
- Re: [netmod] [Rtg-yang-coord] High Level Comments… Acee Lindem (acee)
- Re: [netmod] [Rtg-yang-coord] High Level Comments… Acee Lindem (acee)
- Re: [netmod] [Rtg-yang-coord] High Level Comments… Ladislav Lhotka
- Re: [netmod] [Rtg-yang-coord] High Level Comments… Ladislav Lhotka