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

["Leaf Y. Yeh" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
Bernie Volz (volz)
Sent: Saturday, October 16, 2010 11:56 AM
To: Leaf Y. Yeh; [e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf Of
Leaf Y. Yeh
Sent: Friday, October 15, 2010 5:52 AM
To: [e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf Of
Maglione Roberta
Sent: Thursday, October 14, 2010 3:52 PM
To: Tina Tsou; [e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf Of
Tina Tsou
Sent: mercoledì 13 ottobre 2010 23.32
To: [e-mail]
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. 

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è
necessario.