Hi,

Our uPA at SURFnet also has NSI CS 2.0 support. I have an instance available for testing on our acceptance server.

NSI CS 2.0 WS endpoint can be found at https://bod.acc.dlp.surfnet.nl/nsi/v2/provider

providerNSA is urn:ogf:network:nsa:surfnet.nl

With two STPs available for testing:

urn:ogf:network:stp:surfnet.nl:3881
urn:ogf:network:stp:surfnet.nl:3884

There is actual hardware behind these STPs so the dataPlaneStatus will reflect the actual state in the network. There is no need to specify VLANs, internally we map the STPs to VLANs if needed (depends if it is an EPL of EVPL port).

This uPA also accepts NSI CS 1.0CS messages and still uses the old STP specification, this makes the sourceSTP and destSTP specification (see below) a bit odd for now, but this will be fixed soon of course.

                    <sourceSTP>
                        <networkId>urn:ogf:network:stp:surfnet.nl</networkId>
                        <localId>3881</localId>
                    </sourceSTP>

We only support Bidirectional paths.

Please note that we use OAUTH2 access tokens for authorization. You can specify the token in the HTTP header as shown below, the token shown is the token to be used to access the above two STPs.

POST /nsi/reserve HTTP/1.1
HOST: bod.surfnet.nl
Authorization: bearer 78e18baa-6cef-40df-a6a1-089849b35f0a
Content-Type: application/soap+xml; charset=utf-8

<?xml version="1.0" ?><soap:Envelope
    .....

We are working on auto generating the new style topology, I will let you know when this is available.

Looking forward to test with you and sort out the bugs together. Please contact us using bod-dev at list.surfnet.nl.

Cheers,
HansT.

On 7/2/13 1:22 PM, Henrik Thostrup Jensen wrote:

Hi everyone

Might as well get started with this :-)

I have a NSI2 provider endpoint here: http://nsidev.nordu.net:9080/NSI/services/CS2

NSA name: urn:ogf:network:nsa:northernlight

It manages a network named: urn:ogf:network:northernlight

It has the following ports:

ps
netherlight
uvalight

These are all bidirectional, and ethernet vlan ports. They expect a vlan type attribute with a value, which can be a range, i.e.:

               <sourceSTP>
                  <networkId>urn:ogf:network:northernlight</networkId>
                  <localId>urn:ogf:network:northernlight:ps</localId>
                  <labels>
                     <ns3:attribute type="vlan">
                        <value>2-3</value>
                     </ns3:attribute>
                  </labels>
               </sourceSTP>

They support the VLANs 1780-1783, but I have a bug in the label selection, so right now you can specify whatever, but I'll get that fixed :-). There are definitely bugs in this thing, so don't be too surprised if you find something.

There is also a topology resource available here:
http://nsidev.nordu.net:9080/NSI/topology/northernlight.xml
There are however known structural errors in this, so for now it is just for show.

If anyone else has provider endpoints ready for testing, post them to mailling list or just me, and I'll give them a go :-).

    Best regards, Henrik

Henrik Thostrup Jensen <htj at nordu.net>
Software Developer, NORDUnet

_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg