From t.kudoh at aist.go.jp  Wed Feb  1 10:14:08 2012
From: t.kudoh at aist.go.jp (Tomohiro Kudoh)
Date: Thu, 2 Feb 2012 00:14:08 +0900
Subject: [Nsi-wg] summary of Ad-hoc NSI f2f meeting at Joint Tech 2012
	Winter:
Message-ID: <CAEGiyHv8ZNrPG9e6fbR-+wTkmLaesNVRxSiVK5193SqWhDAiiA@mail.gmail.com>

Ad-hoc NSI f2f meeting at Joint Tech 2012 Winter:

Present:
Chin Guok
Hans Trompert
Jeroen van der Ham
Jerry Sobieski
John MacAuley
Tom Lehman
Tomohiro Kudoh
Xi Yang

There was consensus on the following:

1. An STP can have 0 or more <type,value> tuples ?=>
STP (<network_id>, <local_id>, <type_1,value_1>, .. , <type_n,value_n>)
? ? ?- e.g. STP (NetA, EndPt1, port, 1000, vlan, 123)
? ? ?- open question on how tuples can relate to one another, e.g.
port? 1-4 have vlans 1-4

The STP specification incorporating the <type,value> tuples is still
just a STP *identifier*. ? I.e. this in itself does not imply that
these?values are in any way related to specific technology or hardware
features.

On the other hand, <type,value> tuples can be used to define
capabilities. The capabilities can describe technology, hardware,
policy, or other limitations.

The value of the "type" string is not defined as part of the NSI CS
standard, i.e. it is defined as part of the service definition. ?The
NSI?CS standard only codifies the presence of <type,value> pairs as
part of?the STP identifiers. It is up to the provider (PA) to define
them. However,?we do expect that there will be a best-practices
document describing?some <type,value> combinations and capabilities.

2. The <value> filled can be an individual value or a range
? ? ?- if a <value> is a range then it is a "STP_Bundle"
? ?I.e., these tuples may also be used to specify constraints that
identify a set of STPs.

3. Open question on how we can describe constrains for STPs, e.g.
? ? ?STP (NetA, EndPt1, <port, $1>, <vlan, $2>)
? ? ?STP (NetA, EndPt1, <port, $3>, <vlan, $4>)
? ? ?Capabilities: $1 != $3, $2 = $4 ?=> no vlan translation

4. Open question on how we can describe and bundle SDP

From imonga at es.net  Wed Feb  8 02:59:49 2012
From: imonga at es.net (Inder Monga)
Date: Tue, 07 Feb 2012 23:59:49 -0800
Subject: [Nsi-wg] Call Tomorrow and Agenda
Message-ID: <4F322B75.10202@es.net>


Hi all,

The following is dial-in information for Wednesday's NSI call, time: 
7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET,  24:00 JST

1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International 
participants dial: Toll Number: 303-248-0285  Or International Toll-Free 
Number: http://www.readytalk.com/intl 3. Enter 7-digit access code  
8937606, followed by "#"

Agenda:

1. Firewall issues: John Macauley
2. Error Handling: Henrik
3. Other topics

Thanks
Inder


Henrik's email attached:

-- 


Failure scenarios and recovery for the NSI protocol version 1.0 and 1.1

== Introduction ==

The main focus will be on the control plane interaction, and how to deal 
with
message loss, crashes, and how to recover from them.

With the exception of the forcedEnd primitives, all NSI control plane
message interactions happens like this:

Requester NSA               Provider NSA

operation               ->
<-  operation received ack
<-  operation result
operation result ack    ->

The main idea between the separation of the operation and operation 
result is
that they may be separated by a significant time, especially the provision
operation which can be separated with several days or months between the
operation and the result.

For failure scenarios, the loss of any of the four messages should be
considered along with crashes of one or both of the NSAs at any point in 
time.
These failure scenarios can be generalized into the availability of an NSA,
i.e., it does not matter if it is the network or NSA that is down, the
distinction is if the NSA received the message or not.

In general the problem is to ensure that the (intended) state of a 
connection
is kept in sync. There are two significant problems in the current 
protocol:

* No clear semantics for the operation received ack
* No clear division of responsibility between requester and provider

Both of these are semantic issues (i.e., behavior), and hence solving them
should not require any changes for the wire-protocol.

 From a theoretical point of view and assuming an asynchronous network 
model
(note that async means something else in distributed systems than in 
networks)
the problem is impossible to solve. Taking a slightly less pessimistic view
(i.e., a partial synchronous network model), it becomes possible to recover
some failures. Taking a pragmatic approach most errors are recoverable, 
given
that the network and NSAs becomes functional at some point in time.


== Control Plane Failure Scenarios & Recovery ==

The following will go through a range of failure scenarios, and describe 
how to
recover from them. Note that some of the scenarios can be solved in 
multiple
ways. I've taken the approach that it is the responsibility of the 
requester to
ensure that the connection at the at the provider is in the required state.

A: Requester NSA did not receive the operation received ack.

Note: This failure is equivalent to not being able to dispatch the message
       (here there failure just occurs earlier).

Note: If the operation result message is received within the timeout, 
this case
       can be ignored.

Potential causes: Message loss, network outage, provider NSA is down

If the requester NSA after a certain amount of time have not received the
operation received ack it must assume that the connection cannot be 
created or
the state change. This can be dealt with in multiple ways:

   1. Do nothing (hope it comes up again)
   2: An alternative circuit can be found.
   3: Tear down the connection and send operation failure up the tree.

Which strategy to choose here is policy dependent and is up the individual
implementation and organization. OpenNSA currently does 3.

For the sake of preventing stale connections, the requester can keep a 
list of
"dead" connections. The status of these connections can then be checked at
certain intervals via query and a control primitive for fixing the 
status send
if needed.


B: Provider NSA could not deliver the operation received ack

This situation is a special case of scenario A, but seen from the provider
point of view.

Repeated delivery attempts can be tried, but this an only an incremental
improvement/optimization and does affect the end result.

The provider should not try and change the state of connection, besides the
latest received primitive from the requester (do the least surprising 
thing).
It is up to the requester to discover the current state (via query) and 
change
it if needed.

Since it is the responsibility of the requester to discover the state, 
there is
no need for the provider to perform "reverse query". In fact, using the 
reverse
query, for connection state update may cause more harm than good, as 
having the
provider change the connection status automatically may not be what the
provider wants (he might have compensated somehow) and does not follow
the element of least surprise, and leaves the control of the connection 
at two
parties.

Alternatively, a "Hi, I'm alive; sorry for the downtime" primitive be
introduced from provider to requester, which the requester can then use 
to fire
off any controlling primitives. This is, however, just an optimization.


C: Provider NSA could not deliver the operation result message

This case should be handled as described in scenario B.


D: Requester NSA did not receive the operation result message.

This case should be handled as described in scenario A.


E: Operation result ack was not received.

This case should be handled as described in scenario B.


== Data Plane Failure Scenarios & Recovery ==

Data plane failures are somewhat different from control plane failures. 
I am
not well-versed in networking and NRMs, but will try to come up with a
strategy:

In general, I see two sorts of failures:

   1. The failure is happening in my local domain.
   2. The failure is happening outside my local domain.

This might be an overly simplistic view of things.

We assume that any fail-over, etc. have also failed, so the failure 
cannot be
corrected (if it can be corrected quickly, it probably should).

The further handling of a data plane failure will probably be policy 
dependent.
For some users the network, might be completely unusable after a failure,
where some would like to try and have it repaired. However trying to 
decide /
figure out where and how this policy should be enforced is a rather tricky
process, and probably out of scope of NSI for now.

Instead I would suggest sending terminate messages downwards and forcedEnd
upwards. Once this propagates to the initial requester a policy-correct 
action
can be taken. I.e., convert a data-plane failure into a control-plane 
issue.


== Recommendation / Action items ==

* Make the exact semantics of the operation received ack clear

Recommendation:
- The message has been received (duh)
- The request is sane
- The request has been serialized (crash safe).
- The specified connection exists (for provision, release, terminate)
- The request was authorized

   This has the following implication:
   - Once the operation received ack has been received by the requester,
     the connection should show up on a query result. If we cannot expect
     the connection to show after the receival, the primitive should be
     removed as it has no semantic value.
   - Failing early will save message exchanges and time.

* Make it clear which of the NSAs has the responsibility for what

Recommendation:
- The provider is the authority for connection status (duh)
- Keeping connection state synchronized is the responsibility of the 
requester

   This has the following implication:
   - Any (non-scheduled) connection state change must only be done at the
     initiative of the requester
   - The requester query interface is not needed.

-- 

-- 
Inder Monga
510-486-6531
http://www.es.net
Follow us on Twitter: ESnetUpdates/Twitter <http://bit.ly/bisCAd>
Visit our blog: ESnetUpdates Blog 
<http://bit.ly/9lSTO3><http://bit.ly/d2Olql>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120207/cf15de63/attachment.html>

From htj at nordu.net  Wed Feb  8 07:18:22 2012
From: htj at nordu.net (Henrik Thostrup Jensen)
Date: Wed, 8 Feb 2012 13:18:22 +0100 (CET)
Subject: [Nsi-wg] Call Tomorrow and Agenda
In-Reply-To: <4F322B75.10202@es.net>
References: <4F322B75.10202@es.net>
Message-ID: <alpine.DEB.2.02.1202081317340.22900@scandium>

Hi

On Tue, 7 Feb 2012, Inder Monga wrote:

> Agenda:
> 
> 1. Firewall issues: John Macauley
> 2. Error Handling: Henrik
> 3. Other topics

Maybe status / missing items for version 1.1.


     Best regards, Henrik

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


From john.macauley at surfnet.nl  Wed Feb  8 09:10:16 2012
From: john.macauley at surfnet.nl (John MacAuley)
Date: Wed, 8 Feb 2012 09:10:16 -0500
Subject: [Nsi-wg] Call Tomorrow and Agenda
In-Reply-To: <4F322B75.10202@es.net>
References: <4F322B75.10202@es.net>
Message-ID: <A61A2021-9734-43EE-8919-0985A98C0BC8@surfnet.nl>

Slides for today.



On 2012-02-08, at 2:59 AM, Inder Monga wrote:

> 
> Hi all,
> 
> The following is dial-in information for Wednesday's NSI call, time:  7:00 PDT  10:00 EDT, 15:00 GMT,  16:00 CET,  24:00 JST
> 
> 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285  Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code  8937606, followed by ?#?
> 
> Agenda:
> 
> 1. Firewall issues: John Macauley
> 2. Error Handling: Henrik
> 3. Other topics
> 
> Thanks
> Inder
> 
> 
> Henrik's email attached:
> 
> -- 
> 
> 
> Failure scenarios and recovery for the NSI protocol version 1.0 and 1.1 
> 
> == Introduction == 
> 
> The main focus will be on the control plane interaction, and how to deal with 
> message loss, crashes, and how to recover from them. 
> 
> With the exception of the forcedEnd primitives, all NSI control plane 
> message interactions happens like this: 
> 
> Requester NSA               Provider NSA 
> 
> operation               -> 
>                         <-  operation received ack 
>                         <-  operation result 
> operation result ack    -> 
> 
> The main idea between the separation of the operation and operation result is 
> that they may be separated by a significant time, especially the provision 
> operation which can be separated with several days or months between the 
> operation and the result. 
> 
> For failure scenarios, the loss of any of the four messages should be 
> considered along with crashes of one or both of the NSAs at any point in time. 
> These failure scenarios can be generalized into the availability of an NSA, 
> i.e., it does not matter if it is the network or NSA that is down, the 
> distinction is if the NSA received the message or not. 
> 
> In general the problem is to ensure that the (intended) state of a connection 
> is kept in sync. There are two significant problems in the current protocol: 
> 
> * No clear semantics for the operation received ack 
> * No clear division of responsibility between requester and provider 
> 
> Both of these are semantic issues (i.e., behavior), and hence solving them 
> should not require any changes for the wire-protocol. 
> 
> From a theoretical point of view and assuming an asynchronous network model 
> (note that async means something else in distributed systems than in networks) 
> the problem is impossible to solve. Taking a slightly less pessimistic view 
> (i.e., a partial synchronous network model), it becomes possible to recover 
> some failures. Taking a pragmatic approach most errors are recoverable, given 
> that the network and NSAs becomes functional at some point in time. 
> 
> 
> == Control Plane Failure Scenarios & Recovery == 
> 
> The following will go through a range of failure scenarios, and describe how to 
> recover from them. Note that some of the scenarios can be solved in multiple 
> ways. I've taken the approach that it is the responsibility of the requester to 
> ensure that the connection at the at the provider is in the required state. 
> 
> A: Requester NSA did not receive the operation received ack. 
> 
> Note: This failure is equivalent to not being able to dispatch the message 
>       (here there failure just occurs earlier). 
> 
> Note: If the operation result message is received within the timeout, this case 
>       can be ignored. 
> 
> Potential causes: Message loss, network outage, provider NSA is down 
> 
> If the requester NSA after a certain amount of time have not received the 
> operation received ack it must assume that the connection cannot be created or 
> the state change. This can be dealt with in multiple ways: 
> 
>   1. Do nothing (hope it comes up again) 
>   2: An alternative circuit can be found. 
>   3: Tear down the connection and send operation failure up the tree. 
> 
> Which strategy to choose here is policy dependent and is up the individual 
> implementation and organization. OpenNSA currently does 3. 
> 
> For the sake of preventing stale connections, the requester can keep a list of 
> "dead" connections. The status of these connections can then be checked at 
> certain intervals via query and a control primitive for fixing the status send 
> if needed. 
> 
> 
> B: Provider NSA could not deliver the operation received ack 
> 
> This situation is a special case of scenario A, but seen from the provider 
> point of view. 
> 
> Repeated delivery attempts can be tried, but this an only an incremental 
> improvement/optimization and does affect the end result. 
> 
> The provider should not try and change the state of connection, besides the 
> latest received primitive from the requester (do the least surprising thing). 
> It is up to the requester to discover the current state (via query) and change 
> it if needed. 
> 
> Since it is the responsibility of the requester to discover the state, there is 
> no need for the provider to perform "reverse query". In fact, using the reverse 
> query, for connection state update may cause more harm than good, as having the 
> provider change the connection status automatically may not be what the 
> provider wants (he might have compensated somehow) and does not follow 
> the element of least surprise, and leaves the control of the connection at two 
> parties. 
> 
> Alternatively, a "Hi, I'm alive; sorry for the downtime" primitive be 
> introduced from provider to requester, which the requester can then use to fire 
> off any controlling primitives. This is, however, just an optimization. 
> 
> 
> C: Provider NSA could not deliver the operation result message 
> 
> This case should be handled as described in scenario B. 
> 
> 
> D: Requester NSA did not receive the operation result message. 
> 
> This case should be handled as described in scenario A. 
> 
> 
> E: Operation result ack was not received. 
> 
> This case should be handled as described in scenario B. 
> 
> 
> == Data Plane Failure Scenarios & Recovery == 
> 
> Data plane failures are somewhat different from control plane failures. I am 
> not well-versed in networking and NRMs, but will try to come up with a 
> strategy: 
> 
> In general, I see two sorts of failures: 
> 
>   1. The failure is happening in my local domain. 
>   2. The failure is happening outside my local domain. 
> 
> This might be an overly simplistic view of things. 
> 
> We assume that any fail-over, etc. have also failed, so the failure cannot be 
> corrected (if it can be corrected quickly, it probably should). 
> 
> The further handling of a data plane failure will probably be policy dependent. 
> For some users the network, might be completely unusable after a failure, 
> where some would like to try and have it repaired. However trying to decide / 
> figure out where and how this policy should be enforced is a rather tricky 
> process, and probably out of scope of NSI for now. 
> 
> Instead I would suggest sending terminate messages downwards and forcedEnd 
> upwards. Once this propagates to the initial requester a policy-correct action 
> can be taken. I.e., convert a data-plane failure into a control-plane issue. 
> 
> 
> == Recommendation / Action items == 
> 
> * Make the exact semantics of the operation received ack clear 
> 
> Recommendation: 
> - The message has been received (duh) 
> - The request is sane 
> - The request has been serialized (crash safe). 
> - The specified connection exists (for provision, release, terminate) 
> - The request was authorized 
> 
>   This has the following implication: 
>   - Once the operation received ack has been received by the requester, 
>     the connection should show up on a query result. If we cannot expect 
>     the connection to show after the receival, the primitive should be 
>     removed as it has no semantic value. 
>   - Failing early will save message exchanges and time. 
> 
> * Make it clear which of the NSAs has the responsibility for what 
> 
> Recommendation: 
> - The provider is the authority for connection status (duh) 
> - Keeping connection state synchronized is the responsibility of the requester 
> 
>   This has the following implication: 
>   - Any (non-scheduled) connection state change must only be done at the 
>     initiative of the requester 
>   - The requester query interface is not needed. 
> 
> --  
> 
> -- 
> Inder Monga
> 510-486-6531
> http://www.es.net
> Follow us on Twitter: ESnetUpdates/Twitter 
> Visit our blog: ESnetUpdates Blog
> 
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120208/329dc2cf/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NSI-firewall issues-v1.pdf
Type: application/pdf
Size: 1414400 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120208/329dc2cf/attachment-0001.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120208/329dc2cf/attachment-0003.html>

From t.kudoh at aist.go.jp  Wed Feb  8 10:19:58 2012
From: t.kudoh at aist.go.jp (Tomohiro Kudoh)
Date: Thu, 9 Feb 2012 00:19:58 +0900
Subject: [Nsi-wg] new state machine
Message-ID: <CAEGiyHvfxEuANUhNMn7FrtpYPvEXeDOQ-Hpvrht=oHN14h=_ng@mail.gmail.com>

Hi all,

Here is a slide of a new state machine.

Here, prov.cf/rel.cf does not mean data plane failure, but means
confirmation of delivery of a prov/rel request to all the children.

I am not sure how we can handle prov.fl (and rel.fl) messages. Since
they are not related to data plane, they are almost fatal. Going back
to the previous state may not make sense. (In most cases, such .fl
message will not be sent back, but time out will happen).

Tomohiro
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NSI-SM-Single-Diagram-Feb_8_2012.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 132416 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120209/3cd2106c/attachment-0001.pptx>

From imonga at es.net  Thu Feb  9 05:20:13 2012
From: imonga at es.net (Inder Monga)
Date: Thu, 09 Feb 2012 02:20:13 -0800
Subject: [Nsi-wg] Call Tomorrow and Agenda
In-Reply-To: <A61A2021-9734-43EE-8919-0985A98C0BC8@surfnet.nl>
References: <4F322B75.10202@es.net>
	<A61A2021-9734-43EE-8919-0985A98C0BC8@surfnet.nl>
Message-ID: <4F339DDD.1090904@es.net>

John

Can you please send the minutes of the discussion and the next actions?

For the list members:

There was a proposal to discuss the NSI-Client (or UNI) or whatever we 
want to name the interface between an application and NSA agent during 
the march OGF face to face meeting. 2 hour timeslot should be enough. 
The question is does every software application implementing the NSA 
interface has to follow all the rules of NSA including the state machine 
of the RA?

For next week's discussion - please read Henrik's email on error 
handling below.


Thanks
Inder

John MacAuley wrote:
> Slides for today.
>
>
> On 2012-02-08, at 2:59 AM, Inder Monga wrote:
>
>>
>> Hi all,
>>
>> The following is dial-in information for Wednesday's NSI call, time: 
>> 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET,  24:00 JST
>>
>> 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. 
>> International participants dial: Toll Number: 303-248-0285  Or 
>> International Toll-Free Number: http://www.readytalk.com/intl 3. 
>> Enter 7-digit access code  8937606, followed by "#"
>>
>> Agenda:
>>
>> 1. Firewall issues: John Macauley
>> 2. Error Handling: Henrik
>> 3. Other topics
>>
>> Thanks
>> Inder
>>
>>
>> Henrik's email attached:
>>
>> -- 
>>
>>
>> Failure scenarios and recovery for the NSI protocol version 1.0 and 1.1
>>
>> == Introduction ==
>>
>> The main focus will be on the control plane interaction, and how to 
>> deal with
>> message loss, crashes, and how to recover from them.
>>
>> With the exception of the forcedEnd primitives, all NSI control plane
>> message interactions happens like this:
>>
>> Requester NSA               Provider NSA
>>
>> operation               ->
>> <-  operation received ack
>> <-  operation result
>> operation result ack    ->
>>
>> The main idea between the separation of the operation and operation 
>> result is
>> that they may be separated by a significant time, especially the 
>> provision
>> operation which can be separated with several days or months between the
>> operation and the result.
>>
>> For failure scenarios, the loss of any of the four messages should be
>> considered along with crashes of one or both of the NSAs at any point 
>> in time.
>> These failure scenarios can be generalized into the availability of 
>> an NSA,
>> i.e., it does not matter if it is the network or NSA that is down, the
>> distinction is if the NSA received the message or not.
>>
>> In general the problem is to ensure that the (intended) state of a 
>> connection
>> is kept in sync. There are two significant problems in the current 
>> protocol:
>>
>> * No clear semantics for the operation received ack
>> * No clear division of responsibility between requester and provider
>>
>> Both of these are semantic issues (i.e., behavior), and hence solving 
>> them
>> should not require any changes for the wire-protocol.
>>
>> From a theoretical point of view and assuming an asynchronous network 
>> model
>> (note that async means something else in distributed systems than in 
>> networks)
>> the problem is impossible to solve. Taking a slightly less 
>> pessimistic view
>> (i.e., a partial synchronous network model), it becomes possible to 
>> recover
>> some failures. Taking a pragmatic approach most errors are 
>> recoverable, given
>> that the network and NSAs becomes functional at some point in time.
>>
>>
>> == Control Plane Failure Scenarios & Recovery ==
>>
>> The following will go through a range of failure scenarios, and 
>> describe how to
>> recover from them. Note that some of the scenarios can be solved in 
>> multiple
>> ways. I've taken the approach that it is the responsibility of the 
>> requester to
>> ensure that the connection at the at the provider is in the required 
>> state.
>>
>> A: Requester NSA did not receive the operation received ack.
>>
>> Note: This failure is equivalent to not being able to dispatch the 
>> message
>>       (here there failure just occurs earlier).
>>
>> Note: If the operation result message is received within the timeout, 
>> this case
>>       can be ignored.
>>
>> Potential causes: Message loss, network outage, provider NSA is down
>>
>> If the requester NSA after a certain amount of time have not received 
>> the
>> operation received ack it must assume that the connection cannot be 
>> created or
>> the state change. This can be dealt with in multiple ways:
>>
>>   1. Do nothing (hope it comes up again)
>>   2: An alternative circuit can be found.
>>   3: Tear down the connection and send operation failure up the tree.
>>
>> Which strategy to choose here is policy dependent and is up the 
>> individual
>> implementation and organization. OpenNSA currently does 3.
>>
>> For the sake of preventing stale connections, the requester can keep 
>> a list of
>> "dead" connections. The status of these connections can then be 
>> checked at
>> certain intervals via query and a control primitive for fixing the 
>> status send
>> if needed.
>>
>>
>> B: Provider NSA could not deliver the operation received ack
>>
>> This situation is a special case of scenario A, but seen from the 
>> provider
>> point of view.
>>
>> Repeated delivery attempts can be tried, but this an only an incremental
>> improvement/optimization and does affect the end result.
>>
>> The provider should not try and change the state of connection, 
>> besides the
>> latest received primitive from the requester (do the least surprising 
>> thing).
>> It is up to the requester to discover the current state (via query) 
>> and change
>> it if needed.
>>
>> Since it is the responsibility of the requester to discover the 
>> state, there is
>> no need for the provider to perform "reverse query". In fact, using 
>> the reverse
>> query, for connection state update may cause more harm than good, as 
>> having the
>> provider change the connection status automatically may not be what the
>> provider wants (he might have compensated somehow) and does not follow
>> the element of least surprise, and leaves the control of the 
>> connection at two
>> parties.
>>
>> Alternatively, a "Hi, I'm alive; sorry for the downtime" primitive be
>> introduced from provider to requester, which the requester can then 
>> use to fire
>> off any controlling primitives. This is, however, just an optimization.
>>
>>
>> C: Provider NSA could not deliver the operation result message
>>
>> This case should be handled as described in scenario B.
>>
>>
>> D: Requester NSA did not receive the operation result message.
>>
>> This case should be handled as described in scenario A.
>>
>>
>> E: Operation result ack was not received.
>>
>> This case should be handled as described in scenario B.
>>
>>
>> == Data Plane Failure Scenarios & Recovery ==
>>
>> Data plane failures are somewhat different from control plane 
>> failures. I am
>> not well-versed in networking and NRMs, but will try to come up with a
>> strategy:
>>
>> In general, I see two sorts of failures:
>>
>>   1. The failure is happening in my local domain.
>>   2. The failure is happening outside my local domain.
>>
>> This might be an overly simplistic view of things.
>>
>> We assume that any fail-over, etc. have also failed, so the failure 
>> cannot be
>> corrected (if it can be corrected quickly, it probably should).
>>
>> The further handling of a data plane failure will probably be policy 
>> dependent.
>> For some users the network, might be completely unusable after a 
>> failure,
>> where some would like to try and have it repaired. However trying to 
>> decide /
>> figure out where and how this policy should be enforced is a rather 
>> tricky
>> process, and probably out of scope of NSI for now.
>>
>> Instead I would suggest sending terminate messages downwards and 
>> forcedEnd
>> upwards. Once this propagates to the initial requester a 
>> policy-correct action
>> can be taken. I.e., convert a data-plane failure into a control-plane 
>> issue.
>>
>>
>> == Recommendation / Action items ==
>>
>> * Make the exact semantics of the operation received ack clear
>>
>> Recommendation:
>> - The message has been received (duh)
>> - The request is sane
>> - The request has been serialized (crash safe).
>> - The specified connection exists (for provision, release, terminate)
>> - The request was authorized
>>
>>   This has the following implication:
>>   - Once the operation received ack has been received by the requester,
>>     the connection should show up on a query result. If we cannot expect
>>     the connection to show after the receival, the primitive should be
>>     removed as it has no semantic value.
>>   - Failing early will save message exchanges and time.
>>
>> * Make it clear which of the NSAs has the responsibility for what
>>
>> Recommendation:
>> - The provider is the authority for connection status (duh)
>> - Keeping connection state synchronized is the responsibility of the 
>> requester
>>
>>   This has the following implication:
>>   - Any (non-scheduled) connection state change must only be done at the
>>     initiative of the requester
>>   - The requester query interface is not needed.
>>
>> -- 
>>
>> -- 
>> Inder Monga
>> 510-486-6531
>> http://www.es.net <http://www.es.net/>
>> Follow us on Twitter: ESnetUpdates/Twitter <http://bit.ly/bisCAd>
>> Visit our blog: ESnetUpdates Blog 
>> <http://bit.ly/9lSTO3><http://bit.ly/d2Olql>
>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
>> https://www.ogf.org/mailman/listinfo/nsi-wg
>




Inder Monga
Tel: | Mobile
imonga at es.net|

<http://www.linkedin.com/in/indermonga>
Get a signature like this. 
<http://r1.wisestamp.com/r/landing?promo=18&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_18> 
Click here. 
<http://r1.wisestamp.com/r/landing?promo=18&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_18> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120209/7553c505/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkedinbutton_option_1.png
Type: image/png
Size: 3685 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120209/7553c505/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p.gif
Type: image/gif
Size: 35 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120209/7553c505/attachment-0001.gif>

From Guy.Roberts at dante.net  Tue Feb 14 13:10:44 2012
From: Guy.Roberts at dante.net (Guy Roberts)
Date: Tue, 14 Feb 2012 18:10:44 +0000
Subject: [Nsi-wg] Wednesday's NSI conf call
Message-ID: <3E95E051CC79034BAED5A47C11C1BD803BB02B60E5@dexch.win.dante.org.uk>

Hi all,



The following is dial-in information for Wednesday's NSI call, time:  7:00 PDT  10:00 EDT, 15:00 GMT,  16:00 CET,  24:00 JST



1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285  Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code  8937606, followed by "#"





Please let me know if you have any items that you would like to have added to the call agenda.



Guy


_____________________________________________________________________

      **       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 at dante.net<mailto:guy.roberts at dante.org.uk>
  D A N T E    United Kingdom       WWW:    http://www.dante.net
_____________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120214/faf4dfdd/attachment.html>

From htj at nordu.net  Wed Feb 15 03:50:59 2012
From: htj at nordu.net (Henrik Thostrup Jensen)
Date: Wed, 15 Feb 2012 09:50:59 +0100 (CET)
Subject: [Nsi-wg] Wednesday's NSI conf call
In-Reply-To: <3E95E051CC79034BAED5A47C11C1BD803BB02B60E5@dexch.win.dante.org.uk>
References: <3E95E051CC79034BAED5A47C11C1BD803BB02B60E5@dexch.win.dante.org.uk>
Message-ID: <alpine.DEB.2.02.1202150948520.870@scandium>

Hi

On Tue, 14 Feb 2012, Guy Roberts wrote:

> Please let me know if you have any items that you would like to have 
> added to the call agenda.

Error handling. I send out an email some time ago about it.

We touched upon it last week, but we spend far too much time arguing about 
silly details (I think some people hadn't actually read the email).


     Best regards, Henrik

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


From htj at nordu.net  Wed Feb 15 05:24:34 2012
From: htj at nordu.net (Henrik Thostrup Jensen)
Date: Wed, 15 Feb 2012 11:24:34 +0100 (CET)
Subject: [Nsi-wg] new state machine
In-Reply-To: <CAEGiyHvfxEuANUhNMn7FrtpYPvEXeDOQ-Hpvrht=oHN14h=_ng@mail.gmail.com>
References: <CAEGiyHvfxEuANUhNMn7FrtpYPvEXeDOQ-Hpvrht=oHN14h=_ng@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1202150956370.870@scandium>

Hi Tomohiro

(long email, sorry).

On Thu, 9 Feb 2012, Tomohiro Kudoh wrote:

> Here is a slide of a new state machine.

Thanks for making this.

I am bit puzzled by the introduction of the auto-provisioning state, but I 
can see it being useful in places where there is an NRM which can do 
auto-start, and auto-provisioning representing that we are interacting 
with the NRM to set this up. If this is what you meant, I think it makes 
sense.

It is still not possible to release an auto-provisioned connection (i.e., 
going back to reserved from auto-provision), which I think is needed. It 
will probably not be the most used feature, but since we have the ability 
to release a provisioned connection it should also be possible to stop an 
auto-provisioning from happening, which is currently not possible. If we 
introduce this and the auto-provisioning state, we will also need a state 
for when auto-provisioning is being cancelled.

Event when a connection have been auto-provisioned it should still, IMHO, 
go through the provision state as this is when the hardware brings up the 
connection - it is not something that can be skipped. This would cause 
provisionConfirmed to be emitted twice, which is not what we want. The new 
state machine is also slightly inconsistent wrt. provisionConfirmed - in 
auto provision it is emitted when going into auto-provision (i.e., long 
before the hardware is activated), and in the non-auto-provision it is 
emitted when the hardware is activated. Could we consider introducing a 
new primitive, e.g., autoProvisionConfirmed or linkActivated which was 
emitted when the hardware is brought up. I know this somewhat breaks the 
nice symmetry of the model.

Finally: I have difficulty seperating the cleaning and terminating state, 
and they seem mostly equivalent for me, but I hadn't joined NSI at the 
time it was created, so can someone fill me in. I also not quite sure how 
to respond to a forcedEnd message.

> I am not sure how we can handle prov.fl (and rel.fl) messages. Since
> they are not related to data plane, they are almost fatal. Going back
> to the previous state may not make sense. (In most cases, such .fl
> message will not be sent back, but time out will happen).

I think we have to realize that the current four primitives and associated 
responses doesn't cut it. These failures can be either fatal (as in: the 
connection is termianted), or non-fatal (as in: try again later and it 
might work). However this is not possible to express in the current 
provisionFailed / releaseFailed primitives. The protocol is designed such 
that the requester can expect the remote connection to be in a certain 
state when a one of these primitives are received, but that is not the 
case here. This is also the case with terminateFailed, which I don't think 
any of us really know how to handle :-).

A solution is to use the forcedEnd for fatal events, and have 
provisionFailed / releaseFailed indicate a move back to scheduled - 
however then there is no need for a releaseFailed.

I've attached a picture of the state machine as I envision it. There are 
probably still some things wrong with it, and it mostly as basis for 
future discussion :-).


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nsi-statemachine-htj-20120215.pdf
Type: application/pdf
Size: 8194 bytes
Desc: 
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120215/3c640a6e/attachment-0001.pdf>

From t.kudoh at aist.go.jp  Wed Feb 15 09:54:34 2012
From: t.kudoh at aist.go.jp (Tomohiro Kudoh)
Date: Wed, 15 Feb 2012 23:54:34 +0900
Subject: [Nsi-wg] new state machine
In-Reply-To: <alpine.DEB.2.02.1202150956370.870@scandium>
References: <CAEGiyHvfxEuANUhNMn7FrtpYPvEXeDOQ-Hpvrht=oHN14h=_ng@mail.gmail.com>
	<alpine.DEB.2.02.1202150956370.870@scandium>
Message-ID: <20120215233135.955F.A4D1037D@aist.go.jp>

Hi Henrik,

Thank you for your comments and state machine proposal.
I've put my comment inline.

On Wed, 15 Feb 2012 11:24:34 +0100 (CET)
Henrik Thostrup Jensen <htj at nordu.net> wrote:

> Hi Tomohiro
> 
> (long email, sorry).
> 
> On Thu, 9 Feb 2012, Tomohiro Kudoh wrote:
> 
> > Here is a slide of a new state machine.
> 
> Thanks for making this.
> 
> I am bit puzzled by the introduction of the auto-provisioning state, but I 
> can see it being useful in places where there is an NRM which can do 
> auto-start, and auto-provisioning representing that we are interacting 
> with the NRM to set this up. If this is what you meant, I think it makes 
> sense.

The "Auto Provisioning" is required to wait confirm messages sent back
from all the children.

> It is still not possible to release an auto-provisioned connection (i.e., 
> going back to reserved from auto-provision), which I think is needed. It 
> will probably not be the most used feature, but since we have the ability 
> to release a provisioned connection it should also be possible to stop an 
> auto-provisioning from happening, which is currently not possible. If we 
> introduce this and the auto-provisioning state, we will also need a state 
> for when auto-provisioning is being cancelled.

OK. I added them.

> Event when a connection have been auto-provisioned it should still, IMHO, 
> go through the provision state as this is when the hardware brings up the 
> connection - it is not something that can be skipped. This would cause 
> provisionConfirmed to be emitted twice, which is not what we want. The new 
> state machine is also slightly inconsistent wrt. provisionConfirmed - in 
> auto provision it is emitted when going into auto-provision (i.e., long 
> before the hardware is activated), and in the non-auto-provision it is 
> emitted when the hardware is activated. Could we consider introducing a 
> new primitive, e.g., autoProvisionConfirmed or linkActivated which was 
> emitted when the hardware is brought up. I know this somewhat breaks the 
> nice symmetry of the model.

This is a matter of whether to separate data plane errors from NSI base
messages. At Baton Rouge, I have discussed with John and Chin, and we
thought it is better to separate them. i.e. prof.cf/rel.cf just mean
prov.rq/prov.cf have already been propagated to all the children.

I think we need to discuss this matter first.

> Finally: I have difficulty seperating the cleaning and terminating state, 
> and they seem mostly equivalent for me, but I hadn't joined NSI at the 
> time it was created, so can someone fill me in. I also not quite sure how 
> to respond to a forcedEnd message.



> > I am not sure how we can handle prov.fl (and rel.fl) messages. Since
> > they are not related to data plane, they are almost fatal. Going back
> > to the previous state may not make sense. (In most cases, such .fl
> > message will not be sent back, but time out will happen).
> 
> I think we have to realize that the current four primitives and associated 
> responses doesn't cut it. These failures can be either fatal (as in: the 
> connection is termianted), or non-fatal (as in: try again later and it 
> might work). However this is not possible to express in the current 
> provisionFailed / releaseFailed primitives. The protocol is designed such 
> that the requester can expect the remote connection to be in a certain 
> state when a one of these primitives are received, but that is not the 
> case here. This is also the case with terminateFailed, which I don't think 
> any of us really know how to handle :-).
> 
> A solution is to use the forcedEnd for fatal events, and have 
> provisionFailed / releaseFailed indicate a move back to scheduled - 
> however then there is no need for a releaseFailed.

OK. I think I agree with you.

> I've attached a picture of the state machine as I envision it. There are 
> probably still some things wrong with it, and it mostly as basis for 
> future discussion :-).
> 

Your state machine does not allow skew of prov.rq message delivery. If
prov.rq is sent by an ultimate RA just before the start_time, some NSA
will receive prov.rq before the start_time and some will do after the
start_time. 

In the attached slide, slide 2 is a SM which supports release during
auto provisioning, but does not transit to the provisioning state in
auto-provision. Slide 3 is a SM which transits to the provisioned state
by using non-symmetrical messages.

(last two slides are the state machines in which release is not
supported)

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

Thanks,

Tomohiro
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NSI-SM-Single-Diagram-Feb_15_2012.pdf
Type: application/octet-stream
Size: 132206 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120215/4a36a524/attachment-0001.obj>

From Guy.Roberts at dante.net  Wed Feb 15 13:48:10 2012
From: Guy.Roberts at dante.net (Guy Roberts)
Date: Wed, 15 Feb 2012 18:48:10 +0000
Subject: [Nsi-wg] minutes from today's NSI conf call
Message-ID: <3E95E051CC79034BAED5A47C11C1BD803BB02B60EB@dexch.win.dante.org.uk>

... are available here:

https://forge.ogf.org/sf/go/doc16396?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 at dante.net<mailto:guy.roberts at dante.org.uk>
  D A N T E    United Kingdom       WWW:    http://www.dante.net
_____________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120215/5bceed95/attachment.html>

From ogf-nsi-project at googlecode.com  Thu Feb 16 07:15:27 2012
From: ogf-nsi-project at googlecode.com (ogf-nsi-project at googlecode.com)
Date: Thu, 16 Feb 2012 12:15:27 +0000
Subject: [Nsi-wg] Issue 56 in ogf-nsi-project: Overloaded usage of
	'Provisioned' state
Message-ID: <0-13212762250893768619-12200957631016055155-ogf-nsi-project=googlecode.com@googlecode.com>

Status: Accepted
Owner: tkudoh... at gmail.com
Labels: Type-Defect Priority-Medium FoundInVersion-1.1 FixedInVersion-2.0

New issue 56 by guy.robe... at gmail.com: Overloaded usage of 'Provisioned'  
state
http://code.google.com/p/ogf-nsi-project/issues/detail?id=56

Description of Issue:
In the state machine defined in NSI v1.1, the 'Provisioned' state is  
overloaded.  Two meanings are associated with this state:
1. All child NSAs have acknowledged receipt of the provision command
2. All child NSAs have confirmed provisioning complete

Discussion of Issue:
Should we refine the state-machine to disambiguate these two different  
understandings of 'Provisioned'.  A proposal has been made to add a new  
message 'Connection-State up'.

Resolution of Issue:



From ogf-nsi-project at googlecode.com  Thu Feb 16 07:24:30 2012
From: ogf-nsi-project at googlecode.com (ogf-nsi-project at googlecode.com)
Date: Thu, 16 Feb 2012 12:24:30 +0000
Subject: [Nsi-wg] Issue 57 in ogf-nsi-project: should we define an NSI-UNI?
Message-ID: <0-13212762250893768619-14867477509162300077-ogf-nsi-project=googlecode.com@googlecode.com>

Status: Accepted
Owner: jmacau... at gmail.com
Labels: Type-Defect Priority-Medium FoundInVersion-1.1 FixedInVersion-2.0

New issue 57 by guy.robe... at gmail.com: should we define an NSI-UNI?
http://code.google.com/p/ogf-nsi-project/issues/detail?id=57

Description of Issue:
The NSI WSDL has become complex leading to the observation that application  
developers are likely to be discouraged from implementing NSI apps. Also,  
current NSI design is not firewall friendly. A possible solution to this  
would be to define a simplified NSI to be used as a UNI.

Discussion of Issue:
John MacAuley has proposed the following solution:
Define a simplified client-specific NSI-CS protocol interface (UNI)
    o A simplified subset of the existing NSI-CS capabilities.
    o Firewall safe.
This interface should use current best practices for client API development:
    o RESTful definition.
    o JSON/XML data representations.
    o Useable from web-based clients.

Resolution of Issue:




From htj at nordu.net  Thu Feb 16 07:52:44 2012
From: htj at nordu.net (Henrik Thostrup Jensen)
Date: Thu, 16 Feb 2012 13:52:44 +0100 (CET)
Subject: [Nsi-wg] new state machine
In-Reply-To: <20120215233135.955F.A4D1037D@aist.go.jp>
References: <CAEGiyHvfxEuANUhNMn7FrtpYPvEXeDOQ-Hpvrht=oHN14h=_ng@mail.gmail.com>
	<alpine.DEB.2.02.1202150956370.870@scandium>
	<20120215233135.955F.A4D1037D@aist.go.jp>
Message-ID: <alpine.DEB.2.02.1202161258480.13138@scandium>

Hi Tomohiro

Replies inline.

On Wed, 15 Feb 2012, Tomohiro Kudoh wrote:

>> I am bit puzzled by the introduction of the auto-provisioning state, but I
>> can see it being useful in places where there is an NRM which can do
>> auto-start, and auto-provisioning representing that we are interacting
>> with the NRM to set this up. If this is what you meant, I think it makes
>> sense.
>
> The "Auto Provisioning" is required to wait confirm messages sent back
> from all the children.

Right. This makes sense (if there is an NRM involved or not is a secondary 
issue).

>> Event when a connection have been auto-provisioned it should still, IMHO,
>> go through the provision state as this is when the hardware brings up the
>> connection - it is not something that can be skipped.
>
> This is a matter of whether to separate data plane errors from NSI base
> messages. At Baton Rouge, I have discussed with John and Chin, and we
> thought it is better to separate them. i.e. prof.cf/rel.cf just mean
> prov.rq/prov.cf have already been propagated to all the children.
>
> I think we need to discuss this matter first.

Yes. I tend to think that we need to seperate replies (one for control 
plane, one for data plane), as we more or less agreed upon yesterday (we 
just haven't quite figure out how yet).

The discussion can be had for release and terminate. Should this be 
returned once the release has been propagated all the way down and back up 
the tree, or once all the links has been teared down. E.g., a 
linkActivated, linkDeactivated, connectionTerminated (don't get to hung up 
on wording).

>> Finally: I have difficulty seperating the cleaning and terminating state,
>> and they seem mostly equivalent for me, but I hadn't joined NSI at the
>> time it was created, so can someone fill me in. I also not quite sure how
>> to respond to a forcedEnd message.

There where some blank lines here. Did you intend to write something?

If no one knows why we have a seperate cleaning and terminating state it 
might be time to reconsider it :-).

>> A solution is to use the forcedEnd for fatal events, and have
>> provisionFailed / releaseFailed indicate a move back to scheduled -
>> however then there is no need for a releaseFailed.
>
> OK. I think I agree with you.

Well, I'm not quite sure what to think of these things myself :-/.

But the releaseFailed and terminateFailed primitives seem quite artificial 
for me.

>> I've attached a picture of the state machine as I envision it. There are
>> probably still some things wrong with it, and it mostly as basis for
>> future discussion :-).
>
> Your state machine does not allow skew of prov.rq message delivery. If
> prov.rq is sent by an ultimate RA just before the start_time, some NSA
> will receive prov.rq before the start_time and some will do after the
> start_time.

You are right, good catch.

> In the attached slide, slide 2 is a SM which supports release during
> auto provisioning, but does not transit to the provisioning state in
> auto-provision. Slide 3 is a SM which transits to the provisioned state
> by using non-symmetrical messages.

The model you present on slide 3 has a problem similar to mine: If a 
release is send aroud start time, the state machine can either return 
reserved or scheduled. This causes a problem as the requester doesn't know 
if an arm or provision command should be send.

I think it is reasonably clear that the way we respond to 
provision/release and to some extent terminate is a bit artifical/clumsy.

I tried to come up with a new state machine, but I need to think a bit 
first.


     Best regards, Henrik

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


From Guy.Roberts at dante.net  Fri Feb 17 05:15:34 2012
From: Guy.Roberts at dante.net (Guy Roberts)
Date: Fri, 17 Feb 2012 10:15:34 +0000
Subject: [Nsi-wg] Agenda for NSI workshop in Oxford
Message-ID: <3E95E051CC79034BAED5A47C11C1BD803BB02B60FB@dexch.win.dante.org.uk>

Hello All,

I have created a template to help us prepare an agenda for our face-to-face meeting in Oxford, this is available here on google docs:

https://docs.google.com/document/d/1y0a3X66qAoXRaXyDxGy-xiL_aIfidVaIJP1-_aKcxKs/edit

Could everyone please take a look and add any topics that you would like to discuss relating to v2.0 issues?  This agenda will be reviewed on the next NSI call.

Guy
_____________________________________________________________________

      **       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 at dante.net<mailto:guy.roberts at dante.org.uk>
  D A N T E    United Kingdom       WWW:    http://www.dante.net
_____________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120217/e53c1193/attachment.html>

From Freek.Dijkstra at sara.nl  Fri Feb 17 07:00:19 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Fri, 17 Feb 2012 13:00:19 +0100
Subject: [Nsi-wg] NSI topology
Message-ID: <4F3E4153.2010705@sara.nl>

Hello Guy, Inder, Tomohiro,
cc: NML and NSI groups

Last week Roman ?apacz (PSNC) took Jeroen's AutoGOLE network description
and turned it into an XML format. (Thanks Roman!)

In that process, we discovered a few differences how AutoGOLE and NML
describe a network model. The main differences are:

* NML links and ports are unidirectional, AutoGOLE links are
  bidirectional
* NML uses links and ports to describe network connections (a
  proposal to describe only links, not the ports was not followed
  up), AutoGOLE only describes the ports (the links are described
  as connectedTo between the ports, but have no identifier of their
  own)


Of course there are some commonalities:
* Both implementations focus on logical connections, not physical
  connections.
* Both implementations have provisionings to ensure a layer of
  abstraction in case attributes of a link or port change (in NML:
  the identifiers are opaque strings and have no inherent attributes;
  in AutoGOLE and NSI: the distinction between SDP and STP)

In yesterday's NML conference [1], we briefly discusses these
differences and commonalities.


Now, I do not know to what aspect the NSI working group is building on
the AutoGOLE work, and what the current issues are. I don't want to
interrupt the considerable progress the NSI group is making, and
certainly don't want to get in the way of more great demos such as
previous year's AutoGOLE demos by interrupting their implementation
timelines.

I think it would be good for the NML group to:
- educate the NSI working group participants on these differences.
- listen to the NSI group if there are any problems with the topology
  as we specified.

I realise that the above may take some valuable resources of the NML
working group, but I am dedicated to make sure our groups are aligned.


My question to you (as NSI co-chairs) is if you think the above is
useful, and if so, when we can best discuss this.  Would it be useful to
discuss this with the whole NSI group, or a subset?  I propose that we
dedicate a timeslot for this work, and am happy to use the NML break-out
slot for this purpose (if you like it earlier, we can see if we can ask
Joel to re-arrange some slots). We can also use a NSI or NML telephone
call to discuss this.

Part of that work means for NML-WG to provide example topology
descriptions (which can be done within a few days). But also means
making code contributions, which I don't think the NML-WG has the
resources for on short term notice.

What is your recommended way forward?

Regards,
Freek Dijkstra

[1] http://www.ogf.org/pipermail/nml-wg/2012-February/000815.html

From htj at nordu.net  Fri Feb 17 09:07:51 2012
From: htj at nordu.net (Henrik Thostrup Jensen)
Date: Fri, 17 Feb 2012 15:07:51 +0100 (CET)
Subject: [Nsi-wg] new state machine
In-Reply-To: <alpine.DEB.2.02.1202161258480.13138@scandium>
References: <CAEGiyHvfxEuANUhNMn7FrtpYPvEXeDOQ-Hpvrht=oHN14h=_ng@mail.gmail.com>
	<alpine.DEB.2.02.1202150956370.870@scandium>
	<20120215233135.955F.A4D1037D@aist.go.jp>
	<alpine.DEB.2.02.1202161258480.13138@scandium>
Message-ID: <alpine.DEB.2.02.1202171501570.2522@scandium>

Hi again

On Thu, 16 Feb 2012, Henrik Thostrup Jensen wrote:

> I tried to come up with a new state machine, but I need to think a bit first.

I've come up with a new suggestions. Two states are introduced denoting 
that a control plane message has been received (but not replied to yet), 
along with two primitives to emit when a link activated / deactivated. The 
names are probably not the final ones.

Again, I'm not really sure how this should look, and I not suggestion we 
adaopt this one immediately. However the state machine is important as it 
shows how we interact bewteen the NSA and control a connection, and what 
commands can be accepted depending on the current connection state.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: statemachine-try4.png
Type: image/png
Size: 63638 bytes
Desc: 
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120217/6181dcfb/attachment-0001.png>

From htj at nordu.net  Fri Feb 17 10:17:35 2012
From: htj at nordu.net (Henrik Thostrup Jensen)
Date: Fri, 17 Feb 2012 16:17:35 +0100 (CET)
Subject: [Nsi-wg] new state machine
In-Reply-To: <alpine.DEB.2.02.1202171501570.2522@scandium>
References: <CAEGiyHvfxEuANUhNMn7FrtpYPvEXeDOQ-Hpvrht=oHN14h=_ng@mail.gmail.com>
	<alpine.DEB.2.02.1202150956370.870@scandium>
	<20120215233135.955F.A4D1037D@aist.go.jp>
	<alpine.DEB.2.02.1202161258480.13138@scandium>
	<alpine.DEB.2.02.1202171501570.2522@scandium>
Message-ID: <alpine.DEB.2.02.1202171616130.2522@scandium>

Hi again

On Fri, 17 Feb 2012, Henrik Thostrup Jensen wrote:

> I've come up with a new suggestions. Two states are introduced denoting that 
> a control plane message has been received (but not replied to yet), along 
> with two primitives to emit when a link activated / deactivated. The names 
> are probably not the final ones.

And another one. This one is starting to look a bit better, but I still 
don't think it is there yet.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: statemachine-try6.pdf
Type: application/pdf
Size: 58124 bytes
Desc: 
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120217/7c385f5f/attachment-0001.pdf>

From Guy.Roberts at dante.net  Mon Feb 20 04:28:01 2012
From: Guy.Roberts at dante.net (Guy Roberts)
Date: Mon, 20 Feb 2012 09:28:01 +0000
Subject: [Nsi-wg] Agenda for NSI workshop in Oxford
In-Reply-To: <4F3ED121.4010703@es.net>
References: <3E95E051CC79034BAED5A47C11C1BD803BB02B60FB@dexch.win.dante.org.uk>
	<4F3ED121.4010703@es.net>
Message-ID: <3E95E051CC79034BAED5A47C11C1BD803BB02B6108@dexch.win.dante.org.uk>

I have enabled editing.

Guy

From: Inder Monga [mailto:imonga at es.net]
Sent: 17 February 2012 22:14
To: Guy Roberts
Subject: Re: [Nsi-wg] Agenda for NSI workshop in Oxford

I couldn't edit it - but would like to discuss how applications and users will use NSI. Will they have to have NSAs?

Inder


Guy Roberts wrote:
Hello All,

I have created a template to help us prepare an agenda for our face-to-face meeting in Oxford, this is available here on google docs:

https://docs.google.com/document/d/1y0a3X66qAoXRaXyDxGy-xiL_aIfidVaIJP1-_aKcxKs/edit

Could everyone please take a look and add any topics that you would like to discuss relating to v2.0 issues?  This agenda will be reviewed on the next NSI call.

Guy
_____________________________________________________________________

      **       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 at dante.net<mailto:guy.roberts at dante.org.uk>
  D A N T E    United Kingdom       WWW:    http://www.dante.net
_____________________________________________________________________


_______________________________________________

nsi-wg mailing list

nsi-wg at ogf.org<mailto:nsi-wg at ogf.org>

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

--
Inder Monga
510-486-6531
http://www.es.net
Follow us on Twitter: ESnetUpdates/Twitter<http://bit.ly/bisCAd>
Visit our blog: ESnetUpdates Blog<http://bit.ly/9lSTO3>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120220/f90cabc4/attachment.html>

From Guy.Roberts at dante.net  Tue Feb 21 09:15:21 2012
From: Guy.Roberts at dante.net (Guy Roberts)
Date: Tue, 21 Feb 2012 14:15:21 +0000
Subject: [Nsi-wg] Wednesday's NSI conf call
Message-ID: <3E95E051CC79034BAED5A47C11C1BD803BB02B6114@dexch.win.dante.org.uk>

Hi all,



The following is dial-in information for Wednesday's NSI call, time:  7:00 PDT  10:00 EDT, 15:00 GMT,  16:00 CET,  24:00 JST



1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285  Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code  8937606, followed by "#"





Agenda:

*         Agree list of topics and NSI v2.0 functions to discuss in Oxford - agree agenda: https://docs.google.com/document/d/1y0a3X66qAoXRaXyDxGy-xiL_aIfidVaIJP1-_aKcxKs/edit

*         State machine review.

*         Review open issues



Guy


_____________________________________________________________________

      **       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 at dante.net<mailto:guy.roberts at dante.org.uk>
  D A N T E    United Kingdom       WWW:    http://www.dante.net
_____________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120221/fa6e31be/attachment.html>

From john.macauley at surfnet.nl  Tue Feb 21 10:36:42 2012
From: john.macauley at surfnet.nl (John MacAuley)
Date: Tue, 21 Feb 2012 10:36:42 -0500
Subject: [Nsi-wg] Agenda for NSI workshop in Oxford
In-Reply-To: <3E95E051CC79034BAED5A47C11C1BD803BB02B6108@dexch.win.dante.org.uk>
References: <3E95E051CC79034BAED5A47C11C1BD803BB02B60FB@dexch.win.dante.org.uk>
	<4F3ED121.4010703@es.net>
	<3E95E051CC79034BAED5A47C11C1BD803BB02B6108@dexch.win.dante.org.uk>
Message-ID: <85B6DD4E-7090-487D-A2A0-46A95FD3716E@surfnet.nl>

I would also like to add a signalling/control plane topology discussion to the list.  i have a slide package we can use to discuss the topic of finding a messaging path for your reservation request.

John.

On 2012-02-20, at 4:28 AM, Guy Roberts wrote:

> I have enabled editing.
>  
> Guy
>  
> From: Inder Monga [mailto:imonga at es.net] 
> Sent: 17 February 2012 22:14
> To: Guy Roberts
> Subject: Re: [Nsi-wg] Agenda for NSI workshop in Oxford
>  
> I couldn't edit it - but would like to discuss how applications and users will use NSI. Will they have to have NSAs?
> 
> Inder
> 
> 
> Guy Roberts wrote:
> Hello All,
>  
> I have created a template to help us prepare an agenda for our face-to-face meeting in Oxford, this is available here on google docs:
>  
> https://docs.google.com/document/d/1y0a3X66qAoXRaXyDxGy-xiL_aIfidVaIJP1-_aKcxKs/edit
>  
> Could everyone please take a look and add any topics that you would like to discuss relating to v2.0 issues?  This agenda will be reviewed on the next NSI call.
>  
> Guy
> _____________________________________________________________________
>  
>       **       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 at dante.net
>   D A N T E    United Kingdom       WWW:    http://www.dante.net
> _____________________________________________________________________
>  
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
>  
> -- 
> Inder Monga
> 510-486-6531
> http://www.es.net
> Follow us on Twitter: ESnetUpdates/Twitter 
> Visit our blog: ESnetUpdates Blog
> 
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120221/a61d7ef2/attachment.html>

From Freek.Dijkstra at sara.nl  Wed Feb 22 04:52:01 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Wed, 22 Feb 2012 10:52:01 +0100
Subject: [Nsi-wg] NMLify of AutoGOLE topology
Message-ID: <4F44BAC1.70500@sara.nl>

Hi all,

I've tried to NML-ify the AutoGOLE topology. I did in RDF/XML because
that is probably readable by both OWL and XML folks.

Below are the steps I took in detail, along with intermediate results
(which may help in understanding the differences).

The main changes are:
- made ports and link unidirectional, per NML specs.
- use explicit link object to describe the SDP
  (NML has no connectedTo concept)
- change the urn:ogf:network identifiers to a valid syntax,
  the ones currently in AutoGOLE use are not valid according
  to proposed standard nor previous use in either GLIF or
  perfSONAR community.

The file AutoGOLE-Topo-2012-02-22.rdf gives the result so far.

Notes:

1. The resulting topology file has three layers:
  - NML topology
  - dtox NSNetwork
  - dtox NSA
  I really like the clear distinction between the data plane (NML) and
control plane (dtox/NSI). However, I wonder if we should move this to
two layers, perhaps merging dtox:NSNetwork and nml:topology.
2. The dtox:hasSTP relation now points to a nml:bidirectionalport. NML
defines a similar "hasPort" relation between a nml:Topology and
nml:Port. (and there is some discussion to differentiate between
hasOutboundPort and hasInboundPort). If dtox:NSNetwork and nml:topology
are merged, I recommend to use these relations.
3. Yet unclear how exactly to tie Ethernet specifics to the examples, it
seems prudent to use labels and the subnetwork concept as discussed in
the NML-WG in Lyon (see subversion:
https://forge.ogf.org/svn/repos/nml-examples/20110922/other_examples/configured_vlan.xml;
you need a gridforge login. Drop me a line if you can't access it.)


Regards,
Freek Dijkstra


List of steps I took:

Source: AutoGOLE-Topo-2012-01-25.owl

Removed owl:NamedIndividual
Removed schema definitions (owl:Ontology, owl:AnnotationProperty, etc.)
Removed Position comments (used by auto-gole.appspot.com)
Removed unnecessary comments

Result: AutoGOLE-Topo-2012-01-25.rdf

Changed dtox:lat, dtox:long and dtox:Location to geo84:lat, geo84:long
and geo84:SpatialThing
Corrected label of Netherlight location from Copenhagen to Amsterdam
(geo84 was OK)

Changed dtox:STP to nml:bidirectionalport
Grouped ports of a single network in a nml:topology
Commented dtox:connectedTo, since this is not valid NML
Added rdfs:label to all NSA and all locations
Changed admin contact from string to vCard

Result: AutoGOLE-Topo-2012-02-20.rdf

Change urn:ogf:network identifiers to valid syntax
(urn:ogf:network:<FQDN>:<date>:<opaque>)
Make all bidirectional ports unidirectional
Explicitly defined NML links, with sources and sinks

Result: AutoGOLE-Topo-2012-02-22.rdf

Possible future direction:

Merge NML:topology with dtox:NSNetwork
Remove the dtox:managedBy property, as there is already an inverse
relation dtox:managing to find the correct dtox:NSA
Added switch matrix to each NML topology
Define switching capabilities for each topology.
use nml:hasPort instead of dtox:hasSTP

Result: (the-AutoGOLE-future-is-yet-to-be-written.rdf)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AutoGOLE-Topo-2012-01-25.owl
Type: text/xml
Size: 94178 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120222/7d6a594a/attachment-0001.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AutoGOLE-Topo-2012-01-25.rdf
Type: application/rdf+xml
Size: 52002 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120222/7d6a594a/attachment-0003.rdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AutoGOLE-Topo-2012-02-20.rdf
Type: application/rdf+xml
Size: 80231 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120222/7d6a594a/attachment-0004.rdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AutoGOLE-Topo-2012-02-22.rdf
Type: application/rdf+xml
Size: 153902 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120222/7d6a594a/attachment-0005.rdf>

From jerry at nordu.net  Wed Feb 22 06:28:36 2012
From: jerry at nordu.net (Jerry Sobieski)
Date: Wed, 22 Feb 2012 06:28:36 -0500
Subject: [Nsi-wg] Agenda for NSI workshop in Oxford
In-Reply-To: <85B6DD4E-7090-487D-A2A0-46A95FD3716E@surfnet.nl>
References: <3E95E051CC79034BAED5A47C11C1BD803BB02B60FB@dexch.win.dante.org.uk>
	<4F3ED121.4010703@es.net>
	<3E95E051CC79034BAED5A47C11C1BD803BB02B6108@dexch.win.dante.org.uk>
	<85B6DD4E-7090-487D-A2A0-46A95FD3716E@surfnet.nl>
Message-ID: <4F44D164.9050304@nordu.net>

Several topics I'd like to see on the agenda for V2:

--- Related to control plane topology is _topology distribution in 
general_.   Given that some agents will not have a NSI trust relation 
with others, how do we envision NSAs learning topology?   IMO, need to 
me up with some basic NSI requirements/objectives, and then a reasonable 
general approach (details can be worked out later).   This is important 
in that it will have a bearing on what local domains will be responsible 
for managing.   The topology management task in general needs to be 
delegated to the domains themselves - the sooner the better as we will 
see more early adopters over coming 12 months.

--- I would also like to broach the issue of _uni-directional 
connections_ and how we might approach these and the issue of 
_point-to-multipoint connections_ in V2.

--- We have discussed the STP naming extensions, which addresses some 
issues in enumeration of STPs and SDPs.  But we have not worked through 
the _"any point" specification/semantics in the ReservationRequest 
primitive_.  Relaxing the single point constraint on the end points is 
key to resolving some of the exhaustive search issues when hunting for 
intermediate transit points.

--- I think we need a better and more _generally applicable solution to 
the NAT problem_.  Fundamentally,  the NSI high level protocol should be 
able to send messages back and forth to recognized NSAs at will, 
regardless of their NAT situation.  If a RA NSA can send an unsolicited 
NSI message to a PA NSA, then the PA should be able to do likewise to 
the RA NSA.  The NAT issue affects messaging both ways and should not be 
an NSI concern.  I think there are ways to address this situation that 
may not need NSI protocol machinations - and may not require MTL special 
handling either.  Maybe this is part of the UNI discussion?

Thanks!
Jerry

On 2/21/12 10:36 AM, John MacAuley wrote:
> I would also like to add a signalling/control plane topology 
> discussion to the list.  i have a slide package we can use to discuss 
> the topic of finding a messaging path for your reservation request.
>
> John.
>
> On 2012-02-20, at 4:28 AM, Guy Roberts wrote:
>
>> I have enabled editing.
>> Guy
>> *From:*Inder Monga [mailto:imonga at es.net]
>> *Sent:*17 February 2012 22:14
>> *To:*Guy Roberts
>> *Subject:*Re: [Nsi-wg] Agenda for NSI workshop in Oxford
>> I couldn't edit it - but would like to discuss how applications and 
>> users will use NSI. Will they have to have NSAs?
>>
>> Inder
>>
>>
>> Guy Roberts wrote:
>> Hello All,
>> I have created a template to help us prepare an agenda for our 
>> face-to-face meeting in Oxford, this is available here on google docs:
>> https://docs.google.com/document/d/1y0a3X66qAoXRaXyDxGy-xiL_aIfidVaIJP1-_aKcxKs/edit
>> Could everyone please take a look and add any topics that you would 
>> like to discuss relating to v2.0 issues?  This agenda will be 
>> reviewed on the next NSI call.
>> Guy
>> _____________________________________________________________________
>>       **       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 at dante.net 
>> <mailto:guy.roberts at dante.org.uk>
>>   D A N T E    United Kingdom       WWW: http://www.dante.net
>> _____________________________________________________________________
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org  <mailto:nsi-wg at ogf.org>
>> https://www.ogf.org/mailman/listinfo/nsi-wg
>>
>> --
>> Inder Monga
>> 510-486-6531
>> http://www.es.net
>> Follow us on Twitter:ESnetUpdates/Twitter <http://bit.ly/bisCAd>
>> Visit our blog:ESnetUpdatesBlog <http://bit.ly/9lSTO3>
>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
>> https://www.ogf.org/mailman/listinfo/nsi-wg
>
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120222/07aaa69e/attachment.html>

From htj at nordu.net  Wed Feb 22 07:43:56 2012
From: htj at nordu.net (Henrik Thostrup Jensen)
Date: Wed, 22 Feb 2012 13:43:56 +0100 (CET)
Subject: [Nsi-wg] Wednesday's NSI conf call
In-Reply-To: <3E95E051CC79034BAED5A47C11C1BD803BB02B6114@dexch.win.dante.org.uk>
References: <3E95E051CC79034BAED5A47C11C1BD803BB02B6114@dexch.win.dante.org.uk>
Message-ID: <alpine.DEB.2.02.1202221339160.26808@scandium>

On Tue, 21 Feb 2012, Guy Roberts wrote:

> The following is dial-in information for Wednesday's NSI call, time:? 7:00 PDT? 10:00
> EDT, 15:00 GMT,? 16:00 CET,? 24:00 JST

Won't be joining today (flu/cold).

> ??State machine review.

I've send out a couple, but it all seems a bit random right now.

Instead of focussing on the state machine and I think we should try and 
answer some of these questions:

Do we want auto-provision?
Do we want release/provision mechanism
Do we want updates for control plane, data plane, both?

Once answered, making a state machine for the protocol would be 
significantly more straightforward.

Have a good meeting.


     Best regards, Henrik

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

From Guy.Roberts at dante.net  Wed Feb 22 11:16:19 2012
From: Guy.Roberts at dante.net (Guy Roberts)
Date: Wed, 22 Feb 2012 16:16:19 +0000
Subject: [Nsi-wg] OGF34 schedule is now available
Message-ID: <3E95E051CC79034BAED5A47C11C1BD803BB02B611F@dexch.win.dante.org.uk>

Hi All,

The OGF34 schedule is now available here:

https://www.ogf.org/gf/event_schedule/index.php?event_id=23

I look forward to seeing you in Oxford.

Guy
_____________________________________________________________________

      **       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 at dante.net<mailto:guy.roberts at dante.org.uk>
  D A N T E    United Kingdom       WWW:    http://www.dante.net
_____________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120222/816a1b37/attachment.html>

From Guy.Roberts at dante.net  Wed Feb 22 11:36:44 2012
From: Guy.Roberts at dante.net (Guy Roberts)
Date: Wed, 22 Feb 2012 16:36:44 +0000
Subject: [Nsi-wg] Minutes from today's NSI conf call
Message-ID: <3E95E051CC79034BAED5A47C11C1BD803BB02B6120@dexch.win.dante.org.uk>

... are available here:

https://forge.ogf.org/sf/go/doc16398?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 at dante.net<mailto:guy.roberts at dante.org.uk>
  D A N T E    United Kingdom       WWW:    http://www.dante.net
_____________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120222/544ce34d/attachment.html>

From chin at es.net  Wed Feb 22 16:22:34 2012
From: chin at es.net (Chin Guok)
Date: Wed, 22 Feb 2012 13:22:34 -0800
Subject: [Nsi-wg] Agenda for NSI workshop in Oxford
In-Reply-To: <3E95E051CC79034BAED5A47C11C1BD803BB02B6108@dexch.win.dante.org.uk>
References: <3E95E051CC79034BAED5A47C11C1BD803BB02B60FB@dexch.win.dante.org.uk>
	<4F3ED121.4010703@es.net>
	<3E95E051CC79034BAED5A47C11C1BD803BB02B6108@dexch.win.dante.org.uk>
Message-ID: <4F455C9A.5070007@es.net>

Hi Guy,

I would like to open a discussion in Oxford on adding an optional 
constraints field that can be used for prototyping extensions while 
still being compatible with the "base" CS protocol.  For example, if the 
base CS protocol only supports point-to-point services and we wanted to 
prototype a point-to-multipoint service, we can use the optional 
constraints field to carry this information.  It can be useful to 
explore other services such as anycast/multicast/manycast, 
protection/recovery to name a few.

NSAs that are not interested in the prototyping activity can simply 
treat the field as opaque.

If folks are interested in discussing this, I can plan to come up with a 
few slides presenting the idea and some cautionary.

Thanks.

- Chin

On 2/20/12 1:28 AM, Guy Roberts wrote:
>
> I have enabled editing.
>
> Guy
>
> *From:*Inder Monga [mailto:imonga at es.net]
> *Sent:* 17 February 2012 22:14
> *To:* Guy Roberts
> *Subject:* Re: [Nsi-wg] Agenda for NSI workshop in Oxford
>
> I couldn't edit it - but would like to discuss how applications and 
> users will use NSI. Will they have to have NSAs?
>
> Inder
>
>
> Guy Roberts wrote:
>
> Hello All,
>
> I have created a template to help us prepare an agenda for our 
> face-to-face meeting in Oxford, this is available here on google docs:
>
> https://docs.google.com/document/d/1y0a3X66qAoXRaXyDxGy-xiL_aIfidVaIJP1-_aKcxKs/edit
>
> Could everyone please take a look and add any topics that you would 
> like to discuss relating to v2.0 issues?  This agenda will be reviewed 
> on the next NSI call.
>
> Guy
>
> _____________________________________________________________________
>
>       **       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 at dante.net 
> <mailto:guy.roberts at dante.org.uk>
>
>   D A N T E    United Kingdom       WWW: http://www.dante.net
>
> _____________________________________________________________________
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org  <mailto:nsi-wg at ogf.org>
> https://www.ogf.org/mailman/listinfo/nsi-wg
>
> -- 
> Inder Monga
> 510-486-6531
> http://www.es.net
> Follow us on Twitter: ESnetUpdates/Twitter <http://bit.ly/bisCAd>
> Visit our blog: ESnetUpdates Blog <http://bit.ly/9lSTO3>
>
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120222/66250761/attachment.html>

From jerry at nordu.net  Fri Feb 24 12:06:50 2012
From: jerry at nordu.net (Jerry Sobieski)
Date: Fri, 24 Feb 2012 12:06:50 -0500
Subject: [Nsi-wg] New AutoGOLE Topology file 2012-02-24
Message-ID: <4F47C3AA.9040906@nordu.net>

Hi all-

Attached is the next topology file.   The attached pdf shows the map.  
This topo basically is just adding some new topology as it is coming 
up.   Red links and networks are new.

A couple notes:
--- We have added GLORIAD to the AutoGOLE fabric.   GLORIAD will act as 
a transit network between KRLIght and StarLight.   We have not quite 
completed our testing, so we have not removed the existing link.  So 
bear withus while we finish the testing and roll to the new 
configuration.   When we do that, I will remove the old KRL-SL link, and 
publish a new topology.   For now, the existing link should remain 
operational.

--- We have introduced other naming conventions for STPs.   I believe 
all the old names are the same, but new STPs will not conform to last 
falls naming conventions...  This is partially in preparation for 
distributing the local topologies to you all for future autonomous 
management and maintenance (and partially to keep code implementations 
from keying on non-standard naming conventions for provisioning info.)

I hope to delegate topology management back to the networks soon (next 
few weeks.)  But we need to resolve a couple issues about distribution, 
processing, and representation.   Then we will present it to the 
AutoGOLE participants for feedback and then to the NSI group likewise.   
I think we are very close to getting this sorted out.   This will be a 
Big Step Forward.

If you find any errors - please let me know as soon as possible.
Thanks
Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: AutoGOLE-Topo-2012-02-24.owl
Type: text/xml
Size: 96386 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120224/b8f7fcb6/attachment-0001.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AutoGOLE-Diag-2012-02-24.pdf
Type: application/pdf
Size: 367111 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120224/b8f7fcb6/attachment-0001.pdf>

From jerry at nordu.net  Fri Feb 24 12:13:32 2012
From: jerry at nordu.net (Jerry Sobieski)
Date: Fri, 24 Feb 2012 12:13:32 -0500
Subject: [Nsi-wg] Upcoming NSI demonstrations
Message-ID: <4F47C53C.3010706@nordu.net>

Hi all-

I will be giving an NSI talk at the On*Vector conference next week 
(Thursday March 1) in San Diego.  I will be demonstrating the 
visualizers and possibly the AIST provisioning portal.

Also, NORDUnet is holding an internal NSI Introductory Seminar for our 
technical staff and some of our Nordic NREN personnel on March 7/8.

If you all would please check your environments to make sure all is 
functioning properly, I would appreciate it.

Thanks!
Jerry

From t.kudoh at aist.go.jp  Tue Feb 28 15:59:21 2012
From: t.kudoh at aist.go.jp (Tomohiro Kudoh)
Date: Wed, 29 Feb 2012 05:59:21 +0900
Subject: [Nsi-wg] Wednesday's NSI conf call
Message-ID: <20120229044014.4717.A4D1037D@aist.go.jp>

Hi all,

We will have a short (30-min) NSI call tomorrow (Wednesday).

The following is dial-in information for the call, 
time:  7:00 PDT  10:00 EDT, 15:00 GMT,  16:00 CET,  24:00 JST

1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 
2. International participants dial: Toll Number: 303-248-0285  
Or International Toll-Free Number: http://www.readytalk.com/intl 
3. Enter 7-digit access code  8937606, followed by "#"

Agenda:

*         review Oxford meeting agenda:
https://docs.google.com/document/d/1y0a3X66qAoXRaXyDxGy-xiL_aIfidVaIJP1-_aKcxKs/edit

*         Review open issues

Tomohiro



From t.kudoh at aist.go.jp  Wed Feb 29 10:07:39 2012
From: t.kudoh at aist.go.jp (Tomohiro Kudoh)
Date: Thu, 1 Mar 2012 00:07:39 +0900
Subject: [Nsi-wg] assignment list
Message-ID: <CAEGiyHv7PrqU7khE2VU6OMztUUoJaO_GKG0fOKxhYY0Acuv9JQ@mail.gmail.com>

Hello all,

Here is proposed assignments to prepare a slide or a document for the
Oxford meeting.
Note that this does not mean other topic/person cannot make
presentation at the meeting.

1. State Machine: Tomohiro, Chin, Henrik

2. Service Definition(SD): Jerry

3. Topology representation, NML-related, type/value pair representation: Team

4. Users' equipments connection model: Tomohiro

5. Control plane topology and message handling: John

6. Security proflile: Inder
 including, minimum information that should be shared through the
protocol by (all/involved) NSAs.

7. Error handling, PA->RA communication: John, Henrik, Chin

8. Federation: Jerry, Tomohiro

9. Optional constraints: Chin

10. NSA-client interface: John, Inder

11. Uni-directional cirucuit: Jerry

12. Sub-path (route or ERO): Chin, Tomohiro

From t.kudoh at aist.go.jp  Wed Feb 29 10:20:38 2012
From: t.kudoh at aist.go.jp (Tomohiro Kudoh)
Date: Thu, 1 Mar 2012 00:20:38 +0900
Subject: [Nsi-wg] assignment list
In-Reply-To: <CAEGiyHv7PrqU7khE2VU6OMztUUoJaO_GKG0fOKxhYY0Acuv9JQ@mail.gmail.com>
References: <CAEGiyHv7PrqU7khE2VU6OMztUUoJaO_GKG0fOKxhYY0Acuv9JQ@mail.gmail.com>
Message-ID: <CAEGiyHvdibqQ2BGR1rsrG4T94_=MEpVrENC+ZOGpOmXxOGG-Jw@mail.gmail.com>

updated:

Assingments to prepare a slide or document for the Oxford meeting.

1. State Machine: Tomohiro, Chin, Henrik

2. Service Definition(SD): Jerry

3. Topology representation, NML-related, type/value pair
representation: Jeroen, Freek, Team

4. Users' equipments connection model: Tomohiro

5. Control plane topology and message handling: John, Henrik

6. Security proflile: Inder
 including, minimum information that should be shared through the
protocol by (all/involved) NSAs.

7. Error handling, PA->RA communication: John, Henrik, Chin

8. Federation: Jerry, Tomohiro

9. Optional constraints: Chin

10. NSA-client interface: John, Inder

11. Uni-directional cirucuit: Jerry

12. Sub-path (route or ERO): Chin, Tomohiro


2012/3/1 Tomohiro Kudoh <t.kudoh at aist.go.jp>:
> Hello all,
>
> Here is proposed assignments to prepare a slide or a document for the
> Oxford meeting.
> Note that this does not mean other topic/person cannot make
> presentation at the meeting.
>
> 1. State Machine: Tomohiro, Chin, Henrik
>
> 2. Service Definition(SD): Jerry
>
> 3. Topology representation, NML-related, type/value pair representation: Team
>
> 4. Users' equipments connection model: Tomohiro
>
> 5. Control plane topology and message handling: John
>
> 6. Security proflile: Inder
>  including, minimum information that should be shared through the
> protocol by (all/involved) NSAs.
>
> 7. Error handling, PA->RA communication: John, Henrik, Chin
>
> 8. Federation: Jerry, Tomohiro
>
> 9. Optional constraints: Chin
>
> 10. NSA-client interface: John, Inder
>
> 11. Uni-directional cirucuit: Jerry
>
> 12. Sub-path (route or ERO): Chin, Tomohiro



-- 
????   t.kudoh at aist.go.jp
?????? ????????? ???????? ?????????????
?305-8568 ?????????1-1-1????
Phone:029-861-5761 Fax:029-862-6601

From john.macauley at surfnet.nl  Wed Feb 29 11:38:45 2012
From: john.macauley at surfnet.nl (John MacAuley)
Date: Wed, 29 Feb 2012 17:38:45 +0100 (CET)
Subject: [Nsi-wg] assignment list
In-Reply-To: <CAEGiyHv7PrqU7khE2VU6OMztUUoJaO_GKG0fOKxhYY0Acuv9JQ@mail.gmail.com>
Message-ID: <eef95db3-9bf6-4582-ab9c-cba29d8fa764@ms10.zimbra.surfnet.nl>

I would also like to bring in proposals for:
- interface discovery (including versioning)
- Message restructuring for optimization

Thank you,
John.

----- Original Message -----
> From: "Tomohiro Kudoh" <t.kudoh at aist.go.jp>
> To: "NSI WG" <nsi-wg at ogf.org>
> Sent: Wednesday, February 29, 2012 8:07:39 AM
> Subject: [Nsi-wg] assignment list
> 
> Hello all,
> 
> Here is proposed assignments to prepare a slide or a document for the
> Oxford meeting.
> Note that this does not mean other topic/person cannot make
> presentation at the meeting.
> 
> 1. State Machine: Tomohiro, Chin, Henrik
> 
> 2. Service Definition(SD): Jerry
> 
> 3. Topology representation, NML-related, type/value pair
> representation: Team
> 
> 4. Users' equipments connection model: Tomohiro
> 
> 5. Control plane topology and message handling: John
> 
> 6. Security proflile: Inder
>  including, minimum information that should be shared through the
> protocol by (all/involved) NSAs.
> 
> 7. Error handling, PA->RA communication: John, Henrik, Chin
> 
> 8. Federation: Jerry, Tomohiro
> 
> 9. Optional constraints: Chin
> 
> 10. NSA-client interface: John, Inder
> 
> 11. Uni-directional cirucuit: Jerry
> 
> 12. Sub-path (route or ERO): Chin, Tomohiro
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
>