All, I need to capture my closing thought on ServiceType before I forget. I didn't want to extend the meeting with this, but I think it is an important point on which we need resolution. From the discussion today I think Jerry views the service description as a template for ranges and population of parameters. I have extended this to also include other aspects such as service level agreement, things not quantifiable in request parameters. I also see it as a great tool for creating customer specific or group specific services. Services that may have specific needs above those of the masses, and specific resources allocated to them. Let me use the example of an ETS.1G service, an ETS.10G service, and an ETS.100G service. All of these are point-to-point Ethernet, use the same <ets> service schema, and the only difference is the maximum capacity specified in the service description template, however, they are semantically different due to their target user base. I should be able to get my point across with the following use cases... Now let us say we have five networks (A through E) participating in the NSI protocol. They all agree to the ETS.1G service, define the service description template, and support the full specification of the agreement. This ETS.1G service description template is communicated to all their users and is a global service offering to the masses. We can also associate service level agreements such as a repair time on failed services of 48 hours. Networks A, B, and C need to offer an low latency ETS.10G service for specific user cases proposed by their user base. Networks A, B, and C all agree to the ETS.10G service, define the service description template, and support the full specification of the agreement. This ETS.10G service description template is communicated to the end users and they restrictions relating to the service offering (i.e. only networks A, B, and C). This specific service has a guarantee of 2 hours to restore services. Finally, Network E has just installed equipment making them 100G capable and want to offer this service to a special group of users within their network. They define an ETS.100G service, define the service description template, and provide to all their users as a local service offering. This is an experimental service and has a best effort service level agreement. Remember that Network E does not offer an ETS.10G service. Use case #1: User Bob in network A wants to connect port A1 to port E1 with a bandwidth of 500 Mb/s. Bob has been given the two service description templates (or equivalent) that his network supports (ETS.1G and ETS.10G). How this is done is beyond the scope of this discussion. Bob sees that both ETS.1G and ETS.10G will meet his bandwidth requirements, however, network E does not support ETS.10G so he must chose the ETS.1G serviceType for his request. Bob issues his request to local NSA A that validates it using ETS.1G, populates any additional parameters required, and then performs path computation. NSA A must exclude any networks not specifically supporting ETS.1G since those NSA will not understand the ETS.1G serviceType, however, in this specific case all do support the serviceType. Discussion: Although the ETS.100G service offered in Network E could theoretically meet the requirement of the ETS.10G service template, they are in fact two different services offerings and must be treated that way. If Network E is capable of providing the ETS.10G service then they should support the common template. Not advertising the template is an indication that they are not willing to meet the specifics of that service, even if the service criteria is covered by another template. For example, they might not be willing to meet the 2 hours guarantee on service restoration. I think that if we consider how these services will be offered by the service providers, the end users will be given a limited set of supported services based on their requirements, where they are interconnecting from, and who they are interconnecting to. They will not need to make these types of complicated decisions. Use case #2: User Fred in network C wants to connect port A2 to port C2 with a bandwidth of 2 Gb/s. Fred has no other option in this case and must use the ETS.10G service offering. The procedure proceeds as it did in user case #1 using NSA C, except the NSA C will need to exclude networks D and E from path computation since they do not offer the ETS.10G service. As mentioned previously, network E does provide an ETS.100G service, but this network must still be excluded because it does not support the ETS.10G service offering. Use case #3: User George in network E wants to connect port E3 to port A3 with a bandwidth of 2 Gb/s. George is out of luck. His local network offers him the ETS.1G and the ETS.100G service (if he has 100GE ports installed locally). No other networks support the ETS.100G service, so when he specifies the request, his local NSA E will determine that there is no valid path between E3 and A3 (in fact, A3 doesn't support ETS.100G so it is an easy decision). Conclusions I think the service description concept is a good one, but I believe it is more than a simple template for parameters and values. I believe it wraps all aspects of a service up into one neat package, and offers a needed layer of abstraction we do not currently have. Networks are excluded from path computation when they do not support the serviceType, and I would go so far as to say we probably need to tag serviceTypes against ports in topology so we can quickly exclude those that are not capable of "possibly" meeting the criteria. John