[Nsi-wg] Comments on NSI architecture document.

[Jerry Sobieski]

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/20100617/4722cd5a/attachment.html