Peter Memishian wrote:
> The ILL never goes up or down, it "just is", it is the
> network interface that we consider to have changed state.
I don't know what you mean. An ill with one or more up ipifs is able to
send and receive packets of that type (IPv4 or IPv6), and one that has no
up ipifs cannot send or receive packets of that type. This is captured in
the ill_ipif_up_count field, which is either checked for zero or non-zero.
I'd prefer to think of it as being possible to send/receive packets
that are associated with an ill if at least one ipif is marked up
(the difference being that I don't think the ill actually *does*
anything, it just loiters around in memory - albeit quite necessarily.)
> Further, I don't believe that the names of internal structures
> belong in externally visible event names (this interface needs
> to become Committed once the we sort out the issues with
> multiple hooks and dependencies.)
I agree that separation of interface and implementation is important,
but simply omitting the object associated with the event (as has been done
with "NE_DOWN") does not accomplish that separation -- it just yields a
confusing programming interface.
How is it confusing? The documentation (design doc) quite
clearly states how/why these events are generated and all
good programmers read documentation in order to not be
confused, right? Although having said that, this detail
from the design doc isn't currently echo'd in the man
pages thus far.
> Also, if we were to do away with logical interfaces (a point
> I believe you've brought up), then there would be no possible
> confusion here.
The core issue is whether it is possible to configure an address that is
down. If it remains possible (which is probably necessary for backward
compatibility), then the need to differentiate an "address up" event from
an "interface up" event remains.
Adding/removing/changing an address is completely seperate
to the state of a network interface and nor should an address
change be mistaken for a logical interface being configured
up or even created. Presently, it stands to reason that you
could easily receive a NE_PLUMB followed by an NE_ADDRESS_CHANGE
followed by an NE_UP.
It could be said that this is a hole in the current design -
address change events can be delivered for logical intefaces
for which there is no other information received. But there
is currently no need for events that announce addition or
removal of logical interfaces.
In which case, the above three events would have another
event interspersed between the plumb and address changed
that announced the creation of the logical interface for
which the address change was associated with. Similarly,
said event would also need an inverse to announce the
removal.
If someone then wanted to go further and become interested
in when individual logical interfaces went "up" and "down",
then you might start to get confused about what NE_UP and
NE_DOWN referred to. However this was not raised during
the design review and nor has anyone formally expressed
any desire to receive such information. Further, if there
are plans to abolish logical interfaces, then adding
something to refer to them as having UP/DOWN properties,
"for the time being", is tending towards a "temporary hack"
in my book and should be discouraged.
Lastly, if anyone has thoughts or ideas about expanding
(and/or changing) the set of events delivered (and/or the
information sent with them), I think it would be better
if this thread evolved (or a new one started) to discuss
how to do/design that, rather than continue to argue over
semantics/interpretations.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
