Network portion of an STP
Peoples, What am I suppose to put in the network portion of the STP? I was looking in the topology schema and there is nothing specifically called "network" so should I assume it is the topology URN? networkId = "urn:ogf:network:example.org:2013:topology" As a follow-up, do I also then populate the local portion with the full URN of the port? localId = "urn:ogf:network:example.com:2013:eth0-out" Thank you! John
Hi, On 18 Jul 2013, at 22:10, John MacAuley <john.macauley@surfnet.nl> wrote:
What am I suppose to put in the network portion of the STP? I was looking in the topology schema and there is nothing specifically called "network" so should I assume it is the topology URN?
networkId = "urn:ogf:network:example.org:2013:topology"
I guess we have been using the term Network a lot without explicitly saying what it means. If you mean the data plane, then indeed you should go with the topology. If you mean the actor, the NSA id may be a better fit.
As a follow-up, do I also then populate the local portion with the full URN of the port?
localId = "urn:ogf:network:example.com:2013:eth0-out"
That's what we agreed on, yes. Jeroen.
Hi Jeroen, On 7/19/13 8:49 AM, Jeroen van der Ham wrote:
On 18 Jul 2013, at 22:10, John MacAuley <john.macauley@surfnet.nl> wrote:
As a follow-up, do I also then populate the local portion with the full URN of the port?
localId = "urn:ogf:network:example.com:2013:eth0-out" That's what we agreed on, yes.
The definition from the documentation (version 1.4 of July 29, 2013) says: localID = A locally unique identifier for the STP within the associated network. So no need to make this Id globally unique by adding a URN. And the original reason to split the STP Id into a networkId and a localId was to make it easier to parse. So why do you now want to add the URN again to the localId? HansT.
On 12-08-2013 14:45, Hans Trompert wrote:
Hi Jeroen,
On 7/19/13 8:49 AM, Jeroen van der Ham wrote:
On 18 Jul 2013, at 22:10, John MacAuley <john.macauley@surfnet.nl> wrote:
localId = "urn:ogf:network:example.com:2013:eth0-out"
That's what we agreed on, yes.
The definition from the documentation (version 1.4 of July 29, 2013) says: localID = A locally unique identifier for the STP within the associated network.
I have not followed the NSI discussion closely, but I presume the reason is there is a need to map the STP to the NML topology, in NML the STP is represented as a URN, and unfortunately, is no unique way to convert the local ID to a URN. network + local ID does not need to be equal to the URN of the STP. The reason is that in NML the associated network does not need to be unique. A network For example, the STP in Nordunet that is connected to Internet2 may be part of both "Nordunet" and "Nordunet-USA" (where "Nordunet-USA" is part of the "Nordunet" network). Regards, Freek
Hi Freek, On 8/12/13 8:11 PM, Freek Dijkstra wrote:
On 12-08-2013 14:45, Hans Trompert wrote:
Hi Jeroen,
On 7/19/13 8:49 AM, Jeroen van der Ham wrote:
On 18 Jul 2013, at 22:10, John MacAuley <john.macauley@surfnet.nl> wrote:
localId = "urn:ogf:network:example.com:2013:eth0-out" That's what we agreed on, yes. The definition from the documentation (version 1.4 of July 29, 2013) says: localID = A locally unique identifier for the STP within the associated network. I have not followed the NSI discussion closely, but I presume the reason is there is a need to map the STP to the NML topology, in NML the STP is represented as a URN, and unfortunately, is no unique way to convert the local ID to a URN.
network + local ID does not need to be equal to the URN of the STP.
The reason is that in NML the associated network does not need to be unique. A network For example, the STP in Nordunet that is connected to Internet2 may be part of both "Nordunet" and "Nordunet-USA" (where "Nordunet-USA" is part of the "Nordunet" network).
Thank you for your answer. Jerry also gave me an elaborate answer on this topic explaining that because we use NML for topology descriptions the localId needs to be globally unique URN. To avoid future confusion it might be a good idea to slightly change the NSI CS 2.0 documentation on this topic. Cheers, HansT.
participants (4)
-
Freek Dijkstra -
Hans Trompert -
Jeroen van der Ham -
John MacAuley