Re: [v6ops] Fwd: New Version Notification for draft-ietf-dhc-pd-exclude-04.txt

Lorenzo Colitti <lorenzo@google.com> Tue, 20 December 2011 19:29 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3481921F8A69 for <v6ops@ietfa.amsl.com>; Tue, 20 Dec 2011 11:29:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level:
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 tZKrZsXGHkz2 for <v6ops@ietfa.amsl.com>; Tue, 20 Dec 2011 11:29:07 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A461821F8508 for <v6ops@ietf.org>; Tue, 20 Dec 2011 11:29:07 -0800 (PST)
Received: by obcuz6 with SMTP id uz6so2962991obc.31 for <v6ops@ietf.org>; Tue, 20 Dec 2011 11:29:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=PkRqSZQtLAJvr2TT04vRBQTImlaCDgkai2YnzcwU//8=; b=C/wR9ZtUYYAeWNY6SoViwfyh3tpOg6RDXO6VhMUXioain1oNDy54LrCr6jZX3+TVOp abfg2UKPGpZhSJGl1crA==
Received: by 10.182.113.71 with SMTP id iw7mr2912132obb.68.1324409347301; Tue, 20 Dec 2011 11:29:07 -0800 (PST)
Received: by 10.182.113.71 with SMTP id iw7mr2912117obb.68.1324409347179; Tue, 20 Dec 2011 11:29:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.0.11 with HTTP; Tue, 20 Dec 2011 11:28:46 -0800 (PST)
In-Reply-To: <422FF86C-4C27-4C0A-9A5B-F445766220DD@gmail.com>
References: <20111220073924.5093.19864.idtracker@ietfa.amsl.com> <422FF86C-4C27-4C0A-9A5B-F445766220DD@gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 20 Dec 2011 11:28:46 -0800
Message-ID: <CAKD1Yr1vLU4dCX6EgEGSv-WV7b+JJOevvekF_2S1RTh=SPDfpg@mail.gmail.com>
To: jouni korhonen <jouni.nospam@gmail.com>
X-System-Of-Record: true
Content-Type: multipart/alternative; boundary="f46d0447f3c6ad046204b48b146d"
Cc: "v6ops@ietf.org Operations" <v6ops@ietf.org>
Subject: Re: [v6ops] Fwd: New Version Notification for draft-ietf-dhc-pd-exclude-04.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2011 19:29:08 -0000

On Mon, Dec 19, 2011 at 23:49, jouni korhonen <jouni.nospam@gmail.com>wrote:

> We added the applicability statement into the Introduction, which now
> states the pd-exclude is intended for deployments where CEs are on their
> own layer 2 domain. This should clear your concern on 'multicast RAs".
>

As discussed already, I have two objections to this on the grounds that it
needlessly complicates implementations.

First, I object to the text that says "The requesting router must create
sink routes for the delegated prefixes minus the excluded prefixes." This
is complex to implement properly.

I think it should say: "The requesting router must create sink routes for
the entire delegated prefix. If it is desired that the requesting router
route the excluded prefix in any other way, this MUST be configured to do
so via other means (for example, via a Router Advertisement containing a
Prefix Information Option for the excluded prefix and the on-link bit set).

Second, I think the draft should make it clear that only one prefix can be
excluded per delegated prefix, and that if the RR receives (at any time),
another OPTION_IAPREFIX option for the same prefix with different excluded
prefixes, then the RR is free to ignore the previous excluded prefix.