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

[Bharat Joshi <[e-mail]>]

David,

     Thanks a lot for your feedback. Please see my replies in line.

Thanks,
Bharat

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

Not a problem.

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

We have been internally discussing and have been thimking that have a sun-option may be more generic and helpful. It may take care of cases where Client's MAC address is not known.

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

Yes. You are right. That is exactly what we have thought.

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

Apart from this, as mentioned above, that the client's MAC address may be all zeros. [We found a case where a client may set the chaddr to all 0s]

Does DHCP server allocates an IP address to such a request?

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

Ok. So this is what has been proposed in Layer 2 Relay Agent extension draft that L3 RA parse the sub-option and unicast the reply back to the hardware address.

**************** 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
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg