Subject: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent

From: Tina Tsou <[email-masked]>
Date: Wed, 13 Oct 2010 14:32:22 -0700

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

---

From: Maglione Roberta <[email-masked]>
Date: Thu, 14 Oct 2010 09:51:45 +0200

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,

Abstract

Best Regards,
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.

---

From: "Leaf Y. Yeh" <[email-masked]>
Date: Fri, 15 Oct 2010 17:14:20 +0800

Hi, Roberta

The design goal & usage of RAAN (Assignment Notification) option are quite
different with those of Prefix Pool option.
 
* 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?

* 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,
 
Abstract

Best Regards,
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.

---

From: "Leaf Y. Yeh" <[email-masked]>
Date: Fri, 15 Oct 2010 17:51:54 +0800

Hi, Roberta

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.

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.

 

Best Regards,

Leaf Yeh

Hi Tina,

What’s the difference between the new option you are proposing in this draft
and the RAAN option specified in

Thanks

Regards,

Roberta

  _____  

Hi all,

Abstract

   before the aggregation.

 

Best Regards,

Tina TSOU

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 15 Oct 2010 22:56:04 -0500

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,

Thanks

Regards,

Roberta

Hi all,

Abstract

   before the aggregation.

 

Best Regards,

Tina TSOU

---

From: Maglione Roberta <[email-masked]>
Date: Mon, 18 Oct 2010 13:47:50 +0200

Thanks for your answer; in my opinion it would be useful to clarify this point in the document.

Best regards,
Roberta

-----Original Message-----
From: Leaf Y. Yeh [mailto:[email-masked]]
Sent: venerdì 15 ottobre 2010 11.14
To: Maglione Roberta; [email-masked]
Subject: RE: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent - Sent again

Hi, Roberta

Best Regards,

Leaf Yeh

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

Hi all,

Abstract

Best Regards,
Tina TSOU

---

From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <[email-masked]>
Date: Tue, 26 Oct 2010 18:18:58 +0530

Leaf,

I have following comments

1.    Additional processing requirements on Relay & Server

As others have pointed out it might be more efficient to use a out of band protocol like ANCP to configure the aggregation information, rather than having to tag it on dhcp transactions

and increase the processing required on dhcp servers & relays.

2.    Server maintaining the Prefix Pool states might not be sufficient,

[Shree] Since there is no feedback mechanism from relay agent, if the dhcp messages sent by server are lost or missed by Relay agent

e.g. if the relay is down or unreachable during RECONFIGURE.

The Server and Relay agent will be out of sync w.r.t. prefixes.
As a safety measure relay should use lease expiry time or server message (whichever is earlier to expire the prefixes).

3.    Section 5 . Relay Agent Behavior

        The Relay Agent may include the ORO for Prefix Pool Option

in the relay-forward (12) message of SOLICIT (1), REQUEST (3), RENEW

(5), REBIND (6) and RELEASE (8).

[Shree] ORO MUST be included with SOLICIT requests having RAPID COMMIT option, as there may not be a follow on  REQUEST message to add the ORO option and prefix pool might not be learned.
           ORO may also be included in DECLINE.

Section 6 . Server Behavior

               On the other hand, if the prefix of the customer network associated

   to the IA_PD option in the relay-forward message of RELEASE is the

   last releasing prefix within the associated prefix pool, the Server

   (delegating router) shall turn the status of the associated prefix

   pool to be 'Released'.

[Shree] Text should be added to handle DECLINE from client. In case of DECLINE the server should mark the Prefix as 'Released' in Reply.

When the status of prefix pool is reset by manual configuration, the

   Server shall initiate the relay-reply message of RECONFIGURE (10), if

   there is at least one prefix indicated to be valid within the

   associated prefix pool on the Server.

 [Shree] As per RFC 3315 server initiates a relay-reply only when client cannot be directly reached by an unicast address. This behavior is changed with the draft.

If the server does not have an address to which it can
send the Reconfigure message directly to the client, the server uses
a Relay-reply message

--
Shree

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tina Tsou
Sent: Thursday, October 14, 2010 3:02 AM
To: [email-masked]
Subject: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent

Hi all,

Abstract

Best Regards,
Tina TSOU