Re: [dhcwg] Comments - draft-ietf-dhc-l2ra-extensions-00

On Tue, Oct 21, 2008 at 02:43:09PM +0530, Bharat Joshi wrote:
> Pavan meant the unicast hardware sub-option we have proposed in layer 2 Relay Agent extension draft.

Ah, I am confused, it has been awhile since I have reviewed the draft.
High time probably.

You have my permission to apply the appropriate filter to my comments.

> This is a very good idea. Let me rephrase it and let me know if my understanding of what you are proposing is correct.
> 
> L2 RA sets a flag [other than the broadcast flag] if it wants the reply to be unicast to him. DHCP server [if there is no layer 3 relay agent] or Layer 3 Relay Agent always looks at this flag and if the flag is clear, it unicast the message to the L2 RA. L2 RA looks at the broadcast flag and broadcast/unicast DHCP reply accordingly. This looks good.

We may fidget on whether the flag would be set for unicast or set for
broadcast (the question is if any l2ra's exist today which will not
know or set the flag, and what default they can reasonably expect to
work), but yes that's the general idea.

> One question remains. Is it enough if L3 RA [or DHCP server if L3 RA is not there] unicast the DHCP reply to hardware address available from the DHCP message's chadd field? Or we need some mechanism where L2 RA tells L3 RA [or DHCP server] as to what hardware address to use to unicast a DHCP reply message to him?

I am probably agnostic on this point as I am not an L2 relay
implementer.

If the L3 agent transmits to the client's L2 address by unicast, it
presumes the client's L2 address is in the forwarding database and
that the database points to the relevant L2 relay agent (which will
recognize the relay agent information option contents as their own).
This is most likely a safe presumption since "standard" L2 networks
generally are not multi path; spanning tree or similar techniques
remove loops and hold them inactive until the primary path fails.  So
the only path to the client includes the relay agent by definition,
even if the packet is flooded (when the client's chaddr is not in the
forwarding table).

Because there are some modern standard movements that are attempting
to create L2 multipath forwarding (TRILL WG) with more similarity to
routed networks (OSPF-like qualities), and many nonstandard methods to
implement the same exist and are used today, it may be useful to
direct the unicast to the L2 device itself, to ensure the packet finds
the original relay agent and does not find an alternate path that
avoids the relay agent entirely.

I would expect L2 implementers have a stronger and more reliable
opinion than my own, and would defer to their judgement.

As a L3 relay agent implementer (albeit a not widely used/deployed
one), I'd be willing to observe a "directed unicast over-ride" relay
agent information option.  It would not be difficult to implement,
but it would take some time to deploy.

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