IETF Logo Mail Archive

Re: [i2rs] Rtgdir early review of draft-ietf-i2rs-rib-info-model-11

"Susan Hares" <shares@ndzh.com> Tue, 01 August 2017 14:16 UTC

Return-Path: <shares@ndzh.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 336D41275F4; Tue, 1 Aug 2017 07:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.945
X-Spam-Level:
X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no
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 TcCR9OPDdo-0; Tue, 1 Aug 2017 07:16:48 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 A9E1D12711B; Tue, 1 Aug 2017 07:16:44 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.10.26;
From: Susan Hares <shares@ndzh.com>
To: 'Jonathan Hardwick' <jonathan.hardwick@metaswitch.com>, rtg-dir@ietf.org
Cc: i2rs@ietf.org, ietf@ietf.org, draft-ietf-i2rs-rib-info-model.all@ietf.org
References: <150157551332.9546.17310175858783211646@ietfa.amsl.com>
In-Reply-To: <150157551332.9546.17310175858783211646@ietfa.amsl.com>
Date: Tue, 01 Aug 2017 10:10:31 -0400
Message-ID: <007801d30acf$f04d9280$d0e8b780$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQE7A5ElB5TCjRQ2QeiC25IY4N7z2KOfmK1A
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/SvrZ9Eyy53rRwQprXFMavCXulUw>
Subject: Re: [i2rs] Rtgdir early review of draft-ietf-i2rs-rib-info-model-11
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: Tue, 01 Aug 2017 14:16:49 -0000

Jonathan: 

Please thank Henning for his review. 

Sue Hares 

-----Original Message-----
From: Jonathan Hardwick [mailto:jonathan.hardwick@metaswitch.com] 
Sent: Tuesday, August 1, 2017 4:19 AM
To: rtg-dir@ietf.org
Cc: i2rs@ietf.org; ietf@ietf.org; draft-ietf-i2rs-rib-info-model.all@ietf.org
Subject: Rtgdir early review of draft-ietf-i2rs-rib-info-model-11

Reviewer: Henning Rogge
Review result: Has Nits

Submitting on behalf of Henning Rogge:

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

v2.23.0 | Report a Bug | By Email