James Carlson wrote:
> What other splits does NWAM potentially need to know about? For
> example, there's the split between VLANs and the link below: you can't
> have the VLAN configured and usable without the link as well. And
> there's the split between the link and the physical instance -- the
> former might be an aggregation of multiple physical instances, each
> with administrative issues.
Is it pre or post Clearview UV support? I suppose after UV
is done, everything should be clear :-) A VLAN is a data link
and I assume the IP interface centric view we have now in the
NWAM handling (e.g. we use IFF_RUNNING flag to check whether
the underlying link is plugged in) should probably work fine.
We may make NWAM depend on UV if it can make NWAM architecture
simpler.
> Getting into 802.1X is what concerns me here. The authentication
> issues there are at the lowest possible level -- they authenticate a
> "wire" -- and many of the other structures are above that level. If
> we treat 'link' as the lowest level, where it means both "thing that
> IP can plumb" and "thing that 801.X protects," then NWAM can't
> represent (for instance) VLANs.
I do not know about the planned 802.1x support and how its
administrative model works. Could you please elaborate and explain
the issues? For example, suppose a vlan data link is created
(assuming UV again). How does 802.1x fit in the picture?
> (Another wrinkle is wireless operation where one could in theory
> maintain associations with multiple APs ... but we can probably ignore
> that.)
Assuming the above actually works, I suppose we should follow
the vlan model (they are quite similar) and create a data link
for each of those associations.
> This looks like an instance of a much more general issue to me. It's
> possible to scan the sub-IP link for all sorts of information --
> including link partner (for aggregation) and perhaps even VLANs via
> LLDP. I'm not sure what to call that event -- it's some sort of
> "EV_LINK_INFO" bit.
This is true. If we plan to support automatic detection at
that level, we probably want to have such an event.
> (I'd also shy away from the word "finishes" here. Scanning may never
> finish. Instead, I think it'd be nice to have something that reports
> interesting _changes_ in state. If some link layer designer wants to
> say that his link has a "finish" state, that's fine, but I think NWAM
> comes out as more flexible if it doesn't admit this.)
I guess the word "finish" is chosen poorly. It is in the
context of one single wireless scan, and such scan does finish.
The scanning in the above paragraph is similar to the periodic
scanning of wireless networks. That scanning is on-going. When
applied to the wired NIC context, it can be a similar periodic
"link info scanning."
> Should EV_WIRELESS_NET or EV_LINK_INFO appear there somewhere --
> perhaps going from NWAM_LINK_PLUMBED to NWAM_LINK_CONNECTED? (Or does
> it implicitly just loop-to-self everywhere?)
That event is generated by a separate thread doing the periodic
scan as described in the writeup. So it is "missing" from the
diagram. It is "looping."
> How do we deal with configuration changes that don't involve
> EV_IF_UP/EV_IF_DOWN?
What are the other configuration changes we need to deal with?
> Is there something that performs the NWAM_IF_QUERYING function
> essentially all the time? Or are we relying on external providers to
> do that and deliver EV_SIGNAL?
In the current design, there is no on-going info querying.
For example, if NWAM decides that DHCP is used to control an
interface, NWAM will rely on dhcpagent to mark an interface
up/down. And the NWAM daemon listens on a routing socket for
these events.
> If it's the latter, then why not just rely on EV_SIGNAL all the time
> rather than having a 'querying' state ... ?
I think this tied to the above other configuration changes.
Please list them and we can accommodate them in the design.
--
K. Poon.
kacheong.poon at sun.com
