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