[Nsi-wg] Notify Query Primitives

Tue Nov 9 21:54:49 CST 2010

Hi John -

A few comments regarding your input to the Notify doc... In general, I 
had considered some of these but chose to ignore in order to start simply. 

1.  Yes, agree that there should be some registration identifier 
returned in the notify repsonse that can be used for canceling a notify 
later on.  Definately a good idea.

2.  Yes, more informative error code(s) could be returned.  But my 
concern is to not expose unauthorized information by merit of error 
codes.  But as long as it is fairly innocuous, I agree that more 
informative error codes can be more helpful.   In general though, error 
codes are second order issues since they normally should not happen:-)   
For simplicity, I suggested we simply say "Yes you are registered for 
that event" or "No, your registration failed."  Minimally speaking, 
thats all you really need:-)

3. My concern about wildcards is not that they can't be implemented or 
that they don't scale, but that they incur substantial overhead since 
the code must check the condition *very time* one of the parameters 
change.   My only real reason for suggesting wildcards not be allowed 
was to start simply.  I believe the issue of monitoring state to detect 
qualifying events could incur *substantial* runtime overhead, and wll 
defintately make implementation far more complex.    We should be 
cautious about what we decalre to be "notifiable".   Defining the event 
conditions is easy, detecting when all the conditions that make up the 
event click together is hard. For example - everytime a parameter 
changes value, any and all condition it is part of must be evaluated.  
Therefore, every time you update a parameter there must be a check made 
to see if any conditions are attached to the parameter, if there are 
then evaluate it, and then evaluate the event that condition is part of 
as well.    This must be done everytime any notifiable paramter is 
modified.   For this reason, I suggest we limit the set of parameters 
that can be used to define an notification event.

4. regarding a Notify Acknowledge...I didn't think an Ack was necessary 
on the assumption that the underlying transport was guaranteeing 
delivery of the message.  There are times when an NSA should acknowledge 
a message - specifically, when it incurs a commitment or cost not 
previously acknowledged.   But the Notify() action was already requested 
and registered, and if the transport layer still believes the target NSA 
is still reachable, then just sending the message should be (IMO) 
sufficient.  So I just didn't think an acknowledge was necessary...  If 
you require an Ack, then you need timers to handle a case where the Ack 
doesn;t come or takes too long, and ultimately, if it doesn't come - 
what would/should the PA do?

Summary questions on Notify() - These are all *Excellent* observations.  
And I agree, they must be resolved before the Notify() can or should be 
specified as a NSI primitive.  And resolving these will take some time 
and discussion...and IMO make the protocol still more complex (read: 
error prone :-()    I sound like a stuck record, but I concur that all 
these questions should be answered before we can say they function in a 
clear and deterministic manner.

Regarding the size of messages in the QueryResp() message...  I agree 
there are many protocols that can support essentially unlimited size 
messages... If we need to do this, then we need to specify that protocol 
explicitly.  And we need to understand how we combine responses 
filtering up the tree...this is not done by the transport protocol but 
must be specified as part of the NSI protocol.     

Many good points John...thanks for looking it over.

We should also keep in mind a couple other things: 
--- Can the NSI CS Protocol work properly to manage the lifecycle of a 
connection if there is no Notify primitive or no Query primitive?     If 
we can, then maybe these are part of another NSI "service" and should 
not be part of the NSI CS primitives...?

--- How long will it take to resolve the Notify and Query primitive 
functionality ...do we want to wait that long to complete the  NSI V1.0 
waiting for these primitives?   Perhaps these are good V2.0 
features...?   (I think it might be best to do so in the interest of time.)

--- Since these are similar primitives, and one is highly similar to an 
SQL interface, perhaps we should try to define both as SQL interfaces to 
a well defined Relation DB schema that holds the information?   IMO, 
this sounds more and more like a separate NSI service....(but I could be 
wrong:-)

--- These primitives if fully functioned will be complex to implement, 
and costly to support in the code.  How might we reduce the complexity 
or enhance the run time efficiency?  

Talk to you all tomorrow!
Jerry

John MacAuley wrote:
> Jerry,
>
> I added a bunch of comments in red to the document.  We can discuss at 
> the meeting tomorrow morning.
>
> Thank you,
> John.
>
>
> ------------------------------------------------------------------------
>
>
> On 2010-11-09, at 12:09 PM, Jerry Sobieski wrote:
>
>> Hi all-
>>
>> I was to write up something on the Notify and Query Primitives... 
>>  here it is - at least a rough draft.   As usual, as we think these 
>> things through there are lots of considerations,   I tried to keep it 
>> simple to start.    I put down about 3 pages on Notify, and about 2 
>> pages on Query.   High level stuff so it should not take you long to 
>> look it over.   I can summarize on the call Wednesday.
>>
>> Best regards
>> Jerry
>> <NotifyQuery.docx>_______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>
> =
> ------------------------------------------------------------------------
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20101109/88cc070a/attachment.html 