Subject: [dhcwg] comments L2 Relay Agent Information

From: Stefaan DE CNODDER <[email-masked]>
Date: Wed, 21 Nov 2007 09:39:09 +0100

Hi,

I have some comments on draft-joshi-dhc-l2ra-00:

1) section 4.1.1 in point 3 and 6 says that the L2 relay agent looks to
the broadcast flag to see if has to broadcast or to unicast.  Is this
not the task of the DHCP server or L3 relay agent?  Would there be any
reason why the L2 relay agent should also inspect the broadcast flag?
Is it not enough that the L2 relay agent just looks to the destination
MAC address?

2) point 3 in 4.1.1 says that the L2 relay agent removes the relay agent
information option.  As far as I know, this is not mandatory for L3
relay agents (and I have seen implementations that do not remove it), so
  should it for L2 relay agents also not be something optional?

3) point 4 in 4.1.1: A L2 relay agent uses the RAI to find out if it has
appended the RAI or not.  There is not really a requirement that the
content of the RAI must be unique per access link network-wide.  For
instance, if the circuit-id contains a string indicating the slot and
port number of the link, then the same circuit-id can be used by
multiple L2 relay agents.  The DSL Forum has solved this by adding a
DSLAM-ID to the string of the suboptions of the RAI in their suggested
format of the string.  It would be therefore better to add the word
"usually" just like it is done in 3 and 6 where the L2RA "usually" find
the outgoing port based on the RAI, because there are other means as well.

4) Section 4.3.2, point 1: this is not really a new issue when there is
a L3 relay agent and is already mentioned in 4.1.2.

Some typos:
- section 3, point 1: position instead of postion
- I do not understand 3rd sentence in section 3, point 2: "This helps in
preventing the Layer 2 and Layer 3...."
- section 4.3 line 3: "...its seen.." -> "...it is seen..."

regards,
Stefaan

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 21 Nov 2007 22:13:00 +0530

Hi Stefaan,

    Thanks for your comments. Please see my response in line.

Thanks,
Bharat

> Is it not enough that the L2 relay agent just looks to the destination

Yes. You are correct. A L2 RA would not need to look at the broadcast flag at all. We shall correct this in our next revision.

>   should it for L2 relay agents also not be something optional?

As per RFC 3046 whoever has added relay agent information option MUST remove it.

Section 2.1 of RFC 3046:

The Relay Agent Information option echoed by a server MUST be removed by either the relay agent or the trusted downstream network element which added it when forwarding a server-to-client response back to the client.

> the outgoing port based on the RAI, because there are other means as well.

Yes. Adding 'Usually' will be helpful. After re-reading it, I think we need to update it.

> a L3 relay agent and is already mentioned in 4.1.2.

Yes. They are essentially same but we just wanted to keep it at both the places. It just shows that if a L3 RA does not snoop a unicast message, DHCP server should echo back the option 82.

> - section 4.3 line 3: "...its seen.." -> "...it is seen..."

Will fix all of them in next revision.

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