Subject: [dhcwg] FW: I-D ACTION:draft-joshi-dhcp-lease-query-ext-00.txt

From: "pavan_kurapati" <[email-masked]>
Date: Sat, 10 Jun 2006 06:54:47 +0530

Hi,

We published a new draft which extends the LEASEQUERY mechanism mentioned in RFC 4388 to L2 Access networks. Please provide your comments/suggestions on this draft.

Thanks,

Bharat&Pavan

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Extension of DHCP LEASEQUERY in Bridging/Switching networks
        Author(s)       : B. Joshi, P. Kurapati
        Filename        : draft-joshi-dhcp-lease-query-ext-00.txt
        Pages           : 18
        Date            : 2006-6-9
      
As per industry trends, Access Networks have been migrating from
traditional ATM based networks to Ethernet networks.  In Ethernet
based access networks, Access Concentrators are typically configured
to act as traditional bridge.  These Access Concentrators also act as
relay agents and relay DHCP messages between hosts and DHCP servers.
It also maintains and updates lease/location information while
relaying the DHCP messages.  Access Concentrators may use the lease/
location information for anti-spoofing, data forwarding etc.  This
lease/location information is lost if an Access Concentrator gets
rebooted.  RFC 4388 [4] has defined a new message type DHCPLEASEQUERY
to address similar limitation in Routed Access Networks.

This document initially gives an overview of the functioning of the
Access Concentrator acting as a relay agent in a Layer 2 aggregation
network.  The limitation[as mentioned above] in a typical switched/
bridged[layer 2] is then discussed followed by the proposal to extend
the DHCPLEASEQUERY message to address this limitation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-joshi-dhcp-lease-query-ext-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-joshi-dhcp-lease-query-ext-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-joshi-dhcp-lease-query-ext-00.txt".
      
NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

**************** 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Andre Kostur <[email-masked]>
Date: Mon, 12 Jun 2006 21:30:04 -0700

> We published a new draft which extends the LEASEQUERY mechanism mentioned in RFC 4388 to L2 Access networks. Please provide your comments/suggestions on this draft.
A few questions:

1)Wouldn't it be easier if the Access Concentrator had some sort of 
Management IP, and emitted Leasequeries on its own behalf?

2) This draft appears to assume that there is an Ethernet link between 
the access concentrator and the L3 relay (as evidenced by the 6-byte 
required MAC addresses).  Wouldn't it be sufficient to note that the 
upstream packet should be broadcast as per whatever mechanism is 
appropriate for the transport?

3) Why would the L3 relay be allowed to forward the request as an L3 
broadcast (section 5.2)?  Why not simply the configured DHCP servers?

4) According to the draft, the L3 relay can determine whether the LQ 
response is for itself, or for the L2 concentrator based on the GIADDR.  
If it is the "upstream" GIADDR, then the reply is meant for the relay, 
if it is any of the "downstream" GIADDRs, then the reply is meant for 
the concentrator.  However, RFC 4388 doesn't mandate that L3 relays must 
use their "upstream" IP as the GIADDR.  I think this needs stating 
within this draft, as it is modifying the behaviour of the L3 relay.  
This draft doesn't specifically address changes necessary for the L3 
relay to be able to emit its own queries.

5) Regarding Appendix A.  Since the L2 concentrator is appending option 
82 in all cases, can you see a benefit to having this data present in 
normal DHCP traffic?  Perhaps to allow one to look at a lease on the 
DHCP server and be able to determine which conentrator that device came 
through?

---

From: Pavan Kumar Kurapati <[email-masked]>
Date: Tue, 13 Jun 2006 12:52:43 +0530

Hi Andre,
Thanks for the comments. Please find replies inline

Thanks,
Pavan
Andre Kostur wrote:

> pavan_kurapati wrote:
>
>> Hi,
>>
>> We published a new draft which extends the LEASEQUERY mechanism 
>> mentioned in RFC 4388 to L2 Access networks. Please provide your 
>> comments/suggestions on this draft.
>>   
>
> A few questions:
>

Management Networks are typically configured in separate network so that 
the management data does not interfere with user data. Hence I think it 
won't be feasible to use Management IP for this purpose. Moreover, 
Access concentrator is just doing bridging here.

> appropriate for the transport?

Yes. The draft is aimed only at Ethernet based Access Networks. As  our 
document suggest that Access Concentrator acts as Transparent Bridge, 
the upstream would always be Ethernet.

> broadcast (section 5.2)?  Why not simply the configured DHCP servers?

You are right. We will modify it.

> response is for itself, or for the L2 concentrator based on the 
> GIADDR.  If it is the "upstream" GIADDR, then the reply is meant for 
> the relay, if it is any of the "downstream" GIADDRs, then the reply is 
> meant for the concentrator.  However, RFC 4388 doesn't mandate that L3 
> relays must use their "upstream" IP as the GIADDR.  I think this needs 
> stating within this draft, as it is modifying the behaviour of the L3 
> relay.  This draft doesn't specifically address changes necessary for 
> the L3 relay to be able to emit its own queries.

Good Point. We shall add another point in our document which will make 
this a MUST.

>
> 5) Regarding Appendix A.  Since the L2 concentrator is appending 
> option 82 in all cases, can you see a benefit to having this data 
> present in normal DHCP traffic?  Perhaps to allow one to look at a 
> lease on the DHCP server and be able to determine which conentrator 
> that device came through?

This option was meant for L3 relay to unicast the reply to L2 
concentrator instead of sending it as broadcast. There is no way a L3 
relay can determine the MAC address of L2 concentrator unless it keeps 
the state of each query generated by the L2 concentrator. In option 82, 
the circuit-id/remote-id sub-option string itself sometimes includes AC 
information as well [which may not be MAC address] , but it is not 
standard practice and is not followed in all the implementations. That 
was the reason we proposed a new sub option.