|
Alia, Hmmm. 10 years ago is
not (relatively) new? J I believe that – if we bring in some other examples – converged
networking is still an ongoing process. And PWE3 has been affected (in minor ways) by this process. See additional responses
below… From: Alia Atlas [mailto:akatlas@xxxxxxxxx]
Eric, On Sun, Mar 9, 2014 at 6:02 PM, Eric Gray <eric.gray@xxxxxxxxxxxx> wrote: Alia, I assume that this is a change of subject in part to demonstrate that we But the question is a reasonable example whether that is the case or not. It's something that struck me as being interesting to discuss and having general appeal and benefiting from the perspective of many areas. :-)
Yes, I agree that identity separation is a driver. I'm not as persuaded that converged networking is driving new overlays and encapsulations - just b/c pseudo-wires have been around for about 10 years. Network convergence is an ongoing process, even now. Admittedly, the changes
driven by this are mostly small – though arguably that is an artifact of the fact that changes required to deployed equipment MUST be "mostly small" and this means that we may choose a solution that involves small changes over one that might have been a better long-term choice.
I'm, of course, more interested in whether there are common drivers and whether all the solutions need to be point solutions or are more generalizable. The answer to this only seems obvious. Ideal solutions are completely generalizable for all applications, both those that exist now, and those that may come. Then along came reality. Point solutions have the advantages of being simpler to implement (taken one at a time, of course) – i.e. – lower-cost, simpler testing associated with incremental
changes and earlier delivery. From a strictly business perspective, point-solutions are also easier to justify as each such solution can be easily tied to a specific customer need (hence revenue opportunity) and early delivery means a faster ROI – but here I stray from purely
technical discussion. In addition, each point solution deployed becomes part of the "field" against which future changes MUST be compared for compatibility reasons – because (for additional non-technical reasons) we cannot simply wish them away. Hence generalization – while a goal – is not something we can easily apply to a problem space (that has been partially solved in deployments) after the fact. This is the reason why we currently have so many RFCs. Many (possibly most?) of them could be considered point solutions. We could probably come up with a single generalized RFC to replace them all. Chances are good it would be lots simpler – especially if it included function sub-setting, appropriate capability negotiation, etc. AND assumed compatibility with existing solutions was not a requirement.
It WOULD be interesting to see how the RFC Editor would deal with the list of obsoleted RFCs. Possibly by saying "see Appendix X."
We would then have a generalized solution to all networking problems and no
hope that anyone would use it in our collective lifetimes. So it is likely that the best approach is to work toward a "point-solution" that is generalized for the uses about which we are aware and compatible with the cumulative "point-solutions" we know about. I think we all agree that for this to be useful, it MUST also be timely – which means we have to decide at some point that we "have enough information" and get started. And then we can look forward to a series of point solutions to address what was out there, but we were not aware of. This can be particularly difficult
when nobody is very willing to talk about what is "out there." Point solutions – depressing as it may seem – are what us less-than-perfect people have to look forward to. -- Eric
|