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

[Bharat Joshi <bharat_joshi at infosys.com>]

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

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

Ok.

> 1. Introduction;
> 
> 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.

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

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

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

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.

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

Ok. Thanks.

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

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.

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

Ok. We will mention this.

> 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?


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