[Nsi-wg] suggested diagrams

Wed Sep 15 06:10:38 CDT 2010

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 at man.poznan.pl                   Networking Center
+48 61 850 25 26                             http://www.man.poznan.pl
________________________________________________________________________

> -----Original Message-----
> From: Guy Roberts [mailto:Guy.Roberts at dante.net]
> Sent: Wednesday, September 15, 2010 12:37 PM
> To: 'radek.krzywania at 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 at 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 at man.poznan.pl                   Networking Center
> +48 61 850 25 26                             http://www.man.poznan.pl
> __________________________________________________________
> ______________
> 
> 
> > -----Original Message-----
> > From: nsi-wg-bounces at ogf.org [mailto:nsi-wg-bounces at 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 at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg