Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent - Sent @ 3rd

"Leaf Y. Yeh" <leaf.y.yeh@huawei.com> Tue, 26 October 2010 16:03 UTC

Return-Path: <leaf.y.yeh@huawei.com>
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86EFE3A6958 for <dhcwg@core3.amsl.com>; Tue, 26 Oct 2010 09:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eVUUN45epSF for <dhcwg@core3.amsl.com>; Tue, 26 Oct 2010 09:03:29 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1D8EA3A6888 for <dhcwg@ietf.org>; Tue, 26 Oct 2010 09:03:28 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAW000TYNCEV3@szxga04-in.huawei.com> for dhcwg@ietf.org; Wed, 27 Oct 2010 00:05:03 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAW00FV8NCE4N@szxga04-in.huawei.com> for dhcwg@ietf.org; Wed, 27 Oct 2010 00:05:02 +0800 (CST)
Received: from lst9242355d22a ([183.15.104.227]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAW00DNENCEHY@szxml02-in.huawei.com>; Wed, 27 Oct 2010 00:05:02 +0800 (CST)
Date: Wed, 27 Oct 2010 00:05:02 +0800
From: "Leaf Y. Yeh" <leaf.y.yeh@huawei.com>
In-reply-to: <2EAEDFB5-B79F-401C-8EC1-857E0EB38717@nominum.com>
To: 'Ted Lemon' <Ted.Lemon@nominum.com>
Message-id: <00c201cb7527$8cc50e90$a64f2bb0$%y.yeh@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset="us-ascii"
Content-language: zh-cn
Content-transfer-encoding: 7bit
Thread-index: Act0XwtFqU7oApRfSA644uNpJCSeZgAvNJPQ
References: <173C2922115645EFAD0E98234686E27A@china.huawei.com> <00b601cb741f$eeec68b0$ccc53a10$%y.yeh@huawei.com> <E158B569-804C-4CCB-A293-E5B2CE6BAE03@employees.org> <00cf01cb7429$f33e5220$d9baf660$%y.yeh@huawei.com> <E6DFEE68-170B-4B00-8EDD-EDC2506DD473@nominum.com> <E8664DEA-F8DA-46C3-9D57-DF4B2BA85BDC@employees.org> <4556E9C9-1B98-4FD8-B60A-96DB2E49816E@nominum.com> <65BF1A85-6470-478C-A855-E4F7B438F633@employees.org> <2EAEDFB5-B79F-401C-8EC1-857E0EB38717@nominum.com>
Cc: dhcwg@ietf.org, volz@cisco.com
Subject: Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent - Sent @ 3rd
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Oct 2010 16:03:32 -0000

Hi, Ted

Ole- the prefix pool option would only get you the aggregate. the router
would still need the more specifics per IA_PD routes.
Ted- Hm, are you sure about that? I will admit that I haven't read the draft
closely either yet, but I thought the relay option contained the information
needed. If the relay option is aggregating routes for more than one client,
that would be a problem.

Ole is right. Either the PE router implementing server or the PE router
implementing relay does still need the routes pointing to each of the
customer network in its routing table. The aggregation route generated on
the PE router covers all the prefixes delegated to customer routers (CPE, PD
requesting router, routed-RG). When advertised by the routing protocol in
the ISP core network, the aggregation route dramatically decreases the route
entries in the routing table of ISP core routers. This is the purpose why
the draft introduced a new mechanism & DHCPv6 option.

FYI - BBF WT-177 Rev.16 Section 6.2 'Routing Table Functions' of 'BNG
requirements'

*R-20	When the BNG, acting as a DHCPv6 Relay Agent, receives a downstream
Relay-Reply message containing a Reply message including an IA_PD option, it
MUST add a route (allocated IPv6 prefix contained in the IA_PD, next hop
contained in the peer-address field) to the relevant BNG routing table
*R-21	When the DHCPv6 Relay Agent implemented in a BNG receives an
upstream Release message (or a Relay-Forward message containing a Release
message) including an IA_PD option, it MUST delete the route corresponding
to the delegated prefix(es) indicated in this option.

R-22	When the lease related to a delegated prefix expires, the BNG MUST
remove the corresponding route from the BNG routing table.

*R-26	When the DHCPv6 server implemented in a BNG sends a downstream
DHCPv6 Reply message including an IA_PD option, it MUST add a route
(allocated IPv6 prefix contained in the IA_PD, next hop contained in the
destination address of the DHCPv6 Reply) to the relevant BNG routing table.
*R-27	When the DHCPv6 server implemented in a BNG receives an upstream
Release message (or a Relay-Forward message containing a Release message)
including an IA_PD option, it MUST delete the route corresponding to the
delegated prefix(es) indicated in this option.

The above requirements of BNG (BRAS, PE) sounds to needs the technical
support from DHCPv6 Snooping or the alternative RAAN option, but they are
all talking about the processing of the PD prefix pointing to the customer
network, not yet about the prefix pool discussed in the draft
(http://datatracker.ietf.org/doc/draft-yeh-dhc-dhcpv6-prefix-pool-opt/ ).


Best Regards,
Leaf



-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com] 
Sent: Tuesday, October 26, 2010 12:10 AM
To: Ole Troan
Cc: Leaf Y.Yeh; dhcwg@ietf.org; volz@cisco.com
Subject: Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent - Sent @ 3rd

On Oct 25, 2010, at 12:00 PM, Ole Troan wrote:
> no, it wouldn't. the prefix pool option would only get you the aggregate.
the router would still need the more specifics per IA_PD routes.

Hm, are you sure about that?   I will admit that I haven't read the draft
closely either yet, but I thought the relay option contained the information
needed.   If the relay option is aggregating routes for more than one
client, that would be a problem.

> correct! ;-)
> (this is done when the box is provisioned though, and certainly not
something you'd do every day).

I think that depends on the environment.   In some cases obviously stability
is important, but in the case of something like a mobile phone, I get the
impression that these delegations would be fairly temporary.

> yes, agree. even though as stated above, you would still need to snoop for
the more specifics.

When we were talking about RAAN, one of the motivations was to avoid
snooping.   It would be relatively easy to have the relay option contain the
actual delegation as well as the enclosing prefix, if that were desired.