Hi, I would say that NOX is trying to discover the logical network, not virtual network. NOX holds no concept of a virtual network. What it needs to know is if the network/datapath can forward packets along a certain link or not. As long as the physical switches or network hypervisor (aka FlowVisor) consistently forward or block packets, the LLDP strategy works fine.
I would be very careful to ensure NOX (or any OpenFlow controller for that matter) does not have explicit idea of whether it is operating on a virtual or physical network. Yes, admittedly there is a good amount of idealism here. But this is critical as OpenFlow grows. Early clutter often results in further headaches (and also papers to write). Back to topology discovery, I do not think LLDP from the controller is the future. But a proposal for an alternative at the datapath level was shot down for inclusion to OpenFlow 1.0. There is a good amount of similarity in the mechanisms between link fault detection and topology discovery. I would imagine a joint mechanism/primitive at the datapath is the right thing to do (because fault detection is delay sensitive). That's my humble opinion on this. Regards KK PS>> Perfecting a hack is not my cup of tea/coffee. On 15 November 2010 22:08, James "Murphy" McCauley <jam...@nau.edu> wrote: > 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 > _______________________________________________ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
