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

["Guang Yao" <[e-mail]>]

Hi, Pascal

Thank you very much for these comments!

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

Guang:
I agree. But there should be some meaningful ways to recover the bindings. Or else, it is meaningless only discovering the trouble. 

"And from there take action which can be one of Query DHCP server, query other switches, create entry with a low trust level..."

Guang:
I can understand you are suggesting possible alternatives, but I'm not sure how "query other switches" works.
"create entry with a low trust level " is not in the scope of this WG.

As you noted, LQ is the most effective and direct way to recover the binding. If LQ is too heavy, maybe a lightweight LQ should be designed. Introducing other mechanisms will make this solution further complicated.

Best regards,
Guang

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[e-mail]] 
Sent: Monday, April 28, 2014 9:18 PM
To: Guang Yao; 'Ted Lemon'
Cc: [e-mail]; 'SAVI Mailing List'; 'Jean-Michel Combes'
Subject: RE: [savi] WGLC: draft-ietf-savi-dhcp-22



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