Subject: [dhcwg] draft-ietf-dhc-l2ra-00 comments

From: "David W. Hankins" <[email-masked]>
Date: Tue, 15 Apr 2008 11:03:36 -0700

I'm building on notes I scribbled down during IETF week, so some of
these are debatable and maybe more due to lobby induced fever than
right thinking.  Still, I provide them for discussion points (and the
few that are typographical).

1. Introduction;

o I think the text 'as they deem appropriate' is unneeded.

o There are three places that the Relay Agent Information option is
  referred to, just for consistency I think it should always be
  preceeded by a the;

   they deem appropriate and also add 'Relay Agent Information' option
   to the DHCP messages.  DHCP servers use this option for IP address

   to add Relay Agent Information option as they are closer to the end

   Layer 2 devices append the Relay Agent Information option and

I think the last one reads better, and the first two would read
better as 'the Relay Agent Information Option'.

o Specifically clarify;

   hosts.  These Layer 2 devices can not relay the message to the DHCP
   servers as they are typically configured in bridging mode.  These

My complaint is that 'bridging mode' does not presume a lack of
addressing.

Suggest:

for context the preceeding text, unchanged:

   In some network configurations, there is a need for Layer 2 devices
   to add Relay Agent Information option as they are closer to the end
   hosts.

My suggested edit (keeping the same paragraph):

   These Layer 2 devices are typically operating only as media bridges
   for the network, and may have no IPv4 addresses on the network in
   question.  Lacking a valid IPv4 source address, they cannot relay
   packets directly to a DHCP server located on another network.

for context the remaining text, unchanged:

   A Layer 3 Relay Agent relays it to the DHCP server.

3. Need of Layer 2 Relay Agent

o s/upto/up to/, missing space.

       have to intercept unicast DHCP messages as well to keep this
       information upto date.

o Suggested reason 3:

   3.  For the L2 Relay agent to make use of "cookies" it places in
       the Relay Agent Information Option's contents, such as using
       the Circuit-ID to locate which port to direct the Server's
       replies.

4.1.1. Client-server interaction

o Note in step 3 that the server's reply may be either broadcast or
  unicast to [End Host #1]'s mac address.  In either case, it is
  presumed the packet will transit [Layer 2 Device #1].

4.2.2. Issues due to introduction of Layer 2 Relay Agent

o Suggest adding (in addition to similar 4.1.2 issues):

   Layer 2 relay agents which maintain persistent state, such as
   updating filters or client registration, must be prepared to handle
   potentially conflicting responses from different DHCP Servers.
   Some Layer 2 relay agents instead use "the most recent DHCP
   packet", and this is not necessarily a reflection of which state a
   client has actually adopted.  Even where a client requests a single
   address, and two servers ack the single address, they MAY differ
   for example in lease times.  If the relay agent selects the server
   reply which has a shorter lease time, it would expire its state
   possibly before the client even has a chance to renew it.
   Therefore, Layer 2 relay agents SHOULD select the longest lease
   time of two conflicting but similar replies, by discarding replies
   that shorten the lease time.

Or possibly this should be an expanded discussion of 4.2.1's point?

One of the things I've gotten email about in the past from a l2ra
implementor is this subject, and I'm trying to see if we can give
guidance that helps folks avoid falling into the same trap.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 16 Apr 2008 16:15:29 +0530

Hi David,

    Thanks for your detailed review. We will address them before we come
out with next revision of this draft. 

    Please see my response in line.

Regards,
Bharat

> few that are typographical).

Ok.

> o I think the text 'as they deem appropriate' is unneeded.

Actually this text was taken from RFC 3046. Let us see if we can reword
this.

> better as 'the Relay Agent Information Option'.

Ok. We will make this consistent across the draft. We will use the third
one everywhere.

>    A Layer 3 Relay Agent relays it to the DHCP server.

Ok. Got your point. But saying 'may have no IPv4 addresses' does not
look entirely correct. Because typically even bridges have a management
IP address but this address can not be used at all.

We will reword it to make this point clear.

>        have to intercept unicast DHCP messages as well to keep this

Ok. Thanks.

>        the Circuit-ID to locate which port to direct the Server's

Ok. We had am impression that this is implicitly done in Case 1. But
yes, I agree that this could be a reason for doing L2 RA.

>   presumed the packet will transit [Layer 2 Device #1].

Ok. We will mention this.

> Or possibly this should be an expanded discussion of 4.2.1's point?

Ok. This point seems to require some discussion.

We feel that when client receives multiple OFFER messages, it will
choose only one of the server and will send REQUEST message identifying
that server. Now Layer 2 Relay Agent should typically extract/glean
Lease Information to install filters etc when it sees an Ack from the
Server.

So my question is that we won't have a case where two servers are acking
for the same request. I am not sure if I am missing something here.

**************** 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://www.ietf.org/mailman/listinfo/dhcwg

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 16 Apr 2008 19:33:38 +0530

Hi David,

> for the same request. I am not sure if I am missing something here.

I was discussing this and realize that we have already mention something similar for REBIND case in point 3 under section 4.3.2.

We can enhance this point to reflect your suggestion.

If it is something else, please do let us know.

Thanks,
Bharat

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 16 Apr 2008 10:13:48 -0700

> for the same request. I am not sure if I am missing something here.

Actually there are multiple scenarios, as DHCPREQUEST is used not just
in the transition from selecting->bound, but also in renewal and
rebinding.  You noted this in a later email. :)

More importantly, where a server-id is present, it does not imply only
one server will reply, as there may be a failover configuration
present (and some DHCP servers ignore the server-id sent by clients
anyway for various reasons).  So it is simplest just to say that any
DHCPREQUEST MAY net multiple DHCPACKs (and NAKs!).

Especially in a failover configuration, two servers may be prepared to
answer requests for a given IPv4 address being requested, and some
will do so regardless of server-identifier (or at least will be wiling
to answer for each other, or may use the same "anycast"
server-identifier, or ... any number of things).

The consequence is precisely two DHCPACKs, under failover, presuming
that the lease being requested is in the ACTIVE state already, or has
been reserved for the client.