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

[pavan_kurapati <[e-mail]>]

Hi Woj,

Replies inline. We agree to remove L2MAC NAT portion if it complicates things. So, I am removing the comments related to that to save some text

Thanks,
Pavan

________________________________________
From: Wojciech Dec (wdec) [[e-mail]]
Sent: Wednesday, October 15, 2008 10:30 PM
To: pavan_kurapati; [e-mail]
Cc: dhc Chairs; Ted Lemon; Ralph Droms (rdroms)
Subject: RE: Comments -  draft-ietf-dhc-l2ra-extensions-00

Hi Pavan,

Continued inline... Woj>

> -----Original Message-----
> From: pavan_kurapati [mailto:[e-mail]]
> Sent: 14 October 2008 16:07
> To: Wojciech Dec (wdec); [e-mail]
> Cc: dhc Chairs; Ted Lemon; Ralph Droms (rdroms)
> Subject: RE: Comments - draft-ietf-dhc-l2ra-extensions-00
>
> 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 -

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

Woj> Perhaps I didn't explain myself clearly: When a client broadcasts
an ethernet frame (any ethernet frame) and for whatever reason one
doesn't want that frame to be received by other clients then there are
standard means of isolating users at layer 2, without requiring dhcp
extensions/features. The draft above talks about that.

Pavan> OK. Just to make it clear, we are not proposing any extensions in DHCP to prevent upstream flooding. We are handling prevention of flooding through DHCP only in downstream direction. For upstream flooding prevention, we've just suggested usage of uplonk port in Access concentrator as a recommendation which does not change anything to DHCP protocol. Do you want us to remove this reference as well?

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

Woj> You may want to take note of the fact that such unicast replies are
the norm in already deployed broadband networks, and explicit features
exist to disable broadcasting back. Unless we conclude that there are
cases when broadcast replies from a server/relay are an absolute must,
then I'd say that there is no problem to solve here.

Pavan> This problem can be solved in 2 ways. 1) Obsolte the broadcast flag 2) Use unicast option
To do option 1 we have to formally obsolte the same. Option 2 is a cleaner solution for RA to pick up the address given in the option and unicast it back. Either way, it has to come through a draft and get WG approval. Ignoring broadcast flag otherwise is not DHCP standard compliant.


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

Woj> Ok, now I'm even more confused. What will the server include in
it's leasequery reply to get the message back to the L2RA that generated
the query? I thought that the Opt82 inserted by the L2RA (not the L3RA)
was the way of accomplishing that.

Pavan> L2RA would generate leasequery with relay-agent-hw-address option added. L3RA would populate 'giaddr' to leasequery message similar to other DHCP messages. (Please note that L2RA would not populate 'giaddr' in leasequery even though RFC 4388 mandates populating the same for leasequery generator. This is clearly mentioned in section 5.2.1). Server would unicast the reply to L3RA just like a regular DHCP reply message and adds back 'relay-agent-hw-address' option that came in leasequery. L3RA would use relay-agent-hw-address option to unicast it to L2RA's MAC address.

There is no option 82 added to leasequery message either by L2RA or L3RA. Only LEASEASSIGNED will have option 82 which the server had stored for that lease. This is inline with RFC 4388.

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

Woj> Let's keep the comment in the queue pending clarification on how
the server sends back query replies to the L2RA

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

Woj> Unless we have a good reason for it to cache, I'd say it should go.

Pavan> OK

>

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