[Nsi-wg] updated STP proposal

Freek Dijkstra Freek.Dijkstra at sara.nl
Tue Jul 31 10:43:48 EDT 2012


Hi Guy,

I have a few questions as well.

First a remark.

> I don't see why the localId needs to be a full URN.  The full URN can
> be easily resolved by looking at both the localId and the NetworkId.
> Could you please explain this requirement further?

For NML compatibility, where the the Port ID is a single full URI,
rather than a NetworkId, localID tuple. (As said earlier, if you like a
tuple to quickly identify the Network, you can simply use two URIs --
there are admittedly more elegant solutions, like using DDNS to find the
Network ID, but it is more flexible and the complaint that it looks
uglier can easily be remedied by hiding the prefix part in a user
interface).

Now you need to translate between the localID and NML identifier. I am
missing that mechanism in your proposal, and recommend to add that part.

> "- Why has the definition of an STP changed? Last I heard these would be uni-directional to be able to map to NML Ports, and this would also solve the ERO direction ambiguity."
> I tried to pitch the STP as a grouping of 2 uni-directional ports, but no one in the working group liked this (except for NML to make their mapping easier), so it was dropped.

I must say I'm actually very disappointed with the current proposal.

While I can see the point about the localID above, I just don't see any
advantage over the previous proposal with a source Port and destination
Port per STP. That proposal had three distinct advantages:
* Direction is completely unambiguous
* Supports all sorts of connections (bidirectional, unidirectional,
  point-to-multipoint, multipoint-to-multipoint, with and without ERO)
* simple one-to-one mapping with NML (I frankly don't see a way to make
  this NML compatible)

What was the rationale of this decision?

Regards,
Freek



More information about the nsi-wg mailing list