Jeroen van der Ham wrote:
Jeroen van der Ham wrote:
In absence of a better identifier I suggest using a URL to the standard. Or the group that wrote the standard if none is available. I agree that this is incredibly annoying, and that we'll probably have to maintain a list with identifiers for technologies. But we can't just make stuff up while referring to other standards organisations.
This actually raises an important point, that was also identified during an NSI call today: how do we make sure that different networks will use the same identifiers for technologies and adaptations?
IMO, we can't go the GMPLS way and define what identifiers can be used. This would mean that we would have to standardize a list of identifiers, and keep it up to date as new standards evolve.
We also can't directly use the identifiers of GMPLS, because we use different model.
And unfortunately, there does not seem be to be a simple way of determining identifiers for technologies and adaptations. Even the URLs above took me some time to find and are somewhat arbitrary.
Does anyone have an idea on how we could solve this?
[Freek steps on his soap box] Let me ask: what are we trying to solve exactly, and why do you dismiss the enumeration approach of GMPLS? In my view, we want to create a model that is strongly forward compatible. That means that NO SOFTWARE SHOULD BE UPDATED IF A NEW TECHNOLOGY COMES ALONG. After all, we are explicitly dealing with multi-domain, and we can not expect our neighbour to upgrade their software if our network moves to some fancy new technology. Let me rub in the fact that nearly everyone things IPv4 has reached its limit, and IPv6 is the accepted predecessor. Still, it has OVER 10 YEARS and still MOST ISPs have NOT updated their software. And that is easy compared that what we are doing (after all, what router does not support IPv6 these days) CCAMP dealt with this by modelling everything as a list of parameters in GMPLS. Every technology gets a number. That's it. In my view, the best approach is that software is able to dynamically load new technologies, and to make it possible to do the same reasoning as it did before. In fact, enumeration does work that way. Let's assume you see a Switching Type of value 38. Now, you know this is not defined at http://www.iana.org/assignments/gmpls-sig-parameters. However, you DO know that it is a switching matrix at some unknown new layer, and you still can reason about it. Problem solved, right? So why do I still agree with Jeroen that enumeration is not the way to go? Well, we deal with research networks, experimental networks, so I will take it even a step further: NO NML EXTENSION SHOULD BE NEEDED IF A NEW TECHNOLOGY COMES ALONG. So, indeed, NO standardization action by defining a new number. No IANA. So If network X want to use PBB though it is not defined, they should be able to make their own PBB technology definition, and if network Y wants to use MPLS-TP, they can create their own technology definition. This is the same as that X defines parameter 27 and network Y defines parameter 38 for PBB and MPLS-TP respectively. The problem arises when network Z comes along and defines their own definition of PBB. In GMPLS terms, what if they would define parameter 19 for PBB? In my view three things need to happen: - Software must be able to understand new technology definitions. Much like a new number comes along in GMPLS. - These definitions should be dynamically loaded (pull/push/...) by software. (In NDL, this is done by pointing to a URL with a technology schema). - Whoever defines these schemas should be able to define equivalence relations between technology definitions. The last point is important: everyone can just make a definition, and start using it. The word will spread, and other people will start using that technology definition. If multiple people define the same technology, one can define an equivalence relation and thus resolve the just created incompatibility. The hard part is how to define equivalence when different sublayers are used. For example, if X defines one Ethernet layer, while Y defines 4 layers (MAC layer, C-VLAN layer, B-VLAN layer and I-SID layer). This is hard, but not undoable. In fact, even when we do require a standardization action, I claim that WE MUST DEFINE EQUIVALENCE RELATIONS FOR ADAPTATIONS Imagine we have a world with Ethernet over fiber. Everyone describes that as two layers: Ethernet layer and fiber layer. Now some smart guy (O.E. DeLange if not for my mix up in chronology) comes along and introduces two wavelengths on the same fiber. So now we have three layers: Ethernet over a wavelength over a fiber. Surely we do not want to update all software to deal with this change, but instead tell them that "Ethernet over fiber" is really equivalent to "Ethernet over a wavelength over a fiber" This is not new, Figure 13 in G.805 deals with this (I don't think this is repeated in G.800). Now it is up to us to define a syntax how to deal with this. [Freek leaves his soap box] Now, I intentionally took my views to an extreme, I do appreciate your rebuttal. Looking forward to it, Freek