It seems obvious that a discussion and some decisionmaking is needed on this issue at some point, though I'm not sure how interested anyone is in having that day be today. It certainly was not my intention to kick that off. :)
Let me clarify my thinking a bit. First off, we have the following: 1) The chassis ID TLV is currently being abused a bit by NOX 2) .. and things aren't working right (with some DPIDs) These are two evils. The intention of my patch is to lessen the amount of evil in the world by doing the following: A) Resolve #2 by actually working right B) Maybe abuse the chassis ID TLV a bit less (a very secondary concern) by using a "local" type which other things may be less likely to misinterpret So my primary question is: does it accomplish this? Does anyone see any way in which it is WORSE than the situation we currently have? Secondarily, is there an advantage to us "standardizing" a bit here? If you think the System Description TLV is a suitable place for it, okay. Could we at least format it as a hex string with a distinguishing mark like my patch does for the chassis ID (e.g., "dpid:a0b1c2d3e") rather than jamming eight random bytes into a field meant to "contain an alpha-numeric string that is [a] textual description"? -- Murphy On Tue, 2010-11-16 at 00:33 -0500, Nicholas Bastin wrote: > 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
