Re: [netmod] Question about ietf-routing

"Acee Lindem (acee)" <acee@cisco.com> Wed, 07 June 2017 14:27 UTC

Return-Path: <acee@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87E112EC73; Wed, 7 Jun 2017 07:27:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 pgOmqIKkhXqM; Wed, 7 Jun 2017 07:27:14 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68B3129466; Wed, 7 Jun 2017 07:27:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2394; q=dns/txt; s=iport; t=1496845634; x=1498055234; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pS2axgnh+/Va+WveOzA7w/fGMWp15Yj4gG6dajCZHH4=; b=Timlt6zZnXZCJPlohb+dJwZZyzZR27JSUwKFNFvzWClIi/R1R/p6/TzA X1RIkPOmMHh7A9nUa2+up95+JfWv08+wL2GCF29wSk1OdUuP6aW7sg+KJ Xdbgi4GMCsWtCrPjMoGAhLR1USckgWKarr9M72qtTFm1Yq1XHVFpImfRB k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DiAAClDDhZ/4cNJK1eGQEBAQEBAQEBAQEBBwEBAQEBg1higQ0Hg2yKGKdoghAhC4UuSgIaglo/GAECAQEBAQEBAWsohRkCAQECAQEhEToLEAIBCBoCJgICAiULFRACBAENBYorEK5WgiaLfwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuKVoRqOoJYgmEFkDOOBgKTNpIAlGYBHziBCnQVRocIdgGIRIENAQEB
X-IronPort-AV: E=Sophos;i="5.39,311,1493683200"; d="scan'208";a="437022063"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jun 2017 14:27:13 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v57ERDuj016938 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Jun 2017 14:27:13 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Jun 2017 10:27:12 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 7 Jun 2017 10:27:12 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Ladislav Lhotka <lhotka@nic.cz>, Alex Campbell <Alex.Campbell@Aviatnet.com>
CC: "netmod@ietf.org" <netmod@ietf.org>, RTG YANG Design Team <rtg-dt-yang-arch@ietf.org>
Thread-Topic: [netmod] Question about ietf-routing
Thread-Index: AQHS3x5Bkeeb5JjXkkKedeZMDHRzCqIZMowAgABDgAA=
Date: Wed, 07 Jun 2017 14:27:12 +0000
Message-ID: <D55D8492.B2373%acee@cisco.com>
References: <1496792599527.55133@Aviatnet.com> <64B138D8-929F-43AA-8246-DD1AB8793274@nic.cz>
In-Reply-To: <64B138D8-929F-43AA-8246-DD1AB8793274@nic.cz>
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.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <F9277932FF7DAF4BB2297B097BE2625D@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/qrEWi0ecpOzsHS22uiXz3KgQj7s>
Subject: Re: [netmod] Question about ietf-routing
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 07 Jun 2017 14:27:17 -0000

+YANG Routing Design Team

On 6/7/17, 2:25 AM, "Ladislav Lhotka" <lhotka@nic.cz> wrote:

>Hi Alex,
>
>in earlier revisions of the ietf-routing module (up to
>draft-ietf-netmod-routing-cfg-17), we had a configuration item
>("recipient-ribs") that allowed for assigning RIBs to routing protocol
>instances. The reason for removing it is summarized in my presentation
>from IETF 92, slides 10 and 11:
>
>https://www.ietf.org/proceedings/92/slides/slides-92-netmod-9.pdf
>
>(and yes, I wasn't a big fan of this change).
>
>Maybe Acee can give additional background.

The RIBs which the control plane protocols populated are normally dictated
by the address family. In the case of multiple topologies, a specific RIB
(as identified by name) will need to be explicitly associated with the
topology in the control plane protocol as opposed to being connected to
the control plane protocol at a higher level.

Thanks,
Acee 




>
>Lada 
>
>> On 7 Jun 2017, at 01:43, Alex Campbell <Alex.Campbell@Aviatnet.com>
>>wrote:
>> 
>> Hi,
>> 
>> I noticed that the ietf-routing YANG (published in RFC 8022) allows for
>>multiple instances of each control plane protocol, as well as multiple
>>RIBs per address family.
>> However I don't see any way to associate one with the other. Without
>>additional configuration, protocols will only place their routes in
>>default RIBs.
>> Is it intended that this will be left to vendor-specific modules and/or
>>future standards?
>> 
>> Alex
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: 0xB8F92B08A9F76C67
>
>
>
>
>