Re: [Rtg-yang-coord] issue :R03: assignment of interfaces to routing instances

"Acee Lindem (acee)" <acee@cisco.com> Thu, 12 February 2015 23:09 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 E71671A008F; Thu, 12 Feb 2015 15:09:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, 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 yytubQjVVXbj; Thu, 12 Feb 2015 15:09:45 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067331A1A4F; Thu, 12 Feb 2015 15:09:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2085; q=dns/txt; s=iport; t=1423782584; x=1424992184; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vEDsKePdCR9yCgTFrvu39WtSkJpXL1u97SeQsEy7NSU=; b=ReWj8jQPTm1W8FMagyYcQSPz/jLrDKCCnmqV31tZ51gqqlFfyP9FfvPs fNIlGDSgYcpDuFI051s6q+9p1W79MnLN1gJP+d6c6s7K0AeEG44W8Fn5v 3+qq9VsHXy4B28fIQVv37ksv+5kocChEAtCaa+gdkwM5dfGw+v+zNZD3e g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkIFAGox3VStJV2d/2dsb2JhbABYA4MGUloEwyCFdQKBJUMBAQEBAQF8hA0BAQRyBw4CAgEIDgIILhsXJQIEAQ0FG4gS1VABAQEBAQEBAQEBAQEBAQEBAQEBAQEXBIsIhF0QBxGEGQWKAoUniTOBGI4qgz4ig25vgUR/AQEB
X-IronPort-AV: E=Sophos;i="5.09,567,1418083200"; d="scan'208";a="396071617"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 12 Feb 2015 23:09:43 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t1CN9hxL012936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Feb 2015 23:09:43 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 12 Feb 2015 17:09:42 -0600
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Xufeng Liu <xufeng.liu@ericsson.com>
Thread-Topic: [Rtg-yang-coord] issue :R03: assignment of interfaces to routing instances
Thread-Index: AQHQRxj77tD6GUYxhkmEAnTuReZw3g==
Date: Thu, 12 Feb 2015 23:09:42 +0000
Message-ID: <D1029726.E4B5%acee@cisco.com>
References: <AAB1CC9C17CBA440BDFA169056B93B9EB10521@eusaamb107.ericsson.se> <35023717-7EE8-4F45-B2F4-B24E0F86FA5A@nic.cz> <20150113212732.GD1545@elstar.local> <23976026-499F-4C9C-844A-DB53BE244992@nic.cz> <AAB1CC9C17CBA440BDFA169056B93B9EB1128D@eusaamb107.ericsson.se> <20150114155450.GA3625@elstar.local> <AAB1CC9C17CBA440BDFA169056B93B9EB1139B@eusaamb107.ericsson.se> <CABCOCHSiWG=x0vTYKKxqhMqd69yK+Nuo0k_Y_=Y_KHkQBDi3FA@mail.gmail.com> <D0DBD855.889EB%jeff.tantsura@ericsson.com> <AAB1CC9C17CBA440BDFA169056B93B9EB11472@eusaamb107.ericsson.se> <20150114174655.GA3932@elstar.local>
In-Reply-To: <20150114174655.GA3932@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.116.152.200]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <46F9CFCEA069744DADDD76A62BE62B93@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/31F7qoapq_A2tQN1FfHG-UswLHQ>
Cc: "rtg-yang-coord@ietf.org" <rtg-yang-coord@ietf.org>, Routing WG <rtgwg@ietf.org>, Andy Bierman <andy@yumaworks.com>, Jeff Tantsura <jeff.tantsura@ericsson.com>, Ladislav Lhotka <lhotka@nic.cz>
Subject: Re: [Rtg-yang-coord] issue :R03: assignment of interfaces to routing instances
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: <http://www.ietf.org/mail-archive/web/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, 12 Feb 2015 23:09:48 -0000

I believe the fact that we are having trouble resolving this is that the
model is wrong. I would propose the following:

   1. Remove the interface list completely from rtf-cfg configuration.
   2. Augment the RFC 7223 to include a reference to a routing-instance.
An interface should be part of one and only one routing-instance.
   3. Provide a list of interfaces in the operational state in the rtg-cfg
model. 

One reason I'm proposing this change is that I believe a routing-instance
implies an IPv4/IPv6 address space and the interfaces list MUST NOT be
disjoint from the assigned addresses (refer to RFC 7277). If you want to
have a list of interfaces in the routing-instance, you should deprecate
RFC 7277 or, at least, say that it only applies to the default instance.

In all fairness, Lada disagrees with me on this point and wants the
flexibility of associating an interface with multiple routing-instances.
Additionally, he feels that the list inside the routing-instance will
facilitate better interface selection checking. I don¹t see the latter as
an issue as the same checking could be applied when an attempt is made to
augment the RFC 7223 interface.

Thanks,
Acee 

   

On 1/14/15, 12:46 PM, "Juergen Schoenwaelder"
<j.schoenwaelder@jacobs-university.de> wrote:

>On Wed, Jan 14, 2015 at 04:43:29PM +0000, Xufeng Liu wrote:
>> Hi Andy,
>> 
>> The concatenated string format is actually what we plan to do. However,
>>to me, it is more like a hack than an engineered solution. The model
>>fails to capture such a relationship properly.
>>
>
>If your interface names are no unique, I would assume that you will
>face other issues as well. For example, one may use an interface name
>to disambiguate link-local addresses. I am not sure how that works if
>your interface name is not unique.
>
>/js
>
>-- 
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>