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

From: "Leaf Y. Yeh" <[email-masked]>
Date: Mon, 25 Oct 2010 16:38:01 +0800

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

---

From: Ole Troan <[email-masked]>
Date: Mon, 25 Oct 2010 10:47:43 +0200

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:
> 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: [email-masked] [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
> 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: [email-masked] [mailto:[email-masked]] On Behalf Of Leaf Y. Yeh
> 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: [email-masked] [mailto:[email-masked]] On Behalf Of Maglione Roberta
> What’s the difference between the new option you are proposing in this draft and the RAAN option specified in
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tina Tsou
> 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'ambiente. Non stampare questa mail se non è necessario.
>  
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Leaf Y. Yeh" <[email-masked]>
Date: Mon, 25 Oct 2010 17:49:43 +0800

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:[email-masked]] On Behalf Of Ole Troan
Sent: Monday, October 25, 2010 4:48 PM
To: Leaf Y. Yeh
Cc: [email-masked]; [email-masked]
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.

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?
make it clear.
3ffe:ffff:1234:5600:/56
Bernie Volz (volz)
>  
> 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.
Leaf Y. Yeh
>  
> 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.
>  
> 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.
Maglione Roberta
Tina Tsou

---

From: Ole Troan <[email-masked]>
Date: Mon, 25 Oct 2010 12:05:30 +0200

> configuration) for the RA besides for the clients. Right?

that was what I wanted to hear the working group's opinion on...

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Oct 2010 09:55:48 -0400

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

Hm, to be clear here, the DHCP relay is not "snooping DHCP traffic."   It is receiving and processing DHCP traffic, some of which is already intended for it.   The only question is whether having the DHCP server distribute routing information to the relay is the right answer.   It's to that point that I was asking Ole if he had a better option in mind.

---

From: Ole Troan <[email-masked]>
Date: Mon, 25 Oct 2010 16:13:03 +0200

Ted,

> Hm, to be clear here, the DHCP relay is not "snooping DHCP traffic."   It is receiving and processing DHCP traffic, some of which is already intended for it.

come on it is! ;-)
the PD relay has to snoop on the IA_PD options to inject a route for the prefixes.
at least without the RAAN option.

>   The only question is whether having the DHCP server distribute routing information to the relay is the right answer.   It's to that point that I was asking Ole if he had a better option in mind.

so is the prefix pool option going to be included in every client - server exchange?
in that case that would be a lot of duplicate information (prefix pool option would be the same for every exchange that has an IA_PD that it is an aggregate for).

or would it only be sent once to the relay? if so, I didn't think we had a message type for that?

for alternatives; management application / manual configuration is the state of the art... ANCP perhaps?

having a way of provisioning the relay is neat, I'm just a little concerned how well this fits into the DHCP model. especially if this isn't triggered by a client exchange.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Oct 2010 11:37:10 -0400

> at least without the RAAN option.

Yes, that's right, that's what it's doing now.   This draft gets us away from that, though, which seems like a win to me.

> in that case that would be a lot of duplicate information (prefix pool option would be the same for every exchange that has an IA_PD that it is an aggregate for).

How often do you expect these exchanges to happen?   Given that an exchange is always happening between the client and the server anyway, do you think that it's disadvantageous to add an extra twenty or so bytes to the message to accomplish this purpose?

> or would it only be sent once to the relay? if so, I didn't think we had a message type for that?

That would be a big change to the protocol, and probably not a good solution.

> for alternatives; management application / manual configuration is the state of the art... ANCP perhaps?

So in other words, you don't have an alternative proposal.   :)

> having a way of provisioning the relay is neat, I'm just a little concerned how well this fits into the DHCP model. especially if this isn't triggered by a client exchange.

I think it fits fine.   I'm having trouble figuring out what's leading you to think it might not--if it's the question of an extra exchange, that's not what the current draft seems to be saying, and it's certainly not how I'd do it.   Since the PD exchange is basically about getting a a prefix route, it seems appropriate that information about how to route that prefix would be conveyed to the relay agent at the same time.

---

From: Ole Troan <[email-masked]>
Date: Mon, 25 Oct 2010 18:00:11 +0200

Ted,

> Yes, that's right, that's what it's doing now.   This draft gets us away from that, though, which seems like a win to me.

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.

> How often do you expect these exchanges to happen?   Given that an exchange is always happening between the client and the server anyway, do you think that it's disadvantageous to add an extra twen…

OK, cool. I had gotten myself into thinking that this would be server to relay signaling, without client exchange.

> That would be a big change to the protocol, and probably not a good solution.

indeed, that was what I thought was proposed. guess, I should really read the draft. ;-)

> So in other words, you don't have an alternative proposal.   :)

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

> I think it fits fine.   I'm having trouble figuring out what's leading you to think it might not--if it's the question of an extra exchange, that's not what the current draft seems to be saying, an…

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

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Oct 2010 12:09:34 -0400

> 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.

> (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.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 25 Oct 2010 20:45:21 -0500

This is really very similar to the RAAN
(http://tools.ietf.org/id/draft-ietf-dhc-dhcpv6-agentopt-delegate-04.txt
) work that the DHC WG was working on a while back and stalled. One of
the reasons it stalled was a issue raised by Thomas Narten ... I don't
recall all of the specifics, but I think it had to do with out of order
packets which could end up communicating the wrong information (adding
information after it should have been removed, or vice versa). But I may
be remembering incorrectly - I think I sent an email to the DHC WG
mailing list describing the issue (or Thomas did). This is also an issue
with snooping ... and the SRSN option
(http://tools.ietf.org/id/draft-ietf-dhc-dhcpv6-srsn-option-02.txt) was
there to address some of these issues -- I do vaguely recall Thomas
coming up with another problem that even SRSN didn't solve, but I could
be mis-remembering.

As snooping isn't a DHC WG work item, what exactly various
implementation do to prevent the out-of-ordering issue (which admittedly
isn't very likely but *is* possible) isn't an DHC WG issue.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Monday, October 25, 2010 12:10 PM
To: Ole Troan
Cc: Leaf Y.Yeh; [email-masked]; Bernie Volz (volz)
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.

> (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.

---

From: "Leaf Y. Yeh" <[email-masked]>
Date: Tue, 26 Oct 2010 19:05:53 +0800

Hi, Ted

As mentioned in the draft, Prefix Pools are usually maintained on the
Server. We do need a mechanism to transfer the information about these
prefix pools from server to relay located on the PE in the scenario for the
setup of the necessary aggregation routes. The draft proposed a mechanism
within the scope of DHCPv6 while using the new defined option.

Best Regards,
Leaf

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Monday, October 25, 2010 9:56 PM
To: Leaf Y.Yeh
Cc: 'Ole Troan'; [email-masked]; [email-masked]
Subject: Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent - Sent @ 3rd

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

Hm, to be clear here, the DHCP relay is not "snooping DHCP traffic."   It is
receiving and processing DHCP traffic, some of which is already intended for
it.   The only question is whether having the DHCP server distribute routing
information to the relay is the right answer.   It's to that point that I
was asking Ole if he had a better option in mind.

---

From: "Leaf Y. Yeh" <[email-masked]>
Date: Wed, 27 Oct 2010 00:05:02 +0800

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:[email-masked]] 
Sent: Tuesday, October 26, 2010 12:10 AM
To: Ole Troan
Cc: Leaf Y.Yeh; [email-masked]; [email-masked]
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.

> (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.

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.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Oct 2010 12:48:32 -0400

On Oct 25, 2010, at 9:45 PM, Bernie Volz (volz) wrote:
> One of
> information after it should have been removed, or vice versa).

The issue Thomas raised was an edge case where you could get a minor transient failure  if a packet arrived out of order.   The problem was self-healing, and also unlikely.   Ralph and I talked about this off and on for a while and concluded that the amount of effort required to prevent the problem was simply out of proportion to the problem we were concerned about, and that it really wasn't necessary.

The reason RAAN never proceeded further was that Ralph was no longer an advocate for it, and we didn't have a new proponent.   It wasn't that it was a bad idea from a technical perspective.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 26 Oct 2010 12:29:39 -0500

Ted:

I agree that Thomas' case was unlikely to occur; not sure about the
self-healing (it would eventually heal when T1 expired or the subscriber
took some action, but that could be hours or days later).

RAAN kind of died because it was taking so long and a solution was
needed and so those that needed the solution started snooping (for
addresses at first, as was already being done for IPv4). At least in my
mind, RAAN wasn't ever a "MUST" have - it was just a nice to have
because it avoided the need for snooping and allowed some additional
flexibility as to what is told to relay could be slightly be different
than what was told to the client.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Tuesday, October 26, 2010 12:49 PM
To: Bernie Volz (volz)
Cc: Ole Troan; Leaf Y.Yeh; [email-masked]
Subject: Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent - Sent @
3rd

> information after it should have been removed, or vice versa).

The issue Thomas raised was an edge case where you could get a minor
transient failure  if a packet arrived out of order.   The problem was
self-healing, and also unlikely.   Ralph and I talked about this off and
on for a while and concluded that the amount of effort required to
prevent the problem was simply out of proportion to the problem we were
concerned about, and that it really wasn't necessary.

The reason RAAN never proceeded further was that Ralph was no longer an
advocate for it, and we didn't have a new proponent.   It wasn't that it
was a bad idea from a technical perspective.