The following is dial-in information for Wednesday’s NSI call: Time: 7:30 PDT 10:30 EDT, 15:30 BST, 16:30 CEST, 23:30 JST Call: +1-734-615-7474 (Please use if you do not pay for Long Distance) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0155180 Agenda -- a) review plans for OGF when people will arrive, session times and other sessions b) submitting architecture document - current version (Guy has done a lot of work on this) http://forge.gridforum.org/sf/go/doc15984?nav=1 c) Review docs submitted 1. Chin/Inder revised error handling 2. Jerry - service definition text 3. John - revised trust and authentication (see attached) Other?
Peoples, I spent some time going through the specification in detail last week, but unfortunately, I used an older version of the document so last night I consolidated my comments against Guy’s version I pulled down on Monday. I colour coded for your reading pleasure. Red implies original text from the document. I have attached a word version of the comments if the formatting gets lost in transit. John. _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. And similarly, _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. _Section 3.6 Trust and authentication in NSI_ The term “service handler” is used for the first time. Should this read, “message handler” as defined in figure 5? “The second mode is to employ a more message based trust framework such as Web Services. This message based form is more appropriate for occasional messaging as might occur between an application agent and various provider NSAs.” I believe this last statement is subjective and should be removed from the document. I am currently working on a production product that is processing over 400 SOAP messages a second with per message authentication while performing other more computationally heavy tasks. I think this exceeds the expectation of “occasional” :-) _Section 3.7 Error handling NSI_ The term “Network errors” is ambiguous based on the topic at hand. Could we better qualify this to “Service plane (NSI protocol infrastructure) errors” to distinguish this from transport plane network errors? I was going to complain about our confusing use of the term “service” but have no valid alternative :-) “A failure in the Service Plane should not result in an incomplete service.” should be restated as a goal objective. If we have started to provision an end-to-end transport connection and part way through we have a provider NSA or DCN failure we have no way of knowing if the sub-network connection was established or not, and therefore, we are in an incomplete state that we cannot recover from. “For example, a user may request that if any NSA fails, all the NSAs handling the same service instance should tear down the Connection Service in the Transport Plane.” This is a very interesting error handling scenario. I had assumed that only the requesting NSA would need to listen for failure notifications from individual provider NSA against the services it instantiated, but with this example we imply that each NSA will listen for events from other NSA on services it may only tandem so that it might tear down the tandem during failures (a chain would only require adjacent NSA to be monitored as failures would be cascaded). Do we really want this additional complexity to protect against a double failure? I would recommend we keep it simple and have the requesting NSA decide when to tear down the transport resources through a cancel request, otherwise, all connection resources get cleaned up at end-time. “Failures in the Service Plane during Reservation, Provisioning, Teardown, and Release phases can cause problems for the operation of the NSI.” Do we want to normalize these phases against the states described in Figure 15? Specifically, the phase “teardown” is not stated in Figure 15. In fact, is “teardown” not redundant with “releasing”? “Figure 11: Local/Remote Failures” was a bit confusing for me. Does the rounded square represent a local NSA? Should we expand this section, or add an appendix covering error use cases? _Section 3.8 Transport failure awareness_ Detection of transport errors should be a local issue but the NSI protocol needs to specify a mechanism to notify other NSA of a local transport failure against a connection. The correlation of local transport error to impacted connections is a local matter. Once again, should we expand this section, or add an appendix covering error use cases? _Section 5.1.3 The Connection Service States_ “In the NSI, a connection goes through five phases: Reserving, Scheduled, Provisioning, In-Service, Releasing.” I think we could benefit from having a high level state machine in the document to capture additional information implied in the text. As I was trying to correlate the phases to the operations as defined in Figures 15 and 16, as well as include error handling, I formed the opinion that we need some additional state information beyond what we in Figure 15 to show the life cycle of a connection. “When the Release has completed, the connection object is deleted from the Service Plane.” Given my previous statement I believe we do not want to delete the connection object after resources have been freed, but introduce additional end states that allow the object to exist after the scheduled end time. At the moment, if a cancelRequest is processed to completion the connection object would end up being deleted as soon as the transport resources have been released. Now I can no longer see the state of this connection object, and therefore, cannot determine any state information about the connection after the fact. If the originating user did not issue the cancel request, they would have no way to query their connection to see what happened. I think an easy solution to this problem is to have a set of end states for a connection object and place a hold over timer on the connection object that would eventually remove it from the NSA, but only after a period of time (say 24 hours). We also need to clearly indicate if the connection was terminated due to error, a cancel request, or if the scheduled end-time occurred. _Section 5.1.4 Connection reservation messages_ “If the connection request includes a valid start-time and an end-time then the request is considered to be an advance reservation request.” Does this preclude me from specifying a ”duration” instead of an “end-time” for an advance reservation? “If the connection request has the start-time set to ‘asap’ and has a duration field rather than an end time field, the request is considered to be an immediate reservation request.” Why preclude an end-time as a possible field for the immediate reservation? We only need trigger off the “asap” to determine it is an immediate reservation. Can we normalize the “de-provisioning” terminology to “releasing” as stated in previous sections? “When operating in explicit mode, it is the responsibility of the requestor NSA to signal the reservation to begin provisioning and to begin de-provisioning of the connection. These signals are known as the ProvisionRequest and CancelRequest.” Based on the statement in section 5.1.5, paragraph 2, “The reservation end-time refers to the time at which the reservation is removed. (If the user has not yet sent a CancelRequest signal the connection is de-provisioned first)” can I assume that “signaling of de-provisioning” is optional and both automatic and explicit mode connections will be automatically torn down when end-time occurs? _Section 5.1.5 Connection reservation and timing parameters_ I think we need to make the following two definitions consistent as they introduce conflicting code logic that really doesn’t need to be. 1. “For advance reservation with /automatic/ provisioning, the start-time refers to the time at which the connection moves from provisioning state to in-service state.” 2. “For advance reservation with /explicit/ provisioning, the start-time refers to the time at which the provider is able to accept a provision signal.” In #1 the NSA must start provisioning the local connection segment at “start-time” – “guard-time” (this is my definition of guard-time and not the one in the document) so that the connection can be “in-service” by “start-time.” However, for #2 the “start-time” parameter represents the point at which the requesting NSA can request provisioning of the connection to start. In the case of #2, the actual “in-service” state is achieved at “start-time” + “guard-time” and not “start-time” as in #1. I think we should try to avoid this type of confusion in the document, as it will also imply two separate definitions in an NSA implementation. May I suggest that the behavior of the “ProvisionRequest” operation changes the state of an “advance reservation with explicit provisioning” to an “automatic provisioning” state. This would be beneficial for two reasons: 1. A Requestor NSA can send down a “ProvisioningRequest” operation before “start-time” without receiving an error for issuing the request too early. The Provider NSA would then transition the explicit reservation to an automatic state and start provisioning the connection at “start-time” – “guard-time”. 2. If the Requestor NSA is made aware of the connection provisioning “guard-time” it can issue the “ProvisioningRequest” operation at “start-time” – “guard-time” to get the same behavior as the automatic provisioning case. In both cases the “ProvisionConfirmation” notification, or perhaps a new ActivationConfirmation notification (if we want to keep the other one as ack to the operation itself), would be sent back when the connection is provisioned in the transport plane. “The reservation end-time refers to the time at which the reservation is removed. (If the user has not yet sent a CancelRequest signal the connection is de-provisioned first).” Could we not also use “start-time + duration” to imply “end-time”? ““Infinite” can be used as an end time. In this case, resources are reserved forever (i.e. until a release request is received or may be overwritten by policy limits). ” If we get an infinite duration request and there is an NSA policy specifying a maximum connection duration, why would we not reject the connection request with an appropriate service definition policy error providing the policy maximum? This would allow the requesting NSA to find an alternative route that could support an infinite duration, or at least adjust expectations in a subsequent request. “It takes some time to process a request. Possible maximum time required to process a request and make resources ready for provisioning is called “guard time”.” I thought that “guard-time” also included the transport provisioning/activation overhead as well? This definition seems to only cover the reservation overhead, so a requesting NSA must utilize a different value for the time to provision. “This system is designed to be compatible with systems based on 2PC.” I do not think this statement is 100% true given the example provided. When we modified DRAC to support the Phosphorus/Harmony interface model they also had a two phase commit (reserve/hold resources and commit resources) which also included an explicit activation operation as well. I always questioned the value of commit operation, as it didn’t save us anything in DRAC as the reserve costs the most. I can now see the value if we are trying to do a “start-now” operation but want to make sure an end-to-end path is available before provisioning connections. _Section 5.1.7 Tree and Chain Connection modes for inter-domain pathfinding_ I found this section interesting in that even though I understand general routing, tree, and chain path finding I had to read the section three times and made a ton of notes before concluding that I did understand what was written. I think restructuring this section a bit would solve my problem. This section would benefit from a reference network topology diagram and an example course grained inter-domain path computation somewhere before tree and chain path finding are introduced. Figures 17 and 18 can then reference NSA and nodes from the example diagram to show how a path through the network could be reserved. The general description of chaining needs to be expanded to provide some additional details. I would have expected head-end path computation as the first step to determine a rough path through the network, and to guide the “next hop” to receive the request in the chain. Although a similar statement was made for tree based path finding it was not stated for chain based, although, it may have been implied in the statements around reservation. I am also concerned with this statement: “Alternatively, if the local NSA does not have sufficient topology information or authorization credentials to identify and interact directly with all the downstream networks, the local NSA can simply choose a neighbor network as the next hop, and using the interconnect STP as the ingress point, forward a request to that next hop NSA for handling.” This statement implies to me that I do not need to do head-end path computation and I can just throw the request to any adjacent node and it would magically reach its destination. In a highly connected network this might be a feasible plan, but in other cases there could be a lot of dead end computations before a viable path it found. Lastly, the statement “It is highly distributed, scales well and is robust” could be brought into question given the description of chaining in this section ;-)
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
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
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
participants (3)
-
Jerry Sobieski -
John MacAuley -
John Vollbrecht