Hi folks -
Attached is a document that was posted to the NSI list almost two years
ago about the complexities of adaptations. It is still 98% accurate and
relevant.
This topic of adaptation and switching capabilities does not seem to me
to be an urgent issue. And its complexities are becoming quite evident.
I understand why some engineers want to be able to hop layers - but
while I understand it, IMO its just unnecessary. I strongly assert that
we are putting a lot of hacks into the topology, the service
descriptions, and NSI to do this before we have really thought all the
issues through and that what we are inserting into this NSI standard
will not in fact do what you expect or hope it will.
I suggest that we shelve the issue as part of v2 and address the issue
more formally in v3. So, in V3 we should create a feature called
"service adaptation for automated pathfinding" and define its real use
cases/needs - and from those use cases identify a set of basic and
fundamental requirements that must be met - in the NSI protocol, in NML,
in Service Descriptions, in Best Practice, ... And then decide how
best to implement them in a way that scales effectively, supports
provider autonomy, is secure, and above all is as simple as possible.
And I would also assert that we find a way to allow these services to
become more sophisticated incrementally - too much required on Day One
makes it difficult to deploy. I suspect we will find many many
aspects of this [adaptation/swithcing capabilites] that break (e.g. what
if a transit network does not advertise certain functions?). And many
aspects that are related (e.g. looping) that must be solved in
conjunction, or that pose an alternative mechanism (e.g. topology
distribution) and unexpected complexities (e.g. unidirectional vs
bi-directional topologies or circuit requests, multi-point circuits, etc.)
The reason I suggest that the automated adaptation issue is not urgent
is because we are presently already able to take advantage of
multi-layer services by means of abstraction and apriori tunneled
adjacencies in the topology. (See the attached document.) And we can
do this with dynamic provisioning at each layer - if not between layers.
This may not be glorious automated pathfinding, but it none-the-less
lets us take advantage of underlying service layers for the near term
and where it is truly necessary while we take a more thoughtful and
comprehensive look at the actual requirements and full range of
mechanisms for automated multi-layer provisioning on the global basis.
I also think this issue has (yet again) polluted the NSI *Service*
oriented concept by falling back into traditional concepts of hardware
plumbing based thinking. We need to get away from this traditional
fixation on hardware technology and stay focused on the service
presentation of these network service domains. There is no real need to
deal with the hardware issues at the global service layer. I strongly
suggest that if we would just try to do this as utterly simply as
possible -i.e flat consistent service regions - at least initially - we
will find that 99% of all issues are satisfactorilly resolved. And any
additional adaptation considerations are being made much more complex
because we do not have an established and generalized model of a flat
service regions/layers from which to make generalized adaptation
extensions. We actually need these simple flat contiguous service
regions as a generic foundation before we can effectively develop viable
or scalable models for adaptating between these layers (right now we are
thinking about hardware adaptation - not service layer adaptation!) By
adding all of these hacks we are actually making adatation much more
convoluted and difficult to handle and we will be rethinking it all in
v3 anyway. We really REALLY need to slow down and think the issues
through.
If we push the adaptation issue and "switching capability" issue to V3,
and for v2 commit to a simple flat contiguous service regions we do two
things: We get a viable service on the air that 90% of all NRENs will
be able to actually deploy and users care about, and we gain real first
hand experience on what the service really needs in order to be
successful on a global basis. THe adaptive switching is an
optimization for which we have no established services yet to optimize.
(We could go through al of these hacks onyl to find SURFnet is the only
network that needs them (SURF is just an example:-).) We can use the
actual experience to inform and weigh those actual uses cases that we
think are so important. It is much more important at this stage that we
have a single user oriented service region broadly deployed globally,
than to have these adaptations - the adaptions are causing significant
delays to publishing and deploying these services.
And I will bet you we find that most of our traditional thinking about
multi-layer adaptation breaks down in the NSI service oriented model and
becomes moot - an anachronistic habit from older technologies that is no
longer particularly meaningful (just like protection switching vs
reliability modeling...) We are trying to recreate old solutions to old
technology issues. And as I say too often - we are making the problem
*MUCH* more difficult than it has to be.
So please review the attached document if only for informational
purposes. And I propose that we shelve the adaption/switching
capabilities issues and extract them from v2, and put them on the
discussion list for v3.
Best regards
Jerry
