Rare project developers

[mc36 <>]

hi,

On 3/14/22 17:00, Alexander Gall wrote:
> Hi
>
> On Mon, 14 Mar 2022 14:56:09 +0100, mc36 <> said:
>
> > nice spot and an interesting question......
> > first of all, i agree with the suggestion to the state.py idea of yours...
>
> > regarding the new port_add/del message, i don't feel that it's a good idea
> > to even remove a port from that table, ever... okk we accidentally removed
> > the export-port for a while, but when re-adding it, one would expect that
> > the counters are back... especially the accumulated crc to name one....
>
> I don't think it's a bad thing to remove a port from the list of
> active ports if it's not referenced by an export-port clause. For one
> thing, it will make sure that the port is shut down, which I would
> expect as a user. If we don't remove the port once the export clause
> goes away, I guess we would still have to generate a message that
> issues a shutdown (even if there is a "no shutdown" in the interface
> config). Removing the port would make that a non-brainer.
when one no export-port something, a state <id> 0 issued...


> Also, for some configuration changes it is actually necessary to
> remove the port. For example, let's assume we have ports 1/0 and 1/1
> configured as 10G. Then we want to replace it by 1/0 configured as
> 100G.  This requires that 1/1 needs to be removed first since the 100G
> config uses all 4 lanes.

when such a config requested from freerouter, it issues 2 state messages for 
now....
tight now, the state message have this format: state id 0/1 speed etc....

okkk, got the point... i'll add the new message then....

but since the state message will only have to deal with the (no)shutdown 
state finally,
what if we move all the parameters from it to the new message?
i mean the following:
state id 0/1 --- just to indicate the shutdown state
ports_add/del/mod id speed etc --- to indicate the port config change

> > anybody else have a different opinion?
>
> > ohhh, anyway, i also had an idea from the above.... we really would need an
> > other backward communication regarding the crc... let's say "show inter sdn1 
> > controller"
>
> I don't understand how this relates to the issue above. Can you please
> explain?

it's a completely different idea i just got while i discussed with you the 
above.... :)

thanks,
cs