Hello Seb, Thanks for reviewing the design.
Sebastien Roy wrote: [..] > On Tue, 2009-06-30 at 12:21 -0400, Rishi Srivatsavai wrote: >> 5.3 AF_TRILL sockets >> ...Callers must have the PRIV_SYS_NET_CONFIG >> privilege for any of the ioctls below to succeed. > > Other aspects of bridging configuration require sys_dl_config, so why > would this one be broader (sys_net_config includes sys_dl_config, > sys_ip_config, sys_ppp_config, and some other things). This seems like > overkill. True, I will correct it to sys_dl_config. > Maybe I missed it, but is there a description of how the AF_TRILL Volo > plugin module hooks in with bridging piece for transmit. Does it call > into the bridging code directly, or does it hook into some GLDv3 kernel > entry point? The TRILL_NEWBRIDGE ioctl sets up the hooks to call into bridging code directly. Sections 5.1 and 5.3 describe this step to register TRILL with bridging. But please let me know if it should be improved. >> 6. libdladm configuration >> >> TRILL IS-IS daemon (trilld) uses libdladm to access bridge instance >> configuration. trilld determines the data links that are part of the >> RBridge instance from libdladm and also retrieves link properties such >> as the default VLAN tag of the link using libdladm. > > So if it's already using libdladm to get some information on the links > it uses, then why would you need these special ioctls? > > TRILL_HWADDR > TRILL_GETMTU > > These are generic link attributes that can be obtained through libdladm > as well. True, I think these ioctls were introduced in AF_TRILL prior to the use of libdladm for link configuration. I will investigate and see if we can avoid introducing them. >> 7.1 trilld config file options >> >> Users can specify the following options in the configuration file for >> trilld: >> >> * hostname <hostname> : Specifies the hostname for the RBridge instance. >> Used in VTY command output to refer to the system running the RBridge >> instance. >> >> * password <password> : authentication password for the VTY interface. > > So this is no more or less secure than password options for other VTY > interfaces in Quagga, right? I think if you state this up front, less > eyebrows will be raised about your storing of a clear-text password in a > configuration file... Correct, it is saved in clear text as with isisd and other Quagga daemons. I will add a note stating the password is stored in clear text just as with other Quagga daemons. Thanks, Rishi _______________________________________________ networking-discuss mailing list [email protected]
