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

"Leaf Y. Yeh" <leaf.y.yeh@huawei.com> Mon, 25 October 2010 09:48 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 D160D3A699C for <dhcwg@core3.amsl.com>; Mon, 25 Oct 2010 02:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.216
X-Spam-Level:
X-Spam-Status: No, score=0.216 tagged_above=-999 required=5 tests=[AWL=0.711, 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 x1aN7gs4Dt5r for <dhcwg@core3.amsl.com>; Mon, 25 Oct 2010 02:48:53 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 179A03A681E for <dhcwg@ietf.org>; Mon, 25 Oct 2010 02:48:53 -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 <0LAU00LFHBAZXN@szxga04-in.huawei.com> for dhcwg@ietf.org; Mon, 25 Oct 2010 17:49:47 +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 <0LAU00DVIBAYT2@szxga04-in.huawei.com> for dhcwg@ietf.org; Mon, 25 Oct 2010 17:49:46 +0800 (CST)
Received: from y00168393 ([10.70.39.77]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAU00KXGBAVZF@szxml04-in.huawei.com> for dhcwg@ietf.org; Mon, 25 Oct 2010 17:49:46 +0800 (CST)
Date: Mon, 25 Oct 2010 17:49:43 +0800
From: "Leaf Y. Yeh" <leaf.y.yeh@huawei.com>
In-reply-to: <E158B569-804C-4CCB-A293-E5B2CE6BAE03@employees.org>
To: 'Ole Troan' <otroan@employees.org>, dhcwg@ietf.org
Message-id: <00cf01cb7429$f33e5220$d9baf660$%y.yeh@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset="ISO-8859-1"
Content-language: zh-cn
Content-transfer-encoding: quoted-printable
Thread-index: Act0IZ+Qcf98s9f8TuOYk+MIDXcKxQAAQlvA
References: <173C2922115645EFAD0E98234686E27A@china.huawei.com> <00b601cb741f$eeec68b0$ccc53a10$%y.yeh@huawei.com> <E158B569-804C-4CCB-A293-E5B2CE6BAE03@employees.org>
Cc: 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: Mon, 25 Oct 2010 09:48:54 -0000

Hi, Ole

Ole- so it is one thing that a relay snoops DHCP traffic between client and
server, 

Per the section 6.2 'Routing table function' of 'Broadband Network Gateway
Requirements' in BBF WT-177, RA does snoop the DHCPv6 message between client
and server for the adding & deleting the route entry pointing to the
customer network in its routing table.

Ole- but it is another when the DHCP protocol is used to provision the
intermediate device. is this something we really want DHCP to do?

Yes, we can. We can let DHCPv6 use for some kind of provision (or stateful
configuration) for the RA besides for the clients. Right?

Best Regards,
Leaf


-----Original Message-----
From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan
Sent: Monday, October 25, 2010 4:48 PM
To: Leaf Y. Yeh
Cc: volz@cisco.com; dhcwg@ietf.org
Subject: Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent - Sent @ 3rd

so it is one thing that a relay snoops DHCP traffic between client and
server, but it is another when the DHCP protocol is used to provision the
intermediate device.

is this something we really want DHCP to do?

cheers,
Ole


On Oct 25, 2010, at 10:38 , Leaf Y. Yeh wrote:

> Hi, Bernie
>  
> Bernie – So, if the DHCPv6 server is allocating addresses from a /40 to
the CPEs (which may be getting /56), the Prefix Pool option would contain
the /40 prefix so that the Relay would advertise the /40 instead of just
each of the /56 prefixes actually assigned to the CPEs?
>  
> That’s right. 
>  
> Bernie – You might want to include an example such as this in the draft to
make it clear.
>  
> I got a new Fig.1 in my I.D.-01 (pls. refer to
http://datatracker.ietf.org/doc/draft-yeh-dhc-dhcpv6-prefix-pool-opt/ ) to
make a little bit more clarification on it.
>  
> For example:
> a.      Binding entry @ server is :  pe#1_cfi#2 < - > 3ffe:ffff:0::/40
> b.     Client-facing interface @ PE implementing RA :  interface_id=
pe#1_cfi#2;  prefix pool= 3ffe:ffff:1200::/40
> c.      Prefix got through DHCPv6-PD @ CE :  customer network=
3ffe:ffff:1234:5600:/56
>  
> Bernie – This does assume that there is only one relay being allocated
prefixes from this /40 pool? That’s probably why there’s the text about
Interface-Id option.
>  
> The relay agent (RA) described in my I.D. is always implemented on the
Provide Edge router (PE, BRAS, or BNG). If we look into the access network
architecture defined in Broadband Forum (BBF) WT-177(or TR-101), one more
Lightweight DHCPv6 Relay Agent (LDRA) (pls. refer to
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-ldra/ ) is always
implemented in the Access Node (AN), which acts as a link-layer bridge
between Customer Router  (CPE, CE, or Routed-RG) and PE. The Interface ID
option inserted by AN is used by the server to identified the subscriber
line to which the prefix of the customer network (eg. /56) is delegated,
while the Interface ID option inserted by PE implementing RA described in my
I.D. is used by the server to identified to client-facing interface of PE
where the prefix pool (eg. /40) is located or configured.
>  
>  
> Best Regards,
> Leaf Yeh
>  
>  
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of
Bernie Volz (volz)
> Sent: Saturday, October 16, 2010 11:56 AM
> To: Leaf Y. Yeh; dhcwg@ietf.org
> Subject: Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent - Sent @
3rd
> 
> So, if the DHCPv6 server is allocating addresses from a /40 to the CPEs
(which may be getting /56), the Prefix Pool option would contain the /40
prefix so that the Relay would advertise the /40 instead of just each of the
/56 prefixes actually assigned to the CPEs? You might want to include an
example such as this in the draft to make it clear. When I first read it, I
thought it was similar to the RAAN option too.
>  
> This does assume that there is only one relay being allocated prefixes
from this /40 pool? That’s probably why there’s the text about Interface-Id
option.
>  
> -          Bernie
>  
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of
Leaf Y. Yeh
> Sent: Friday, October 15, 2010 5:52 AM
> To: dhcwg@ietf.org
> Subject: Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent - Sent @
3rd
>  
> Hi, Roberta
>  
> The design goal & usage of RAAN (Assignment Notification) option are quite
different with those of Prefix Pool option.
>  
> l  RAAN option specified in draft-ietf-dhc-dhcpv6-agentopt-delegate-04, is
sent by the DHCPv6 server to inform the RA (Relay Agent) of the IPv6
prefixes & the IPv6 addresses that have been assigned to the DHCPv6 client
by the server.
>  
> Because RA can directly get the information about the address assigned &
the prefixes delegated from the messages relayed through RA, it sounds not
be necessary to use the Assignment Notification option to get these
information.
>  
> Is this a reason why DHC WG let the
I.D.-draft-ietf-dhc-dhcpv6-agentopt-delegate-04 expire?
>  
> l  Prefix_Pool_Option defined in draft-yeh-dhc-dhcpv6-prefix-pool-opt, is
sent by the DHCPv6 server to inform the RA of the IPv6 prefix pool from
which the prefix of the customer network is got to delegate.
>  
> The information about the Prefix Pools can be used to generate the
aggregation (black-hole) route entries in the routing table on RA, which is
regarded as a necessary (or strongly recommended) action on the PE router in
the new draft.
>  
> The information about the Prefix Pools is always maintain on the server,
so we need a new mechanism of Prefix_Pool_Option to transfer these
information from the server to RA.
>  
>  
> Best Regards,
>  
> Leaf Yeh
>  
>  
>  
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of
Maglione Roberta
> Sent: Thursday, October 14, 2010 3:52 PM
> To: Tina Tsou; dhcwg@ietf.org
> Subject: Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent
>  
> Hi Tina,
> What’s the difference between the new option you are proposing in this
draft and the RAAN option specified in
> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-delegate-04 ?
>  
> Thanks
> Regards,
> Roberta
>  
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of
Tina Tsou
> Sent: mercoledì 13 ottobre 2010 23.32
> To: dhcwg@ietf.org
> Subject: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent
>  
> Hi all,
> http://datatracker.ietf.org/doc/draft-yeh-dhc-dhcpv6-prefix-pool-opt/
> talks about Prefix Pool Option for DHCPv6 Relay Agent.
>  
> Abstract
>  
>    The Prefix Pool option provides an automatic mechanism for the
>    information exchange between DHCPv6 server and DHCPv6 Relay Agent.
>    The information about Prefix Pools maintained on DHCPv6 server can be
>    transferred from server to relay agent through this DHCPv6 option to
>    support the necessary route aggregation on the provide edge router,
>    which has a huge number of routes pointing to the customer networks
>    before the aggregation.
>  
> Your comments are welcome.
>  
>  
> Best Regards,
> Tina TSOU
> http://tinatsou.weebly.com/contact.html
>  
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione derivante
dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione, Grazie.
> This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the
sender by return e-mail, Thanks.
> 
> <image001.gif>Rispetta l'ambiente. Non stampare questa mail se non è
necessario.
>  
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg