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

Rob Shakir <> Wed, 21 October 2015 13:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CBC581A8846; Wed, 21 Oct 2015 06:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SJ3JdjNd-KK6; Wed, 21 Oct 2015 06:58:56 -0700 (PDT)
Received: from ( [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E72F11A87E7; Wed, 21 Oct 2015 06:58:55 -0700 (PDT)
Received: from [2601:681:201:5165:3c38:7adb:87c3:3db8] (helo=piccolo.local) by with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1ZotuS-0006Pb-FL; Wed, 21 Oct 2015 14:58:32 +0100
Date: Wed, 21 Oct 2015 07:58:46 -0600
From: Rob Shakir <>
To: Ladislav Lhotka <>
Message-ID: <etPan.56279a16.7204de92.12fd@piccolo.local>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <etPan.56279299.3a0e4920.12fd@piccolo.local> <>
X-Mailer: Airmail Beta (334)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="56279a16_3aa4f079_12fd"
Archived-At: <>
Cc: Routing YANG <>, "=?utf-8?Q?" <>, "Acee Lindem \(acee\)" <>, NETMOD WG <>, Routing WG <>
Subject: Re: [Rtg-yang-coord] [netmod] rib-data-model and routing-cfg
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Oct 2015 13:58:58 -0000

On 21 October 2015 at 07:52:43, Ladislav Lhotka ( 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.