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

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

Hi, Shree

 

The following is the reply of the questions on the clarification against my
I.D.:

 

[Shree]  .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.

 

If we agreed the necessary of route aggregation on PE, then the question is
how to transfer the information about prefix pool from the Server to the
relay agent even in the possible way employing ANCP. But I believe the best
way to solve this question (or problem) is DHCPv6 itself.

 

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

 

Though there is no direct feedback from Relay Agent to Server, the DHCPv6
message exchange do provide reliability mechanism, such as the Section 14,
'Reliability of Client Initiated Message Exchange', and section 19.1.2,
'Time Out and Retransmission of Reconfiguration Messages' of RFC 3315.

 

It can be concluded the Relay Agent got the correct information about prefix
pool after the CE (requesting router in PD) got the correct prefix from the
server (delegating router in PD) through DHCPv6 process.

 

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

 

Per my I.D., ORO for the prefix pool can be included in the Relay-Forward
message by Relay Agent. Per the section 20.1, section 7.1 & section 22.10 of
RFC3315, the message from the client (including Solicit message with Rapid
Commit Option) will be encapsulated in the Relay Message Option of
Relay-Forward message. ORO inserted by RA here has no impact on the message
exchange between client & server.

 

Per the section 12.1 of RFC3633, Decline message is not used with DHCPv6-PD.

 

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

 

Same answer as the above question. Per the section 12.1 of RFC3633, Decline
message is not used with DHCPv6-PD.

 

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

 

Since PE acts as a Relay Agent in the Fig.1 of my I.D., the server can not
send the Reconfigure message directly to the client, the server uses a
Relay-reply message of RECONFIGURE (10).

 

By the way, will you attend the DHC WG session of IETF79, Thursday
afternoon, Beijing? If you were there, we could have a face-to-face
discussion on my I.D.

 

 

Best  Regards,

Leaf

 

 

From: JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)
[mailto:[e-mail]] 
Sent: Tuesday, October 26, 2010 8:49 PM
To: Tina Tsou; [e-mail]
Cc: [e-mail]
Subject: RE: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent

 

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: [e-mail] [mailto:[e-mail]] On Behalf Of
Tina Tsou
Sent: Thursday, October 14, 2010 3:02 AM
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