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

[pavan_kurapati <[e-mail]>]

Hi Woj,

Thanks for the detailed review. Please find my comments inline with <Pavan> tag. Please note that this draft  not only solves broadcast issues. It is intended for all extensions possible for L2RA (including leasequery extensions)

Thanks,
Pavan Kurapati

From: [e-mail] [[e-mail]] On Behalf Of Wojciech Dec (wdec) [[e-mail]]
Sent: Monday, October 06, 2008 7:13 PM
To: [e-mail]
Cc: dhc Chairs; Ted Lemon; Ralph Droms (rdroms)
Subject: [dhcwg] Comments -  draft-ietf-dhc-l2ra-extensions-00
 Hi Folks,
Here are my review comments for draft-ietf-dhc-l2ra-extensions-00. I
have mainly doubts about the scope of the problem that's being addressed
and concern on whether it is actually suitable as a DHC WG item.
Section 1
----------
It's stated that "This document proposes enhancements in Layer 2 Relay
Agent [7] which
   addresses issues like flooding between Layer 3 Relay Agent and Layer
   2 Relay Agent"
Could the authors describe what is/are the scenario(s) under which such
flooding occurs *between* the Layer 3 and Layer 2 agents? Some form of
problem statement/description would be welcome. Section 3 appears to
contain an brief overview, of these, but mixes them with enhancements.

<Pavan> DHCP messages can be flooded between L3 and L2 RAs if "broadcast" flag is set or when MAC translation is used. DHCPLEASEQUERY initiated by L2RA and the reply will be broadcast between L3RA and L2RA. We will add problem statement/description in the beginning of the draft if it helps in avoiding any confusion
</Pavan>

This actually brings me to comment on Section 3...
Section 3
---------
"Broadcasting DHCP requests on all interfaces
   A normal Layer 2 Relay Agent[7] would broadcast a DHCP request
   message to all its interfaces except..."
This not quite normal behaviour. I don't quite see how this is a problem
*between* the L3 and L2 relay agents, if anything this is a problem for
any ethernet broadcast frame sent "upstream" from the client towards a
L2 access node. If so, then this problem has nothing to do with DHCP,
and is actually covered in say the private vlan concept in 802.1d (also
explained in
http://www.ietf.org/internet-drafts/draft-sanjib-private-vlan-10.txt).
As such I do not believe that this is actually a problem to be covered
in a DHC draft, besides the fact that there are other ways in which the
"broadcast issue" can be handled.
BTW I am implicitly assuming that we're talking about ethernet here (are
we? Surely any non broadcast ethernet L2 access node doesn't run into
this issue)

<Pavan> Yes. We are talking about Ethernet L2 access node. For a normal Layer 2 device, DHCP message will be treated similar to any other broadcast message and that is why it may be broadcasting it on all interface as it would have done for other broadcast messages without any extension [Uplink port/Lan router port]. For control messages like DHCP/PPPoX, it is important that these are sent only on uplink port and not flooded on all access ports which is not a common behavior of a normal Etherent switch. That is what is the intention here. Do you think this intention is not clearly visible here?
</Pavan>

"Layer 3 Relay Agent broadcasting DHCP replies
   Layer 3 Relay Agents generally broadcast DHCP replies towards Layer 2
   Relay Agents. "
I don't quite see why it's stated that L3 relay agents generally
broadcast replies. If anything, my experience points to the contrary, ie
that in SP environments the L3 relay will either explicitly unicast at
L2 replies or have a configurable option to ignore requests with the
broadcast flag set. As such I don't quite see that this is a problem
which requires additional DHC work for a L2 relay. If anything the L3
relay functionality could be described somewhere (it already is
documented in vendor release notes). Also, if the motivation is that
there are hosts that can only interpret broadcast MAC frames before an
IP address is assigned, then something is wrong there.

<Pavan> I dont think it is correct to assume that all L3 relays unicast the replies towards L2. There are potentially 2 issues here. One is for L3RA to identify the right outgoing interface (since option 82 is added by L2RA) and then identifying the correct L2RA. If there is any mechanism by which L3RA correctly idenfifies the MAC of L2 relay by looking at the reply from the DHCP server, it is not standardised or documented and may be propreitory (i.e say, if it uses 'chaddr' to get the MAC address of the client). On the other hand, identifying the correct interface on L3RA itself is a problem currently, which we tried to address in another draft (relay chaining) which is out of scope here. The mechanism we are suggesting needs some changes in both L2 and L3 RAs.
</Pavan>

The remaining problem/extension described in this section is:
"Recovering Lease Information from Server
   A Layer 2 Relay Agent[7] may snoop DHCP messages and maintain the
   lease information.  This information is lost if the Layer 2 Relay
   Agent reboots."
This appears to be a valid problem, but actually has little to do with
broadcasts between the L3 and L2 agents. That said, the method proposed
may have some issues... (more on that in the next section review

<Pavan>
We are not covering only broadcast issues in this draft. This draft handles extensions to L2RA wherever required. Currently leasequery mechanism is not supported for L2RA and we are proposing the same here.
</Pavan>

Section 5.2.3
-------------
"While generating a DHCP reply for a DHCPLEASEQUERY message, if the
   message type is DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN, it MUST echo
   back the Relay Agent Information received in the DHCPLEASEQUERY
   message.  If the message type is DHCPLEASEACTIVE, DHCP server
   prepares the message as described in RFC 4388 and ignores the Relay
   Agent Information option received in the DHCPLEASEQUERY message."
If I interpret this correctly the server will:
- send a response message to the L3 relay with the L2 relay agent option
(opt82) with For LeaseQueries that have no valid/active lease
- send a response message to the L3 relay without the L2 relay agent
option (opt82) with For LeaseQueries that have a valid lease

<Pavan> Sorry for the confusion but this was a stale paragraph that remained from previous versions. We were supposed to delete this whole thing as there is no change in DHCP server behavior. To clarify a bit more, in our earlier versions we proposed that L3RA should add option 82 to leasequery message so that it can find out the outgoing interface in case of non LEASEACTIVE reply. In case of LEASEACTIVE, it will anyway have the IP address status to rely on finding the outgoing interface. So, to summarise, DHCP server was supposed to use option 82 present in leasequery for replies of inactive/unknown lease and should use option 82 stored in the database for lease active message. We dropped this idea in the latest draft after our internal discussions, as we thought we should not be handling issues of L3RA in this draft.
</Pavan>

This leads me to conclude that in the latter case an L2 relay
(eventually receiving the reply) will be unable not correlate it to a
given port. If the assumption is that the server needs to insert in the
reply *another* (a cached) relay agent info option, then it raises very
much the possibility that the L2 relay receiving it was not actually the
one that generated it (and should probably ignore the response). In
either case I do not see how the L2 relay can then use the message for
anything useful. In fact this appears could well lead to an undesirable
aspect: If a client with a valid lease moves in the same domain to
another L2 agent in the same domain he/she will be Denied the service
until the lease expires (as per section 5.2.1) - assuming that the
"query" feature use is coupled with security.
Now, in the former case, i.e. when the L2 relay receives a reply
(DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN), then even though it can
correlate it to a given port, I see no benefit in it doing so; it had no
state to begin with, and now it has no valid state to go on either.
What's the point in all this?

<Pavan> Please see the above reply. </Pavan>

Section 5.2.5.1
---------------
"When a DHCPLEASEUNASSIGNED message is received by a Layer 2 Relay
   Agent, it means that there is no active lease for the IP address
   present in the DHCP server, but that a server does in fact manage
   that IP address.  Layer 2 Relay Agent SHOULD cache this information
   for later use."
What later use? Why is caching this info useful? (Note: A similar
question may be brought forward to rfc4388, but that's bygone now...
Let's talk about why is it useful to have this caching on a L2 relay)

<Pavan> Yes, caching is not good but we tried to keep the same behavior as 4388. If required, we can change this statement
</Pavan>

Section 6.
----------
"Even though the DHCP clients are not setting the broadcast flag, it
   is still possible that the DHCPOFFER and DHCPACK messages from the
   DHCP server are sent to all access concentrators.  This is when the
   access concentrator implements a MAC concentration or MAC translation
   function. "
This sanctions the use of L2 MAC NAT which I do not think that the IETF
should get involved in... It also appears that this may be the source of
the real problem which could cause a L3 agent reply sent to a perfectly
valid client unicast mac address to be flooded in an L2 domain. If in
the upstream direction, MACs are NATed but the L3 relay replies to the
client MAC address then that frame will get flooded. It's a problem with
MAC NATing, not DHCP IMO. Actually, it's testament to why the MAC NATIng
is flawed; the L2 MAC NAT device needs a DHCP NAT function too,
translating the client mac address field (and likely breaking rfc3118).

<Pavan> Yes, it is with the case of L2 MAC NAT. We tried to address this case also with DHCP as these implementations do exist hence we were addressing the same in our draft. If everyone feels that we should not be handling L2MAC NAT then we will remove it.
</Pavan>

I'd welcome a discussing/resolution of the above before continuing with
the review of some of the other details.
Regards,
Woj.


> -----Original Message-----
> From: John Jason Brzozowski
> [mailto:[e-mail]]
> Sent: 03 October 2008 23:25
> To: dhc WG
> Cc: Ted Lemon; David Miles; Ralph Droms (rdroms); Wojciech
> Dec (wdec); dhc Chairs
> Subject: [CORRECTION] draft-ietf-dhc-l2ra-extensions-00
>
> Folks,
>
> This is a correction to the original email below.
>
> The following draft has been accepted as a WG work item.  If
> you have any questions or concerns please send feedback to
> the mailing list.
>
> Feedback from the WG or the team below, if not already
> forwarded, is requested.
>
> Thanks,
>
> -Ralph Droms, John Brzozowski
>    dhc WG chairs
>
> On 9/18/08 12:22 PM, "John Jason Brzozowski"
> <[e-mail]> wrote:
>
> > Folks,
> >
> > Before we continue discussions surrounding the above becoming a WG
> > work item we determined in Dublin that additional mailing
> discussion is required.
> >
> > Please review the draft and send your comments and question
> to the WG.
> >
> > Additionally, the following folks have also agreed to
> review the draft:
> >
> > * David Miles
> > * Ted Lemon
> > * Woj dec
> > * Ralph Droms
> >
> > Once the review is complete and sufficient discussion has
> occurred on
> > the mailing we will revisit next steps for
> draft-ietf-dhc-l2ra-extensions-00.
> >
> >
> > Thanks,
> >
> > John
>
> =========================================
> John Jason Brzozowski
> Comcast Corporation
> e) mailto:[e-mail]
> m) 609-377-6594
> =========================================
>
>
>
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg

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