Hi Jerry, On this point: '...I know (and the NSA can tell) what a fully specified STP is because it is in his local name table. But how does an NSA recognize an "underspecified" stp? ... ' I don't see why an under-specified STP can't be in the topology - after all we have not agreed what the topology looks like. So my feeling is that if a network advertises a 10GE port (under specified STP) then it should still be possible to request a VLAN on that port. This work as follows: RA sends a CS request for a VLAN service, giving one end as an STP for the 10GE port. The PA does its stuff and finds an available VLAN (this is pathfinding so is out of scope for the moment). The PA then sends back a CS confirmation to the RA with the STP of the Ethernet port replaced by the STP of the VLAN. Describing the mechanism of how this is achieved may be too advanced for V1.0, but I don't think should do anything to the protocol/WSDL to prevent this happening. Guy From: Jerry Sobieski [mailto:jerry@nordu.net] Sent: 21 April 2011 06:26 To: Guy Roberts Cc: nsi-wg@ogf.org Subject: Re: [Nsi-wg] minutes from today's NSI call Hi All- I apologize for missing the call today... The Internet2 Spring meeting had me wrapped up, and I just missed the call. I have read the minutes. I have two comments: 1. As much as I want to support the underspecified endpoints thinking, I really don't think we can in V1.0 ... To wit: Define an "underspecified" STP. I know (and the NSA can tell) what a fully specified STP is because it is in his local name table. But how does an NSA recognize an "underspecified" stp? And if the NSA can recognized it, how is it to resolve it into a "fully specified" STP? i.e. what does an "underspecified STP" mean? What are the semantics? Have we just started defining new topology structures? 2. AS for technology specific info in the STP. IMO, we should avoid this religiously - this breaks the NSI abstraction. Why would this even be necessary? The NSI connection service primitives are technology agnostic. Technology specifics may be found in the Service Request that are part of the Service Definition (e.g. MTU), but other than that, we should make sure the primitives themselves remain technology agnostic - including the names of endpoints. The Endpoint will always map to some topological location - *that* is where the physical or technology specific info should be found - not in the stp name itself. Admittedly, we can't stop a local NSA from encoding information in the local endpoint(s) names (e.g. name:="vlan100") but that is purely a local convention and of no significance to the other NSAs. Doing so may have human significance, but not NSI significance. If you encode technology specifics in the WSDL that defines an NSI Message, then you are adding information to the NSI message. That information therefore should be common to all Connection Services regardless of technology. So fundamentally, adding information to the WSDL that defines a NSI message is redefining the NSI message and is therefore considered a protocol addition. As a new protocol addition, it should be justified within the NSI protocol semantics, or should be expressly forbidden. Again - why would this even be necessary? All- If we keep the NSI-CS protocol faithful to the NSI abstractions, (Networks, Endpoints, Connections, and Services) we will be fine. The protocol works beautifully as is without last minute hacks. The CS primitives do Reservations and Provisioning. The issues of pathfinding are dependent on Topology - which we have not worked out yet. Be patient, and have confidence - the CS protocol is really well thought out as is. We will find that many of these issues go away or will be improved with the ensuing topology discussions...don't panic and try to wedge something in at this eleventh hour that we have not considered thoroughly. Thanks! Jerry On 4/20/11 1:36 PM, Guy Roberts wrote: The minutes from today's NSI call are available here: http://forge.gridforum.org/sf/go/doc16256?nav=1 _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts@dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________ _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org<mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg

Hey John- On 4/21/11 8:49 AM, John MacAuley wrote:

The interesting conclusion I came to in this whole discussion is that a fully qualified STP is actually an under qualified STP for the layer above. The real question we need to ask is if the connection services protocol should support the dynamic creation of new topological layers, or is it a stitching protocol such that we only interconnect already specified topologies. The fully qualified STP leans more towards a stitching model, where the under qualified supports the creation of new topology layers. So my key beef with all this is that we have begun discussing topology as a pre-requisite to getting V1.0 out the dor. And we've added another feature that was not a requirement. And as you indicate above, there are other aspects and implications we have not thought through.

None of these objections is about the quality of the concept proposed...just that its going to take additional thinking to vett it properly ...additional delay to the 1.0 spec that is unnecessary.

I think both "fully" and "under" have their place in the solution. I think the fully-qualified definitely has a place at E-NNI boundaries between networks to allow for predetermined (VLAN) connectivity and to reduce the need for technology specific negotiation between the domains during connection reservation. I can even see that administrators may want to use the fully-qualified STP on some client ports where limited connectivity options are needed. However, I also see great value in the under-specified STP at these client ports as well.

Guy is totally correct in his statement. Everything is solvable through the yet to be defined topology protocol ;-)

But we are requiring something in the spec that we have not defined yet...additional topological constructs.

John.

Jerry

On 2011-04-21, at 6:40 AM, Guy Roberts wrote:

...

Hi Jerry, On this point: ‘…I know (and the NSA can tell) what a fully specified STP is because it is in his local name table. But how does an NSA recognize an "underspecified" stp? … ’ I don’t see why an under-specified STP can’t be in the topology – after all we have not agreed what the topology looks like. So my feeling is that if a network advertises a 10GE port (under specified STP) then it should still be possible to request a VLAN on that port. This work as follows: RA sends a CS request for a VLAN service, giving one end as an STP for the 10GE port. The PA does its stuff and finds an available VLAN (this is pathfinding so is out of scope for the moment). The PA then sends back a CS confirmation to the RA with the STP of the Ethernet port replaced by the STP of the VLAN. Describing the mechanism of how this is achieved may be too advanced for V1.0, but I don’t think should do anything to the protocol/WSDL to prevent this happening. Guy *From:*Jerry Sobieski [mailto:jerry@nordu.net] *Sent:*21 April 2011 06:26 *To:*Guy Roberts *Cc:*nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> *Subject:*Re: [Nsi-wg] minutes from today's NSI call Hi All-

I apologize for missing the call today... The Internet2 Spring meeting had me wrapped up, and I just missed the call.

I have read the minutes. I have two comments:

1. As much as I want to support the underspecified endpoints thinking, I really don't think we can in V1.0 ... To wit: Define an "underspecified" STP. I know (and the NSA can tell) what a fully specified STP is because it is in his local name table. But how does an NSA recognize an "underspecified" stp? And if the NSA can recognized it, how is it to resolve it into a "fully specified" STP? i.e. what does an "underspecified STP" mean? What are the semantics? Have we just started defining new topology structures?

2. AS for technology specific info in the STP. IMO, we should avoid this religiously - this breaks the NSI abstraction. Why would this even be necessary? The NSI connection service primitives are technology agnostic. Technology specifics may be found in the Service Request that are part of the Service Definition (e.g. MTU), but other than that, we should make sure the primitives themselves remain technology agnostic - including the names of endpoints. The Endpoint will always map to some topological location - *that* is where the physical or technology specific info should be found - not in the stp name itself. Admittedly, we can't stop a local NSA from encoding information in the local endpoint(s) names (e.g. name:="vlan100") but that is purely a local convention and of no significance to the other NSAs. Doing so may have human significance, but not NSI significance. If you encode technology specifics in the WSDL that defines an NSI Message, then you are adding information to the NSI message. That information therefore should be common to all Connection Services regardless of technology. So fundamentally, adding information to the WSDL that defines a NSI message is redefining the NSI message and is therefore considered a protocol addition. As a new protocol addition, it should be justified within the NSI protocol semantics, or should be expressly forbidden. Again - why would this even be necessary?

All- If we keep the NSI-CS protocol faithful to the NSI abstractions, (Networks, Endpoints, Connections, and Services) we will be fine. The protocol works beautifully as is without last minute hacks. The CS primitives do Reservations and Provisioning. The issues of pathfinding are dependent on Topology - which we have not worked out yet. Be patient, and have confidence - the CS protocol is really well thought out as is. We will find that many of these issues go away or will be improved with the ensuing topology discussions...don't panic and try to wedge something in at this eleventh hour that we have not considered thoroughly.

Thanks! Jerry

On 4/20/11 1:36 PM, Guy Roberts wrote: The minutes from today’s NSI call are available here: http://forge.gridforum.org/sf/go/doc16256?nav=1 _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail:guy.roberts@dante.net <mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg

Found a small error this morning when updating the reserveRequest XML instance. Have attached all the files again. John. On 2011-04-24, at 11:37 PM, John MacAuley wrote:

I have attached an update XSD and both the interface and service WSDL. Please have a look at these new versions as there are some changes.

John. <ogf_nsi_connection_interface_1_0.wsdl><ogf_nsi_connection_service_1_0.wsdl><ogf_nsi_connection_types_1_0.xsd>_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg

Atsuko, I am so sorry I didn't take the time to run it through the compiler. This was an oversight on my part. I had removed the dependencies on the ogf_nsi_connection_faults_1_0.wsdl file but forgot to remove the imports. It just happened to pass validation since I left the fault file in my local directory :-( I have removed the associated imports and compiled the WSDL. The updated versions are attached. I will send a separate response on the asynchronous topic. John. On 2011-04-26, at 3:32 AM, Atsuko Takefusa wrote:

Hi all,

Jouh, could you send us "ogf_nsi_connection_faults_1_0.wsdl", please? I cannot generate stub files.

By the way, it might be too late,,, I have investigated on web services asyncronous call and I thought why we would not use the JAX-WS asynchronous invocation model. General WS development tools, such as Axis and CXF, support this model, which enables us to develop client and server codes easily and beautifully.

Thanks,

Atsuko G-lambda, AIST

2011/4/25 John MacAuley <john.macauley@surfnet.nl>:

...

Found a small error this morning when updating the reserveRequest XML instance. Have attached all the files again.

John.

On 2011-04-24, at 11:37 PM, John MacAuley wrote:

...

I have attached an update XSD and both the interface and service WSDL. Please have a look at these new versions as there are some changes.

John. <ogf_nsi_connection_interface_1_0.wsdl><ogf_nsi_connection_service_1_0.wsdl><ogf_nsi_connection_types_1_0.xsd>_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg

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

-- Atsuko Takefusa Information Technology Research Institute, AIST

Hi John, Thank you for sending us the updated wsdls. I will check them. I did not know implementation of the JAX-WS asynchronous invocation model at that time. But now, I want to use this model, as a developer. :) Thanks, Atsuko 2011/4/27 John MacAuley <john.macauley@surfnet.nl>:

Atsuko, You are correct in that the JAX-WS 2.0 asynchronous invocation model is an elegant solution and it can be used on the existing synchronous WSDL definition by annotating the service definition binding with "<enableAsyncMapping>true</enableAsyncMapping>".  This will let you utilize the JAX-WS asynchronous interface with the existing synchronous WSDL message interaction. Can I assume you want to take this one step further and use the WS-Addressing asynchronous message exchange?  For those in Hong Kong you may remember be discussing WS-Addressing in one of the presentations.  I had thought about using it, but I was concerned implementation compatibility, and peoples willingness to move away from the synchronous pattern.  This was why I simulated a similar mechanism using the synchronous model, and putting the replyTo address and a transactionId in the message specification. I am open to revisiting the topic as it will only change the WSDL specific files. John. On 2011-04-26, at 3:32 AM, Atsuko Takefusa wrote:

Hi all,

Jouh, could you send us "ogf_nsi_connection_faults_1_0.wsdl", please? I cannot generate stub files.

By the way, it might be too late,,, I have investigated on web services asyncronous call and I thought why we would not use the JAX-WS asynchronous invocation model. General WS development tools, such as Axis and CXF, support this model, which enables us to develop client and server codes easily and beautifully.

Thanks,

Atsuko G-lambda, AIST

2011/4/25 John MacAuley <john.macauley@surfnet.nl>:

Found a small error this morning when updating the reserveRequest XML instance.  Have attached all the files again.

John.

On 2011-04-24, at 11:37 PM, John MacAuley wrote:

I have attached an update XSD and both the interface and service WSDL.  Please have a look at these new versions as there are some changes.

John.

<ogf_nsi_connection_interface_1_0.wsdl><ogf_nsi_connection_service_1_0.wsdl><ogf_nsi_connection_types_1_0.xsd>_______________________________________________

nsi-wg mailing list

nsi-wg@ogf.org

http://www.ogf.org/mailman/listinfo/nsi-wg

_______________________________________________

nsi-wg mailing list

nsi-wg@ogf.org

http://www.ogf.org/mailman/listinfo/nsi-wg

-- Atsuko Takefusa Information Technology Research Institute, AIST

-- Atsuko Takefusa, Ph. D. Information Technology Research Institute, AIST