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

Hello Ted:

> IOW the switch can't have a link-local address per subnet?

[PT] 

I've never fully made up my mind that a vlan is a subnet. E.g., we use private vlans that segregate the subnet in order to isolate some clients or defeat some unwanted linklocal scope broadcast storms (because as we know there's no such a thing as a workable linkscope MLD snooping). This is one of these multilink subnets that are not supposed to exist... 

Anyway; whether they are private or not, there can be a great many vlans and it can become a real hassle to configure one SVI per vlan. On top of the operator work for CLI and management, there's also all the CPU and memory involved. It's not that the switch can't do it but rather that it's not necessarily a good idea to force the admin to configure an SVI on all vlans.

> Again, if it's a managed switch, it doesn't make sense that you wouldn't want
> it to have a routable L3 address.   You might want to constrain what L3
> address it has, and yes, there are operational ramifications to this.   But are
> you saying that you aren't managing the switch?

[PT] I actually implemented a client to lease query in our SAVI switches, that will revalidate an address as learnt through DHCP.
It turned out that a function like that can rapidly become a real hassle to configure, with dependencies between otherwise unrelated CLIs. 
So yes, there is at least one vlan with an SVI on it in a managed switch, and yes we can use it to source LQ. But it does not mean that it is an easy thing to deploy.

> > . It is currently not very common to
> > deploy DHCP on access switches when the L2/L3 boundary is one layer up
> > (on aggregation/distribution). And I am not talking about the one you
> > have at home.
> 
> Of course not.   Mine doesn't do leasequery or SAVI.   I was using it as an
> example of the minimum functionality one might expect in a switch that
> _does_ do SAVI.

[PT] I would not complain that the switch is expected to support the LQ based validation function, though adding a dhcpv6 client to a switch image does not necessarily come for free. It seems to me that the draft goes very deep into the implementation of the guts of the FSM as opposed to the externally observable behavior, and I'm not sure that this particular FSM is the only way to implement the function and get all the necessary interoperation. At least there should be enough options to implement some user policies such as use LQ or not to validate the SAVI state, which, all in all, looks a lot like an operator decision. 

I agree with Guang's proposed change, and maybe we should be documenting the value / risk involved in using LQ or not?

Cheers,

Pascal

> _______________________________________________
> savi mailing list
> savi@ietf.org
> https://www.ietf.org/mailman/listinfo/savi