Re: [renum] New Version Notification for draft-jiang-6renum-enterprise-01.txt

Teco Boot <teco@inf-net.nl> Mon, 14 November 2011 01:41 UTC

Return-Path: <teco@inf-net.nl>
X-Original-To: renum@ietfa.amsl.com
Delivered-To: renum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E981B11E80DB for <renum@ietfa.amsl.com>; Sun, 13 Nov 2011 17:41:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RT12XVXzj-8 for <renum@ietfa.amsl.com>; Sun, 13 Nov 2011 17:41:22 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B2A6A11E80D7 for <renum@ietf.org>; Sun, 13 Nov 2011 17:41:21 -0800 (PST)
Received: by yenq4 with SMTP id q4so2787512yen.31 for <renum@ietf.org>; Sun, 13 Nov 2011 17:41:21 -0800 (PST)
Received: by 10.236.154.74 with SMTP id g50mr11280542yhk.72.1321234881324; Sun, 13 Nov 2011 17:41:21 -0800 (PST)
Received: from dhcp-13af.meeting.ietf.org (dhcp-13af.meeting.ietf.org. [130.129.19.175]) by mx.google.com with ESMTPS id l18sm27509501anb.22.2011.11.13.17.41.18 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Nov 2011 17:41:20 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="us-ascii"
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <4EC061A3.4050301@gmail.com>
Date: Mon, 14 Nov 2011 02:41:13 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C4032B38-8CD1-4D7B-AD65-935B48115788@inf-net.nl>
References: <8AE0F17B87264D4CAC7DE0AA6C406F450C41B0CA@szxeml509-mbs.china.huawei.com> <2527553C-D797-4CFC-AAA1-7D946C7910FF@inf-net.nl> <4EC061A3.4050301@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: "renum@ietf.org" <renum@ietf.org>
Subject: Re: [renum] New Version Notification for draft-jiang-6renum-enterprise-01.txt
X-BeenThere: renum@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Renumbering discussion mailing list." <renum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/renum>, <mailto:renum-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/renum>
List-Post: <mailto:renum@ietf.org>
List-Help: <mailto:renum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/renum>, <mailto:renum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Nov 2011 01:41:23 -0000

>> Page 11:
>>>>      - Border filtering
>>>>      In a multihomed site, an egress router to ISP A could normally
>>>>      filter packets with source addresses from other ISPs. The egress
>>>>      router connecting to ISP A should be notified if the egress router
>>>>      connecting to ISP B initiates a renumbering event in order to
>>>>      properly update its filter function.
>> 
>> I don't get this. Isn't ingress filtering recommended? Do ISP A and B coordinate? IMHO an ISP should block packets with other ISPs PA addresses.
>> So the network has to forward packets with ISP_A source addresses to ISP_A, not ISP_B. And forward packets with ISP_B source addresses to ISP_B, not ISP_A.
>> 
> 
> I think the text you quote is confused; it is not the enterprise's egress
> routers that do the filtering, but the ISPs' ingress routers.
> 
> Then there's another discussion. A large enterprise running multiple PA prefixes
> would surely tell *all* its ISPs about those prefixes, and expect them to
> relax their ingress filters accordingly. A small enterprise probably couldn't
> do that, so needs two things:
> 
> 1. Address pair selection in the hosts that avoids this problem.
> 2. Egress router selection based on source address.
> 
> In any case the renumbering issue is how to inform all your ISPs of the
> new prefix to be allowed in their ingress filters, and the old prefix
> that is now to be blocked.

I don't see ISPs relax the PA ingress filters. I say routing shall better support multi-homing, it is needed for small enterprises (point 2 above). Large enterprises may have many PA prefixes, so needed there also.

RFC 3704 section 4.3 describes some options for directing packets to the correct ISP. It says "This is not a complicated procedure", but the approach looks clumsy to me. The problem should be tackled at the root, a fix in routing. Get this into gap-analysis document?

PS1: On solutions, not to mention BRDP-based routing: check draft-baker-fun-routing-class.
PS2: I understand it will take some time before this is fixed. But that is no excuse to postpone.

Teco.