[irs-discuss] A few comments on the draft-ietf-netmod-routing-cfg-04 draft.
Bruno Rijsman <brijsman@juniper.net> Mon, 03 September 2012 11:17 UTC
Return-Path: <brijsman@juniper.net>
X-Original-To: irs-discuss@ietfa.amsl.com
Delivered-To: irs-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D069F21F84F9; Mon, 3 Sep 2012 04:17:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6Niw3HQFyOL; Mon, 3 Sep 2012 04:17:33 -0700 (PDT)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id EB19F21F84D7; Mon, 3 Sep 2012 04:17:32 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUESRzF6zkcfw+54w0vavS7PJtCpYiM0l@postini.com; Mon, 03 Sep 2012 04:17:33 PDT
Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 3 Sep 2012 04:15:10 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 3 Sep 2012 07:15:09 -0400
From: Bruno Rijsman <brijsman@juniper.net>
To: "netmod@ietf.org" <netmod@ietf.org>
Date: Mon, 03 Sep 2012 07:15:08 -0400
Thread-Topic: A few comments on the draft-ietf-netmod-routing-cfg-04 draft.
Thread-Index: Ac2JxWCgGDoHt3+QR+66VvaZlNieRQ==
Message-ID: <6A19849347D1D1499E75EB41E82C420A4BCFD2C219@EMBX01-WF.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "irs-discuss@ietf.org" <irs-discuss@ietf.org>
Subject: [irs-discuss] A few comments on the draft-ietf-netmod-routing-cfg-04 draft.
X-BeenThere: irs-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:irs-discuss@ietf.org>
List-Help: <mailto:irs-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Sep 2012 11:17:33 -0000
I have a few comments on the draft-ietf-netmod-routing-cfg-04 draft. 1) Generalize the concept of a next-hop It appears that in the current model, routes can point to an outgoing interface and a next-hop address. The concept of next-hops needs to be generalized. Next-hops can have multiple tuples of outgoing interfaces and next-hop addresses. The most common reasons is Equal Cost Multi Path (ECMP) where a single route has multiple next-hops. This is not the same as multi-pathing in the sense of multiple active routes to the same prefix each contributing one next-hop. A variation of this is NECMP where the next-hops are different weights. Another reason for multiple next-hops is fast re-route where the next-hops represent alternatives (the first one whose interface is up is used). Another needed generalization of next-hops is the ability to push and pop MPLS labels, VLAN tags, etc. Another is the ability to add a level of indirection (e.g. BGP indirect next-hop for fast BGP reconvergence). The OpenFlow 1.x documents are a good source to look for generalized next-hop examples. 2) Generalize the concept of a prefix Section 4.2 says that the core routing data model only defines the following minimal set of route attributes: destination-prefix, next-hop, outgoing-interface. However, in section 4 there are no destination-prefix or next-hop. There are only v4ur:dest-prefix, v4ur:next-hop, v6ur:dest-prefix, v6ur:next-hop. It appears that the destination-prefix and next-hop were removed from the base object and moved to the derived object. In my opinion, it would make sense to move the destination-prefix (as a simple bit-string and length) and the next-hop back to the base object. The derived object could have a string object to contain the destination-prefix as a human-readable string (e.g. "10.0.0.0/8" for an IPv4 prefix). Furthermore, section 4.2 assumes that the routes are always IP routes (it uses repeatedly uses terms like "IP prefix"). The routes can be non-IP routes. For example, MPLS routes which are /20 exact matches on a label, or CLNS routes, or other protocols. Some VPLS implementations even use the "routing table" abstraction to represent Ethernet routes (as exact /48 routes on MAC addresses). 3) Static (and direct) routes for multiple routing tables. Figure 2 appears to imply that static and direct routes can only be inserted in the main routing table. Is it possible to install static routes in multiple additional routing tables? 4) More attributes for static routes. Configured static routes (routes in the pseudo routing-protocol "static") need more attributes (e.g. metric). 5) Add support for routing-instances. Allow the creation of multiple routing-instances (also known as VRFs) per logical-router. Allow interfaces to be assigned to routing-instances. Allow multiple instances of routing protocols, scoped by routing-instance. 6) Ability for a client to subscribe to RIB changes It would be very useful for a client to be able to subscribe to route table changes. (I am not a YANG expert and I don't know if such a thing is even possible in YANG.) In the subscription, the client could specify one or more routing tables in which it is interested and filter(s) to specify which subset of routes it is interested in. 7) More sophisticated filters Section 4.5 explicitly says that the core routing data model only defines a skeleton for filtering. It would be "good" for the working group to continue this work and define more sophisticated filtering mechanisms. -- Bruno PS: Cross-post to the Interface to the Routing System (IRS) mailing list because they are discussing very similar functionality.
- [irs-discuss] A few comments on the draft-ietf-ne… Bruno Rijsman
- [irs-discuss] Comments on problem statement and f… Thomas Nadeau
- Re: [irs-discuss] A few comments on the draft-iet… Ladislav Lhotka