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

[pavan_kurapati <[e-mail]>]

Hi David,
Just to elaborate on Bharat's point, having a sub-option instead of a flag will address some scenarios where MAC address to be unicasted is not known from the DHCP header. Consider an example where CPE is operating in IPoA (IP over AAL5) encapsulation and not doing bridging.
                      IPoA
PC----CPE----------L2RA-----L3RA------Server

In this mode, there wont be any ethernet header between CPE and L2RA hence CPE does not populate 'chaddr'. L2RA will populate the ethernet header and hence the Layer 2 network between the relay agents will only learn the MAC address of L2RA. Hence having a sub-option here will solve all the cases where there is a chance of flooding between L3 and L2 Relay agents

Thanks,
Pavan

________________________________________
From: [e-mail] [[e-mail]] On Behalf Of Bharat Joshi [[e-mail]]
Sent: Thursday, October 23, 2008 9:40 AM
To: David W. Hankins; DHC WG
Subject: Re: [dhcwg] Comments -  draft-ietf-dhc-l2ra-extensions-00

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