[Nsi-wg] Comments on NSI architecture document.

[Jerry Sobieski]

Hmm ...This is a good point John.   Let me try to restate you rissue:   
If an RA receives a request with an undetermined optional parameter, and 
that parameter is not fixed before decomposing the request for down-tree 
processing, then there exists a possibility that down-tree (tree model) 
sub-requests could defaut that parameter to different (and possibly 
incompatible) default values.

Execellent and valid observation.

I have to agree that in this case, the undetermined parameter needs to 
be fixed by the parent NSA in order that downstream PAs use the same 
constraint in path computation.  And I am thinking the best simplest 
approach would indeed be to require that any undefined parameters should 
be fixed before decomposing the request.   

But on the other hand, the need to do this may be dependent on the 
parameter's fundamental purpose and the degree of incompatibility caused 
by disparate subsegments.   For instance, some paramters may not be 
incompatible, but may simply induce a lowest common denominator on 
performance end to end, such as a packet_drop_rate or bit_error-rate.   
And if the originating RA does not specify a value, then it is 
reasonable to assert that that constraint (or the results of such an 
undeterminant request) is not of interest.    This would be a very 
strict interpretation but may not be the right practical approach. 

It should be noted that if an NSA assigns a default value to an 
undetermined parameter and the resulting subrequests fail, it is 
reasonable to suggest that the NSA could try another auto-generated 
assigned value and resubmit the request downstream.   It is possible 
that there may be a number of paramters left undetermined in a request.  
And trying all permutations , while strictly possible, could be very 
timeconsuming and costly in terms of cycles, and so would not scale in a 
heavy request load.   The way to deal with this is to try a value, if it 
fails, pass the failed request (including the defaults) back to the 
user.  We let the user decide if they wish to adjust the paramters and 
try again.

So, for now, lets assert that undetermined paramters found in a request 
SHOULD be defaulted by the PA-NSA before decomposing the request and 
forwarding downstream.  Further, since there may be several possible 
downstream defaults, we leave it to the NSA to "do whats right" - i.e. 
to implement some heuristic to make an intelligent decision in choosing 
a default.

Good catch.   Lets simmer on this and make sure this is a good approach.
Jerry

John MacAuley wrote:
> Thank you Jerry for talking the time to respond.  I have been reading 
> the specification with protocol implementation in mind so want to make 
> sure I understand the concepts.  I think the Service Definition 
> concept is good and have implemented similar mechanisms in other 
> products.  Where my specific confusion comes in is around the handling 
> of optional parameters with defaults where the default values are 
> different per NSA domain.  You can reassure me that this is not a 
> valid concern, but let me outline the use case that came to mind when 
> I read this section of the document.
>
> A User Client (UC) issues a reservation request to a local NSA which 
> will assume the role of Requester NSA (RA) for this example.  The RA 
> creates a service definition template populated with parameters 
> important to the UC.  In this scenario let us assume that the MTU was 
> not specified by the UC, and therefore, will utilize the defaults 
> supported by the network.
>
> If the RA who receives the UC request then fills in the MTU parameter 
> with its default value before issuing the schedule request to 
> subordinate Provider NSA (PA), then we are all good and the default 
> value chosen by the RA for MTU will be sent down and approved by all 
> subordinate PA, or alternatively, rejected if the MTU value is not 
> supported.
>
> From the text written I assumed that the RA would not fill in the MTU 
> parameter:
>
>     "If a service parameter is not present in the service request,
>     then the provider NSA should “fill in the blanks” from default
>     values in the Service Definition."
>
> I may have read too much into this text, and in fact, we really expect 
> the RA to fill in the default values, but this was the impression I 
> was left with.  So now if we look at the same example, but in this 
> case the RA does not fill in the default MTU size, we can have two 
> separate subordinate PA select incompatible MTU sizes.  The resulting 
> connection service definition information would be returned to the RA 
> and it would see that the MTU sizes are incompatible.  I therefore 
> assumed a second pass would be required to normalize these values in 
> the subordinate PA.
>
> So am I out in left field on this one?
>
> John.
>  
> On 10-06-17 4:53 AM, Jerry Sobieski wrote:
>> Here are my thoughts on the Service Definition issues John refers to:
>>
>>
>> John MacAuley wrote:
>>>
>>> _Section 3.4 NSI Service Definitions_
>>>
>>> “A service request is fully specified when all parameters associated 
>>> with that service have been determined either by explicit user 
>>> specification or by implicit default values found in the Service 
>>> Definition.”
>>>
>>> Are service definition defaults a common global configuration or are 
>>> these defaults a localized decision?  If they are a localized 
>>> decision then the requestor NSA should “fill in the blanks” so that 
>>> all subsequent provider NSA contacted have the assumed default 
>>> values filled in the service request.
>>>
>> Service Definitions are not expected/required to match one another 
>> completely.   Of course, the more similar they are, the better, but I 
>> don't think we can assert or assume that every network will  have 
>> the  exact same service capabilities.    I think "similar" service 
>> definitions will have the same service parameters,  and "identical" 
>> services would have the same  values for  those parameters.
>>
>> I think the SD ought to flag parameters that are required (i.e. 
>> *must* be specified by the requester), and those that are optional 
>> (i.e. the requester *may* specify these parameters).   For optional 
>> parameters, the SD *may* specify the default value to be used if the 
>> request does not explicitly specify the value.  If a Service 
>> Definition specifies a default value for a parameter, it must be 
>> used.  If the SD does not specify a default for an optional 
>> parameter, then that parameter should not even be considered as a 
>> constraint at all when searching the topology for a path (e.g. such a 
>> parameter might be the Bit Error Rate...if unspecified, it is not 
>> considered as a constraint, and the user gets whatever is associetaed 
>> with the path that is found based upon other constraints.)
>>
>> Implicit here is a notion that when the reservation is confirmed, 
>> there exist "settings" for all parameters associated with the service 
>> instance.   Some (many?) of these paramters may not have been 
>> specified as constraints in the original request, but they 
>> nevertheless get resolved as the path is selected.
>>
>> We (I?) need to consider this default handling issue more 
>> thoroughly.  But I do not think it is a significant issue for the NSI 
>> Architecture doc.  This is part of pathfinding, and as such IMO it is 
>> out of scope for the NSI Arch.
>>
>> However, I do think the Service Definition concept overall should be 
>> the subject of its own white paper (its been 5 years since Tom Lehman 
>> and I wrote the original concept paper.)   There are many issues for 
>> which it appears to be a very elegant approach and so we will want a 
>> more complete treatment than a few paragraphs in the NSI Architecture 
>> documnet.
>>
>>> _Section 5.1.2 Service Definitions for Connection Services_
>>>
>>> “If a service parameter is not present in the service request, then 
>>> the provider NSA should “fill in the blanks” from default values in 
>>> the Service Definition.  As the request is processed down the NSA 
>>> service tree, default values adopted in one transit network may 
>>> implicitly constrain the request in downstream networks.  Therefore, 
>>> in general, each NSA should use default values that provide the 
>>> greatest leeway to the pathfinder in satisfying the request both 
>>> within the local network and in external downstream networks.”
>>>
>>> This mechanism is rather complex as described.  If service 
>>> parameters are left open ended by some NSA, then an additional visit 
>>> to that NSA must be performed to finalize the actual negotiated 
>>> parameters.  In the tree model this would require a second pass to 
>>> commit the final service definition negotiated across the network.  
>>> In the chain model it would require the end terminating NSA in the 
>>> chain to finalize the service definition and then every node 
>>> returning up the chain would finalize their definition.
>>>
>> Hmmm... I'm not sure I follow John.
>>
>> These paramters fill strategies do not affect the tree/chain 
>> reservation process.  If an RA does not fill the request, then the PA 
>> has two choices: it must make some assumptions and process the 
>> request; or not, and reject the request.    If the RA does not 
>> specify, say, MTU, should we reject the request until it does?   Why 
>> can not we simply apply a default value that offers the best value to 
>> the user, and then process the request down the tree normally?    We 
>> can adopt different strategies...  The Provider NSA could fill with a 
>> value that is most likely to succeed in reserving a path, in this 
>> example 1500B MTU might provide the best odds of finding a viable 
>> path.   Or an alternative strategy might be to find a value that 
>> provides a "better" connection irregardless of how likely it is to be 
>> suceesfully found, in this case the MTU might be 9000B MTU.  These 
>> default selections strategies are so nuanced that I don't think we 
>> want to deal with them at this time.    So I propose we allow the SD 
>> to  identify required and optional parametrs, and the SD can specify 
>> defaults for optional params.
>>
>> The pathfinding and confirmation process remains the same regardless 
>> of how we set the defaults.   There is no additional cost in 
>> complexity for either tree or chain model (remember- the chain is 
>> just a degenerate form of the tree model)
>>
>>
>> Hope this helps!
>> Jerry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100622/a18885a2/attachment-0001.html