Re: [dhcwg] Layer 2 Relay Agent Information draft

pavan_kurapati <pavan_kurapati@infosys.com> Sun, 26 April 2009 13:33 UTC

Return-Path: <pavan_kurapati@infosys.com>
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6423A69E5 for <dhcwg@core3.amsl.com>; Sun, 26 Apr 2009 06:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.895
X-Spam-Level:
X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rfksjocbohcw for <dhcwg@core3.amsl.com>; Sun, 26 Apr 2009 06:33:08 -0700 (PDT)
Received: from kecgate02.infosys.com (unknown [61.95.162.76]) by core3.amsl.com (Postfix) with ESMTP id 8F4343A68E8 for <dhcwg@ietf.org>; Sun, 26 Apr 2009 06:33:07 -0700 (PDT)
X-TM-IMSS-Message-ID: <c53979aa00047a2b@kecgate02.infosys.com>
Received: from blrkechub02.ad.infosys.com ([10.66.236.42]) by kecgate02.infosys.com ([61.95.162.76]) with ESMTP (TREND IMSS SMTP Service 7.0; TLS: TLSv1/SSLv3,128bits,RC4-MD5) id c53979aa00047a2b ; Sun, 26 Apr 2009 19:04:16 +0530
Received: from BLRKECMBX01.ad.infosys.com ([10.66.236.21]) by blrkechub02.ad.infosys.com ([10.66.236.42]) with mapi; Sun, 26 Apr 2009 19:04:23 +0530
From: pavan_kurapati <pavan_kurapati@infosys.com>
To: Ramesh <ramesh22@gmail.com>, Bharat Joshi <bharat_joshi@infosys.com>
Date: Sun, 26 Apr 2009 19:04:23 +0530
Thread-Topic: [dhcwg] Layer 2 Relay Agent Information draft
Thread-Index: AcnGV6penttWXMF2QJuANdFAeJCZQAAGOowk
Message-ID: <7221E17E68B1A944ADCE8A83364DBEE61AC554F789@BLRKECMBX01.ad.infosys.com>
References: <31D55C4D55BEED48A4459EB64567589A0E857E6A43@BLRKECMBX02.ad.infosys.com>, <42704ecd0904260313y15c90d64o1db7e6384030e0b4@mail.gmail.com>
In-Reply-To: <42704ecd0904260313y15c90d64o1db7e6384030e0b4@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Layer 2 Relay Agent Information draft
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Apr 2009 13:33:09 -0000

Hi Ramesh,
Thanks for the review. Please find replies inline

Thannks,
Pavan
________________________________
From: dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] On Behalf Of Ramesh [ramesh22@gmail.com]
Sent: Sunday, April 26, 2009 3:43 PM
To: Bharat Joshi
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Layer 2 Relay Agent Information draft


Bharat,

Few comments/suggestions. Search for [Ramesh].

Section 4.1.1

-------------
3 ... The DHCP server responds with a DHCPOFFER message after applying its local policies.
[Ramesh] Will it be good to mention ".. after applying its local policies for
address allocation". This is just to make clear of what policy, DHCP is all concerned
about and readers do not relate this to any system policies.



[Pavan] I feel the text is generic and conveys the message.


Section 4.1.1

-------------
3 ...A Layer 2 Relay Agent may be configured to intercept unicast DHCP messages.
[ramesh] I think all L2 Relay Agents SHOULD intercept _all_ the DHCP messages from server
_if_ it has inserted option-82. This is because for a client, option-82 do not make any sense.



[Pavan] Mandating all L2RAs to intercept unicast messages may be too strict behavior  given that there are implementations which doesnt do it. I feel 'may' is good here.

section 4.1.1
-------------
6. ...

DHCPNACK - RFC 2131 refer to DHCPNAK and not DHCPNACK. Is this ok?

[Pavan] Yes, thanks. Will change it.

section 4.2.2

-------------
1 .... Layer 2 relay agents SHOULD select the longest lease time of two conflicting
but similar replies, by discarding replies that shorten the lease time.
[Ramesh] I thought, to keep the state of a client, L2 Relay Agent will learn
from the REQUEST+ACK message exchange which involves only one server. So there
is no question of keeping a client state more than its life time. Am I missing
something here?

In any case, Maintaining a state ( and hence filter) even after a client is dead,
mean anomalies.



[Pavan] This condition can occur when multiple DHCP servers are configured for failover. In such a configuration, there are servers which ignore server-id and in certain exceptional conditions may respond to the same IP address request with multiple ACKs. In this scenario, L2RA must take the one which has more lease time.


section 4.3.2

-------------
3 ...Because of this, it could be difficult for the DHCP server to differentiate
between a RENEWING and REBINDING state.
[Ramesh] Did you mean "difficult to differentiate between RENEW and REBIND messages
here? State is term used in the server context, right?
If you are talking about server state - then its server who leased out an IP and
hence it would know the state of the client based on T1 & T2.

[Pavan] Actually this state is in terms of client's context. A client would broadcast the dhcp message with client address filled in this state. In case of failover configurations, a REBIND may imply that one of the primary server is not responding [since it is broadcast]. However, in L2RA, since unicast messages are also intercepted and option 82 added, a RENEW may be misunderstood as REBIND by server. Let us know if it is not clear.

--
cheers
ramesh




On Wed, Apr 22, 2009 at 6:43 AM, Bharat Joshi <bharat_joshi@infosys.com<mailto:bharat_joshi@infosys.com>> wrote:
Hi All,

      We have published version 04 of Layer 2 Relay Agent Information draft. This version addresses several editorial comments provided by Alfred.

      Draft is available at http://www.ietf.org/internet-drafts/draft-ietf-dhc-l2ra-04.txt

Thanks,
Bharat
**************** 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
dhcwg@ietf.org<mailto:dhcwg@ietf.org>
https://www.ietf.org/mailman/listinfo/dhcwg