Hi Jeroen, Thanks for taking time to review the STP proposal. Some feedback to your questions: "- Why has the definition of the local id been changed? The last I heard was that these would be full URNs which could be mapped separately to NML Port identifiers." 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? "- 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. Guy -----Original Message----- From: Jeroen van der Ham [mailto:vdham@uva.nl] Sent: 31 July 2012 12:43 To: Guy Roberts Cc: nsi-wg@ogf.org Subject: Re: [Nsi-wg] updated STP proposal Hi, I'm trying to catch up on the progress since I went on holiday, so please allow me to ask some obvious questions: - Why has the definition of the local id been changed? The last I heard was that these would be full URNs which could be mapped separately to NML Port identifiers. - 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. Jeroen. On 30 Jul 2012, at 18:12, Guy Roberts wrote:

Hello all,

Please find attached a re-worked proposal for STPs based on input that I have received from Tomohiro Kudoh and Jerry Sobieski last week.

Guy

_____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK +44 1223 371316

DANTE is the project co-ordinator and operator of GÉANT, the high-speed pan-European research and education network that is transforming the way researchers collaborate. Learn more at: www.geant.net<http://www.geant.net/> Like us on: www.facebook.com/GEANTnetwork<http://www.facebook.com/GEANTnetwork> Follow us at: www.twitter.com/GEANTnews<http://www.twitter.com/GEANTnews>

DANTE is the trading name of Delivery of Advanced Network Technology to Europe Limited registered in England & Wales. Registration Number 2806796. Registered Office - 9400 Garsington Road, Oxford Business Park, Oxford OX4 2HN. _____________________________________________________________________

<STPs_summary6.docx><STPs_summary6.pdf>_______________________________ ________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg

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