[Nml-wg] Forward compatibility

[Freek Dijkstra]

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