[i2rs] rtgdir Early Review of draft-ietf-i2rs-rib-model

Henning Rogge <hrogge@gmail.com> Mon, 31 July 2017 13:43 UTC

Return-Path: <hrogge@gmail.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738361275FD; Mon, 31 Jul 2017 06:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HlctbT9SfQS0; Mon, 31 Jul 2017 06:43:43 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D0FE1322DC; Mon, 31 Jul 2017 06:43:43 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id s6so118010867qtc.1; Mon, 31 Jul 2017 06:43:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ROVMjYWjj7yCCVhzFLIkCjiQIgAw34Otem2/3a4c17A=; b=IuEq1aIPwsbLeGDgDK/HzIhqWUemBtVw5If2N/C3r1xnbKVvi/9FCT4CnemUV7hxve 8EJbk4fttUUsYAFi802sqy+akOpPZx686PM31VpMiDSdwjdr9F5FTTEbwA8xeoiMMniN 2p2aWQJWMV5mhmONIjKNAuEwXVQGytkwTB4XaH9Wt5ABBrCpdhFO36fa2Xk34rZW10+6 XBtUq8jOJfrd7laZ0fZchL9VtT1n5mAWZIEz2bzR9/Mv88ux557Ovy0tCNgR2rnpM7P+ doA9rZoWiBwsMHNLTHO5waoph593ik34GMmgSw2k/lvJ3afgnEFN8OSo2cEccXyemtvw IwpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ROVMjYWjj7yCCVhzFLIkCjiQIgAw34Otem2/3a4c17A=; b=AA051456LiTWhL+croWJkb97V8KpzFFq/2yBEyTp5pcDv76rnJ4gcJ5HKHNB+cjeZy 8Qq1Cd2fSmyBAgwKrXhJhBftaNRpui8toGWFFODs9wSWinvgICJPBPsD4/jNE5RKgu/9 iEX7XC/iMNNhiZf97lUs6LoVNJVVQUKpVwfMRJleMz3GSHUGwZuiprjHKMLfT9ZHcqc3 eojNbehwNDjzfKBLcprGJ07QLXgxEH58oTsWHnptC0eRI9J75I5LUz/7KY0kqifTSJCR DL6iss0/Rr1gj6nm0iCweccPluP4Yy85/dq4j4d37sirznVLU8vF90vs/5vQ96Ks/i+S Gtdg==
X-Gm-Message-State: AIVw110QUcnVVOtePLBhQP7HT5Oy5UIoBnIbW0a2h77w9/E5gLqcuZ3j 1XKzaaYlKfYBwjkzs5Twy+ynWGRRbpoG
X-Received: by 10.200.50.242 with SMTP id a47mr21525146qtb.91.1501508621966; Mon, 31 Jul 2017 06:43:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.55.98 with HTTP; Mon, 31 Jul 2017 06:43:11 -0700 (PDT)
From: Henning Rogge <hrogge@gmail.com>
Date: Mon, 31 Jul 2017 15:43:11 +0200
Message-ID: <CAGnRvuoswD5jqrsLV_mcCydWmZTHK3EiM8j-ROnX6Qg9mNLrkg@mail.gmail.com>
To: draft-ietf-i2rs-rib-info-model@ietf.org, Jonathan Hardwick <jonathan.hardwick@metaswitch.com>, Susan Hares <skh@ndzh.com>, i2rs@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/aAvaZHN1DpEN1u19ckVGo8-F5bk>
Subject: [i2rs] rtgdir Early Review of draft-ietf-i2rs-rib-model
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Jul 2017 13:43:44 -0000

Hi,

I was asked to do an early review of the i2rs-rib-info-model...

I liked the comprehensive approach describing the RIB, including
tunnels, multi-topology routing (by using multiple RIBs) and routing
reactions (like drop/icmp-error).

I found a few things in the draft that in my opinion need a bit more work...

First it seems that Section 2.3 (Route) is a bit out of sync with the
BNF later in the document, it should at least mention matching the
source-IP address of the IP headers.

Second (if I read the BNF in Section 6 correctly), the match for a
route seems to be one of the list "ip address, MPLS label, MAC
address, interface". I think it should be possible to combine
"interface" or "mac address" with an IP address to restrict the focus
of a route, e.g. "match fe80::1 from interface X".


Last, I wonder if multicast routing needs more different types of
matchers, e.g. a match on the TTL of the IP packet to limit the range
of a multicast group.

There is also problem of multicast routing in MANETs (see RFC 6621)
which can use a hash-based duplicate detection to determine if it
forwards or drops a multicast packet. Would this be out of scope for
the draft?

Henning Rogge