[Nml-wg] Forward compatibility
Freek Dijkstra
Freek.Dijkstra at sara.nl
Wed Aug 12 14:39:12 CDT 2009
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
More information about the nml-wg
mailing list