IETF Logo Mail Archive

Re: [Rtg-yang-coord] [netmod] rib-data-model and routing-cfg

"Acee Lindem (acee)" <acee@cisco.com> Wed, 21 October 2015 16:42 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 2A0DD1AC444; Wed, 21 Oct 2015 09:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 TFtT8okKdlxd; Wed, 21 Oct 2015 09:42:00 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EE481AC436; Wed, 21 Oct 2015 09:42:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10241; q=dns/txt; s=iport; t=1445445721; x=1446655321; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ppJEzH5FSxnelwxxrLCTPxzw2WtQWe6PxXen8RJd9vI=; b=h5CiXhVCwULK60nDhGJbLHRaPJRvfkTKAB40Udzu14ODs/hKRpzqSJBo j6KMtngUHX5Lj66ZEgaNJ7GTbzd8DNJYonsxAroIbA7VSfbuiFkbOSbDe iamBM/F046hJaA2Nv5hUIehc/9VTMz+djM9IwDZ9LsIm6XWlrVWuwkR7Z E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D4AQC5vydW/51dJa1dgmlNgUMGvgYBDYFahh4CHIEqOBQBAQEBAQEBgQqELQEBAQQjVhACAQgOAwMBAigDAgICMBQJCAIEAQ0FiDCxQZMPAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIt1hHwRB4JpgUUFliQBjR6cIAEfAQFCghYYgVVyhGGBBgEBAQ
X-IronPort-AV: E=Sophos;i="5.17,712,1437436800"; d="scan'208,217";a="199142006"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 21 Oct 2015 16:42:00 +0000
Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t9LGfxKj005458 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Oct 2015 16:41:59 GMT
Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 21 Oct 2015 11:41:39 -0500
Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.000; Wed, 21 Oct 2015 11:41:39 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Rob Shakir <rjs@rob.sh>, Ladislav Lhotka <lhotka@nic.cz>
Thread-Topic: [netmod] rib-data-model and routing-cfg
Thread-Index: AQHRDAiWYM8r/j6Te06TBUmXHw32eZ52N66A
Date: Wed, 21 Oct 2015 16:41:39 +0000
Message-ID: <D24D3116.37669%acee@cisco.com>
References: <7E24547E-B42B-46E2-AF76-F7639D61963F@nic.cz> <D23D3103.34500%acee@cisco.com> <D2429721.34A0E%acee@cisco.com> <DBF22257-A7A2-4679-927A-EBCC1022FE13@nic.cz> <D242C30E.34C2A%acee@cisco.com> <m27fmowezi.fsf@birdie.labs.nic.cz> <D2458D0F.36813%acee@cisco.com> <etPan.56279299.3a0e4920.12fd@piccolo.local> <2C6909AC-51B9-42D8-82EB-B5006BABC845@nic.cz> <etPan.56279a16.7204de92.12fd@piccolo.local>
In-Reply-To: <etPan.56279a16.7204de92.12fd@piccolo.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.199]
Content-Type: multipart/alternative; boundary="_000_D24D311637669aceeciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/DlMSXISzCSGEpIM9UAMC12MEkOc>
Cc: Routing YANG <rtg-yang-coord@ietf.org>, "i2rs@ietf.org" <i2rs@ietf.org>, NETMOD WG <netmod@ietf.org>, Routing WG <rtgwg@ietf.org>
Subject: Re: [Rtg-yang-coord] [netmod] rib-data-model and 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, 21 Oct 2015 16:42:03 -0000

I guess in the L3VPN use case, both the IPv4 and IPv6 VPNs are for the same customer (since the interface only goes to one place).

 I’ve been thinking about this for much of the morning and I see, at least, the following options:

          1. Move the reference(s) to routing-instance to “/if:interfaces/if:interface/ip:ipv4”  and “/if:interfaces/if:interface/ip:ipv6”.
          2. Keep the reference at the “/if:interface/if:interface/“ level but make it a container with a more complex structure including the overall reference and feature enabled override references for specific purposes (L2, IPv6, IPv4, etc).
          3. Others?

I like #2 since it is optimized towards the most common use case.

With respect to encapsulation, I don’t understand how they could be different for different AFs unless they are, in fact, different RFC 7223 interfaces. Am I missing something?

Thanks,
Acee

From: Rob Shakir <rjs@rob.sh<mailto:rjs@rob.sh>>
Date: Wednesday, October 21, 2015 at 9:58 AM
To: Ladislav Lhotka <lhotka@nic.cz<mailto:lhotka@nic.cz>>
Cc: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, Routing WG <rtgwg@ietf.org<mailto:rtgwg@ietf.org>>, "i2rs@ietf.org<mailto:i2rs@ietf.org>" <i2rs@ietf.org<mailto:i2rs@ietf.org>>, NETMOD WG <netmod@ietf.org<mailto:netmod@ietf.org>>, Routing YANG <rtg-yang-coord@ietf.org<mailto:rtg-yang-coord@ietf.org>>
Subject: Re: [netmod] rib-data-model and routing-cfg

On 21 October 2015 at 07:52:43, Ladislav Lhotka (lhotka@nic.cz<mailto:lhotka@nic.cz>) wrote:
One option would be to create two virtual interfaces - one for IPv4 VPN and another for IPv6 VPN, and define routing-instance and addresses separately for each.

This is only workable if an implementation must support two virtual interfaces that have the same underlying encapsulation (i.e.., they are simply logically separating IPv4 and IPv6), in some implementations, this isn’t the case, and the virtual interfaces must have different encapsulations.

In openconfig-interfaces, each sub-interface is associated with a single VLAN, so in this case, we would need the network-instance to be specified on a per address-family basis there. There is nothing to stop one having a single leaf at the sub-interface or interface level that is inherited by the other constructs - this is something that I have been considering based on work on the network-instance model that we recently published.

r.

v2.23.0 | Report a Bug | By Email