[Nsi-wg] Some recommendations about layer adaptations

[Jerry Sobieski]

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: NSI multilayer processing.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 986724 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20131111/af9e09f0/attachment-0001.docx>