[Nml-wg] Dealing with unknown relations

[Jeroen van der Ham]

Hi,

On 17 Aug 2012, at 14:57, Freek Dijkstra <freek.dijkstra at sara.nl> wrote:
> I like NML to be extensible. For example, if some NML publisher likes to
> add information that benefits monitoring or provisioning, that should be
> possible.
> 
> A NML receiver should silently ignore this added information. However,
> we also don't want a receiver to just accept anything. If there is some
> obvious error in the NML, the receiver should still just reply with an
> error message.

I am not entirely sure that we can reasonably make this distinction. And even if we can, without bloating the current schema into probably twice its current size.

> Imagine a receiver that receives some NML line containing a relation.
> 
> 1. The relation is well-defined.
>   e.g. Node N --hasService--> SwitchingService S
> 2. The relation is unknown
>   e.g. Node N --hasDynamicService--> SwitchingService S
> 3. The relation is clearly invalid
>   e.g. Node N --hasService--> Node Y
> 4. The relation is known, but the meaning is undefined
>   e.g. Port P --hasService--> LabelService L
> 
> Should we make a distinction between 3 and 4?
> 
> For the purpose of extensibility, I would argue that it is useful to
> make this distinction.
> 
> In fact, the current document makes this distinction. To quote the text
> on "hasService":
> 
>> hasService relates a Network Object to a Service. This schema only
>> defines the meaning of:
>> • Port to AdaptationService, relating one server-layer Port to an
>>  adaptation function
>> • Port to DeadaptationService, relating one server-layer Port to a
>>  deadaptation function
>> • Node or Topology to SwitchingService, describing a switching
>>  capability of that Node or Topology.
> 
> So in this case "Port P --hasService--> LabelService L" would be
> syntactical VALID NML but with UNDEFINED meaning. "Node N
> --hasService--> Node Y" would simply be syntactically INVALID NML.

I am not sure how you make that distinction based on the description given above. For both Port and Node there is a possible "hasService" relation defined, and neither "LabelService" nor "Node" are defined as possible ranges of the hasService relation.

Just the fact that "LabelService" is a new kind of object should not make it different.

> Regardless if we think this distinction is useful, we should define how
> a NML receiver should handle the information. I can think of four
> situation what it should do with it:
> a) reject the line and reply with an error message
> b) accept the line and process it (for an known relation)
> c) silently drop the line
> d) store the line, even though it is unknown
> 
> I'm not sure if (d) is ever a good idea. It means that a receiver will
> accept a Topology from T, and store all, including unknown statements,
> and if asked by someone else, it would faithfully replicate the original
> topology, including all unknown statements.

D is a very well established way of handling things which is also applied to OSPFs extension fields for example. It is an excellent way of easing a new kind of relation into the system without having to rely on a flag-day where everyone switches over.

Silently dropping is a really bad idea, which makes diagnostics a nightmare.

I am very much in favor of always accepting and storing.

Jeroen.