Phil, good work!
Some comments from a read through.
* There's no discussion of what happens should some form of protocol
offload be in use.
For example, if checksum offload is in use with interface foo0, will
outgoing packets observed through the /dev/ipnet/foo0 have a correct
checksum?
* In various places the document refers to "local zones", though I
understood we were to avoid using that term, preferring "non-global
zones". Personally I don't care, though consistency is good.
* The term "IP traffic" is used in lots of places and I think that
this means "IP_DL_SAP and IP6_DL_SAP traffic", which explicitly
excludes ARP, etc. Is that correct?
It would be good to be specific about what things an administrator
might expect to see that won't be there.
* In section 2, requirement 3 doesn't call out that fact that traffic
local to a non-global zone should be visible.
* Section 3.1 describes the rules which govern whether a packet will
be passed to a consumer. The second part of the rule begins:
"DL_PROMISC_PHYS is enabled and the interface...."
Could you say what type of packets would fall into this case?
* Why is the default behaviour of the observability device to _not_
pass up ancillary data? (Particularly given that snoop will always
ask for it.)
* The version management of DL_IOC_IPNETINFO seems odd. If an
application exists that can understand both versions 1 and 2 of the
ancillary data, how does the application indicate this to the
observability device?
If ancillary data were always present the kernel could pass upward
data in the "current" version. If the application doesn't
understand this, it should fail. This approach would mean that a
single application might function over several versions of the
ancillary data.
* Will the project team provide changes to the maintainers of
"ethereal" to support the new observability device?
* Given that the ancillary data forms part of an on-disk file format,
specifying the alignment and sizes of elements of dl_ipnetinfo_t
seems necessary.
* Section 4.2: the zone of an interface can change in much the same
way as the address, meaning that it will be necessary to track such
changes.
* Section 5: are the ipolink_t and ipoaddr_t data structures
necessary? It seems that they shadow the existing ill and ipif
structures - perhaps ill and ipif could be extended to provide the
relevant functionality? This would avoid the need to keep the two
sets of data coordinated.
dme.
--
David Edmondson, Solaris Engineering, Sun Microsystems.
_______________________________________________
networking-discuss mailing list
[email protected]
