Re: [savi] WGLC: draft-ietf-savi-dhcp-22

["Pascal Thubert (pthubert)" <[e-mail]>]

Cheers,

Pascal

> -----Original Message-----
> From: Guang Yao [mailto:[e-mail]]
> Sent: lundi 28 avril 2014 13:01
> To: 'Ted Lemon'; Pascal Thubert (pthubert)
> Cc: [e-mail]; 'SAVI Mailing List'; 'Jean-Michel
> Combes'
> Subject: RE: [savi] WGLC: draft-ietf-savi-dhcp-22
> 
> Dear folks,
> 
> Thank you very much for all the comments. Because the topic forks into
> multiple threads, I made a summary for the discussions, including our
> revision decisions.
> 
> We are grateful to any advanced comments.  Thank you again.
> 
> Best regards,
> Guang Yao
> 
> 1. LQ problem
> 
> The original post from Eric:
> "1) There seem to be a requirement in several places of the document (see
> below) to send LEASEQUERY to the DHCP server.  That is certainly useful to
> do so, but switches are sometimes pure layer-2 switches, and don't
> implement a DHCP stack not they have a layer-3 address to source traffic
> from.
> Even when the switches have a layer-3 leg,  setting then to reach out the
> DHCP server is not a trivial operation, and not one which is typically done on
> layer-2 access switches.
> Whenever the LEASEQUERY is mandated,  I'd rather have it as a SHOULD,
> with some alternate behavior (delete the entry for instance).
> "
> 
> The discussions:
> 
> Pascal: least there should be enough options to implement some user
> policies. maybe we should be documenting the value / risk involved in using
> LQ or not?
> 
> Eric: I am not sure how to read this ("MUST" followed but "if it can't").  Isn't
> it contradictory? I thought "SHOULD" was exactly the way to say that.
> 
> Eric: In the data snooping process...If no conflict was detected, it does the LQ
> I'll tend to argue that if LQ is required, the DETECTION state is not necessary
> and should be removed. If LQ is optional, and DETECTION failed to detect a
> conflict, then the entry should not move back right away to NO_BIND?
> 
> Ted: BTW, I agree with Eric that the MUST there should be a SHOULD...
> 
> Pascal: I'm not sure that this particular FSM is the only way to implement the
> function and get all the necessary interoperation.
> 
> Ted: I think the added flexibility you are talking about might in theory be a
> good thing, but might in practice actually be a bad outcome.   In any case,
> it's certainly true that implementors can do this differently if they like, as
> long as their implementation behaves in a way that interoperate with
> implementations that follow the documented FSM.
> 
> [final decision]
>  (a) for the data snooping process, LQ is necessary, or else there is no need
> to perform the data snooping process (there is no other way to sync state
> with the DHCP server). Considering the whole data snooping process is a
> conditional MUST, the LQ is actually a conditional MUST.

[PT] An observation that "sync state" is not the perfect wording since the best we can do is re-validate whether the server knows the address but not push a state.
I agree that in the context of DHCP only, snooping makes a lot more sense with LQ; in a general network, though, data snooping is valuable to - at least- discover that there is either a missing state or an usurpation. And from there take action which can be one of Query DHCP server, query other switches, create entry with a low trust level...

Cheers,

Pascal