On Tue, Nov 16, 2010 at 00:17, James "Murphy" McCauley <jam...@nau.edu>wrote:
> Rob and Nick, the System Description TLV seems like both overkill and > misuse as well to me. It seems to be designed for advisory type > information for humans. Do you include the "full name and version > identification of the system's hardware type, software operating system, > and networking software"? Do we WANT to do that? > It's definitely not misuse - you might consider it overkill. This is however traditionally the type of information that usually gets jammed in there. Yes, it is typically only ever read by humans (and eHealth, OpenView, Tivoli, etc.), but using it programmatically ourselves is hardly out of the norm - plenty of vendors jam information in there that their product uses to make decisions (and happily ignore anything else they find in there). > Srini's patch used the "network" chassis subtype, which also seems like > misuse, as it is intended to be "and octet string that identifies a > particular network address family and an associated network > address" (using the IANA Address Family Numbers, for which "DPID" does > not have an entry!). > The network chassis subtype is definitely wrong. The only well known subtypes we can use are those that support arbitrary ASCII strings. > I was kind of trying to avoid it, but maybe we should actually Do The > Right Thing here and use the Organizationally Specific TLV. If we ask > nicely, maybe we can use Nicira's OUI? Martin? Using an OS TLV isn't necessarily the right thing - it further hides our data to no real end. It depends if you care to use other products to inspect the packets sent by NOX (and other controllers/switches), because most of them will take a pass on OS TLV contents, since obviously they don't know what they are. It might make sense to argue that we need an OpenFlow TLV or something, but that seems a bit outside the scope of NOX (and also begs the question of why use LLDP in the first place, as it puts us firmly in the space of repurposing a pre-OF protocol to do OF's bidding, which is a road that only leads in disaster). It might also just make more sense to define an OpenFlow discovery packet (preferably one that isn't restricted to ethernet as the transport layer) and use that. Interoperating with LLDP to the extent of handling LLDP packets that non-OF switches happen to send would be a good idea, but sending LLDP packets to perform our own somewhat non-LLDP discovery seems like a path fraught with peril in the long term. -- Nick
_______________________________________________ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
