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

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

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

Woj> MAC translation is equal to MAC NATing, and firstly I would like to
understand why the community think that this is a reasonable thing to
do. As with IP NAT, MAC NAT is a slippery slope, and one that breaks
other aspects of ethernet (eg 802.1xrev). Secondly if agreed to as
reasnable I would like to understand why does the access-node that
engages in MAC NATing not implement a DHCP ALG to do the MAC NAT in the
payload, instead of going after protocol extensions to handle the
resulting problems? 

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

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

Woj> IMO the L2RA leasequery is the only possibly interesting thing
here, if/when we're able to actually determine that such a leasequery is
beneficial (doubts below)

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

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

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

Woj> I subscribe to the "no MAC NAT" list :-)

Cheers,
Woj.
> 
> 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