> > I would imagine a joint mechanism/primitive at > the datapath is the right thing to do (because fault detection is > delay sensitive). > > Yes, I'd like to second that. Although, I wasn't closely involved in the discussions, and it seems like the idea of a BFD-like protocol on the switch was rejected as hard.
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 >
_______________________________________________ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
