[dhcwg] Regarding Extension of Leasequery draft

["pavan_kurapati" <[e-mail]>]

Hi,

There were some issues raised during the last WG meet regarding this draft(www.ietf.org/internet-drafts/draft-joshi-dhcp-lease-query-ext-02.txt) and it was decided to take it to the mailing list. We have discussed some of these issues offline with those who have raised these during WG meeting. I am listing the discussions with clarifications.

1. Is this draft related to only DSL technology?

No. Our draft applies to any Layer 2 Access Networks for example, xPON, Wimax, EFM etc.

2. DSL Forum has suggested an alternate method (BFD) which obviates the need of Leasequery

The proposal is just a draft method. BFD itself doesnt solve the problem completely.
BFD defines a mechanism to check the status of IP session between IP edge router and CPE. When L2RA goes down, CPE would tear down the IP session and restarts the DHCP. So, L2RA would rebuild the lease information from scratch and so leasequery may not be required. But there are many deployments where DHCP Clients reside outside RG/Modems and RG does plain bridging. In this case BFD would not work because we cant have all user equipments running BFD. Also, it will not work when L2RA comes back up before the BFD keepalive timer expires.

3. Modem would know DSL line going down and initiate DHCP again
We have seen deployments where even if modem is acting as a DHCP client, modem does not restart the DHCP re-configuration when the line goes down. Also as mentioned above, there are many deployments where DHCP is initiated by an entity residing outside the modem.

4. What will happen when L3RA also removes the state when L2RA goes down? How to bring the state in L3RA up?

L3RA generally doesnt keep state. In cases where it keeps the state and removes the routes after detecting that it is no longer valid (either by BFD or by any other means) there has to be a mechanism to bring the state up in L3RA. To address this we plan to propose the following

In the below scenario, L3RA has removed IP session and does not have the state anymore. L2RA has also lost its state because of reboot.

Client sends a packet upstream. L2RA generates leasequery. L3RA updates 'giaddr' with incoming i/f IP address. If LEASEACTIVE is received, L3RA would update its state and bring up the IP session. L3RA would forward the LEASEACTIVE to L2RA. L2RA would update its state in its own table. L3RA might contact AAA/policy server to trigger the authorisation again after seeing LEASEACTIVE. This is out of scope of the document.

For downstream packets, L3RA should have a mechanism to re-create the IP session if required. To re-create the IP session L3RA might use same  mechanism mentioned in RFC 4388.

Please let us know if there are any more suggestions/concerns regarding this draft.

Thanks,
Pavan


Pavan Kumar Kurapati
Infosys Technologies Ltd,
Bangalore



**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg