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

["Wojciech Dec (wdec)" <[e-mail]>]

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

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

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

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

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)

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

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