Re: [netmod] [Rtg-yang-coord] High Level Comments on draft-ietf-netmod-rtg-cfg-16.txt
"Acee Lindem (acee)" <acee@cisco.com> Wed, 19 November 2014 13:36 UTC
Return-Path: <acee@cisco.com>
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 7E33F1A1B9B; Wed, 19 Nov 2014 05:36:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.095
X-Spam-Level:
X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 73mwq993IyUd; Wed, 19 Nov 2014 05:36:04 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861AF1A037C; Wed, 19 Nov 2014 05:36:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3548; q=dns/txt; s=iport; t=1416404164; x=1417613764; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=p9IN5XvYMaIVY5gMMLZY2xQ2N2e7eIXTLmnTdYm3w/g=; b=j0l9apoYish/9oWmFgv/42Cb+hQCxoBf9dhb0z5vA09vut25TEOj6p+9 7QrQgxutP61XPafX+F8NKHJovLx99MJmLLhbUobE93OAjivyZ6HqpGg1k YNpspGCN+8I6EWpFfFC5ISmThZdoMCk2O/8ur7/FzEV+r6KzGHfAlTa1N U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicFAFWcbFStJA2G/2dsb2JhbABagw6BLgTTVQKBBBYBAQEBAX2EAwEBBDo/EAIBCA4KHhAyJQIEAQ0FiEHTNQEBAQEBAQEBAQEBAQEBAQEBAQEZkQgHhEsBBJAYgj+MCoEzg1WECoYrgzWECYI2gUVtgUiBAwEBAQ
X-IronPort-AV: E=Sophos;i="5.07,417,1413244800"; d="scan'208";a="98113511"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP; 19 Nov 2014 13:36:03 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sAJDa3Kb027287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Nov 2014 13:36:03 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.191]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Wed, 19 Nov 2014 07:36:03 -0600
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>, "lhotka@nic.cz" <lhotka@nic.cz>
Thread-Topic: [Rtg-yang-coord] [netmod] High Level Comments on draft-ietf-netmod-rtg-cfg-16.txt
Thread-Index: AQHQA/Xztr8uJfo+j0iZcOT/psr2YZxoBFuA
Date: Wed, 19 Nov 2014 13:35:46 +0000
Message-ID: <D0920478.93BC%acee@cisco.com>
References: <D09109E6.930E%acee@cisco.com> <m261ebfkxu.fsf@nic.cz> <20141119.134003.1741683880484092511.mbj@tail-f.com>
In-Reply-To: <20141119.134003.1741683880484092511.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <69A61F9C2037B948AFED268A7EA3E8B2@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/o7UmK7oqGeWbq9PPR8Pxi2kyUmk
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:36:06 -0000
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. > >[...] > >> > 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. 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
- [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