Agreed, By programmable flows, if i understand correctly what you are referring to is applications programmable flows (else flows have always been programmed...). This pushes complexity up into the application layer, which challenges if identified and adrressed could result in powerful paradigms in networking and its operations (self -*?) IRTF could address these... What are flow decisions applications would like to make an OSS system specould be one eager candidate for the same (maybe work with TMF on it...)s? Overlays can be good and bad, good for backward compatibility, scaling, bad for the certain rigidity it brings to the architecture...yes, overlays in one aspect (control) could lead to a homogenization in the other (flows) and possible vice versa. Related to global awareness, Vint gave a couple of examples yesterday, dealing with context awareness...in making speech recongintion tractable, and wearable computers....This is a powerful concept indeed...and application controlled flows allows precisely this, to bring context awareness into routing decisions...it is like the applications are walking around wearing routers on their heads! Wearable routers for applications! I wonder if defintion should come before conceptualization or the other way around...maybe it should be overlayed, when and at what point....? Sitaraman
> Right, but designers (there's lots) could use a few simplec grorund rules. > > Flows have always been a part of switch-router designs, > time to open them up for programming, in itself not a trivial task - > as can be seen from the various bug queries in this list. > > Overlays - well, at least youi know they don't break basic connectivity, > rather they use it and interject additional logic in well defined edge > points. > > Global awareness - that's the most tricky part, it could use a simple > definition and a resilient structure of how it's used and how it works. > "Controller" isn't such a definition. > > > On Jan 25, 2013, at 10:32, sitara...@nmsworks.co.in wrote: > > I believe in one thing... > simplicity must always occur as a result of addressing and hiding > complexity, there is no free lunch as they say, simplicity in itself > without someone somewhere identifying, addressing and hiding for the > clients, the complexity...well simply will have true little true value > addition is what i feel...simplicity is for the users complexity is for > the designers....the more the complexity is identified and addressed, the > more the world will enjoy simplicity as a result.... > Sitaraman >> [not sure which lists you were trying to post to, so I added >> s...@irtf.org] >> >> >> I'll just note here as a general comment that part of the success (and >> really, beauty) of the IP architecture is its inherent simplicity. If >> SDN becomes a dumping ground for *gratuitous* complexity (as we are >> currently seeing in many venues) then it will fail. >> >> --dmm >> >> >> On Fri, Jan 25, 2013 at 10:08 AM, <sitara...@nmsworks.co.in> wrote: >>> We had Vint Cerf himself visit and talk to us today evening. >>> Amongst others, he highlighted to us Openflow and SDN allowing routing >>> based on content in addition to headers. >>> My immediate reaction was question that this being an antithesis to >>> standardization.....then Vint mentioned an example about routing based >>> on >>> charactersitics of the data and routers selectively choosing to listen >>> (per my understanding of what Vint said, not certain i got it >>> entirely.) >>> Could we say that the conventional protocols are more leaning towards >>> syntactic standardization (Bits in header fields have tightly defined >>> ranges and constructs). >>> Has Semantic standardization, pattern matching been done before at >>> IETF/IRTF? >>> Any relationship to Ontologies? >>> ARe the implications to correctness, convergence, routing loops and >>> such >>> of algorithms in this context been formally studied? >>> Would it make sense to start halfway and have two header components, >>> one >>> decided by the protocol and the other header components contents >>> decided >>> by the application itself (this will form a special part of the data). >>> yet this part of the data being in a well defined restricted area of >>> the >>> data..is this beginning to look like optical network framing where >>> frame >>> at one layer is data for the other? Combine this with NMS based >>> routing, >>> (decoupled control of SDN) SDN is beginning to get a lot of the >>> charactersitics of Optical then? >>> Sitaraman >>> >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>> >>> _______________________________________________ >>> openflow-discuss mailing list >>> openflow-discuss@lists.stanford.edu >>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > sdn mailing list > s...@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
