Hi, I can't join you today (I am on other project meeting in Zurich). Regarding signalled reservations, from the diagrams it seems that either Requestor NSA or/and Provider NSA can ignite the creation of connection. In fact, those approaches excludes themselves in some way. I see only two possible scenarios (explained in my email) and both are possible, but having both of them allowed at the same time does not bring much sense to me (some messages will be ignored, has no meaning and will generate unnecessary message flows). Hope it's more clear now :) Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________

-----Original Message----- From: Guy Roberts [mailto:Guy.Roberts@dante.net] Sent: Wednesday, September 15, 2010 12:37 PM To: 'radek.krzywania@man.poznan.pl'; 'John Vollbrecht'; 'NSI WG' Subject: RE: [Nsi-wg] suggested diagrams

Radek,

Thanks for these comments.

I agree that simplicity and a quick turn-around for the Connection Service standard is a priority. On balance I am also not in favour of a modify command in version 1.0. As you say, a cancel command followed by a new request will work in many cases.

I am not sure that I understand your point regarding signalled reservations - perhaps we can discuss on the call today?

Guy

-----Original Message----- From: Radek Krzywania [mailto:radek.krzywania@man.poznan.pl] Sent: 15 September 2010 08:53 To: 'John Vollbrecht'; 'NSI WG' Subject: Re: [Nsi-wg] suggested diagrams

Hi all, Maybe I am in minority, but for the sake of simplicity, and speed up the process of NSI protocol v1 release, I would really skip anything related to modification of the reservation. First - users usually knows what they want, so I don�t expect this option to be extensively used. Second - in most cases this introduce complexity to reservation processing, which requires use cases and analyses. In some cases modification of reservation cause to create completely new one, with new path, new attributes, etc. This IMHO is v2.

I've missed last call, so maybe I am not in the subject right now (I will miss today call also due to travelling), but sending ResvConn from Requestor NSA is either pointless or should be the only option. Provider will not set up the connection before scheduled time, so Provider NSA will ignore Requestor NSA ResvConn message in such case. If Provider NSA will not setup a connection as scheduled by himself, what is the reason to book it (operator can't use those resources anyway)? The following options are possible: - Provider NSA books resources (not configure). Requestor NSA can ignite the connection creation anytime between scheduled time and also terminate it within that time. Provider NSA anyway needs to close the connection at the end of scheduled time, if Requestor NSA did not so. So Requestor NSA needs to keep track of connection state anyway (but that obvious). - Provider NSA creates connection in the scheduled time frame (connection start/end time), thus Requestor NSA does not need to send anything. The circuit will be just there as requested. Here an information from Provider NSA to Requestor NSA about circuit creation/cancellation is required (therefore the dashed lines on figures 2 and 3 in your pdf for ConfProv and CancelConf should be solid, thus obligatory). Requestor NSA may cancel the connection any time as well, by sending a message to Provider NSA (but this is not obligatory, also I would not care for v1; this is kind of reservation modification as it changes reservation end time in fact).

Mixing those two scenarios introduces mixed use cases, while we should think if such situations will happen in reality. The issue will arise while we get accounting system and what policy will be used to charge users - time based or connection based. If user is charged per connection, he will not care to release resources before connection expiration time, as this will not save "money" for him (in contrary to operator, but not necessary). If policy is on time basis, user may pay far more attention to when start and close connections. On the other hand, from operator point of view, resources are booked anyway, so it does not matter if the connection is created and active, or not (except some green IT stuff, power and cooling, etc., while connection is active, but this is not the case here, especially for v1). Due to this, I am closer to the first scenario, where ProviderNSA takes care of setting up and tearing down the circuits, while Requestor NSA is just requesting a connection in specific time frame (booking/scheduling). Huh - this email is getting long :) If you wish, I could write a short document on that, providing issues any thoughts.

And small comment on primitives - the message names should be unified ConfResv, ConfProv, but CancelConf. So the last message should be ConfCancel.

Best regards Radek __________________________________________________________ ______________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl __________________________________________________________ ______________

...

-----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of John Vollbrecht Sent: Tuesday, September 14, 2010 11:52 PM To: NSI WG Subject: [Nsi-wg] suggested diagrams

Attached are two pics - the first is a possible replacement for figure 3 in section 5 of the current doc. The second shows some additional primitives that can be added in similar way.

Separating the timelines is meant to indicate that the initiating requestor might not be the same in each case. The dotted lines indicate that some messages are optional in the getting the work done in a connection lifecycle.

We might talk about this tomorrow.

I haven't had a chance to show the notify, but I will try to add this tomorrow before the call.

John

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

Hi, Seems I’m not necessary in minority :) with no modify(). Regarding reservation start time, I agree with Jerry in most points. In AutoBAHN e.g. each IDM (in comparison to Provider NSA) ignite the connection creation by himself, according to his calendar entries. The reservation home domain IDM is notified about status change, so since all domain along the path report connection activation, the service is delivered to the user. Another point in my mind, in reference to what Jerry mention about connection state – the state of the connection is not simple value (active, or whatever), but it’s sum of all intra-domain stated of the local “sub-connections”, as it can be provisioned in one domain, in-service in other, etc.. That’s again the example of AutoBAHN. I also agree to follow the same rule for “immediate” reservation. For sake of simplicity mostly, but in fact there is not much differences between immediate and advance (except resources management). Also an argument to use start time and duration, instead of start and end time. Since reservation is required “immediately” it will start after provisioning time (which is unknown). If user set a duration, the service will be kept for that time. If a user specify an end time instead, the duration of the service will be ambiguous. It’s then a question of what is more important to users – to have service for a specific time, or to finish at specific time. I slightly disagree with the last Jerry conclusion. But only slightly. In fact for v1 we should keep it simple, but on the other hand, we can’t use defaults. The negotiation process is the most important one for NSI connection service, as it defines how the connection will be configured. User should be out of it, as far as possible (set start time, duration, start point, end point, capacity, click OK, and get some coffee). But the NSAs will need to set the low level network attributes and agree them (e.g. full/half duplex, autonegotiation, 100/1000 Mbps, VLAN identifier, domain peering points for particular connection, etc.). We can keep it simple, but not with defaults at low level. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and <mailto:radek.krzywania@man.poznan.pl> radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 <http://www.man.poznan.pl> http://www.man.poznan.pl ________________________________________________________________________ From: Jerry Sobieski [mailto:jerry@nordu.net] Sent: Wednesday, September 15, 2010 2:34 PM To: radek.krzywania@man.poznan.pl Cc: 'John Vollbrecht'; 'NSI WG' Subject: Re: [Nsi-wg] suggested diagrams Hi Radek / all- I agree with Radek that a modify() primitive is not something we should include in V1.0 There are too many complexities and fundamentally it does not provide the protocol a capability that is not able to be perfromed though other mechanisms. As for provisioning, we had quite a long discussion - several as I recall - regarding how a connection reservation should go from "scheduled" state thru "provisioning" state to "active" state. I agree with Radek that ultimately a Provision() request issued from a RA will be ignored (should be ignored!) if it is not within the reserved time of the reservation...and if the resources are reserved for a certain time but not provisioned, they are still allocated to the Connection and so the connection owner should still be charged accordingly. ..And if the user is being charged, why should the PA not provision the connection when the reservation begins regardless of whether the RA requests it explicitly? I do not recall from our discussions why we thought the RA needed to do this? There is a certain elegance that I like by having the prime mover NSA initiate the provisioning that goes down the service tree and bubbles back up the service tree with confirmations... But there are timing complexities here that cause problems, and there are other ways to have the notifications bubble up the service tree. Seperately, there was an issue of provisioning time. I.e. Does the reserved "Start Time" represent when the "Provisioning" state is entered, or does it represent when the "In-Service" state is entered? The implication is that in the latter case some [estimated] guard time must be added to the start time in the reservation to allow for provisioning time. As I recall, we were converging on a consensus view that for the RA initiatied "Manual Start" connection the Start Time was the start of provisioning, and for a PA initiatied "Auto-Start" connection that the Start Time was the In-Service time. --> The simplest way to resolve this for v1.0 would be to simply assert that Provisioning begins at the Start Time, and that Release begins at the End Time, and both are PA initiated. This makes the user accountable for setup time, and the network accountable for tear down time. It could be a policy decision to only charge the user for the In-Service time, but we simplify the service protocol by simply mapping Start Time to one specific event, and simply mapping End Time to another specific event. (Note: a reservation could still be released early by RA request, but the PA release would be standard.) A lot of the discussion of Manual/Auto start had to do with synchronicity of calendars: If I issue a manual start down tree, but the down tree calendar is not quite sych'd with my calendar, I might get a reject just because I issue the manual start too early... So this introduces all kinds of protocol complexities in order to recover and/or retry it later... Again, a RA initiated manual start may actually introduce a lot of unwanted complexities. The simplest approach is IMO to require each NSA to autostart their provisioning and, seperately, require a up-tree notify() whenever the connection state changes. The state change notify will allow each PA to know deterministically that all subtree components are completed, and then it can push a notify up to the RA. I do not recall what the use case justification was for an RA initiated Manual Start. However, as stated above, I can envision the need for a PA->RA notification ( or alert of some sort) that the Connection has transitioned into an "In Service" lifecycle state (or more generally a notification whenever the Connection changes state.) Ultimately, IMO we need to be able to assure that the state of a connection is deterministic within every NSA and that the protocol converges to a single state for all NSAs. This means that even though each NSA up and down the tree may have a different state for their portion of the connection at certain times as it ttransitions, that given time, the protocol will converge to a single state for the connection end to end and up/down the service tree. This implies that certain states are stable and will only change if there is an external triggering event (such as a timer expiry or a new protocol message is received). There is also the issue of "immediate" connection requests. I.e. a connection whose start time has already passed (or was specified as null). These connections are to be placed into service as soon as possible. I suggest for simplicity sake, that these requests follow the same lifecycle as a book-ahead reservation. I.e. they are initiated with a Reserve() primitive like any other connection, Response go back like any other primitive, and the provisioning is auto-started, and the connection goes into service as quickly as these states can be managed down the service tree. I don't see a need to do things differnently for immediate vs scheduled reservations. Finally, I think it is fundamental that the Connection service provide first and foremost a simple ability to deliver a connection with the specific and guarranteed characteristics requested by the user. I think the simplest approach to this is to fill in unspecified characteristics with defaults from a Service Definition, and then provide a Yea or Nay confirmation. No negotiation, no PA adjusted parameters, no guesses as to what the user might accept, no 20 questions, ....The user requests exactly what they want, and the network either says yes or no. This would be the best way to get started (IMHO:-) Sorry for the length...ugh Jerry Radek Krzywania wrote: Hi all, Maybe I am in minority, but for the sake of simplicity, and speed up the process of NSI protocol v1 release, I would really skip anything related to modification of the reservation. First - users usually knows what they want, so I don’t expect this option to be extensively used. Second - in most cases this introduce complexity to reservation processing, which requires use cases and analyses. In some cases modification of reservation cause to create completely new one, with new path, new attributes, etc. This IMHO is v2. I've missed last call, so maybe I am not in the subject right now (I will miss today call also due to travelling), but sending ResvConn from Requestor NSA is either pointless or should be the only option. Provider will not set up the connection before scheduled time, so Provider NSA will ignore Requestor NSA ResvConn message in such case. If Provider NSA will not setup a connection as scheduled by himself, what is the reason to book it (operator can't use those resources anyway)? The following options are possible: - Provider NSA books resources (not configure). Requestor NSA can ignite the connection creation anytime between scheduled time and also terminate it within that time. Provider NSA anyway needs to close the connection at the end of scheduled time, if Requestor NSA did not so. So Requestor NSA needs to keep track of connection state anyway (but that obvious). - Provider NSA creates connection in the scheduled time frame (connection start/end time), thus Requestor NSA does not need to send anything. The circuit will be just there as requested. Here an information from Provider NSA to Requestor NSA about circuit creation/cancellation is required (therefore the dashed lines on figures 2 and 3 in your pdf for ConfProv and CancelConf should be solid, thus obligatory). Requestor NSA may cancel the connection any time as well, by sending a message to Provider NSA (but this is not obligatory, also I would not care for v1; this is kind of reservation modification as it changes reservation end time in fact). Mixing those two scenarios introduces mixed use cases, while we should think if such situations will happen in reality. The issue will arise while we get accounting system and what policy will be used to charge users - time based or connection based. If user is charged per connection, he will not care to release resources before connection expiration time, as this will not save "money" for him (in contrary to operator, but not necessary). If policy is on time basis, user may pay far more attention to when start and close connections. On the other hand, from operator point of view, resources are booked anyway, so it does not matter if the connection is created and active, or not (except some green IT stuff, power and cooling, etc., while connection is active, but this is not the case here, especially for v1). Due to this, I am closer to the first scenario, where ProviderNSA takes care of setting up and tearing down the circuits, while Requestor NSA is just requesting a connect ion in specific time frame (booking/scheduling). Huh - this email is getting long :) If you wish, I could write a short document on that, providing issues any thoughts. And small comment on primitives - the message names should be unified ConfResv, ConfProv, but CancelConf. So the last message should be ConfCancel. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________ -----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of John Vollbrecht Sent: Tuesday, September 14, 2010 11:52 PM To: NSI WG Subject: [Nsi-wg] suggested diagrams Attached are two pics - the first is a possible replacement for figure 3 in section 5 of the current doc. The second shows some additional primitives that can be added in similar way. Separating the timelines is meant to indicate that the initiating requestor might not be the same in each case. The dotted lines indicate that some messages are optional in the getting the work done in a connection lifecycle. We might talk about this tomorrow. I haven't had a chance to show the notify, but I will try to add this tomorrow before the call. John _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg

Hi John, Extending the time is not as easy. Even if the connection is not active yet, it is scheduled in calendars. So in fact you need to check all domains if they have free resources for the same path to extend reservation duration. In case not, you need to find other path. Since reservation is scheduled, things get complex. If it gets active, things gets very complex. :) Also don’t touch accounting right now. It’s a question whether it is even in the scope of NSI-WG. I just used accounting example to show options for ignition of in-service status. But this is a subject where you can write books about. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and <mailto:radek.krzywania@man.poznan.pl> radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 <http://www.man.poznan.pl> http://www.man.poznan.pl ________________________________________________________________________ From: John Vollbrecht [mailto:jrv@internet2.edu] Sent: Wednesday, September 15, 2010 3:44 PM To: Jerry Sobieski Cc: John Vollbrecht; radek.krzywania@man.poznan.pl; 'NSI WG' Subject: Re: [Nsi-wg] suggested diagrams On Sep 15, 2010, at 8:34 AM, Jerry Sobieski wrote: Hi Radek / all- I agree with Radek that a modify() primitive is not something we should include in V1.0 There are too many complexities and fundamentally it does not provide the protocol a capability that is not able to be perfromed though other mechanisms. I am fine with making modify a v2 capability. However I note the simple use case where a application has not finished its work and would like to continue if possible. It can extend the time without taking the connection down. If the connection is still reserved not active, it can extend or reduce the reservation without risking losing it entirely. I agree with Radek that figuring out how to charge for this is very difficult. An extension of that charging issue is at what point is a reservation charge for - as soon as it is reserved even if it is cancelled later? Or perhaps only when the reservation is provisioned? In the latter case one might reserve connections and then cancel if not needed. Very complicated, and not something for v1 in my opinion. As for provisioning, we had quite a long discussion - several as I recall - regarding how a connection reservation should go from "scheduled" state thru "provisioning" state to "active" state. I agree with Radek that ultimately a Provision() request issued from a RA will be ignored (should be ignored!) if it is not within the reserved time of the reservation...and if the resources are reserved for a certain time but not provisioned, they are still allocated to the Connection and so the connection owner should still be charged accordingly. ..And if the user is being charged, why should the PA not provision the connection when the reservation begins regardless of whether the RA requests it explicitly? I do not recall from our discussions why we thought the RA needed to do this? There is a certain elegance that I like by having the prime mover NSA initiate the provisioning that goes down the service tree and bubbles back up the service tree with confirmations... But there are timing complexities here that cause problems, and there are other ways to have the notifications bubble up the service tree. Seperately, there was an issue of provisioning time. I.e. Does the reserved "Start Time" represent when the "Provisioning" state is entered, or does it represent when the "In-Service" state is entered? The implication is that in the latter case some [estimated] guard time must be added to the start time in the reservation to allow for provisioning time. As I recall, we were converging on a consensus view that for the RA initiatied "Manual Start" connection the Start Time was the start of provisioning, and for a PA initiatied "Auto-Start" connection that the Start Time was the In-Service time. --> The simplest way to resolve this for v1.0 would be to simply assert that Provisioning begins at the Start Time, and that Release begins at the End Time, and both are PA initiated. This makes the user accountable for setup time, and the network accountable for tear down time. It could be a policy decision to only charge the user for the In-Service time, but we simplify the service protocol by simply mapping Start Time to one specific event, and simply mapping End Time to another specific event. (Note: a reservation could still be released early by RA request, but the PA release would be standard.) A lot of the discussion of Manual/Auto start had to do with synchronicity of calendars: If I issue a manual start down tree, but the down tree calendar is not quite sych'd with my calendar, I might get a reject just because I issue the manual start too early... So this introduces all kinds of protocol complexities in order to recover and/or retry it later... Again, a RA initiated manual start may actually introduce a lot of unwanted complexities. The simplest approach is IMO to require each NSA to autostart their provisioning and, seperately, require a up-tree notify() whenever the connection state changes. The state change notify will allow each PA to know deterministically that all subtree components are completed, and then it can push a notify up to the RA. I do not recall what the use case justification was for an RA initiated Manual Start. However, as stated above, I can envision the need for a PA->RA notification ( or alert of some sort) that the Connection has transitioned into an "In Service" lifecycle state (or more generally a notification whenever the Connection changes state.) Ultimately, IMO we need to be able to assure that the state of a connection is deterministic within every NSA and that the protocol converges to a single state for all NSAs. This means that even though each NSA up and down the tree may have a different state for their portion of the connection at certain times as it ttransitions, that given time, the protocol will converge to a single state for the connection end to end and up/down the service tree. This implies that certain states are stable and will only change if there is an external triggering event (such as a timer expiry or a new protocol message is received). There is also the issue of "immediate" connection requests. I.e. a connection whose start time has already passed (or was specified as null). These connections are to be placed into service as soon as possible. I suggest for simplicity sake, that these requests follow the same lifecycle as a book-ahead reservation. I.e. they are initiated with a Reserve() primitive like any other connection, Response go back like any other primitive, and the provisioning is auto-started, and the connection goes into service as quickly as these states can be managed down the service tree. I don't see a need to do things differnently for immediate vs scheduled reservations. Finally, I think it is fundamental that the Connection service provide first and foremost a simple ability to deliver a connection with the specific and guarranteed characteristics requested by the user. I think the simplest approach to this is to fill in unspecified characteristics with defaults from a Service Definition, and then provide a Yea or Nay confirmation. No negotiation, no PA adjusted parameters, no guesses as to what the user might accept, no 20 questions, ....The user requests exactly what they want, and the network either says yes or no. This would be the best way to get started (IMHO:-) Sorry for the length...ugh Jerry Radek Krzywania wrote: Hi all, Maybe I am in minority, but for the sake of simplicity, and speed up the process of NSI protocol v1 release, I would really skip anything related to modification of the reservation. First - users usually knows what they want, so I don’t expect this option to be extensively used. Second - in most cases this introduce complexity to reservation processing, which requires use cases and analyses. In some cases modification of reservation cause to create completely new one, with new path, new attributes, etc. This IMHO is v2. I've missed last call, so maybe I am not in the subject right now (I will miss today call also due to travelling), but sending ResvConn from Requestor NSA is either pointless or should be the only option. Provider will not set up the connection before scheduled time, so Provider NSA will ignore Requestor NSA ResvConn message in such case. If Provider NSA will not setup a connection as scheduled by himself, what is the reason to book it (operator can't use those resources anyway)? The following options are possible: - Provider NSA books resources (not configure). Requestor NSA can ignite the connection creation anytime between scheduled time and also terminate it within that time. Provider NSA anyway needs to close the connection at the end of scheduled time, if Requestor NSA did not so. So Requestor NSA needs to keep track of connection state anyway (but that obvious). - Provider NSA creates connection in the scheduled time frame (connection start/end time), thus Requestor NSA does not need to send anything. The circuit will be just there as requested. Here an information from Provider NSA to Requestor NSA about circuit creation/cancellation is required (therefore the dashed lines on figures 2 and 3 in your pdf for ConfProv and CancelConf should be solid, thus obligatory). Requestor NSA may cancel the connection any time as well, by sending a message to Provider NSA (but this is not obligatory, also I would not care for v1; this is kind of reservation modification as it changes reservation end time in fact). Mixing those two scenarios introduces mixed use cases, while we should think if such situations will happen in reality. The issue will arise while we get accounting system and what policy will be used to charge users - time based or connection based. If user is charged per connection, he will not care to release resources before connection expiration time, as this will not save "money" for him (in contrary to operator, but not necessary). If policy is on time basis, user may pay far more attention to when start and close connections. On the other hand, from operator point of view, resources are booked anyway, so it does not matter if the connection is created and active, or not (except some green IT stuff, power and cooling, etc., while connection is active, but this is not the case here, especially for v1). Due to this, I am closer to the first scenario, where ProviderNSA takes care of setting up and tearing down the circuits, while Requestor NSA is just requesting a connect ion in specific time frame (booking/scheduling). Huh - this email is getting long :) If you wish, I could write a short document on that, providing issues any thoughts. And small comment on primitives - the message names should be unified ConfResv, ConfProv, but CancelConf. So the last message should be ConfCancel. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and <mailto:radek.krzywania@man.poznan.pl> radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 <http://www.man.poznan.pl/> http://www.man.poznan.pl ________________________________________________________________________ -----Original Message----- From: <mailto:nsi-wg-bounces@ogf.org> nsi-wg-bounces@ogf.org [ <mailto:nsi-wg-bounces@ogf.org> mailto:nsi-wg-bounces@ogf.org] On Behalf Of John Vollbrecht Sent: Tuesday, September 14, 2010 11:52 PM To: NSI WG Subject: [Nsi-wg] suggested diagrams Attached are two pics - the first is a possible replacement for figure 3 in section 5 of the current doc. The second shows some additional primitives that can be added in similar way. Separating the timelines is meant to indicate that the initiating requestor might not be the same in each case. The dotted lines indicate that some messages are optional in the getting the work done in a connection lifecycle. We might talk about this tomorrow. I haven't had a chance to show the notify, but I will try to add this tomorrow before the call. John _______________________________________________ nsi-wg mailing list <mailto:nsi-wg@ogf.org> nsi-wg@ogf.org <http://www.ogf.org/mailman/listinfo/nsi-wg> http://www.ogf.org/mailman/listinfo/nsi-wg

Hi, I don’t want anyway in V1, because it MAY happen it is not possible to extend reservation duration on the same path. And it still require to ask all domains along the path if they can extend the reservation. For AutoBAHN we have never meet a user requirement to do such things yet, maybe people related to ION had different experiences. I would rather keep v1 as simple as possible, and play with extensions as soon as we will be able to deliver any service at all ;) Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and <mailto:radek.krzywania@man.poznan.pl> radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 <http://www.man.poznan.pl> http://www.man.poznan.pl ________________________________________________________________________ From: John Vollbrecht [mailto:jrv@internet2.edu] Sent: Wednesday, September 15, 2010 5:31 PM To: radek.krzywania@man.poznan.pl Cc: John Vollbrecht; 'Jerry Sobieski'; 'NSI WG' Subject: Re: [Nsi-wg] suggested diagrams I agree mostly - small note below - On Sep 15, 2010, at 10:53 AM, Radek Krzywania wrote: Hi John, Extending the time is not as easy. Even if the connection is not active yet, it is scheduled in calendars. So in fact you need to check all domains if they have free resources for the same path to extend reservation duration. In case not, you need to find other path. True, but a simple case is if it can be extended on the same path because it is available. If it is, why not use it. Since reservation is scheduled, things get complex. If it gets active, things gets very complex. :) Also don’t touch accounting right now. It’s a question whether it is even in the scope of NSI-WG. I just used accounting example to show options for ignition of in-service status. But this is a subject where you can write books about. This I agree with 100% Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and <mailto:radek.krzywania@man.poznan.pl> radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 <http://www.man.poznan.pl/> http://www.man.poznan.pl ________________________________________________________________________ From: John Vollbrecht [mailto:jrv@internet2.edu] Sent: Wednesday, September 15, 2010 3:44 PM To: Jerry Sobieski Cc: John Vollbrecht; radek.krzywania@man.poznan.pl; 'NSI WG' Subject: Re: [Nsi-wg] suggested diagrams On Sep 15, 2010, at 8:34 AM, Jerry Sobieski wrote: Hi Radek / all- I agree with Radek that a modify() primitive is not something we should include in V1.0 There are too many complexities and fundamentally it does not provide the protocol a capability that is not able to be perfromed though other mechanisms. I am fine with making modify a v2 capability. However I note the simple use case where a application has not finished its work and would like to continue if possible. It can extend the time without taking the connection down. If the connection is still reserved not active, it can extend or reduce the reservation without risking losing it entirely. I agree with Radek that figuring out how to charge for this is very difficult. An extension of that charging issue is at what point is a reservation charge for - as soon as it is reserved even if it is cancelled later? Or perhaps only when the reservation is provisioned? In the latter case one might reserve connections and then cancel if not needed. Very complicated, and not something for v1 in my opinion. As for provisioning, we had quite a long discussion - several as I recall - regarding how a connection reservation should go from "scheduled" state thru "provisioning" state to "active" state. I agree with Radek that ultimately a Provision() request issued from a RA will be ignored (should be ignored!) if it is not within the reserved time of the reservation...and if the resources are reserved for a certain time but not provisioned, they are still allocated to the Connection and so the connection owner should still be charged accordingly. ..And if the user is being charged, why should the PA not provision the connection when the reservation begins regardless of whether the RA requests it explicitly? I do not recall from our discussions why we thought the RA needed to do this? There is a certain elegance that I like by having the prime mover NSA initiate the provisioning that goes down the service tree and bubbles back up the service tree with confirmations... But there are timing complexities here that cause problems, and there are other ways to have the notifications bubble up the service tree. Seperately, there was an issue of provisioning time. I.e. Does the reserved "Start Time" represent when the "Provisioning" state is entered, or does it represent when the "In-Service" state is entered? The implication is that in the latter case some [estimated] guard time must be added to the start time in the reservation to allow for provisioning time. As I recall, we were converging on a consensus view that for the RA initiatied "Manual Start" connection the Start Time was the start of provisioning, and for a PA initiatied "Auto-Start" connection that the Start Time was the In-Service time. --> The simplest way to resolve this for v1.0 would be to simply assert that Provisioning begins at the Start Time, and that Release begins at the End Time, and both are PA initiated. This makes the user accountable for setup time, and the network accountable for tear down time. It could be a policy decision to only charge the user for the In-Service time, but we simplify the service protocol by simply mapping Start Time to one specific event, and simply mapping End Time to another specific event. (Note: a reservation could still be released early by RA request, but the PA release would be standard.) A lot of the discussion of Manual/Auto start had to do with synchronicity of calendars: If I issue a manual start down tree, but the down tree calendar is not quite sych'd with my calendar, I might get a reject just because I issue the manual start too early... So this introduces all kinds of protocol complexities in order to recover and/or retry it later... Again, a RA initiated manual start may actually introduce a lot of unwanted complexities. The simplest approach is IMO to require each NSA to autostart their provisioning and, seperately, require a up-tree notify() whenever the connection state changes. The state change notify will allow each PA to know deterministically that all subtree components are completed, and then it can push a notify up to the RA. I do not recall what the use case justification was for an RA initiated Manual Start. However, as stated above, I can envision the need for a PA->RA notification ( or alert of some sort) that the Connection has transitioned into an "In Service" lifecycle state (or more generally a notification whenever the Connection changes state.) Ultimately, IMO we need to be able to assure that the state of a connection is deterministic within every NSA and that the protocol converges to a single state for all NSAs. This means that even though each NSA up and down the tree may have a different state for their portion of the connection at certain times as it ttransitions, that given time, the protocol will converge to a single state for the connection end to end and up/down the service tree. This implies that certain states are stable and will only change if there is an external triggering event (such as a timer expiry or a new protocol message is received). There is also the issue of "immediate" connection requests. I.e. a connection whose start time has already passed (or was specified as null). These connections are to be placed into service as soon as possible. I suggest for simplicity sake, that these requests follow the same lifecycle as a book-ahead reservation. I.e. they are initiated with a Reserve() primitive like any other connection, Response go back like any other primitive, and the provisioning is auto-started, and the connection goes into service as quickly as these states can be managed down the service tree. I don't see a need to do things differnently for immediate vs scheduled reservations. Finally, I think it is fundamental that the Connection service provide first and foremost a simple ability to deliver a connection with the specific and guarranteed characteristics requested by the user. I think the simplest approach to this is to fill in unspecified characteristics with defaults from a Service Definition, and then provide a Yea or Nay confirmation. No negotiation, no PA adjusted parameters, no guesses as to what the user might accept, no 20 questions, ....The user requests exactly what they want, and the network either says yes or no. This would be the best way to get started (IMHO:-) Sorry for the length...ugh Jerry Radek Krzywania wrote: Hi all, Maybe I am in minority, but for the sake of simplicity, and speed up the process of NSI protocol v1 release, I would really skip anything related to modification of the reservation. First - users usually knows what they want, so I don’t expect this option to be extensively used. Second - in most cases this introduce complexity to reservation processing, which requires use cases and analyses. In some cases modification of reservation cause to create completely new one, with new path, new attributes, etc. This IMHO is v2. I've missed last call, so maybe I am not in the subject right now (I will miss today call also due to travelling), but sending ResvConn from Requestor NSA is either pointless or should be the only option. Provider will not set up the connection before scheduled time, so Provider NSA will ignore Requestor NSA ResvConn message in such case. If Provider NSA will not setup a connection as scheduled by himself, what is the reason to book it (operator can't use those resources anyway)? The following options are possible: - Provider NSA books resources (not configure). Requestor NSA can ignite the connection creation anytime between scheduled time and also terminate it within that time. Provider NSA anyway needs to close the connection at the end of scheduled time, if Requestor NSA did not so. So Requestor NSA needs to keep track of connection state anyway (but that obvious). - Provider NSA creates connection in the scheduled time frame (connection start/end time), thus Requestor NSA does not need to send anything. The circuit will be just there as requested. Here an information from Provider NSA to Requestor NSA about circuit creation/cancellation is required (therefore the dashed lines on figures 2 and 3 in your pdf for ConfProv and CancelConf should be solid, thus obligatory). Requestor NSA may cancel the connection any time as well, by sending a message to Provider NSA (but this is not obligatory, also I would not care for v1; this is kind of reservation modification as it changes reservation end time in fact). Mixing those two scenarios introduces mixed use cases, while we should think if such situations will happen in reality. The issue will arise while we get accounting system and what policy will be used to charge users - time based or connection based. If user is charged per connection, he will not care to release resources before connection expiration time, as this will not save "money" for him (in contrary to operator, but not necessary). If policy is on time basis, user may pay far more attention to when start and close connections. On the other hand, from operator point of view, resources are booked anyway, so it does not matter if the connection is created and active, or not (except some green IT stuff, power and cooling, etc., while connection is active, but this is not the case here, especially for v1). Due to this, I am closer to the first scenario, where ProviderNSA takes care of setting up and tearing down the circuits, while Requestor NSA is just requesting a connect ion in specific time frame (booking/scheduling). Huh - this email is getting long :) If you wish, I could write a short document on that, providing issues any thoughts. And small comment on primitives - the message names should be unified ConfResv, ConfProv, but CancelConf. So the last message should be ConfCancel. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and <mailto:radek.krzywania@man.poznan.pl> radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 <http://www.man.poznan.pl/> http://www.man.poznan.pl ________________________________________________________________________ -----Original Message----- From: <mailto:nsi-wg-bounces@ogf.org> nsi-wg-bounces@ogf.org [ <mailto:nsi-wg-bounces@ogf.org> mailto:nsi-wg-bounces@ogf.org] On Behalf Of John Vollbrecht Sent: Tuesday, September 14, 2010 11:52 PM To: NSI WG Subject: [Nsi-wg] suggested diagrams Attached are two pics - the first is a possible replacement for figure 3 in section 5 of the current doc. The second shows some additional primitives that can be added in similar way. Separating the timelines is meant to indicate that the initiating requestor might not be the same in each case. The dotted lines indicate that some messages are optional in the getting the work done in a connection lifecycle. We might talk about this tomorrow. I haven't had a chance to show the notify, but I will try to add this tomorrow before the call. John _______________________________________________ nsi-wg mailing list <mailto:nsi-wg@ogf.org> nsi-wg@ogf.org <http://www.ogf.org/mailman/listinfo/nsi-wg> http://www.ogf.org/mailman/listinfo/nsi-wg

Hi Inder, But we can’t put everything into the protocol in v1. IMHO we should focus on delivering the service and what is the minimum we need to do that (protocol is ready not when there is nothing to add, but when there is nothing else to remove :) ). Since we have that, we can develop it further. Backward compatibility will be always a case, but we can deal with that in various ways. Also people should be interested in upgrades and follow our work, instead of using v1 forever, while we are e.g. about to release v5. Adding a modify() in v2 will not change so much in v1 version IMHO, so I don’t see the case here. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and <mailto:radek.krzywania@man.poznan.pl> radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 <http://www.man.poznan.pl> http://www.man.poznan.pl ________________________________________________________________________ From: Inder Monga [mailto:imonga@es.net] Sent: Thursday, September 16, 2010 3:23 PM To: radek.krzywania@man.poznan.pl Cc: John Vollbrecht; NSI WG Subject: Re: [Nsi-wg] suggested diagrams Radek I appreciate your concerns and the ability to provide service. But would like you to consider separating the service provided from the protocol definition. A domain can choose not to support the modification service even though it is part of the language/protocol. We can make certain primitives optional. It is not easy to standardize new features in protocols , come with v2 and also worry about backward compatibility at the protocol level. Inder On Sep 16, 2010, at 12:15 AM, "Radek Krzywania" <radek.krzywania@man.poznan.pl> wrote: Hi, I don’t want anyway in V1, because it MAY happen it is not possible to extend reservation duration on the same path. And it still require to ask all domains along the path if they can extend the reservation. For AutoBAHN we have never meet a user requirement to do such things yet, maybe people related to ION had different experiences. I would rather keep v1 as simple as possible, and play with extensions as soon as we will be able to deliver any service at all ;) Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________ From: John Vollbrecht [mailto:jrv@internet2.edu] Sent: Wednesday, September 15, 2010 5:31 PM To: radek.krzywania@man.poznan.pl Cc: John Vollbrecht; 'Jerry Sobieski'; 'NSI WG' Subject: Re: [Nsi-wg] suggested diagrams I agree mostly - small note below - On Sep 15, 2010, at 10:53 AM, Radek Krzywania wrote: Hi John, Extending the time is not as easy. Even if the connection is not active yet, it is scheduled in calendars. So in fact you need to check all domains if they have free resources for the same path to extend reservation duration. In case not, you need to find other path. True, but a simple case is if it can be extended on the same path because it is available. If it is, why not use it. Since reservation is scheduled, things get complex. If it gets active, things gets very complex. :) Also don’t touch accounting right now. It’s a question whether it is even in the scope of NSI-WG. I just used accounting example to show options for ignition of in-service status. But this is a subject where you can write books about. This I agree with 100% Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and <mailto:radek.krzywania@man.poznan.pl> radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 <http://www.man.poznan.pl/> http://www.man.poznan.pl ________________________________________________________________________ From: John Vollbrecht [mailto:jrv@internet2.edu] Sent: Wednesday, September 15, 2010 3:44 PM To: Jerry Sobieski Cc: John Vollbrecht; radek.krzywania@man.poznan.pl; 'NSI WG' Subject: Re: [Nsi-wg] suggested diagrams On Sep 15, 2010, at 8:34 AM, Jerry Sobieski wrote: Hi Radek / all- I agree with Radek that a modify() primitive is not something we should include in V1.0 There are too many complexities and fundamentally it does not provide the protocol a capability that is not able to be perfromed though other mechanisms. I am fine with making modify a v2 capability. However I note the simple use case where a application has not finished its work and would like to continue if possible. It can extend the time without taking the connection down. If the connection is still reserved not active, it can extend or reduce the reservation without risking losing it entirely. I agree with Radek that figuring out how to charge for this is very difficult. An extension of that charging issue is at what point is a reservation charge for - as soon as it is reserved even if it is cancelled later? Or perhaps only when the reservation is provisioned? In the latter case one might reserve connections and then cancel if not needed. Very complicated, and not something for v1 in my opinion. As for provisioning, we had quite a long discussion - several as I recall - regarding how a connection reservation should go from "scheduled" state thru "provisioning" state to "active" state. I agree with Radek that ultimately a Provision() request issued from a RA will be ignored (should be ignored!) if it is not within the reserved time of the reservation...and if the resources are reserved for a certain time but not provisioned, they are still allocated to the Connection and so the connection owner should still be charged accordingly. ..And if the user is being charged, why should the PA not provision the connection when the reservation begins regardless of whether the RA requests it explicitly? I do not recall from our discussions why we thought the RA needed to do this? There is a certain elegance that I like by having the prime mover NSA initiate the provisioning that goes down the service tree and bubbles back up the service tree with confirmations... But there are timing complexities here that cause problems, and there are other ways to have the notifications bubble up the service tree. Seperately, there was an issue of provisioning time. I.e. Does the reserved "Start Time" represent when the "Provisioning" state is entered, or does it represent when the "In-Service" state is entered? The implication is that in the latter case some [estimated] guard time must be added to the start time in the reservation to allow for provisioning time. As I recall, we were converging on a consensus view that for the RA initiatied "Manual Start" connection the Start Time was the start of provisioning, and for a PA initiatied "Auto-Start" connection that the Start Time was the In-Service time. --> The simplest way to resolve this for v1.0 would be to simply assert that Provisioning begins at the Start Time, and that Release begins at the End Time, and both are PA initiated. This makes the user accountable for setup time, and the network accountable for tear down time. It could be a policy decision to only charge the user for the In-Service time, but we simplify the service protocol by simply mapping Start Time to one specific event, and simply mapping End Time to another specific event. (Note: a reservation could still be released early by RA request, but the PA release would be standard.) A lot of the discussion of Manual/Auto start had to do with synchronicity of calendars: If I issue a manual start down tree, but the down tree calendar is not quite sych'd with my calendar, I might get a reject just because I issue the manual start too early... So this introduces all kinds of protocol complexities in order to recover and/or retry it later... Again, a RA initiated manual start may actually introduce a lot of unwanted complexities. The simplest approach is IMO to require each NSA to autostart their provisioning and, seperately, require a up-tree notify() whenever the connection state changes. The state change notify will allow each PA to know deterministically that all subtree components are completed, and then it can push a notify up to the RA. I do not recall what the use case justification was for an RA initiated Manual Start. However, as stated above, I can envision the need for a PA->RA notification ( or alert of some sort) that the Connection has transitioned into an "In Service" lifecycle state (or more generally a notification whenever the Connection changes state.) Ultimately, IMO we need to be able to assure that the state of a connection is deterministic within every NSA and that the protocol converges to a single state for all NSAs. This means that even though each NSA up and down the tree may have a different state for their portion of the connection at certain times as it ttransitions, that given time, the protocol will converge to a single state for the connection end to end and up/down the service tree. This implies that certain states are stable and will only change if there is an external triggering event (such as a timer expiry or a new protocol message is received). There is also the issue of "immediate" connection requests. I.e. a connection whose start time has already passed (or was specified as null). These connections are to be placed into service as soon as possible. I suggest for simplicity sake, that these requests follow the same lifecycle as a book-ahead reservation. I.e. they are initiated with a Reserve() primitive like any other connection, Response go back like any other primitive, and the provisioning is auto-started, and the connection goes into service as quickly as these states can be managed down the service tree. I don't see a need to do things differnently for immediate vs scheduled reservations. Finally, I think it is fundamental that the Connection service provide first and foremost a simple ability to deliver a connection with the specific and guarranteed characteristics requested by the user. I think the simplest approach to this is to fill in unspecified characteristics with defaults from a Service Definition, and then provide a Yea or Nay confirmation. No negotiation, no PA adjusted parameters, no guesses as to what the user might accept, no 20 questions, ....The user requests exactly what they want, and the network either says yes or no. This would be the best way to get started (IMHO:-) Sorry for the length...ugh Jerry Radek Krzywania wrote: Hi all, Maybe I am in minority, but for the sake of simplicity, and speed up the process of NSI protocol v1 release, I would really skip anything related to modification of the reservation. First - users usually knows what they want, so I don’t expect this option to be extensively used. Second - in most cases this introduce complexity to reservation processing, which requires use cases and analyses. In some cases modification of reservation cause to create completely new one, with new path, new attributes, etc. This IMHO is v2. I've missed last call, so maybe I am not in the subject right now (I will miss today call also due to travelling), but sending ResvConn from Requestor NSA is either pointless or should be the only option. Provider will not set up the connection before scheduled time, so Provider NSA will ignore Requestor NSA ResvConn message in such case. If Provider NSA will not setup a connection as scheduled by himself, what is the reason to book it (operator can't use those resources anyway)? The following options are possible: - Provider NSA books resources (not configure). Requestor NSA can ignite the connection creation anytime between scheduled time and also terminate it within that time. Provider NSA anyway needs to close the connection at the end of scheduled time, if Requestor NSA did not so. So Requestor NSA needs to keep track of connection state anyway (but that obvious). - Provider NSA creates connection in the scheduled time frame (connection start/end time), thus Requestor NSA does not need to send anything. The circuit will be just there as requested. Here an information from Provider NSA to Requestor NSA about circuit creation/cancellation is required (therefore the dashed lines on figures 2 and 3 in your pdf for ConfProv and CancelConf should be solid, thus obligatory). Requestor NSA may cancel the connection any time as well, by sending a message to Provider NSA (but this is not obligatory, also I would not care for v1; this is kind of reservation modification as it changes reservation end time in fact). Mixing those two scenarios introduces mixed use cases, while we should think if such situations will happen in reality. The issue will arise while we get accounting system and what policy will be used to charge users - time based or connection based. If user is charged per connection, he will not care to release resources before connection expiration time, as this will not save "money" for him (in contrary to operator, but not necessary). If policy is on time basis, user may pay far more attention to when start and close connections. On the other hand, from operator point of view, resources are booked anyway, so it does not matter if the connection is created and active, or not (except some green IT stuff, power and cooling, etc., while connection is active, but this is not the case here, especially for v1). Due to this, I am closer to the first scenario, where ProviderNSA takes care of setting up and tearing down the circuits, while Requestor NSA is just requesting a connect ion in specific time frame (booking/scheduling). Huh - this email is getting long :) If you wish, I could write a short document on that, providing issues any thoughts. And small comment on primitives - the message names should be unified ConfResv, ConfProv, but CancelConf. So the last message should be ConfCancel. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and <mailto:radek.krzywania@man.poznan.pl> radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 <http://www.man.poznan.pl/> http://www.man.poznan.pl ________________________________________________________________________ -----Original Message----- From: <mailto:nsi-wg-bounces@ogf.org> nsi-wg-bounces@ogf.org [ <mailto:nsi-wg-bounces@ogf.org> mailto:nsi-wg-bounces@ogf.org] On Behalf Of John Vollbrecht Sent: Tuesday, September 14, 2010 11:52 PM To: NSI WG Subject: [Nsi-wg] suggested diagrams Attached are two pics - the first is a possible replacement for figure 3 in section 5 of the current doc. The second shows some additional primitives that can be added in similar way. Separating the timelines is meant to indicate that the initiating requestor might not be the same in each case. The dotted lines indicate that some messages are optional in the getting the work done in a connection lifecycle. We might talk about this tomorrow. I haven't had a chance to show the notify, but I will try to add this tomorrow before the call. John _______________________________________________ nsi-wg mailing list <mailto:nsi-wg@ogf.org> nsi-wg@ogf.org <http://www.ogf.org/mailman/listinfo/nsi-wg> http://www.ogf.org/mailman/listinfo/nsi-wg _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg

Hi, Fragmented calendar is something we can’t avoid somehow. We can’t prevent user from canceling the reservation, but we can still charge him for that (economy is simple and brutal). Even if not the full price, someone can define a cost as a static value for provision + calculated cost for usage of particular links. The static value is not returned in case of cancellation. Anyway the calendar will be fragmented, as users books links on their preferences of start end time. So we can’t schedule them in the calendar, in order to utilize resources in most optimal way. So unless we implement a feature schedule-as-soon-as-possible (not v1), and users start to use it, the calendar will be fragmented. And even if they will use this option, this will not be the whole community (e.g. radioastronomers are glued to specific sky observations periods). Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and <mailto:radek.krzywania@man.poznan.pl> radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 <http://www.man.poznan.pl> http://www.man.poznan.pl ________________________________________________________________________ From: Harold Teunissen [mailto:harold.teunissen@surfnet.nl] Sent: Wednesday, September 15, 2010 5:38 PM To: radek.krzywania@man.poznan.pl Cc: John Vollbrecht; Jerry Sobieski; NSI WG Subject: Re: [Nsi-wg] suggested diagrams Radek, all, I believe account can somehow be combined within the authorization flow of the particular connection. It depends how intermediate network charge each other and than how the user/application/virtual organization is charged. A reserved and confirmed end-to-end path could be renegotiated unless the application is capable of dealing which such a negotiation mechanism. Of course the application could cancel a resevation, leaving a gap in the schedule. If this happens often you might end up with a heavy defragemented calendar. Harold Teunissen SURFnet Sent from my iPad On Sep 15, 2010, at 16:55, "Radek Krzywania" <radek.krzywania@man.poznan.pl> wrote: Hi John, Extending the time is not as easy. Even if the connection is not active yet, it is scheduled in calendars. So in fact you need to check all domains if they have free resources for the same path to extend reservation duration. In case not, you need to find other path. Since reservation is scheduled, things get complex. If it gets active, things gets very complex. :) Also don’t touch accounting right now. It’s a question whether it is even in the scope of NSI-WG. I just used accounting example to show options for ignition of in-service status. But this is a subject where you can write books about. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and <mailto:radek.krzywania@man.poznan.pl> radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 <http://www.man.poznan.pl> http://www.man.poznan.pl ________________________________________________________________________ From: John Vollbrecht [mailto:jrv@internet2.edu] Sent: Wednesday, September 15, 2010 3:44 PM To: Jerry Sobieski Cc: John Vollbrecht; radek.krzywania@man.poznan.pl; 'NSI WG' Subject: Re: [Nsi-wg] suggested diagrams On Sep 15, 2010, at 8:34 AM, Jerry Sobieski wrote: Hi Radek / all- I agree with Radek that a modify() primitive is not something we should include in V1.0 There are too many complexities and fundamentally it does not provide the protocol a capability that is not able to be perfromed though other mechanisms. I am fine with making modify a v2 capability. However I note the simple use case where a application has not finished its work and would like to continue if possible. It can extend the time without taking the connection down. If the connection is still reserved not active, it can extend or reduce the reservation without risking losing it entirely. I agree with Radek that figuring out how to charge for this is very difficult. An extension of that charging issue is at what point is a reservation charge for - as soon as it is reserved even if it is cancelled later? Or perhaps only when the reservation is provisioned? In the latter case one might reserve connections and then cancel if not needed. Very complicated, and not something for v1 in my opinion. As for provisioning, we had quite a long discussion - several as I recall - regarding how a connection reservation should go from "scheduled" state thru "provisioning" state to "active" state. I agree with Radek that ultimately a Provision() request issued from a RA will be ignored (should be ignored!) if it is not within the reserved time of the reservation...and if the resources are reserved for a certain time but not provisioned, they are still allocated to the Connection and so the connection owner should still be charged accordingly. ..And if the user is being charged, why should the PA not provision the connection when the reservation begins regardless of whether the RA requests it explicitly? I do not recall from our discussions why we thought the RA needed to do this? There is a certain elegance that I like by having the prime mover NSA initiate the provisioning that goes down the service tree and bubbles back up the service tree with confirmations... But there are timing complexities here that cause problems, and there are other ways to have the notifications bubble up the service tree. Seperately, there was an issue of provisioning time. I.e. Does the reserved "Start Time" represent when the "Provisioning" state is entered, or does it represent when the "In-Service" state is entered? The implication is that in the latter case some [estimated] guard time must be added to the start time in the reservation to allow for provisioning time. As I recall, we were converging on a consensus view that for the RA initiatied "Manual Start" connection the Start Time was the start of provisioning, and for a PA initiatied "Auto-Start" connection that the Start Time was the In-Service time. --> The simplest way to resolve this for v1.0 would be to simply assert that Provisioning begins at the Start Time, and that Release begins at the End Time, and both are PA initiated. This makes the user accountable for setup time, and the network accountable for tear down time. It could be a policy decision to only charge the user for the In-Service time, but we simplify the service protocol by simply mapping Start Time to one specific event, and simply mapping End Time to another specific event. (Note: a reservation could still be released early by RA request, but the PA release would be standard.) A lot of the discussion of Manual/Auto start had to do with synchronicity of calendars: If I issue a manual start down tree, but the down tree calendar is not quite sych'd with my calendar, I might get a reject just because I issue the manual start too early... So this introduces all kinds of protocol complexities in order to recover and/or retry it later... Again, a RA initiated manual start may actually introduce a lot of unwanted complexities. The simplest approach is IMO to require each NSA to autostart their provisioning and, seperately, require a up-tree notify() whenever the connection state changes. The state change notify will allow each PA to know deterministically that all subtree components are completed, and then it can push a notify up to the RA. I do not recall what the use case justification was for an RA initiated Manual Start. However, as stated above, I can envision the need for a PA->RA notification ( or alert of some sort) that the Connection has transitioned into an "In Service" lifecycle state (or more generally a notification whenever the Connection changes state.) Ultimately, IMO we need to be able to assure that the state of a connection is deterministic within every NSA and that the protocol converges to a single state for all NSAs. This means that even though each NSA up and down the tree may have a different state for their portion of the connection at certain times as it ttransitions, that given time, the protocol will converge to a single state for the connection end to end and up/down the service tree. This implies that certain states are stable and will only change if there is an external triggering event (such as a timer expiry or a new protocol message is received). There is also the issue of "immediate" connection requests. I.e. a connection whose start time has already passed (or was specified as null). These connections are to be placed into service as soon as possible. I suggest for simplicity sake, that these requests follow the same lifecycle as a book-ahead reservation. I.e. they are initiated with a Reserve() primitive like any other connection, Response go back like any other primitive, and the provisioning is auto-started, and the connection goes into service as quickly as these states can be managed down the service tree. I don't see a need to do things differnently for immediate vs scheduled reservations. Finally, I think it is fundamental that the Connection service provide first and foremost a simple ability to deliver a connection with the specific and guarranteed characteristics requested by the user. I think the simplest approach to this is to fill in unspecified characteristics with defaults from a Service Definition, and then provide a Yea or Nay confirmation. No negotiation, no PA adjusted parameters, no guesses as to what the user might accept, no 20 questions, ....The user requests exactly what they want, and the network either says yes or no. This would be the best way to get started (IMHO:-) Sorry for the length...ugh Jerry Radek Krzywania wrote: Hi all, Maybe I am in minority, but for the sake of simplicity, and speed up the process of NSI protocol v1 release, I would really skip anything related to modification of the reservation. First - users usually knows what they want, so I don’t expect this option to be extensively used. Second - in most cases this introduce complexity to reservation processing, which requires use cases and analyses. In some cases modification of reservation cause to create completely new one, with new path, new attributes, etc. This IMHO is v2. I've missed last call, so maybe I am not in the subject right now (I will miss today call also due to travelling), but sending ResvConn from Requestor NSA is either pointless or should be the only option. Provider will not set up the connection before scheduled time, so Provider NSA will ignore Requestor NSA ResvConn message in such case. If Provider NSA will not setup a connection as scheduled by himself, what is the reason to book it (operator can't use those resources anyway)? The following options are possible: - Provider NSA books resources (not configure). Requestor NSA can ignite the connection creation anytime between scheduled time and also terminate it within that time. Provider NSA anyway needs to close the connection at the end of scheduled time, if Requestor NSA did not so. So Requestor NSA needs to keep track of connection state anyway (but that obvious). - Provider NSA creates connection in the scheduled time frame (connection start/end time), thus Requestor NSA does not need to send anything. The circuit will be just there as requested. Here an information from Provider NSA to Requestor NSA about circuit creation/cancellation is required (therefore the dashed lines on figures 2 and 3 in your pdf for ConfProv and CancelConf should be solid, thus obligatory). Requestor NSA may cancel the connection any time as well, by sending a message to Provider NSA (but this is not obligatory, also I would not care for v1; this is kind of reservation modification as it changes reservation end time in fact). Mixing those two scenarios introduces mixed use cases, while we should think if such situations will happen in reality. The issue will arise while we get accounting system and what policy will be used to charge users - time based or connection based. If user is charged per connection, he will not care to release resources before connection expiration time, as this will not save "money" for him (in contrary to operator, but not necessary). If policy is on time basis, user may pay far more attention to when start and close connections. On the other hand, from operator point of view, resources are booked anyway, so it does not matter if the connection is created and active, or not (except some green IT stuff, power and cooling, etc., while connection is active, but this is not the case here, especially for v1). Due to this, I am closer to the first scenario, where ProviderNSA takes care of setting up and tearing down the circuits, while Requestor NSA is just requesting a connect ion in specific time frame (booking/scheduling). Huh - this email is getting long :) If you wish, I could write a short document on that, providing issues any thoughts. And small comment on primitives - the message names should be unified ConfResv, ConfProv, but CancelConf. So the last message should be ConfCancel. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and <mailto:radek.krzywania@man.poznan.pl> radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 <http://www.man.poznan.pl/> http://www.man.poznan.pl ________________________________________________________________________ -----Original Message----- From: <mailto:nsi-wg-bounces@ogf.org> nsi-wg-bounces@ogf.org [ <mailto:nsi-wg-bounces@ogf.org> mailto:nsi-wg-bounces@ogf.org] On Behalf Of John Vollbrecht Sent: Tuesday, September 14, 2010 11:52 PM To: NSI WG Subject: [Nsi-wg] suggested diagrams Attached are two pics - the first is a possible replacement for figure 3 in section 5 of the current doc. The second shows some additional primitives that can be added in similar way. Separating the timelines is meant to indicate that the initiating requestor might not be the same in each case. The dotted lines indicate that some messages are optional in the getting the work done in a connection lifecycle. We might talk about this tomorrow. I haven't had a chance to show the notify, but I will try to add this tomorrow before the call. John _______________________________________________ nsi-wg mailing list <mailto:nsi-wg@ogf.org> nsi-wg@ogf.org <http://www.ogf.org/mailman/listinfo/nsi-wg> http://www.ogf.org/mailman/listinfo/nsi-wg _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg